Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le draft de la prochaine norme C++14 est disponible
Le résumé des nouvelles fonctionnalités par germinolegrand

Le , par Community Management

0PARTAGES

15  0 
C++14 est la prochaine norme prévue pour le C++ en 2014, ce depuis l'annonce du planning en novembre 2012.

La norme C++14 ne sera qu'une modification mineure du langage, visant essentiellement à combler les défauts et les lacunes de la norme C++11 (avec tout de même quelques ajouts de fonctionnalités). Aussi ne contient-elle pas de modifications majeures du langage, pour lesquelles il faudra attendre C++17.

Le nouveau draft est consultable au format PDF sur isocpp.org : N3690.pdf.

Il a été approuvé lors du meeting de Bristol durant laquelle les membres du comité ont voté un à un les ajouts faits à ce CD (Committee Draft).

Les derniers ajouts votés sont notamment :


Et maintenant ? Le CD va maintenant passer au ballotage des NB (National Bodies, soit les représentants nationaux) qui durera trois mois.

Le prochain meeting aura lieu fin septembre à Chicago, où si tout se passe bien le CD deviendra un Draft International Standard (DIS), autrement dit le brouillon du prochain standard. Après le DIS vient le ballotage du JTC qui durera 5 mois, puis 2 mois supplémentaires si le ballotage est approuvé, ce qui conduit à la signature de l'International Standard (IS), prévue en été 2014. En cas d'échec lors d'une de ces étapes il sera nécessaire de produire un nouveau CD, ce qui repousse à fin 2014 voir plus loin la signature de l'IS final.

En parallèle se poursuivent les Technical Specifications (TS - filesystem, networking, concurrency, etc.) et les proposals pour C++1y qui sera cette fois une nouvelle version majeure du langage comme C++11 l'a été pour C++98.

Votre opinion
Suivez-vous avec intérêt l'évolution du C++ ?
Les ajouts votés vous paraissent-t-ils intéressants ?

Sources
isocpp.org - le draft C++14
isocpp.org - rapport du meeting
Commentaire de M. Wong
isocpp.org - ISO/IEC JTC1 Procedures

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Klaim
Membre expert https://www.developpez.com
Le 18/05/2013 à 13:38
Citation Envoyé par iksess Voir le message
Personnellement, je suis bien peu intéressé par les évolutions de la STL. Celle des compilateurs, un peu plus, mais entre Qt et Boost, pourquoi utiliser encore la STL qui a tant de retard...
Parceque c'est la seule bibliotheque qui est garantiee d'etre toujours dispo, toujours implementee par tous les compilateur C++ qui declarent etre suivre le standard.

Peu importe le language, aucune autre bibliotheque que la bibliotheque standard du language ne peut donner des garanties de portabilite et de stabilite d'interface aussi forte.

Quand quelque chose devient officillement standard (et non de-facto standard), tu sais que ca va pas bouger pendant tres longtemps et que t'y auras acces quel que soit ton compilateur; contrairement a quand quelque chose est un standard "de-facto", ce qui veut dire que c'est beaucoup utiliser.

Boost.Filesystem est pas encore standard et a subit pas mal de gros changements de l'interface et du comportement. Et je parle meme pas de Boost.Thread. Les deux sont devenu standard mais leur interface diferrent dans les details de la version boost.
Boost reste un bon indice de ce qui pourrait devenir standard. Mais ca reste different d'un standard. C'est plus ou moins un label de qualite.
7  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 18/05/2013 à 20:28
Citation Envoyé par germinolegrand Voir le message
Le draft de la prochaine norme C++14 est disponible !
sous le doux nom de N3690
Juste pour préciser pour ceux qui ne suivent pas de très près le processus, le draft est le document de travail courant qui est remis à jour après chaque réunion. Ce qui fait de cette version une version un peu particulière c'est que ce draft part en relecture finale pour la version C++14 de la norme. Il ne devrait plus y avoir de nouveautés ajoutées, seulement des corrections apportées, à la demande d'un pays membre de l'ISO. Ce qui signifie entre autres que les fabricants de compilateurs ont désormais une vision assez claire de ce qu'ils doivent faire, et peuvent commencer à implémenter le C++14 sans trop de craintes.
Citation Envoyé par germinolegrand Voir le message

