C++0x : fin des discussions techniques pour la nouvelle normalisation

Le , par Arzar, Membre émérite
THIS IS IT !!

Howard Hinnant, le président du Library Working Group du comité C++ vient de lâcher le morceau sur Stack Overflow !!

Le draft final est terminé !!

Il sera rendu officiel et public le 13 avril. Pour compléter le processus ISO il reste encore quelques formalités administrative mais c'est une étape purement bureaucratique, car du point de vue technique c'est fini !


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 25/03/2011 à 23:52
Zut tu m'as grillé, je voulais faire l'annonce en quasi direct, je n'aurais pas du aller fêter ça au resto avec les autres...

On a effectivement voté pour que la version du draft après les modifications de cette semaine soit proposée comme la nouvelle version du C++. Ça peut prendre un temps indéterminé à finaliser, mais on (Herb, en particulier) tente de faire ce qu'on peut pour accélérer la partie administrative.

Ps : Howard n'est plus en charge du library working group depuis un peu plus d'un an. C'est Alisdair Meredith qui l'a remplacé. Mais il en reste un membre actif.

A noter, comme "gros" changement cette semaine : new et explicit ne sont plus utilisés pour la gestion de l'overload (par contre, final et override restent en place). L'utilisation de noexcept dans la bibliothèque a été rationalisée (et un grand nombre de spécifications ont été enlevées). Les règles de recherche de begin et end pour un range-for ont été modifiées : Le compilateur les cherchera en premier lieu sous la forme de fonctions membre, et s'il ne les trouve pas sous la forme de fonctions libres. Ce qui évitera entre autre une ambiguïté avec boost.
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 26/03/2011 à 1:11
new et explicit ne sont plus utilisés pour la gestion de l'overload
Tu peux préciser? Je ne vois pas du tout de quelle feature tu parles?

Sinon, j'ai entendu dire que les custom string-literal étaient remis en question. Finalement ils sont bien dans C++0x?

Enfin au niveau du nom, finalement ça sera C++11 ou C++2011?
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 26/03/2011 à 1:30
Certains voulaient retirer les user defined literals, ainsi que le forwarding des constructeurs de la classe de base. Rien n'a finalement été retiré.

L'idée d'override, c'est de déclarer d'une fonction en redéfini bien une autre. Si on ne trouve pas de fonction virtuelle correspondante dans la classe de base, il y a une erreur de compilation (exemple vécu : On ajoute const dans un argument de la fonction virtuelle de la classe de base, tout compile, rien ne marche. Là, on aura une elle erreur en compilant la classe dérivée).

A partir de là, le reste me semble plus optionnel. Final indique que l'on ne va pas dériver plus.

Explicit (à mettre à côté du nom de la classe) avait pour but de forcer une classe à déclarer override (et pas seulement virtual) les fonctions qui redéfinissaient une fonction de la classe de base. Et dans ce contexte, new avait pour but de déclarer une fonction avec le même nom qu'une fonction de la classe de base, mais ne la redéfinissant pas. Il y avait des difficultés sur l'utilisation de new, et sans new, ou avec un new partiel (par exemple, sur les fonctions mais pas sur les données membre ni les types) des questions se posaient sur explicit, et les problèmes de compatibilités qu'il pourrait causer. Du coup les deux ont été enlevés.

Pour le nom, j'espère fortement que ce sera C++11, mais ça dépend aussi de la vélocité de l'ISO.
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 26/03/2011 à 11:04
Ok merci pour l'explication, je savais pas pour new et explicit.

Herb Sutter commence a faire echo : http://herbsutter.com/2011/03/25/we-...ndards-meeting

If all goes well, and we expect it will, the International Standard will be approved and published in 2011, henceforth to be known as C++ 2011.
Donc ça serait C++2011? Perso ça me va.
Avatar de Goten Goten - Membre chevronné https://www.developpez.com
le 26/03/2011 à 11:32
Citation Envoyé par JolyLoic Voir le message
Zut tu m'as grillé, je voulais faire l'annonce en quasi direct, je n'aurais pas du aller fêter ça au resto avec les autres...

On a effectivement voté pour que la version du draft après les modifications de cette semaine soit proposée comme la nouvelle version du C++. Ça peut prendre un temps indéterminé à finaliser, mais on (Herb, en particulier) tente de faire ce qu'on peut pour accélérer la partie administrative.

Ps : Howard n'est plus en charge du library working group depuis un peu plus d'un an. C'est Alisdair Meredith qui l'a remplacé. Mais il en reste un membre actif.

A noter, comme "gros" changement cette semaine : new et explicit ne sont plus utilisés pour la gestion de l'overload (par contre, final et override restent en place). L'utilisation de noexcept dans la bibliothèque a été rationalisée (et un grand nombre de spécifications ont été enlevées). Les règles de recherche de begin et end pour un range-for ont été modifiées : Le compilateur les cherchera en premier lieu sous la forme de fonctions membre, et s'il ne les trouve pas sous la forme de fonctions libres. Ce qui évitera entre autre une ambiguïté avec boost.
Comme gros changement y'a aussi "decltype", à l'heure actuelle toute les implémentations sont devenues défectueuses et fausses. Et c'est très bien car decltype avait plusieurs soucis, qui ont été résolu.

