Discussion :

[Sytten]

Oulala VDHL lisible
J'en fais dans mes cours d'électronique et c'est tout sauf lisible/simple quand ça commence à devenir le moindrement complexe.

D'ailleurs ce n'est pas du tout pour la même utilisation.
On ne peut pas comparer un langage généraliste pour CPU (nécessairement peu parallélisé) avec un langage de logique séquentielle/combinatoire.
Par contre, je ne dirais pas que c'est vraiment plus bas niveau que le C++ ou le C, c'est juste différent (En fait c'est un peu plus bas à cause du timing, mais c'est pas mal géré automatiquement de nos jours).
Le VHDL/verilog c'est bien pour générer des trucs qui doivent travailler en parallèle massivement comme des décodeurs ou des traiteurs d'informations, pas pour créer des UI^^

Au niveau des contraintes matérielles comme il a été mentionné plus bas il faut un FPGA, par contre dans le futur je dois avouer que cela risque de devenir plus commun (voir le récent rachat de Intel).
Ils vont probablement être embeded dans les processeurs pour des tâches dédiées, un peu comme les chips dédiées au calcul flottant.
Par contre, ils vont devoir créer de nouveaux langages. Si le mec pense pouvoir compétitionner swift avec du Verilog, il est juste pas bien dans la tête

[Firwen]

Ce type me fait surtout penser à un dinosaure du fortran qui n'a jamais accepté la transition vers le C.
Avec un poil de haine pour la programmation fonctionnelle au passage.
Présenter VHDL, Verilog ou fortran comme des modèles de simplicité en 2016, il faut quand même oser.

là où le bât blesse , c'est que le C++ moderne (C++14, C++17, C++19, C++22 et le brouillon C++11) en est rempli: exemple, unique_ptr, weak_ptr, auto_ptr...

Tous les experts C++ tendent à s'accorder qu'utiliser les templates de la STL n'a rien de répréhensible ni de controversé, même Google dans ses guidelines.

C'est quand on commence à abuser des patterns à la SFINAE que les problèmes apparaissent.
Il y a une grosse différence en terme de complexité entre utiliser un simple std::vector ou un std::unique_ptr...... et venir pondre quelque-chose comme Boost.Lamda.

C++ est et a toujours été une toolbox multi-paradigme géante: il t'offre tout, libre à toi d'utiliser ce que tu veux ou pas

Une perte de performance : selon lui, le C++ moderne intègre une potentielle perte de performance à cause des structures qui deviennent de plus en plus complexes et qui sont passées au compilateur. « C’est ici que Fortran excelle »

De nos jour il n'y a aucune différence en terme de performance entre un code C++ optimisé et un code fortran optimisé. Ça a déjà été analyse mainte et mainte fois dans la littérature.

Et comme avec tous les langages de haut niveau, certaines fonctionnalités bien précises ont un coût en terme de performance si tu les utilises.

La maintenance : citant Edger Djikstra, un mathématicien et informaticien néerlandais du XXᵉ siècle, qui a déclaré que « la simplicité est une condition préalable à la fiabilité »

Un mauvais code est toujours difficile a maintenir, quel que soit le langage.
C'est pour ça qu'on a créer les coding guidelines et les reviews.

Syntaxiquement, C++ n'est pas plus dur à appréhender que Java ou C#. Seul la méta-programmation peut l’être.
Et c'est précisément pour ça que des boites comme Google l'interdise ou en réduise la portée.

Les temps de compilation : Il affirme que les templates augmentent de façon significative le temps de compilation à cause de la recompilation d’un plus grand nombre de fichiers impliqués.

Le seul argument sur lequel je suis d'accord: les temps de compilation C++ sont long. Ceci dit, les modules C++ devrait à l'avenir améliorer ça normalement.

Petite remarque: dans les stats, C++ paye mieux que Java, au moins aux États-Unis.

Et c'est normal.
La learning curve de C++ étant beaucoup plus longue que celle de Java.
Plus le fait que, malheureusement, les personnes qui apprennent un C++ correct à l'école ne sont pas légions.

[Stephane7]

Bonjour à tous, je suis interressé par le C++ mais vu les critiques qu'il porte, je voudrais connaitre quel langage corrige ses défauts pour me lancer dans l'apprentissage de ce langage.
Merci d'avance, salut!