Il a été approuvé lors du meeting de Bristol durant laquelle les membres du comité ont voté un à un les ajouts faits à ce CD (Committee Draft).
Par rapport au C++ 11, il y a eu d'autres ajouts que ceux faits à Bristol, dans des réunions précédentes, mais ce qui n'a pas été ajouté là devra attendre le prochain train (C++17, selon les plans)
Citation Envoyé par germinolegrand Voir le message


En parallèle se poursuivent les Technical Specifications (TS - filesystem, networking, concurrency, etc.) et les proposals pour C++1y qui sera cette fois une nouvelle version majeure du langage comme C++11 l'a été pour C++98.
Les TS sont une nouveauté par rapport à la dernière version du langage. L'objectif est d'accélérer à la fois le rythme de sortie de la norme, et la quantité de changements qu'il y aura dedans. On doit trouver un équilibre entre plusieurs points de vus contradictoires mais valables :
- Quelque-chose dans la norme est très difficile à retirer par la suite, donc ce qui va dans la norme doit être solide et éprouvé
- Beaucoup d'implémentations sont frileuse à travailler sur des fonctions qui n'ont pas été normalisées, de peur de devoir refaire leur travail si elles évoluent, ou de le jeter si elles ne passent pas.
- Comme on tente désormais d'être date-driven pour les sorties de version de la norme, il serait dommage de voir une fonctionnalité importante manquer à 1 mois prêt. Et il serait dommage pour la même raison de voir quelquechose de pas fini accepté de manière prématurée.

Ces TS ont donc pour objectif de fournir des documents officiels, sortant à la date qu'ils veulent, sans corrélation avec les dates du standard, assez solide pour encourager les gens à les implémenter, mais assez souple pour pouvoir être encore modifiés avant l'introduction définitive dans une norme.

L'avenir nous dira ce que ce numéro d'équilibriste donne.
6  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 18/05/2013 à 21:18
Citation Envoyé par Neckara  Voir le message
Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins)

C'est un sujet très difficile à définir, et qui touche à des aspects que la norme ignore sciemment aujourd'hui (compatibilité binaire...). Le seul papier que j'ai vu sur le sujet était déjà ancien, assez vague, et supposait les modules acceptés dans la langage.
Citation Envoyé par Neckara  Voir le message
ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur

Le groupe de travail sur le réseau a probablement des projets de ce type en vue.
Citation Envoyé par Neckara  Voir le message
, accéder à des bases de données en renseignant le pilote à utiliser, etc.

C'est là aussi un sujet complexe et difficile. A Bristol a été décidée la création d'un groupe de travail sur le sujet. Mais mon opinion est qu'aujourd'hui, il manque encore de monde pour travailler sur le sujet, que ce soit en taille pure du groupe de travail, ou par sa composition qui ne regroupe pas assez d'acteurs importants du marché à mon goût.

Citation Envoyé par Lynix  Voir le message
Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if

Il n'y aura pas de static_if pour 2014, et j'espère fortement qu'il n'y en aura pas pour 2017. Ou du moins que s'il y en a, qu'il sera assez bridé pour en rendre sont utilisation moins dangereuse.
Citation Envoyé par jmnicolas  Voir le message

Vu qu'ils ont mis 8 ans pour sortir la précédente révision on peut estimer que C++14 s’appellera C++19, voir C++2x

La situation est assez différente, C++11 était gouverné par les fonctionnalités, avec l'idée d'une norme par décennie au mieux, avec donc la volonté de ne pas s’arrêter avant d'avoir mis dedans "ce qu'il fallait". Désormais, on travaille plus en mode dirigé par le planning, avec des dates de sortie fixées à l'avance.