sinon.... ben HOUURAY `\o/
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 26/03/2011 à 11:33
O__O;

C'est quoi les changements avec decltype? Parceque je l'utilise pas mal dans mes projets...
Avatar de Goten Goten - Membre chevronné https://www.developpez.com
le 26/03/2011 à 11:41
Le problème est avec le protocol result_of.

http://www.open-std.org/jtc1/sc22/wg...011/n3233.html

Toute l'histoire . (ça a été accepté bien entendu)
Avatar de Hinault Romaric Hinault Romaric - Responsable .NET https://www.developpez.com
le 29/03/2011 à 15:10
Le comité ISO C++ valide le Draft final de la norme C++ 0X
il sera publié officiellement dans les mois avenir

Mise à jour du 29/03/11, par Hinault Romaric

Les travaux pour la définition de la nouvelle norme pour le langage de programmation C++ sont enfin achevés et validés.

La norme, qui remplacera celle de 1997, et dont la publication initiale était prévue au plus tard pour 2010, vient de franchir un cap majeur. Le comité de normalisation ISO C ++ vient en effet d'approuver les dernières modifications techniques lors d'une réunion qui s'est tenue du 21 au 25 mars à Madrid en Espagne, sur le Draft final (Final Commitee Draft) et sur un Draft international (Final Draft International Standard - FDIS).

Pour Herb Sutter, président du comité ISO C++, le FDIS est de «très bonne qualité », ce qui en quelque sorte pourrait justifier le retard accusé dans sa validation. « Nous avons pris beaucoup plus de temps pour produire la seconde norme du C++. C'est en partie à cause de ses fonctionnalités ambitieuses, et surtout sa qualité [...] Cette norme est largement considéré comme le document FDIS de plus haute qualité que nous n'ayons jamais élaboré » écrit-il sur son blog.

Au menu, des changements comme l'abandon des clauses new et explicit pour la gestion des overload, la rationalisation de l'utilisation de noexcept dans la bibliothèque ou la modification des règles de recherche de Begin et end pour un range-for.

On notera également la suppression de plusieurs spécifications jugées obsolètes.

La publication officielle de la norme est prévue pour cette année, si le FDIS est validé lors d'une ultime réunion à Genève.

Le nouveau standard aura finalement pour nom de code C++ 2011., mettant ainsi fin à toutes les spéculations. Et à toutes les plaisanteries.

Source : Blog Herb Sutter

Et vous ?

Que pensez-vous de cette nouvelle norme?
Avatar de Firwen Firwen - Membre expérimenté https://www.developpez.com
le 29/03/2011 à 15:42
Aprés Duke Nukem forever, C++ 2011.

Vraiment une sale année pour les trolls 2011

Que du bon, vivement une implémentation à 100% dans GCC, j'en salive déja sur mon clavier
Avatar de guillaume07 guillaume07 - Débutant https://www.developpez.com
le 29/03/2011 à 16:43
"si le FDIS est validé lors d'une ultime réunion à Genève"

Tout n'est donc pas encore validé, je suis un peu perdu avec cette phrase ... ?
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 29/03/2011 à 17:24
Il manque une étape administrative, donc officiellement il sera "finis" vers juillet. Mais techniquement il est déjà fini.

Un peu comme quand tu finis un jeu vidéo mais que l'editeur a besoin de faire un travail marketing autour avant de le mettre dans les bacs.

...

Sauf que c'est pas du marketing, mais juste de l'administration ISO.

Enfin vous m'avez compris quoi.
Avatar de r0d r0d - Expert éminent https://www.developpez.com
le 29/03/2011 à 17:45
Au fait, ce nouveau standard ne permet toujours pas de faire:
Code : Sélectionner tout
std::vector< MaClasseTemplate< UnType > >


Parce que les variadic templates m'ont induit en erreur, et je suis un peu perdu

Sinon, visual 2010 implémente pas encore final et override
Avatar de yan yan - Rédacteur https://www.developpez.com
le 29/03/2011 à 17:52
Citation Envoyé par r0d Voir le message
Au fait, ce nouveau standard ne permet toujours pas de faire:
Code : Sélectionner tout
std::vector< MaClasseTemplate< UnType > >

Comment cela?
Avatar de Goten Goten - Membre chevronné https://www.developpez.com
le 29/03/2011 à 18:22
Citation Envoyé par r0d Voir le message
Au fait, ce nouveau standard ne permet toujours pas de faire:
Code : Sélectionner tout
std::vector< MaClasseTemplate< UnType > >


Parce que les variadic templates m'ont induit en erreur, et je suis un peu perdu

Sinon, visual 2010 implémente pas encore final et override
tu peux même le faire en c++98 ça..
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 29/03/2011 à 22:45
Sinon, visual 2010 implémente pas encore final et override
En même temps ils ont été "fixés" il y a très peu de temps hein...
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 30/03/2011 à 9:15
Citation Envoyé par Klaim Voir le message
Sinon, visual 2010 implémente pas encore final et override
En même temps ils ont été "fixés" il y a très peu de temps hein...
En même temps, je suis dubitatif sur leur intérêt. A priori, j'ai l'impression qu'une utilisation de NVI réduit pas mal les cas 'utiles' de override. Quand à final, à part à des fins d'optimisations par le compilateur, j'avoue que j'en vois mal l'intérêt.
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 30/03/2011 à 12:14
Citation Envoyé par 3DArchi Voir le message
En même temps, je suis dubitatif sur leur intérêt. A priori, j'ai l'impression qu'une utilisation de NVI réduit pas mal les cas 'utiles' de override. Quand à final, à part à des fins d'optimisations par le compilateur, j'avoue que j'en vois mal l'intérêt.
Je ne vois pas trop le lien entre override et NVI. Il y a quand même pas mal de cas où, même avec NVI, la classe de base peut définir une implémentation pour la fonction virtuelle. Et dans ce cas, il est intéressant pour la personne écrivant une classe dérivée de pouvoir être certaine qu'elle ne s'est pas plantée dans l'écriture d'une fonction remplaçant cette fonction virtuelle non pure (ou que la définition de la fonction virtuelle non pure dans la classe de base n'a pas été modifiée par la suite).
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 30/03/2011 à 12:43
Citation Envoyé par JolyLoic Voir le message
Je ne vois pas trop le lien entre override et NVI. Il y a quand même pas mal de cas où, même avec NVI, la classe de base peut définir une implémentation pour la fonction virtuelle. Et dans ce cas, il est intéressant pour la personne écrivant une classe dérivée de pouvoir être certaine qu'elle ne s'est pas plantée dans l'écriture d'une fonction remplaçant cette fonction virtuelle non pure (ou que la définition de la fonction virtuelle non pure dans la classe de base n'a pas été modifiée par la suite).
Effectivement ma mémoire m'a joué des tours. J'avais retenu que l'idée derrière était d'éviter les masquages de fonctions (qui sont empêchés par NVI) alors qu'il y a aussi la conformité de la signature (qui n'est vérifiée ... qu'au plantage de l'exécution sinon ). Je n'ai pas encore lu la dernière mouture du draft (le n342 il me semble) mais cela s'appliquerait plus à new pour les 3 lignes que j'ai pris le temps de voir.
Ceci étant dit, je suis toujours interrogatif sur final.
Avatar de Firwen Firwen - Membre expérimenté https://www.developpez.com
le 30/03/2011 à 16:13
Ceci étant dit, je suis toujours interrogatif sur final.
Je n'arrive pas à trouver de reference sur ce "final" qui me semble pas trés logique.
Où as-tu vu que "final" allait être implémenté dans le draft ?
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 30/03/2011 à 16:25
C'était l'un des attributs qui sont passé en mots-clés récemment.

Personellement je pense que, utilisé avec beaucoup de parcimonie, ça peut être utile, notemment pour les conteneurs de la stl que certains débutants ont tendance a prendre comme base d'autres classes... le souci c'est surtout que rien ne te dit (sauf warning de certains compilateurs) que tu ne devrais pas hériter d'une classe sous pretexte que tupeux, au risque d'avoir des problèmes obscures au runtime (parceque le destructeur de la classe de base n'est pas virtuel.
Là ce serait un moyen de dire explicitement : non.

Mais il est facile d'abuser de ce genre de feature.
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 30/03/2011 à 16:28
Citation Envoyé par Firwen Voir le message
Je n'arrive pas à trouver de reference sur ce "final" qui me semble pas trés logique.
Où as-tu vu que "final" allait être implémenté dans le draft ?
Dans l'ancienne version que j'avais (la n3126) c'était dans les attributs : 7.6.4 Final attribute

Mais dans la nouvelle version (n3242) (pas encore regardée pour ma part), si j'ai bien compris final/override sont passés en mots clés. Tu les as dans 9 Classes (class-virt-specifier) et dans 9.2 Class member (virt-specifier)
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 30/03/2011 à 16:32
Citation Envoyé par Klaim Voir le message
Personellement je pense que, utilisé avec beaucoup de parcimonie, ça peut être utile, notemment pour les conteneurs de la stl que certains débutants ont tendance a prendre comme base d'autres classes... le souci c'est surtout que rien ne te dit (sauf warning de certains compilateurs) que tu ne devrais pas hériter d'une classe sous pretexte que tupeux, au risque d'avoir des problèmes obscures au runtime (parceque le destructeur de la classe de base n'est pas virtuel.
Là ce serait un moyen de dire explicitement : non.

Mais il est facile d'abuser de ce genre de feature.
C'est omettre que l'héritage privé peut avoir de l'intérêt à la place de l'encapsulation
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 30/03/2011 à 16:39
Sans compter que les inheriting constructors permet de plus facilement hériter d'une classe non prévue pour dans les cas où ça a du sens (adapter).
Avatar de r0d r0d - Expert éminent https://www.developpez.com
le 30/03/2011 à 17:12
Concernant les templates, en fait je me suis mal exprimé, je voulais parler de vecteur (ou n'importe quel conteneur template) contenant une classe template non spécialisée. Par exemple:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
template <typename T>
class MaClasseTemplate
{
//...
};

// puis ailleurs:
std::vector< MaClasseTemplate >;
Je ne sais pas pourquoi, j'avais compris que les variadic templates servaient à résoudre ce problème. Sans doute est-ce mon anglais (approximatif) qui m'a joué un tour.

Ça peut paraître bizarre de souhaiter pouvoir faire cela, car à première vue ça n'a pas vraiment de sens. Mais en fait je crois que ça pourrait être utile. J'étais tombé sur ce "besoin" quand j'avais tenté de faire une machine à état finie générique. En effet, je voulais créer un tableau de transitions, les transitions étant des templates dont les types sont les 2 états (départ, arrivée). [HS] C'est d'ailleurs un problème intéressant cette histoire de machine à état, et j'ai toujours pas trouvé de solution générique et élégante. [/HS]

Mais alors du coup, les variadic template ça rend obsolète les typelist? (comme vous le voyez, les templates c'est pas mon truc )
Avatar de guillaume07 guillaume07 - Débutant https://www.developpez.com
le 30/03/2011 à 18:07
Citation Envoyé par r0d Voir le message

Mais alors du coup, les variadic template ça rend obsolète les typelist? (comme vous le voyez, les templates c'est pas mon truc )
Oui
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 30/03/2011 à 18:21
non. Ca rend l'écriture un peu moins absconse
Avatar de Goten Goten - Membre chevronné https://www.developpez.com
le 30/03/2011 à 19:43
Citation Envoyé par r0d Voir le message
Concernant les templates, en fait je me suis mal exprimé, je voulais parler de vecteur (ou n'importe quel conteneur template) contenant une classe template non spécialisée. Par exemple:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
template <typename T>
class MaClasseTemplate
{
//...
};

// puis ailleurs:
std::vector< MaClasseTemplate >;
Je ne sais pas pourquoi, j'avais compris que les variadic templates servaient à résoudre ce problème. Sans doute est-ce mon anglais (approximatif) qui m'a joué un tour.
Y'a les template typedef.

[/HS]
Mais alors du coup, les variadic template ça rend obsolète les typelist? (comme vous le voyez, les templates c'est pas mon truc )
Non.

@guillaume : les typelists c'est pas destiné uniquement à émuler les variadic templates ... (et pire ont a de meilleure méthode pour le faire).
Avatar de ponce ponce - Membre averti https://www.developpez.com
le 30/03/2011 à 20:32
Ceci étant dit, je suis toujours interrogatif sur final.
final et override existent en Java, C#, D, Delphi et même dans Visual C++ (sans /CLR)

Code : Sélectionner tout
1
2
3
4
5
6
7
8
class A sealed
{
};

class B : A // error C3246: 'B' : cannot inherit from 'A' as it has been declared as 'sealed'	
{
}
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class A
{
    virtual void func();
};

class B : public A
{
    virtual void funk() override;  // error C3668: 'B::funk' : method with override specifier 'override' did not override any base class methods
};

class C : public A
{
    virtual int func(); // error C2555: 'C::func': overriding virtual function return type differs and is not covariant from 'A::func'

}
J'ai du mal à en voir les inconvénients...
Avatar de Firwen Firwen - Membre expérimenté https://www.developpez.com
le 30/03/2011 à 21:26
final sur les fonctions membre a un sens en java, puisque par défaut toute les fonctions java sont "virtual" (au sens C++).

Ce n'est pas le cas en C++ où toute fonction membre surchargeable doit être spécifiquement déclarée comme telle, d'où ma question.
Avatar de guillaume07 guillaume07 - Débutant https://www.developpez.com
le 31/03/2011 à 1:58
Citation Envoyé par Goten Voir le message


@guillaume : les typelists c'est pas destiné uniquement à émuler les variadic templates ... (et pire ont a de meilleure méthode pour le faire).
ok désolé j'ignorais
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 31/03/2011 à 7:18
Salut,
Citation Envoyé par ponce Voir le message
J'ai du mal à en voir les inconvénients...
Moi, j'ai du mal à voir l'intérêt des final d'un strict point de vue design. Ca permet des optimisations pour remplacer des appels dynamiques par des appels statiques. Mais à part ça, je vois pas.

J'avais ouvert une discussion l'an dernier (Intérêt du concept de final) mais je n'ai jamais eu de réponses
Avatar de Médinoc Médinoc - Expert éminent sénior https://www.developpez.com
le 31/03/2011 à 11:38
Citation Envoyé par Firwen Voir le message
final sur les fonctions membre a un sens en java, puisque par défaut toute les fonctions java sont "virtual" (au sens C++).

Ce n'est pas le cas en C++ où toute fonction membre surchargeable doit être spécifiquement déclarée comme telle, d'où ma question.
Il faudrait demander aux gars de C# qui ont à la fois la déclaration explicite ("virtual" et le final ("sealed".

Personnellement, le sealed, je l'ai vu beaucoup plus appliqué aux classes qu'aux méthodes.
Avatar de Eridan Eridan - Nouveau Candidat au Club https://www.developpez.com
le 31/03/2011 à 12:29
Citation Envoyé par 3DArchi Voir le message
Salut,
Moi, j'ai du mal à voir l'intérêt des final d'un strict point de vue design. Ca permet des optimisations pour remplacer des appels dynamiques par des appels statiques. Mais à part ça, je vois pas.

J'avais ouvert une discussion l'an dernier (Intérêt du concept de final) mais je n'ai jamais eu de réponses
Il y a peu etre un element de reponse ici : http://www2.research.att.com/~bs/bs_...#no-derivation
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 31/03/2011 à 12:47
Citation Envoyé par Eridan Voir le message
Il y a peu etre un element de reponse ici : http://www2.research.att.com/~bs/bs_...#no-derivation
Non. Comme le dit le post que j'ai mis en lien : j'ai bien compris le comment, ce que j'aimerais savoir c'est le pourquoi ? Est-ce que ça a un intérêt (en dehors d'optimisation ce qui n'est déjà pas si mal).
Avatar de ponce ponce - Membre averti https://www.developpez.com
le 31/03/2011 à 19:06
En dehors de la performance, à mon avis une méthode final a un intêret dans un cas au moins : une classe implémentant une méthode virtuelle de sa classe parente pour tous ses descendants. Le concepteur voudrait alors éviter qu'elle soit redéfinie dans une classe fille.
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 31/03/2011 à 19:16
Citation Envoyé par ponce Voir le message
Le concepteur voudrait alors éviter qu'elle soit redéfinie dans une classe fille.
C'est bien ça qui me dérange. J'ai l'intuition que ce qui se cache dans ce cas c'est une violation du contrat de la classe qui rend dangereux l'héritage. Car sinon, pourquoi vouloir arrêter la possibilité d'adaptation du comportement ?
Avatar de ptyxs ptyxs - Membre averti https://www.developpez.com
le 03/04/2011 à 13:55
Bonjour
existe-t-il quelque part un inventaire déjà constitué de bonnes documentations existantes sur C++0x ?
Avatar de guillaume07 guillaume07 - Débutant https://www.developpez.com
le 05/04/2011 à 0:27
c 0x ou 2011 ?
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 05/04/2011 à 10:01
existe-t-il quelque part un inventaire déjà constitué de bonnes documentations existantes sur C++0x ?
Si tu trouves le document standard illisible, tu peux toujours te racrocher a un mix entre wikipedia (http://en.wikipedia.org/wiki/C%2B%2B0x) et le site de Stroustrup ( http://www2.research.att.com/~bs/C++0xFAQ.html ).

c 0x ou 2011 ?
Herb Sutter a dit C++2011 (voir quelques messages plus haut).
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 13/04/2011 à 13:57
Le mailing post-Madrid vient de sortir. Le dernier draft du standard, identique à ce qui a été envoyé à l'ISO pour normalisation, est :
http://www.open-std.org/jtc1/sc22/wg...011/n3292.html
Avatar de Arzar Arzar - Membre émérite https://www.developpez.com
le 13/04/2011 à 14:00
Le FDIS (Final Draft International Standard) est dispo sur le site du comité !
C'est le document N3290, il fait parti du mailing d'avril.

Edit : Ahahahah joli retour de politesse Loïc, je savais que je n'aurais pas du lancer le téléchargement des 10mo du FDIS pour vérifier que le lien était correct

Edit 2 : ça fait chaud au cœur, la fameuse note qui ouvre chaque draft depuis tant d'année "Note : this is an early draft. It’s known to be incomplet and incorrekt, and it has lots of bad formatting." a enfin disparu !
Avatar de r0d r0d - Expert éminent https://www.developpez.com
le 13/04/2011 à 16:20
M'enfin... j'ai la berlue ou bien il y a une lib de thread prévue par ce standard?
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 13/04/2011 à 16:23
Ben oui, ça fait longtemps qu'elle est prévue! Tu as même une implémentation de cette bibliothèque standard C++2011 dispo (pour quelques sous) là : http://www.stdthread.co.uk/
Avatar de Jean-Marc.Bourguet Jean-Marc.Bourguet - Expert éminent https://www.developpez.com
le 13/04/2011 à 17:31
Citation Envoyé par Arzar Voir le message
Edit 2 : ça fait chaud au cœur, la fameuse note qui ouvre chaque draft depuis tant d'année "Note : this is an early draft. It’s known to be incomplet and incorrekt, and it has lots of bad formatting." a enfin disparu !
C'est present dans n3291 mais pas dans n3290, tout comme ce n'etait pas present dans les versions destinees aux commentaires nationaux.
Avatar de guillaume07 guillaume07 - Débutant https://www.developpez.com
le 15/04/2011 à 20:18
petite question concernant le mot clef alignof :

si alignof(aType) renvoie 8 que faut-il en déduire ?
Avatar de Médinoc Médinoc - Expert éminent sénior https://www.developpez.com
le 15/04/2011 à 21:38
Que les trois derniers bits d'un pointeur sur ce type doivent toujours être nuls, je pense.
Aussi, que sizeof(aType) est aussi multiple de 8, vu que la taille est paddée pour satisfaire les contraintes d'alignement (une structure de 17 octets en fera au moins 24, pour qu'on puisse en allouer un tableau).
Avatar de Goten Goten - Membre chevronné https://www.developpez.com
le 15/04/2011 à 23:23
Citation Envoyé par guillaume07 Voir le message
petite question concernant le mot clef alignof :

si alignof(aType) renvoie 8 que faut-il en déduire ?
Que ton type doit être situé sur une adresse multiple de 8.
Avatar de ptyxs ptyxs - Membre averti https://www.developpez.com
le 16/04/2011 à 17:42
Citation Envoyé par 3DArchi Voir le message
Salut,
Moi, j'ai du mal à voir l'intérêt des final d'un strict point de vue design. Ca permet des optimisations pour remplacer des appels dynamiques par des appels statiques. Mais à part ça, je vois pas.

J'avais ouvert une discussion l'an dernier (Intérêt du concept de final) mais je n'ai jamais eu de réponses
Dans Effective C++, 3ème édition, Item 7, Scott Meyers, regrette l'absence d'un équivalent du sealed de C# ou du final de Java en C++ de l'époque. Il pense que toute classe dépourvue d'un destructeur virtuel, et n'ayant de ce fait pas vocation à servir de base pour des classes dérivées, gagnerait à être 'sealed' (donc maintenant : 'final'), en particulier l'ensemble des classes de conteneurs de la STL.
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 16/04/2011 à 21:14
Salut,
Citation Envoyé par ptyxs Voir le message
Dans Effective C++, 3ème édition, Item 7, Scott Meyers, regrette l'absence d'un équivalent du sealed de C# ou du final de Java en C++ de l'époque. Il pense que toute classe dépourvue d'un destructeur virtuel, et n'ayant de ce fait pas vocation à servir de base pour des classes dérivées, gagnerait à être 'sealed' (donc maintenant : 'final'), en particulier l'ensemble des classes de conteneurs de la STL.
*** Soit la classe n'a aucune fonction virtuelle : l'héritage publique de cette classe n'a aucun sens puisque le comportement effectif d'une instance sera forcément celui défini par son type statique. En revanche, l'héritage privé peut toujours être intéressant (cf par expl un héritage de boost::noncopyable). A partir de là, effectivement final peut être intéressant s'il n'empêche pas l'héritage privé. Mais ce qui n'est pas le cas il me semble.

*** Soit la classe a des fonctions virtuelles. Ne pas avoir de destructeur virtuel s'il est public est de toute façon une faute (qui génère un warning par expl dans gcc avec la bonne option, ou encore dans les outils d'analyse statique de code). L'héritage fait sens. Et à part dans un objectif d'optimisation, je ne vois pas un design qui devrait dire à un moment que l'héritage public doit être arrêté. Sauf s'il y a eu une entourloupe au contrat de base.
Avatar de ptyxs ptyxs - Membre averti https://www.developpez.com
le 18/04/2011 à 16:11
Pense à l'exemple, donnée par Scott Meyers, des classes de conteneurs de la STL, qui ne sont pas conçues pour être la base d'une classe dérivée, mais qui - malheureusement - peuvent l'être. Interdire la dérivation dans de tels cas serait probablement une excellente chose.
On peut imaginer d'autres cas de ce genre, j'imagine, des classes qui ne sont absolument pas conçues pour être la base d'une quelconque autre classe, que ce soit par dérivation publique ou privée, non ?
Ton exemple de la classe uncopyable est intéressant et montre simplement qu'on doit procéder là comme ailleurs au cas par cas...
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 18/04/2011 à 16:43
De telles classes ne sont certes pas faites pour de l'utilisation polymorphe dynamique. De là à en empêcher la dérivation, je ne suis pas certain que ce soit une bonne idée.

Imaginons que j'ai un algorithme qui utilise une classe ayant comme concept tout ce que fourni un vector, plus 1 fonction. Je veux grosso-modo passer un vector à cet algorithme, et comme je n'ai pas de concept_map, je vais créer un adapter pour vector.

Comment créer un tel adapter ? L'idéal peut sembler de créer une classe ayant un vector en variable membre privée, qui forward tout à ce vector. Sauf qu'écrire ça demande d'écrire toute une palanquée de fonctions de forwarding, l'interface de vector étant très grande.

Finalement, n'est-ce pas mieux dans ce cas de dériver de vector, et d'ajouter la fonction manquante ? Éventuellement on peut bloquer la création d'instance de cette classe, et documenter qu'elle n'est pas destinée à du polymorphisme dynamique. On a alors nettement moins de code à maintenir.

Ce cas n'est pas forcément courant, suffisamment peu pour qu'en première approximation, on dise : "Les classes de la STL ne sont pas faites pour être dérivées". Mais de là à ce que le compilateur m'empêche de le faire si j'en ai quand même envie...
Avatar de Flob90 Flob90 - Membre expert https://www.developpez.com
le 18/04/2011 à 18:31
@ptyxs: J'ai du mal à voir des cas où on pourrait formellement interdire l'héritage d'une classe. L'héritage privé est une alternative à la composition (relation has-a), outre le fait que ca peut être plus simple à écrire (l'exemple de JolyLoic), il devient indispensable lorsque ce sous-objet doit être initialisé avant un autre sous-objet hérité. Et je ne vois pas comment, d'un point de vue conception, on peut prévoir que ce genre de cas n'arrivera jamais.
Avatar de ptyxs ptyxs - Membre averti https://www.developpez.com
le 18/04/2011 à 19:13
Bon. Il est vrai qu'on ne trouve guère sur la Toile d'exemple d'emploi concret de cet attribut final, en dehors du cas que j'évoquais et auquel il a été répondu de façon plutôt convaincante...
D'autres idées sur la question ?
Avatar de Luc Hermitte Luc Hermitte - Expert éminent sénior https://www.developpez.com
le 19/04/2011 à 12:55
Citation Envoyé par JolyLoic Voir le message
Imaginons que j'ai un algorithme qui utilise une classe ayant comme concept tout ce que fourni un vector, plus 1 fonction.
[...]
Au détail que nous savons très bien que nous n'aurons jamais accès aux internals du vecteur, et que l'ajout de cette fonction marchera très bien par l'extérieur. (si l'ago est template pour accepter un type vecteur ou autre, on a de bonnes chances que nous puissions le corriger pour émuler la map avec des traits, à l'ancienne -- je ne vois pas beaucoup de libs STLiennes qui sont templates, COTS, et qui supposent des fonctions par rapport aux vectors, d'où mon a priori de développement interne).

Je vois ce que tu veux dire. Je l'ai déjà rencontré plusieurs fois, du moins la mauvaise version (je n'ai encore jamais croisé le cas de vecteur avec une fonction en plus qui est attendue par un algo) et je commence à me dire qu'elle manque de recul.
- Car les détails nous restent interdits, et que l'ajout par l'extérieur et autres traits (certes lourds) marchent très bien
- car nous ne pouvons changer aucun comportement de base (pas de liaison tardive sur les fonctions)
- car pour la même raison, assurer un nouvel invariant est très compliqué à partir du moment où l'héritage est public (ex: container de pointeurs dont on est responsable (-> erase/clear/destr appellent delete), container trié, etc)
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 19/04/2011 à 13:46
L'ajout par l'extérieur pose parfois des problèmes d'ADL, c'est ce qui fait que ça n'a finalement pas été retenu pour le ranged for loop.

Il est même évoqué assez sérieusement pour C++ post 11 d'étendre ce genre de mécanisme (Herb parle d'extention method, à la C#, Bjarne parle de rendre plus ou moins équivalent a.f() et f(a)).

Un autre inconvénient des classes de traits est qu'elles apparaissent dans les messages d'erreur, les rendant encore plus compliqués.

A part ça, je suis globalement d'accord avec toi. Je dis juste que si je tombe sur le cas où ça pourrait marcher, j’aimerais autant que le compilateur ne me bride pas.
Avatar de GeantVert13 GeantVert13 - Membre actif https://www.developpez.com
le 04/05/2011 à 17:08
Bonjour à tous,

Je me posais une question (qui est peut-être bête) à propos de l'implémentation du multithreading dans le nouveau standard...

D'après ce que j'ai compris, une grande partie de C++2011 sera basée (légitimement je suppose, puisque, apparemment, très efficace) sur boost qui est sous licence libre. En revanche, pour ce qui est des thread, ce sera plutôt basé sur la lib just::thread qui est payante et qui vient de la société justSoftware. Le directeur technique, Anthony Williams, étant l'un des auteurs du nouveau standard, ne trouvez vous pas qu'il y a comme un léger conflit d'intérêt ? Y a-t-il eu de tels cas pour les versions antérieures de C++ ?
Cela posera-t-il des problèmes de copyright (ou de royalties à reverser) pour les éditeurs de compilateurs ?

Merci.
Avatar de Flob90 Flob90 - Membre expert https://www.developpez.com
le 04/05/2011 à 17:21
La norme impose une convention pour manipuler les thread, elle ne propose aucun code (il n'y a que l'interface). Chacun est libre de l'implémenter, et la société que tu cites a décidé de le faire, comme n'importe qui d'autre pourrait le faire et comme vont devoir le faire tout les fourniseurs de compilateurs.

C'est just::thread qui se base (est une implémentation de) sur la norme, pas l'inverse.

De même pour tout ce qui vient de boost, les compilateurs peuvent reprendre le code de boost (je crois, la license est très permissif il me semble), mais ils ne sont pas obligé de le faire. (de plus que les interfaces proposé par boost et par la norme ne sont pas nécessairement identique)
Avatar de GeantVert13 GeantVert13 - Membre actif https://www.developpez.com
le 04/05/2011 à 17:35
Citation Envoyé par Flob90 Voir le message
C'est just::thread qui se base (est une implémentation de) sur la norme, pas l'inverse.
C'est justement là qu'est le conflit, Anthony Williams, aurait-il pu "pousser" certains choix pour mieux vendre sa lib ?

Bon c'est sûrement pas très important, c'est juste une question que je me posais...

Si ça ne bloque pas les éditeurs c'est tant mieux.

Merci pour la réponse en tous cas.
Avatar de r0d r0d - Expert éminent https://www.developpez.com
le 04/05/2011 à 17:54
Il y a bien évidemment des conflits d'intérêts dans le commité.
Je ne serai même pas étonné que certains membre ne viennent que pour "défendre leur bistec", ou plutôt celui de leur entreprise.
Mais je n'en sais pas beaucoup plus sur ce sujet, je ne m'y aventurerai donc pas plus. En revanche, je serais trés intéressé par l'avis de ceux qui en savent plus sur la question...
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 04/05/2011 à 18:19
Dans le cas des threads, c'est un peu l'inverse qui s'est produit : Anthony est la personne qui a proposé la majeure partie de l'interface des threads dans la norme. C'est par la suite (ou du moins en même temps) qu'il a développé une implémentation de cette bibliothèque qu'il propose maintenant à la vente. Il a donc écrit sa bibliothèque en fonction de ses propositions pour C++0x, et non pas fait du lobbying pour que sa bibliothèque préexistante soit adoptée. Et ce genre de comportement est recommandé : On est ainsi certain que la bibliothèque en question est implémentable, et on peut se faire une idée de la qualité de son interface en grandeur nature avant de voter pour quelque chose que l'on n'a vu que sur papier.

Il ne faut pas oublier que la majorité des participants au comité sont des employés d'entreprises qui doivent avant tout y représenter les intérêts de leur boîte (par exemple, rien qu'en terme de compilateurs, j'ai vu des gens de Microsoft, Sun, gcc, Intel, IBM, EDG, ce qui couvre quand même une grosse part du marché). C'est ainsi que fonctionne un comité de normalisation. La seule contrainte est grosso modo que les informations données par ces membres ne doivent pas être couvertes par un brevet (lire par exemple les liens dans http://www.open-std.org/jtc1/sc22/wg...2011/n3265.pdf).

J'ai en tête certaines personnes dont on pourrait croire que leur principal objectif est que C++0x n'apporte rien par rapport à C++98, histoire qu'ils n'aient pas de nouveaux investissement à faire...

Alors, certainement, les membres sont partiels. L'idée c'est qu'à devoir voir se mettre d'accord suffisamment de gens partiels, on aboutisse à un consensus auquel les entreprises peuvent adhérer (une norme non suivie est inutile), et qui soit finalement un compromis correct.
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 05/05/2011 à 0:43
J'ai vu beaucoup de fois dans les présentations de Stroustrup le point sur le fait qu'il manque pas mal de représentants des utilisateurs du language. J'imagine qu'il n'y en a aucun en rapport avec le jeu vidéo par exemple?

Je me demandais si des mesures ou des projets pour corriger ça ont été mis en place, ou est-ce qu'il y a des propositions à ce sujet?
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur https://www.developpez.com
le 05/05/2011 à 1:37
C'est assez vrai. On peut même dire qu'un problème est qu'un certain nombre de simples utilisateurs qui y vont s'y font happer par de nouvelles opportunités de carrière.

Finalement, la catégorie la plus représentative des "utilisateurs finaux", par rapport aux développeurs de compilateurs ou de bibliothèques est souvent le monde de l'enseignement.

Pour ce qui est du domaine du jeu vidéo, je ne crois pas y avoir vu de représentants (même si je me souviens d'un papier présenté par une boîte du domaine, mais suivi d'assez peu d'effets).

En utilisateurs style éditeur informatique, on retrouve au comité Adobe, Bloomberg, Google, et certainement d'autres que j'oublie. Mais ce sont souvent des utilisateurs avancés, probablement pas assez représentatifs de la majorité des utilisateurs du langage.

Un des problèmes pour intéresser un utilisateur lambda, c'est à mon avis l'aspect délai. Quelle boîte peut aujourd'hui se permettre de financer une action qui n'aura pour elle des conséquences concrètes que la décennie suivante, dans le meilleur des cas. Je ne sais pas encore vraiment quand j'aurai enfin la possibilité d'utiliser dans ma vie de tous les jours des aspects du C++0x que je connais depuis déjà 5 ans...
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -