Reprise du message précédent :
dites, C++ et C99 sont pas compatibles ?
genre mon compilo C++ a l'air de s'étrangler sur :

Bonne question.

Cette syntaxe d'initialisation de structs C99 est pratique mais pas encore très usitée.

Essaye voir avec -std=c++11

Mais si c'est un compilo un peu particulier, càd pas gcc (ou LLVM), c'est pas gagné d'avance. Si je ne dis pas de bêtises (j'ai suivi ça de très loin), C et C++ n'étaient pas gérés par le même comité jusqu'à il y a quelques années, et c'est à partir de C++11 qu'il y a eu une nouvelle itération de C. Avant C11, la norme était C99, et bcp de gens programment encore en C89.

Sinon, au pire, tu remplaces ce code par:

static const struct {
    GPIO_TypeDef *gpio;
    uint16_t xDirection, xStep, yDirection, yStep, zDirection, zStep;
} motorsPinout = {
   GPIOE,
   GPIO_Pin_3,
   GPIO_Pin_4,
   etc };

et ça devrait passer.

comme toute les écoles non?

j'ai explicitement rajouté les trucs pour la lisibilité.
mon GCC fait que -std=c++0x et il a pas l'air d'aimer non plus.
 
Et je me souviens plus du nom de la chose pour googler.

si vous avez des idées
http://stackoverflow.com/questions [...] tantiation

 
tl;dr:  Il fait pas bon bosser en Italie.
 

Nan mais oublie C99, surtout en embarqué, personne connait, et la plupart des compilos ne l'implémentent pas.

le mien l'implémente (arm-none-eabi-g++ (Linaro GCC 4.6-2011.10) 4.6.2), et justement, le fait que je sois tout seul dans mon garage, c'est peut-être l'occasion de re-tester des fondamentaux qui font peur à l'industrie.

Dommage qu'il n'implémente pas C++11. Il faut une 4.8.

ouais, et j'ai un peu la flemme de re-faire une cross compilation, même s'il existait pour ma target

http://www.reddit.com/r/politics/c [...] al/cckwc3u

edit: et masklinn est marrant en anglais

http://www.reddit.com/r/politics/c [...] ch/cclnvpo

comment il s'appelle le mec qui a défini un style pour les classes C++ ? genre il dit que chaque classe doit avoir un constructeur de tel type et un destructeur de tel type ? j'arrive pas à le googler.
 