De plus, en terme d'étapes, pour C++11, il n'y a eu aucun retard à partir du moment où le draft a été publié pour validation par les pays (c'est avant d'arriver à ce draft que les retards se sont accumulés). Or, on vient d'atteindre précisément cette étape pour le C++14, donc je dirais que pour l'instant, tout est sur les rails.
Citation Envoyé par Gugelhupf  Voir le message
Pour ma part j'attends plutôt des concepts qui simplifient le développement, ou rend le code source multiplateforme comme :
[LIST][*]les modules ! (l'équivalent des package/import en Java ou namespace/using en C#).

Moi aussi je les attends. Et beaucoup de monde les attendent. Doug Gregor en a implémenté une version préliminaire pour Clang, et avait l'air de dire que cette version était dans un état assez avancé pour qu'une nouvelle proposition puisse voir le jour prochainement. J'ai entendu d'autres membres du commité dire que s'il y avait une fonctionnalité et une seule qui justifierait de décaler C++17, c'est bien celle là. Et je suis d'accord ![/QUOTE]

Citation Envoyé par Flob90  Voir le message
[dynarray]
Ça peut être sympa à utiliser comme conteneur.

Je n'utiliserait pas ce mot pour les qualifier... Que ce soit dans leur version langage, avec les array of variable lenght, ou dans la version bibliothèque avec les dynarray, je pense que je n'utiliserai pas ces conteneurs par défaut, mais uniquement dans une phase d'optimisation du code (et toujours avec la version dynarray, pas la version langage).
5  0 
Avatar de gbdivers
Inactif https://www.developpez.com
Le 17/05/2013 à 15:35
On en avait parlé lors des traductions des articles sur les retours d'erreur, il me semble.
Pour moi, finalement ce n'est rien d'autre qu'un pair<bool, T> avec un sémantique adapté et sécurisé. C'est que l'on a par exemple avec map::find, qui retourne un pair<iterator, bool>.
4  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 17/05/2013 à 18:20
Citation Envoyé par Emmanuel Deloget Voir le message
J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.
Aucune des dites alternatives ne travailllent exclusivement qu'avec avec le tas. Soit elles forcent a une allocation sur la pile (les pointeurs intelligents), soient elles empechent l'expression explicite de l'ownership (les pointeurs), soient elles empechent de ne pas avoir de construction du type quand on ne veut pas d'instances (valeurs par defaut).

Optional est une solution si un de ces cas est un probleme. Ca reste un racourcis pour une sorte d'union a semantique claire.
De la meme facon que boost::variant est un racourcis "type-safe" de 'void*'.

Mais, pour rejoindre un poil ce que tu dis, mon experience avec boost::optional est qu'on a pas mal de cas ou on pense que c'est une bonne idee de le retourner plutot qu'autre chose, et ou on a tord sur le long terme.

Autrement dis, on en a besoin, mais je pense que ca va etre pas mal abuse au debut. Le tout est que la bibliotheque standard n'en abuse pas et donne de bons exemples, et surtout que d'autres developeurs de bibliotheques beaucoup utilisees sachent ne pas l'utiliser a tout bout de champs, par exemple juste pour eviter d'avoir a penser aux exceptions ou aux strategies d'echec des utilisateurs (tout un programme).
2  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 19/05/2013 à 13:02
Citation Envoyé par Arzar Voir le message
Et qu'en est-il des concept-lite proposés par Stroustrup, Sutton et Dos Reis et implémentés dans une branche de GCC 4.9 ?
J'avais l'impression que cette forme intermédiaire simplifiée était ce qui était maintenant mis en avant par le comité, ce qui permettrait d'avoir un TR pour les concepts dès 2014. Mais en fait il y a donc encore plusieurs design des concept qui se font concurrence ?
Il n'y a pas vraiment plusieurs design concurrents, il y a un design partiel qui a été proposé, Concept-Lite, et je pense que la question la plus importante qui a été posée est "sera-t-il possible d'aller de ce design partiel à un design plus complet", la question annexe étant "comment gérer les concepts avec une syntaxe légère, en particulier pour les lambdas".

Citation Envoyé par Arzar Voir le message
D'ailleurs à propos des concept-lite je suis tombé sur les slides d'une présentation à la conf c++ now qui explique les concept-lite beaucoup plus simplement que dans le proposal. Et ma fois la syntaxe est plutôt chouette. On est finalement pas si loin des concepts comme initialement envisagée, la seule grosse différence étant l'absence de concept_map j'ai l'impression.
Pas exactement. Les concepts map sont effectivement absentes, et telles que je vois les choses, elles ne sont pas prêtes de revenir. Non, la plus importante différence est dans l'absence de validation de l'implémentation. Les concepts initiaux vérifiaient deux choses : Que l'utilisateur d'un template essayait de l'instancier avec des types conformes, et que l’implémentation d'un template n'utilisait que ce qu'il avait promis d'utiliser des types passés en argument. Cette seconde partie est absente des concepts lite.

Il y a eu une longue discussion en début de réunion à Bristol pour savoir si on mettait les concept light dans C++14. Finalement il a été décidé de créer un TS dédié à ce sujet ainsi qu'à une syntaxe allégée pour les templates. L'objectif est que le TS soit prêt à peut près en même temps que le C++14 (il y a moins de lourdeurs administratives pour la validation d'un TS, donc ça laisse un peu plus de temps), dans l'espoir que des compilateurs commencent à l'implémenter au plus vite, avant même que le TS ne soit transféré dans un working paper, et surtout avant C++17.

Citation Envoyé par Arzar Voir le message
Sinon je suis assez estomaqué par la généralisation des constexpr, je ne pensais pas que le comité irait aussi loin.
Il est bien connu que constpexr en C++11 a été sévèrement bridé, pour éviter de prendre des risques, et qu'il était prévu dès le début de l'étendre dans les standards post c++11, mais quand même si je comprends bien on passe de un seul et unique statement return en C++11 autorisé par fonction constepxr à euuu.... quasiment tout le c++ d'autorisé ?
Excepté deux trois trucs comme l’interdiction de goto/try-catch/variable statique/variable non initialisé + quelques restrictions naturelles comme pas d'allocation dynamique possible + les seules types utilisables sont les built-in et les types dont le constructeur est constepxr, on pourra donc tout faire dans une fonction constepxr ? Comment vont se débrouiller les compilateurs ? Il va falloir qu"ils précompilent les fonctions constexpr pour pouvoir les exécuter pendant la vrai compilation, qqchose comme ça ?
Comment ils vont faire, je ne sais pas trop, je n'ai pas assisté à cette partie de la discussion, mais j'imagine qu'il ne devait pas y avoir une telle marge en terme d'implémentation entre ce qu'ils doivent déjà faire maintenant (et qui a été déclaré comme la fonctionnalité du C++11 la plus longue à mettre en place par certains fabricants de compilateur) et ce qu'il est possible de faire désormais.

Sur le pourquoi des choses, les limitations actuelles posaient des vrais problèmes. En gros, une fonction constexpr peut aussi servir au runtime. Or, les limitations d'écriture des fonctions constexpr faisaient que pour en écrire une valide, il fallait qu'elle soit écrite de manière totalement non optimale pour le runtime. Ce qui forcerait à écrire deux fois les même fonctions, une fois pour le compile time, une fois pour le runtime, et à choisir la bone version au bon moment, ce qui n'est pas aisé et bloque toute généricité. Maintenant, on peut écrire une fonction naturellement et efficacement qui pourra servir au compile time et au runtime.

Howard Hinnant a déjà déclaré qu'avec cette nouvelle fonction il avait pu définir une fonction (jour, mois, année) => date qui tournait 3 fois plus vite quand une partie des arguments était connue à la compilation, sans que l'implémentation soit trop complexe ou artificielle.
2  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 30/05/2013 à 0:00
Citation Envoyé par gbdivers Voir le message
Je vais préciser mon EDIT (n"hésitez pas à splitter la discussion si nécessaire)

Remarque préalable : je n'ai pas retrouvé les anciennes discussions sur l'équivalent de weak_ptr pour unique_ptr.

Validité. C'était mon raison initiale pour un équivalent de weak pour unique. weak proposer en effet expired, qui permet de tester si l'objet est encore valide
[...]
Ce qui revient à dire que dans de nombreux pattern (par exemple une collection), il ne faut pas utiliser un unique (en partant du principe que c'est la collection qui gère la durée de vie des objets), mais des shared (pour que les utilisateurs des objets aient une garantie de leurs validités)
On pourrait à la rigueur utiliser unique dans un collection qui auraient la même durée de vie que le programme et qui ne supprime pas d'objet... mais c'est pas ce que l'on pourrait appeler de la gestion fine de la mémoire

Bref, en conclusion, pas sur qu'il faut ajouter ça dans la norme en fait
J'ai essayé de défendre l'idée à Bristol, mais je n'ai eu qu'un accord mou poli... En fait une telle classe aurait plusieurs intérêts :
- Documentation du code (le cas est arrivé avec la proposition sur les allocateurs polymorphes, où l'on passe un allocator*, et où des gens se sont posés des questions sur la responsabilité de l'objet)
- Éviter des fausses manips (delete sur un tel objet)
- Vérifications, mais c'est très secondaires. Pour moi, si vérifications il y a sur un tel objet, ce n'est pas fonctionnel comme les weak_ptr, mais à des fins de debug uniquement, sous forme d'assert. Et ça a effectivement un coût qu'on ne veut pas faire payer à unique_ptr... du moins pas en mode optimisé. En mode debug, de n'est pas très grave si le coût est augmenté, mais que je peux me rendre compte que mes préconditions sur la validité de mes objets sont mauvaises.
- Peut être possibilité pour des outils d'analyse statique de code de profiter de la sementique mieux définie pour trouver des problèmes.
- J'ai l'impression que j'en oublie...
2  0 
Avatar de Emmanuel Deloget
Expert confirmé https://www.developpez.com
Le 17/05/2013 à 14:39
Citation Envoyé par Neckara Voir le message
Bonjour,

On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.

J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^
J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.

Je vais donc regarder ça d'un oeil nouveau, histoire de peser le pour et le contre.

Citation Envoyé par Neckara Voir le message

Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins)
Ah... A la limite, un système de chargement déchargement de librairies dynamiques, je suis pour. Appeler ça std::plugin, ça reviendrait à imposer aux applications un système qui ne peut pas être générique (et n'est d'ailleurs pas souhaitable). Un plugin peut prendre différentes formes - code natif, code interprété... Bref : la fonctionnalité de base : oui ; un std::plugin: non.

Citation Envoyé par Neckara Voir le message

ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur,
Pour autant que je me le rappelle, c'est en cours. Et la solution viendra à priori de la librairie asio.

Citation Envoyé par Neckara Voir le message

accéder à des bases de données en renseignant le pilote à utiliser, etc.
A l'heure actuelle il n'existe aucun standard pour permettre l'accès aux base de données. Il y a autant de systèmes que d'OS et de DB différents. Si on rajoute à ça les différents types de SGBD (relationnel, objet, nosql...) on arrive à quelque chose qui, mon avis, n'est pas normalisable.

Ce qui peut être normalisé, par contre, c'est une extension du langage genre linq (voire une extension de la librairie qui fournit des services similaires). L'idée est de travailler sur des collections (i.e. des conteneurs). Il devrait être possible d'écrire :

Code : Sélectionner tout
1
2
3
4
5
6
from(collection1, collection 2).select([](const col1type::value_type&a, const col2type::value_type& b) {
    return std::make_tuple(a.id, b.info1, b.info2);
}).where([](const col1type::value_type&a, const col2type::value_type& b) {
     return a.somevalue == b.othervalue;
});
Ce code peut déjà être écrit en C++11. Une extension de ce type peut fournir l'essentiel des services qui sont généralement utilisés sur un SGBD. De plus, il peut être écrit de manière à spécialiser l'accès à un SGBD particulier (tout en continuant de fonctionner sur les conteneurs de la librairie standard).
1  0 
Avatar de jmnicolas
Membre éprouvé https://www.developpez.com
Le 17/05/2013 à 15:58
<troll>
Vu qu'ils ont mis 8 ans pour sortir la précédente révision on peut estimer que C++14 s’appellera C++19, voir C++2x
</troll>
1  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 17/05/2013 à 22:39
Citation Envoyé par Gugelhupf Voir le message

Pourquoi essayer d'imiter LINQ comme C# ?
Emmanuel prenait linq comme exemple, surement pas comme quelque chose à "imiter"

Pourquoi ne pas directement inclure le SQL dans le langage comme le fait PowerBuilder ? (attention je n'ai pas dis que c'est simple à faire ).
Heu... d'accord, on prend quel SGBDR comme référence

Tu n'imagines pas les différences qui peuvent exister au niveau du langage ne serait-ce qu'entre oracle, MsSql et MySql (pour ne citer que ceux là)

Je ne parle pas de la syntaxe des requête "simples" comme un select sur une seule table (voir meme sur plusieurs), mais de la syntaxe de certaines requêtes avancée


Je n'ai pas voulu utiliser le mot complexe.
Tu peux clairement utiliser le mot complexe

C'est un mot parfaitement assumé, qui vient en complément indissociable de la liberté que le langage offre
Je fais du C++ depuis 5 ans, et je trouve que c'est le langage avec lequel j'en apprends tous jours.
Prenons un exemple tout bête :
Code : Sélectionner tout
1
2
3
4
monObjet.maMethode(); // objet stack
monObjet->maMethode(); // pointeur
MaClasse::maMethode(); // méthode statique
std::vector monVector; // utilisation du namespace
En Java : On n'utilise que le symbole "." pour tous ces concepts, un IDE comme Eclipse ou Netbeans t'indique en temps réel la signature au passage du curseur.
Et en java, on fini par ne plus savoir ce qui est une classe, une classe imbriquée, un espace de noms (pardon : un module ) ou si c'est une fonction statique ou non

D'autant plus que, même si on a tendance à l'oublier, C++ essaye de garder un minimum de compatibilité avec C

Si l'on venait à décider de n'utiliser que le point comme accesseur, tout en autorisant (pour la compatibilité d'avec C) d'avoir ->, tu imagines un peu le b...l sans nom que cela foutrait
Après y a tout plein de petit pièges comme la création d'un objet stack dans le paramètre d'une méthode :
maMethode(MaClasse()); // Interdit par la norme, autorisée par Visual Studio
Tout à fait autorisé : cela s'appelle une variable temporaire anonyme

Les pointeurs intelligents... si seulement les mécanismes des pointeurs intelligents étaient automatiquement présent avec les pointeurs nus.
Cela poserait sans doute plus de problème que cela n'apporterait de solution.

Une habitude que j'ai prise est d'utiliser les pointeurs intelligents (surtout std::unique_ptr d'ailleurs ) pour les classes qui doivent s'occuper de la gestion de la durée de vie des objets sous-jascents et d'estimer que, lorsque j'ai un pointeur nu, c'est que je n'ai pas à m'inquiéter de le détruire.

Mais ce n'est qu'une habitude strictement personnelle

Si l'on fait en sorte que les pointeurs nu soient d'office intelligent, doit on les considérer comme des shared_ptr comme des unique_ptr comme autre chose

Quel que soit le choix fait, comment fait on pour assurer la compatibilité envers C

Une fois que le choix est fixé, comment fait on pour s'assurer que tout continue à fonctionner correctement

Si on choisi que ces des unique_ptr, comment fait on si on veut que ce soit une classe particulière qui s'occupe de leur durée de vie

J'ai pris entre 2 et 3 ans pour faire le tour du standard des langages C, PHP et Java... En C++ non, impossible de faire le tour du standard, même si le standard ne possède pas énormément d'API (pas de connexion BDD, pas de création d'interface graphique, pas de gestion du son et image, pas de socket/date pour le moment etc...), la syntaxe du langage est tout simplement trop riche (pour moi).
Je peux te rassurer sur un point : je fais du C++ depuis maintenant plusieurs années et je n'en ai pas encore fait le tour
1  0