[pumbaOfJungle]

Je ne remets pas en cause ses arguments, le gars à l'air de s'y connaître vachement plus que moi.

Toutefois, je mettrais en exergue que le dit-gars parle de domaines très pointus (trading hyper fréquence, communication à très (très haut débit)), qui ne correspondent pas à l'utilisation du C++ que doivent faire 99% des développeurs dans ce langage.

Effectivement j'imagine qu'un programme écrit dans un langage "générique" exécuté sur du matériel "générique" (CPU et GPU) ne permet pas de suivre le rythme qu'un développement "matériel" (fpga) spécifique aura.

Heu, c'est pas un peu une évidence ça ?

[Artemus24]

Salut à tous.

L'opinion d'une seule personne ne fait pas une vérité !

Pourquoi choisir le langage C++ pour cette activité professionnelle ?
Est-ce à cause des applications existantes et qui par la suite, on n'a pas voulu se remettre en question ?

Est-ce que cette personne sait correctement exploiter ce langage dans son contexte professionnel, voire dans la culture de son entreprise ?
Je doute fortement que cette personne possède toutes les qualités pour bien développer en C++ !!!
Il se peut aussi qu'il n'a pas le temps de s'y investir, voire même qu'il n'a plus du tout l'envie de le faire.

Le C++ n'est pas responsable des erreur stratégique de la part de l'entreprise.
Et cela ne vient en aucune façon remettre en cause les qualité de ce langage.
Mais venir le comparer à du fortran, c'est un peu trop facile comme argument.

J'ai déjà vu des usines à gaz où l'on critiquait fortement un langage comme le COBOL.
J'ai surtout constaté que la personne qui développait, n'avait pas les compétences requises !

De toute évidence, ce monsieur a besoin d'un système embarqué pour faire du temps réel pour ses traitements très particulier.

Je trouve la critique un peu radicale même si c'est vrai que le C++ est un peu une usine à gaz.

Votre argument est faux ! Le C++ n'est pas une usine à gaz.
Je reconnais que ce langage n'est pas facile à maitriser pour des débutants.
Mais pour cela, il vous faut les compétences requises. Et puis, ce langage n'a rien à voir avec du 'C' !!!

On comprend mieux en lisant le billet original car son argument est surtout pourquoi passer un temps fou à essayer de devenir un gourou du C++, alors qu'en terme de perf le passage à des technos à base de fpga est beaucoup plus intéressant.

C'est ce que je dis ci-dessus. C'est une erreur stratégique de l'entreprise qui ne remet en aucune façon les excellentes qualités de ce langage.

d'autant plus quand il s'agit du trading haute fréquence (qui est assez... particulier quand même).

Erreur stratégique de l'entreprise !

Un langage spécialisé sera toujours plus simple et efficace qu'un langage généraliste. Ca ne veut pas dire que les langages généralistes ont fait leur temps. Enfin, je ne pense pas.

Je suis du même avis que toi. Si on se trompe de langage pour faire un développement particulier, ce n'est pas le langage qui est en cause.

C'est l'une des raisons qui m'a poussé à abandonné complètement le c++ il y'a quelques années déjà.

Tout dépend de ce que tu désires faire avec le C++. Si c'est pour développer un site web, il n'est pas le plus adapté à cela.

La maîtrise du C++ oblige à en comprendre tous les rouages. L'apprentissage du C++ est de plus en plus long.

Entièrement d'accord avec toi.

Et le fortran ou le C ne font pas mieux, peut-être un nouveau langage de bas niveau mieux adapté au multi-processing?

Arrêtez de comparer des choses qui ne sont pas comparables ! Avez-vous déjà fait du multi-processing avec du fortan ????
Non, car le fortran qui date des années 1960 ne sait pas faire cela.

par exemple le fait que deux variables ne désignent pas le même objet en fortran (par définition) permet de meilleures optimisations.

La notion d'objet n'existe pas en fortran. C'est par l'usage de "common" en fortran que l'on peut associer deux noms de variables à la zone de mémoire.
--> http://fortran.developpez.com/faq/?page=section8#common

bah oui, 99% des machines sont programmées en série, ou part fils d'exécutions série exécutés en parallèle (genre GPU).