(c'est un peu la fête du slip quand on google C++)

forme normale de coplien

Je suis le seul à trouver que 39k (sans compter les probables autres avantages) à la sortie de l'école c'est pas mal ?

\o/ Who's your daddy ? \o/

Vachement en retard mais non, c'est pour ça que le refus historique de MS de supporter C99 (et de ne supporter que C++, mal soit dit en passant) fait chier beaucoup de monde (VS2013 semble améliorer un peu la situation et implémenter les compound literals, designated initializers et variable declarations).

Apparemment il y a progrès, et il y a des points de convergence dans les standards, mais ils ne sont quand même pas compatibles.

'tain les relous.

Oui mais c'est de l'auto déclaration, donc faux

bof, c'est le salaire que j'ai eu, hors primes, hors RTT travaillés, en province il y a 5 ans

 
hé bien ça reste beaucoup

 
Voilà. C'était le discours dont on nous bourrait le mou à l'Epita à l'origine et il me semble que l'Epitech au début pratiquait pas la même forme d'enfumage.
Le seul truc on ils ont été honnêtes avec nous c'était de dire d'entrée que le jeu vidéo payait mal.

sauf si c'est chez valves au usa

 
Y'a toujours des outliers dans toutes les promos de toutes les écoles, ça change pas le tableau général.

 
Ça ne fait effectivement pas partie du C++, quelle que soit la version considérée.  Il me semble que clang l'a en tant qu'extension.
 

 
Les comités sont toujours différents.  Il y a toujours (et toujours eu) des gens impliqués dans les deux et faisant la liaison et désirant éviter les divergences.  Il y a toujours (et toujours eu) des gens que l'aspect compatibilité préoccupe peu (enfin, pour certains on peu se demander si leur préoccupation n'est pas d'introduire des incompatibilités gratuites).
 

 
Coplien pour celle-là, Sutter et Meyer ont aussi popularisé ce genre de règles.  Coplien ne s'occupe plus visiblement de C++ et ses bouquins sont très datés.  Sutter et Meyer sont toujours actifs et leurs derniers bouquins sont toujours dans la ligne popularisation de l'état de l'art.

j'en ai conscience, c'est ironique

moscovici qui se tape une bonnasse de 25 ans, il ne se fait pas chier...

hey mec, il a été parachuté à Montbéliard pendant 15ans, je crois qu'il a le droit à un break

tu serais chaud pour un one to one sur C++ ?
J'ai des messages d'erreurs incohérents entre l'IDE (qui visiblement utilise clang) et g++

Bah sur les salaires si quand meme
Après on est pas encore au niveau de l'Epita, ou ils ont declares recemment qu'ils ne voulaient plus faire de technique
 

Mais c'est de l'amooooouuuuuuuuur  

j'ai essayé de condenser :

j'ai 2 pb.
1) le void * il aime pas, si je joue avec des int ça passe, mais sinon il me dit 'constexpr' needed for in-class initialization of static data member 'port' of non-integral type  
Ce qui est très intéressant vu que void * ça a une bonne tête d'entier.
2) j'aimerai forcer le paramètre GPIOPORT_T de GPIOPin à être un GPIOPort (composition de types au lieu de composition d'instance), comment je peux faire ?

 
Mais ce n'en est pas un formellement.  Il y a un désir de pouvoir faire ce genre de choses, mais autoriser que ce qui est sensé sans s'imposer de résoudre les constantes au link ou pire au load n'est apparemment pas facile.  Le work around classique:

 
En attendant Godot (je veux dire les concepts), il faut se battre un peu contre le langage (ou utiliser une lib qui a déjà gagné la bataille, boost p.e.)
mais quand il ne s'agit pas de diriger des surcharges, je n'en vois pas particulièrement l'intérêt.  C'est quoi le problème que tu cherches à résoudre?

1) bon tant pis, c'est ce que j'avais fait intuitivement.

2) l'idée c'est d'attraper plus d'erreurs des utilisateurs de la lib. En gros j'aimerai être à peu près capable de décrire statiquement le matos du MCU. Y'a des caïds du C++ qui pensent qu'un certain nombre de propriétés sont vérifiables statiquement et typés correctement.

edit: ma première idée c'est d'arriver à tout décrire statiquement, puis à l'usage de revenir à un ratio statique/dynamique plus raisonnable. Mais un petit coup d'extrémisme peut être assez formateur. Un peu comme quand on apprend à tout écrire sans if en objet, après on remet des if.

 
Si l'idée c'est de contraindre les paires GPIO/PIN valides, je crois que je me serais contenté d'un palanquée de constantes de la forme GPIO_A_PIN_1 dans un enum et d'un "int read(GPIO_PIN gpio_pin);" L'existence ou non d'une constante avec le nom attendu suffit à maintenir la contrainte statiquement.

 
La question est "en quoi utiliser un autre type fournissant les mêmes choses est une erreur?" Le typage des templates est du duck typing.
 
Sinon, pour être plus précis dans ma référence à boost, Boost Concept Check http://www.boost.org/doc/libs/1_54 [...] _check.htm et Type Traits http://www.boost.org/doc/libs/1_54 [...] index.html devrait te permettre d'éviter le détour pour apprendre ces arcanes du C++.

nan, mais après chaque pin a une configuration (en lecture digitale, lecture analogique, en écriture, polarité etc.) je voulais un objet pour les représenter.

je vais mater boost, si c'est juste un truc de templates qui n'instancie rien en mémoire au runtime, ça m'intéresse.

 
Ces aspects devraient l'être.

Plus c'est gros, plus ca passe ?  

 
Et si c'est le routeur qui a eu un accident de voiture hein ?