C'est quoi ce charabia ???
Avez-vous au moins la connaissance de ce qu'est [url=https://fr.wikipedia.org/wiki/Machine_de_Turing]la machine de Turing(/url] ? A priori non.
Tous les ordinateurs fonctionnent selon ce principe, c'est à dire séquentiellement. Donc la réponse est 100% !!!
Si votre ordinateurs possèdent plusieurs coeurs, voire plusieurs processeurs, cela ne remet pas en cause le principe de la machine de Turing.

C++ ne peut plus être utilisé parce qu’il est intrinsèquement en série, même dans des systèmes massivement multithread comme les GPU

C'est sûr, que ce n'est pas avec le langage de base du C++ que l'on peut faire cela.
Ce sont des API incluent dans la langage C++, qui permettent de découper votre application en tâches pouvant s'exécuter en parallèle.
Faut-il encore connaitre ces techniques de développement avant de dire que le C++ ne peut pas le faire.

@+

[boumchalet]

Je pense qu'on fait un mauvais procès au C++
Je suis architecte en informatique, et je code et je conseille des équipes en C# , JAVA J2EE, Pyhton, et en C++ , Qt , ...
Pour moi le C++ est le seule langage qui permet de partiquer :
- le multi paradigme : programation fonctionelle, DSL, conception objet, meta programation , générique ....
- d'avoir un niveau d'abstraction tres eleves (Le programmes sont plus court par rapport à Java ) et de pouvoir optimiser l'exuction
- il est vraiment universelle : je ne connnais pas une machine sans un compilateur C++, je recompile des fichiers sources de 30 ans
- Optimisation est sans limite
Par contre :
- ce langage étant universelle => apprentissage difficile
- beaucoup de liberte -> beaucoup de pieges

Il est possible d'aider une équipe de codeur C++ en n'utilisant que les concepts de Java, pour simplifier l'utilisation du langage C++ :
-> pas d'écriture de template par l'équipe , ou tres limite
-> utilisation obligatoire de
- auto, utilisation des shared_ptr et des unique_ptr , ...
- pas de delete ou de new dans le programmes
- pas d'heritage multiple
- pas de passage de pointeur, etc

Il manque au langage :
- Les proprietes, introspection, les packages, programmation par aspect...

[Bestel74]

- pas de delete ou de new dans le programmes
- pas d'heritage multiple
- pas de passage de pointeur, etc

Peut-on vraiment faire un programme sans tout ça ? Sans même passer l'adresse d'une variable à une fonction ?

[dragonjoker59]

Ben oui on peut...
Si les références ne sont pas interdites (ce qui serait idiot, en C++).

[oodini]

Ben oui on peut...
Si les références ne sont pas interdites (ce qui serait idiot, en C++).

Pour désigner une valeur "vide" ou invalide, les pointeurs font tout de même mieux l'affaire que des références.

[Ehonn]

Pour désigner une valeur "vide" ou invalide, les pointeurs font tout de même mieux l'affaire que des références.

Oui. Mais à titre personnel, je préfère std::optional ou équivalent.

[JolyLoic]

On peut très bien. C'est ce que je fais dans la majorité de mon code :
- Pas de new/delete : à remplacer par vector, make_unique, make_shared...
- Pas d'héritage multiple : Je suis peu en phase avec ce point de vue, mais je comprend très bien qu'il puisse avoir de l'intérêt avec des développeurs Java
- Pas de passage par pointeur : Les références sont plus simples et moins risquées à manipuler, et c'est ce qu'un développeur Java manipule par défaut même s'il ne le sait pas.


Sinon, par rapport à l'avis que j'ai vu plusieurs fois dans le thread, comme quoi l'augmentation de taille du C++ le rend toujours plus difficile à maîtriser : Je suis à la fois d'accord et pas d'accord avec ça. Certes, connaître l'ensemble du langage deviens de plus en plus complexe et long. Mais, et ça va dans le même sens que la réponse précédente, je trouve que le sous-ensemble minimal à connaître pour commencer de manière autonome (sans bien évidemment être un expert) a lui tendance à diminuer, ce qui est une bonne chose.

[Chauve souris]

Il me semble (il y a longtemps que je n'ai pas touché à ce langage) que le C++ (ou le C) reste incontournable pour la vitesse de l'éxécutable, en particulier dans les jeux. Ca reste toujours vrai ou bien on utilise autre chose ? Il est clair que pour des applis où le temps dépend des doigts des utilisateurs (bureautique, base de données) ou de l'accès loooong au disque dur, d'autres langages, dits de haut niveau, sont plus aisément utilisables.

Relecture du code. Là aussi si les classes et les fonctions sont bien documentées ça ne devrait pas être un souci. Mais la documentation est une part de temps que ne se donnent pas les développeurs à la bourre, si je peux me permettre ce quasi pléonasme.

[VivienD]

Il est possible d'aider une équipe de codeur C++ en n'utilisant que les concepts de Java, pour simplifier l'utilisation du langage C++ :
-> pas d'écriture de template par l'équipe , ou tres limite
-> utilisation obligatoire de
- auto, utilisation des shared_ptr et des unique_ptr , ...
- pas de delete ou de new dans le programmes
- pas d'heritage multiple
- pas de passage de pointeur, etc.

Je trouve que c'est dommage de faire l'impasse sur l'héritage multiple, vu que ce concept (appartenant pourtant à la programmation orienté objet) n'est pris en charge que par relativement peu de langages. Toutefois, je comprends tout à fait que les éventuelles complications que cela engendre peuvent rebuter au point qu'on ne s'en sert qu'en dernier recours.

En revanche, je ne suis en aucun cas familier avec les pointeur intelligent; je ne m'en sers, pour ainsi dire, jamais. Peut-être ai-je tort. Je me demande s'il est possible de réécrire une fonction comme int str2int(std::string str, bool * ok = nullptr) (*) avec des pointeurs intelligents. Des avis sur la question?

Il manque au langage :
- Les proprietes, introspection, les packages, programmation par aspect...

Euh... Là, je dois avouer que je n'ai rien compris à partir du deux-points, sauf la notion de propriétés, peut-être...

(*) Je sais que c'est un exemple bateau mais je manquais d'inspiration...

[mintho carmo]

Je trouve que c'est dommage de faire l'impasse sur l'héritage multiple, vu que ce concept (appartenant pourtant à la programmation orienté objet) n'est pris en charge que par relativement peu de langages.

Le probleme est surtout que beaucoup ne savent respectent pas le LSP (Liskov substitution principle) sur un héritage simple. Du coup, l’héritage multiple est encore plus souvent mal utilisé que l’héritage simple. D’où la règle implicite d’éviter l’héritage multiple. Mais l’idée est surtout de vouloir éviter les mauvaises utilisations de l’héritage (simple et multiple).

Je me demande s'il est possible de réécrire une fonction comme int str2int(std::string str, bool * ok = nullptr) (*) avec des pointeurs intelligents. Des avis sur la question?

La fonction n'est pas propriétaire du bool, donc pas de unique_ptr ou shared_ptr. De plus ce paramètre est optionnel, donc pas de référence non plus (ou reference_wrapper). L'utilisation de weak_ptr serait abusif (compteur atomique, besoin de lock), surtout que le bool n'est pas obligatoirement managé par un shared_ptr (ca sera souvent une variable locale).

En termes de sémantique, ça serait une référence optionnelle. Du coup, ca peut être un std::optionnal<std::reference_wrapper<bool>>. Mais c'est un peu lourd...
Le pointeur nul est probablement le mieux ici. Cela correspond a un usage accepté (plus ou moins...) : celui de weak pointeur sans compteur de référence (l’équivalent de weak_ptr mais sans shared_ptr). Mais il faut respecter 2 contraintes :

- considérer qu'un pointeur nu ne transmet pas l'ownership (donc interdit de faire un delete sur un pointeur nu que l'on reçoit. Sauf si c'est explicitement indique que l'on transmet l'ownership, par exemple avec owner<T>)
- éviter de jouer au con... on s'amuse pas par exemple a appeler cette fonction dans un thread. Ou sur un pointeur qui peut être invalide (dangling).

Ce type de fonction ne doit être appelée que sur un bool local, pour éviter les problèmes d'ownership ou de lifetime.

Une autre solution est une surcharge :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int str2int(std::string str, bool & ok)
int str2int(std::string str)

C'est plus lourd a implémenter (bien que la seconde fonction peut appeler la première), mais comme le bool n'est plus optionnel, on peut utiliser une référence. C'est probablement le plus safe.

Donc non le C++ est pas dépassé pour l'instant le seul truc qui manque c de pouvoir avoir un garbage collector optionnel intégré au langage et de l'introspection.

J'aime beaucoup l’idée que le GC soit devenu avec le temps un but a chercher et plus un moyen de résoudre un probleme. Comme si le GC était la seule solution a la problématique qu'il essaie (plus ou moins bien...) de résoudre.

La problématique est la gestion manuelle de la mémoire. Et le C++ a des outils pour gérer cela. En premier lieu les variables locales, qui sont automatiquement libérées a la fin de leur portée. Et surtout le RAII.
(Et accessoirement, le C++ propose le support des GC http://en.cppreference.com/w/cpp/mem...lector_support ... mais on va éviter de trop en parler, les gens pourraient être tentés de l'utiliser).

(@VivienD: ne pas connaitre les pointeurs intelligents n'est pas forcement problématique. Par contre, ne pas connaitre le RAII serait problématique. Et les pointeurs intelligents ne sont qu'une application du RAII. Du coup, le probleme avec les gens qui ne connaissent pas les pointeurs intelligents est surtout qu'en général ils savent pas utiliser le RAII et ne savent pas gérer correctement les ressources. Si on ne peut pas utiliser les pointeurs intelligents dans un contexte donnée, mais que l'on gère correctement les ressources, pas de probleme).

Pour l'introspection, mouais... Le probleme est que c'est une solution de facilité utilisée dans d'autres langages. Et du coup, certains veulent l'utiliser aussi en C++, pour "faire la même chose", même lorsque c'est une mauvaise approche et/ou qu'il existe d'autres approches valides en C++.

[boero-teyssier Greg]

En revanche, je ne suis en aucun cas familier avec les pointeur intelligent; je ne m'en sers, pour ainsi dire, jamais. Peut-être ai-je tort. Je me demande s'il est possible de réécrire une fonction comme int str2int(std::string str, bool * ok = nullptr) (*) avec des pointeurs intelligents. Des avis sur la question?


Euh... Là, je dois avouer que je n'ai rien compris à partir du deux-points, sauf la notion de propriétés, peut-être...

(*) Je sais que c'est un exemple bateau mais je manquais d'inspiration...

La fonction n'est pas propriétaire du bool, donc pas de unique_ptr ou shared_ptr. De plus ce paramètre est optionnel, donc pas de référence non plus (ou reference_wrapper). L'utilisation de weak_ptr serait abusif (compteur atomique, besoin de lock), surtout que le bool n'est pas obligatoirement managé par un shared_ptr (ca sera souvent une variable locale).

En termes de sémantique, ça serait une référence optionnelle. Du coup, ca peut être un std::optionnal<std::reference_wrapper<bool>>. Mais c'est un peu lourd...
Le pointeur nul est probablement le mieux ici. Cela correspond a un usage accepté (plus ou moins...) : celui de weak pointeur sans compteur de référence (l’équivalent de weak_ptr mais sans shared_ptr). Mais il faut respecter 2 contraintes :

- considérer qu'un pointeur nu ne transmet pas l'ownership (donc interdit de faire un delete sur un pointeur nu que l'on reçoit. Sauf si c'est explicitement indique que l'on transmet l'ownership, par exemple avec owner<T>)
- éviter de jouer au con... on s'amuse pas par exemple a appeler cette fonction dans un thread. Ou sur un pointeur qui peut être invalide (dangling).

Ce type de fonction ne doit être appelée que sur un bool local, pour éviter les problèmes d'ownership ou de lifetime.

Une autre solution est une surcharge :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int str2int(std::string str, bool & ok)
int str2int(std::string str)

C'est plus lourd a implémenter (bien que la seconde fonction peut appeler la première), mais comme le bool n'est plus optionnel, on peut utiliser une référence. C'est probablement le plus safe.

ici il faut peut-être revoir la façon d'on on a construis la fonction on peut implantée comme sa :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 std::optional<int> str2int(std::string & str)
{
  code pour la transformation et si sa ne marche pas juste faire un return    
}

puis a l'utilisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
auto myInt = str2int(aString);
if (myInt){
le int est valide 
}

en ce qui consterne les propriétés il faudra attendre le pour le c++17 voir c++22 pour la surcharge de l’opérateur dot une construction et une utilisation généralisée.

L'introspection peut être utile dans certains cas mais actuellement elle consomme trop de ressource pour être intégrée au langage.

Les package avec un vrai système d'importation à la java (avec import) serait un véritable bond en avant pour le lagunage.

et il ne faut pas oubliée la notion de Concept qui a était retirée de c++17 qui devaient être une grosse évolution pour le c++
avec tout ça que je ne pence pas que le c++ a atteint ses limites, loin de la

[dragonjoker59]

Moi je ne vois pas l'introspection comme un manque, mais comme une force.
Au moins on est obligés de concevoir nos applications correctement (dur dur...)
Non mais sérieusement, qui peut avoir besoin de cette infâmie? (mis à part les GUI, et encore...)

[mintho carmo]

ici il faut peut-être revoir la façon d'on on a construis la fonction on peut implantée comme sa :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 std::optional<int> str2int(std::string & str)
{
  code pour la transformation et si sa ne marche pas juste faire un return    
}

+1024. Je suis stupide de ne pas avoir parlé de cette écriture, c'est pourtant celle qui est justement donnée dans le draft de std::optional comme exemple d'utilisation

Moi je ne vois pas l'introspection comme un manque, mais comme une force.
Au moins on est obligés de concevoir nos applications correctement (dur dur...)
Non mais sérieusement, qui peut avoir besoin de cette infâmie? (mis à part les GUI, et encore...)

Un des use-cases classiques est l’interfaçage avec des langages de script.

Par contre, personne n'a parlé de la standardisation de l'ABI ? C'est pourtant quelque chose qui est très préjudiciable au C++ (en particulier parce que tous les autres langages qui permettent d’écrire des modules natifs pour les performances, doivent passer par le C et pas le C++, a cause de l'ABI).

[VivienD]

Si j'ai bien compris vos réponses, la fonction int str2int(std::string str, bool * ok = nullptr), ou mieux int str2int(std::string const & str, bool * ok = nullptr), ne peut décemment pas être réécrit avec des pointeurs intelligents, du fait qu'on n'alloue aucune zone de la mémoire vive à l'aide de l'opérateur new car cet argument est généralement une variable locale et que la fonction n'a pas vocation de la libérer à coup de delete dans quelque cas que ce soit. Toutefois, elle pourra être réimplémentée dès C++17 grâce à l'arrivée de std::optional; elle deviendra alors std::optional< int > str2int(std::string const & str).

Je me demande s'il est possible de réécrire une fonction comme int str2int(std::string str, bool * ok = nullptr) (*) avec des pointeurs intelligents. Des avis sur la question?

Justement, le mécanisme d'exceptions est prévu pour ce genre de cas : le code appelant sera beaucoup plus léger qu'une vérification de ce pointeur… Ce genre de code me rappelle beaucoup trop le C .

[...]

J'ai appris le C avant le C++; j'en ai gardé quelques (mauvaises?) habitudes. En revanche, les fonctions-membres de QByteArray et QString qui permettent ce genre de conversion ont aussi l'argument booléen optionnel bool * ok = nullptr, à moins que ce soit bool * ok = 0. Comme quoi!

Quant à l'introspection, je pense avoir compris que cela permet de connaître la classe ou le type d'un objet ou d'une variable ainsi que d'observer les relations entre les classes (héritage, entre autres). Il me semble que c'est possible de faire grâce aux templates, à la SFINAE et à l'opérateur decltype; d'autant plus que la STL nous fournit pas mal de classes et d'outils pour nous faciliter la vie. Néanmoins, je trouve que c'est dommage qu'autant de classes soient regroupées dans l'en-tête type_traits.

En ce qui concerne les packages, ne peut-on pas émuler ce mécanisme de modularisation au travers des espaces de nommages et des en-têtes qu'on «importerait» tout bêtement avec #include?

Ne manquent plus que les propriétés et la programmation par aspect. Toutefois, si la notion de propriétés est le mécanisme qu'émule la macro Q_PROPERTY de la bibliothèque Qt, je pense avoir compris le délire.

[Pyramidev]

dès C++17 grâce à l'arrivée de std::optional; elle deviendra alors std::optional< int > str2int(std::string const & str).

En attendant C++17, on peut déjà utiliser boost::optional :
http://www.boost.org/doc/libs/1_60_0...tml/index.html

[Bousk]

J'utilise std::unique_ptr comme alternative à std::optional pour l'instant par moment.