[futur] L'après C++11

[Jean-Marc.Bourguet]

Envoyé par Klaim

Pour connaitre l'interface (du code) il doit soit lire le fichier un peu cryptique d'interface qu'il a, soit lire une doc externe (qui n'est pas forcément fournie).

Si ça incite à avoir une doc d'utilisation, c'est pas plus mal. C'est un fichier généré, sans commentaires, il ne peut pas servir de substitut à une doc d'utilisation. Et normaliser des annotations pour transporter des commentaires me semble hors de propos.

[JolyLoic]

C'est quand même un point problématique. Actuellement, par exemple, des environnements de développement parsent les commentaires dans les .h pour fournir une documentation (dans un tooltip) au point d'utilisation d'une fonction. Je pense que ce genre de fonctionnalité est utile, il ne faudrait pas qu'elles deviennent impossible à réaliser.

[Kalith]

En jouant avec le python, j'avais beaucoup aimé le concept de modules. Sans savoir que c'était déjà en projet pour le C++, j'avais écrit un petit bout de programme (3000-4000 lignes) qui permet, à partir d'un seul fichier (.mpp) de générer un .h et un .cpp, compilables directement avec n'importe quel compilateur. Le lien (sur ce forum) : click.

Je n'ai pas encore lu la proposition pour les modules du C++, mais je pense que l'esprit est le même.
Par exemple, le fichier .mpp :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
/// Nom du module (definit dans un namespace, Simple)
module Simple::Test;
 
/// Dependance
using module std::string;
 
typedef unsigned int uint;
 
/// Variables globales (dans le namespace Simple)
// Les commentaires avec trois slash sont consideres comme
// de la documentation, et sont exportes dans le .h
/** On peut aussi utiliser cette syntaxe (à la Doxygen).
*/
uint j;
std::string s;
 
/// Fonctions libre
/** Un peu de documentation ?
*/
void TheFunction()
{
    // Do nothing
}
 
uint OtherFunction(uint* p)
{
    return 2*(*p);
}
 
/// Une classe
class MyClass
{
 
    /// Membres prives
    uint f;
    /// ... et statiques
    static uint S = 0u;
 
public :
 
    /// Constructeur
    new(uint i, const uint j, uint* p) : f(i*j), glu(*p)
    {
    }
 
    /// Fonction membre
    uint Member(const uint& i) const
    {
        return glu*i;
    }
 
    /// Membre public
    uint glu;
};
 
/// Une sous namespace
namespace Foo {
    uint z;
}

... produit un fichier .hpp :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#ifndef SIMPLE_TEST_INCLUDED
#define SIMPLE_TEST_INCLUDED
 
#include <string>
 
namespace Simple {
 
    /// Dependance
    typedef unsigned int uint;
 
    /// Variables globales (dans le namespace Simple)
    /** On peut aussi utiliser cette syntaxe (à la Doxygen).
    */
    extern Simple::uint j;
    extern std::string s;
 
    /// Fonctions libre
    /** Un peu de documentation ?
    */
    void TheFunction();
 
    Simple::uint OtherFunction(Simple::uint* p);
 
    /// Une classe
    class MyClass
    {
        /// Membres prives
        Simple::uint f;
        /// ... et statiques
        static Simple::uint S;
 
    public :
 
        /// Constructeur
        MyClass(Simple::uint i, const Simple::uint j, Simple::uint* p);
 
        /// Fonction membre
        Simple::uint Member(const Simple::uint& i) const;
 
        /// Membre public
        Simple::uint glu;
    };
 
    namespace Foo {
 
        extern Simple::uint z;
    }
 
}
 
#endif

... et un fichier .cpp :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include "simple_test.hpp"
 
using namespace Simple;
 
uint Simple::j;
std::string Simple::s;
 
void TheFunction()
{
    // Do nothing
}
 
uint OtherFunction(uint* p)
{
    return 2*(*p);
}
 
uint MyClass::S = 0u;
 
MyClass::MyClass(uint i, const uint j, uint* p) : f(i * j), glu(* p)
{
}
 
uint MyClass::Member(const uint& i) const
{
    return glu*i;
}
 
uint Simple::Foo::z;

Mon code est très expérimental, et n'est pas 100% fonctionnel (j'ai dû faire une ou deux corrections à la main sur l'output ci-dessus), mais je pense que ça permet de se faire une bonne idée de ce que peuvent apporter les modules aux C++ :

• On ne perd pas de temps à modifier à la fois le fichier .hpp et le fichier .cpp : une modification dans le module suffit.
• Comme le fichier d'interface est généré automatiquement, on peut aussi en profiter pour le "pré-compiler", en stockant dans un coin les types et variables exposées par exemple, ce qui diminue éventuellement les temps de compilation.
• On peut aussi en profiter pour proposer aux compilateurs d'avoir une approche de compilation "globale" et non plus fichier par fichier (réduction énorme des temps de compilation).

Avec les concepts, les modules font partie des features qui me plaisent le plus a priori.

[Freem]

Après avoir lues quelques pages (6/ 23 + un saut la ou il parle des template) je suis moyennement convaincu.

Les deux avantages qu'il cite semblent être:
_ plus de problème d'inclusion multiple
_ accélération notable de la compilation

Je ne pense pas que l'inclusion multiple soit encore un véritable problème pour les dev C++, on à des parades bien connues contre ce genre de soucis.

Pour l'accélération de la compilation, il semble que cette technique soit utilisée dans d'autres langages. J'aimerai savoir lesquels, histoire de pouvoir comparer?
Parce que je reste sceptique sur le fait que les templates puissent être accélérés, parce que pour moi ils sont compilés au même moment que les macros, et il semble que les modules ne puissent gérer les macros (il indique dans le papier, vers la 3ème page, que les header ne seront pas dépréciés pour des raisons de compatibilité et à cause de la présence des macros)...


@Kalith:
Ca semble être très différent de ça.
(/!\ les allégations ci dessous sont issues d'un texte lu a à peine 15% et sont donc sûrement percées de nombreux manques de précision, voire d'erreurs)
Les déclarations seraient inclues dans le fichier d'implémentation, les macros restant dans le header.
Le compilateur compile ce fichier, génère notre bon vieux .lib et un fichier .mpp, que le distributeur de la lib fournit ensuite.
Le client fait l'inclusion, et le compilateur va chercher le .mpp correspondant au .lib dans un emplacement standard (sauf si précisé au compilo via un paramètre de la ligne de commande).
Ensuite, il précompile ce fameux .mpp (le mécanisme des header précompilés qui est jusqu'ici une fonctionnalité non-standard devient donc standard) ce qui fera gagner du temps lors des compilations de projet suivantes.
Mais à aucun moment, il ne génère à nouveau le .cpp, et encore heureux, sinon, tout les non-libristes abandonneraient définitivement ce langage!
L'implémentation reste en fait à sa place, dans le .lib.

Sincèrement, excepté le problème de l'inclusion multiple et parfois bordélique du C++, à coup de "#ifndef ...#endif" et de "class Foo;" je ne comprend pas ce que c'est censé apporter.
L'accélération de la compilation, je pense qu'il suffirait de standardiser les entêtes précompilés. Parce que dans le cas ou on utilise des macros, ce ne sont plus 2 fichiers qu'il faut filer, mais 3: .cpp, .h, .mpp
Et je trouve que beaucoup de codes utilisent des macros, l'air de rien...


[edit]
Les concepts seraient effectivement une excellent chose, parce que les erreurs de syntaxes avec les templates sont assez infernales à résoudre quand même. Donc un gros + pour cette fonction aussi

[JolyLoic]

Envoyé par Freem

Après avoir lues quelques pages (6/ 23 + un saut la ou il parle des template) je suis moyennement convaincu.

Les deux avantages qu'il cite semblent être:
_ plus de problème d'inclusion multiple
_ accélération notable de la compilation

Je ne pense pas que l'inclusion multiple soit encore un véritable problème pour les dev C++, on à des parades bien connues contre ce genre de soucis.

C'est un frein important à l'apprentissage du langage, donc ça a un impact sur la taille de la communauté des développeurs C++, donc sur les bibliothèques et outils disponibles...

Envoyé par Freem

L'accélération de la compilation, je pense qu'il suffirait de standardiser les entêtes précompilés. Parce que dans le cas ou on utilise des macros, ce ne sont plus 2 fichiers qu'il faut filer, mais 3: .cpp, .h, .mpp
Et je trouve que beaucoup de codes utilisent des macros, l'air de rien...

Ça va plus loin que les entêtes précompilées. Parce qu'aujourd'hui, à cause entre autres des macros, mais pas seulement, finalement les entêtes précompilées ne peuvent pas être si précompilées que ça. Une inclusion préalable d'un autre fichier peut totalement changer le comportement d'un fichier existant. Du coup, on doit tout laisser ouvert. L'utilité des modules est là de dire qu'on a une frontière claire et nette à laquelle on n’acceptera pas d'être perturbés par d'autres personnes. Donc on a une vraie précompilation, là où la précompilation qui respecte les règles actuelles du C++ n'est que partielle.

Et du coup, comme on a une bibliothèque vraiment autonome, ça laisse au compilateur l'opportunité de faire du travail supplémentaire qu'autrement il ne peut faire qu'au link final (et qui est donc plus lourd), comme détecter si une fonction est pure...

[Niark13]

Envoyé par Freem

Pour l'accélération de la compilation, il semble que cette technique soit utilisée dans d'autres langages. J'aimerai savoir lesquels, histoire de pouvoir comparer?

Les modules sont dans D (http://www.d-programming-language.org) et DMD, le compilo de référence, est très très très rapide. Alexandrescu a fait un comparatif avec Go, en mesurant le temps que prend chaque langage à compiler sa bibliothèque standard et en les divisant par leurs nombre de lignes de code respectives.
Verdict : DMD est 4,2x plus rapide que le compilateur Go de Google.

[Ekleog]

Ou bien le D est 4,2x plus verbeux que le go ... A voir.

[Klaim]

Plus verbeux mais plus clair, rapide et explicite.


Alors à choisir l'un des deux, perso, je préfère de loin D


Enfin c'est pas le sujet de toutes manières.

Les modules tels qu'implémentés dans C#, Java, ActionScript entre autre font que la compilation est toujours de l'ordre de la seconde (notemment en C#).
Pour un très gros programme (fait de plusieurs modules et dépendances) de complexité équivalente en C# et en C++ j'ai vu le code C# se générer en quelques secondes alors que la version C++ a mis 30 minutes.

On arrivera certainement pas aux quelques secondes juste avec les modules en C++ parceque le language lui même complexifie aussi les choses, mais le simple fait de savoi à l'avance ce qui est dispo comme identifiants et de pouvoir récupérer leurs infos déjà préparées pour être compilés, sans avoir a recharger encore et recompiler encore des tonnes de fichiers, ben ça va quand même aider à se raprocher de la minute.


Et évidemmment je parle de projets où toutes les possibilités d'opitmization de compilation (niveau code et niveau configuration du compilateur) ont été mise en place, maiss ou effectivement il y a beaucoup d'inclusions de fichiers puisque l'essentiel du code est template et utilise boost::mpl entre autre. Autant dire que le programme C++ n'étiat pas aussi complexe en terme d'expression que la version C# et donc été bien plus optimisée, mais restait plus lente à compiler évidemment.


Un meilleur exemple du résultat potentiel des modules : les unity build (compiler tout le code du projet comme un seul fichier). Il y a plein de mesures qui démontrent que ça rends la compilation drastiquement plus rapide. D'un point de vue de l'organisation du compilateur en interne, avoir le modules c'est lui permettre de réorganiser son interpretation du code dnas une sorte de gros unity-build par projet et ensuite pouvoir se référer à la partie publique de cette build quand il compile d'autres projets.

[Niark13]

Envoyé par Klaim

Les modules tels qu'implémentés dans C#, Java, ActionScript entre autre font que la compilation est toujours de l'ordre de la seconde (notemment en C#).
Pour un très gros programme (fait de plusieurs modules et dépendances) de complexité équivalente en C# et en C++ j'ai vu le code C# se générer en quelques secondes alors que la version C++ a mis 30 minutes.

On arrivera certainement pas aux quelques secondes juste avec les modules en C++ parceque le language lui même complexifie aussi les choses, mais le simple fait de savoi à l'avance ce qui est dispo comme identifiants et de pouvoir récupérer leurs infos déjà préparées pour être compilés, sans avoir a recharger encore et recompiler encore des tonnes de fichiers, ben ça va quand même aider à se raprocher de la minute.


Et évidemmment je parle de projets où toutes les possibilités d'opitmization de compilation (niveau code et niveau configuration du compilateur) ont été mise en place, maiss ou effectivement il y a beaucoup d'inclusions de fichiers puisque l'essentiel du code est template et utilise boost::mpl entre autre. Autant dire que le programme C++ n'étiat pas aussi complexe en terme d'expression que la version C# et donc été bien plus optimisée, mais restait plus lente à compiler évidemment.


Un meilleur exemple du résultat potentiel des modules : les unity build (compiler tout le code du projet comme un seul fichier). Il y a plein de mesures qui démontrent que ça rends la compilation drastiquement plus rapide. D'un point de vue de l'organisation du compilateur en interne, avoir le modules c'est lui permettre de réorganiser son interpretation du code dnas une sorte de gros unity-build par projet et ensuite pouvoir se référer à la partie publique de cette build quand il compile d'autres projets.

Merci de ces précisions, j'avais volontairement écarté C# et Java, pensant que le fait qu'on compile vers un bytecode intermédiaire plutôt que du code natif faussait un peu le jeu. Et puis, D possède beaucoup de points communs avec C++, notamment ses capacités de méta-programmation, qui peuvent allonger les temps de compilation.

[Klaim]

Je viens de lire la courte proposition des scoped new. http://www.open-std.org/jtc1/sc22/wg...2012/n3348.pdf
Je crois qu'ils se sont raté sur les exemples, ils n'ont pas mis de namespace...

Pouvoir définir un new à utiliser par namespace ça serait le top (même si ça pourrait en embrouiller) surtout pour les bibliothèques.

[bountykiler]

Pour ma part

- concepts
Pas mal, mais c'est pas indispensable non plus.

- module
j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.

- filesystem
Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.

- date
Oui, ça manque aussi.

- range, coroutine, mémoire transactionnelle,
pas lu de quoi il s'agissait.

- string_ref
De ce que je comprens, l'idée est d'encapsuler les std::string& et d'en profiter pour y ajouter des méthodes qui n'existent pas pour le moment (style trim, split, ...).
J'avoue que je vois pas trop l'intérêt.
Par ailleurs, quelqu'un peut-il me dire pourquoi des méthodes telles que trim ou split n'ont toujours pas été ajoutées aux std::string? Y'a-t-il une raison technique à cela? Parce que perso, je trouve que cela reste une lacune.

- Fixed-point arithmetic, digit seperator
Doit probablement être utile à certain.

- concurrent queue
Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).

- stream mutex
pas lu ce que c'était, mais doit probablement amener à plus de facilité/sécurité/efficacité.

- static_if :
J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).

- Rich_pointer
pas encore lu.

Sinon, quelques autres idées en vrac :
* lambda class
Un peu comme cela existe en C#. On pourrait faire des trucs du style :

Code :

1
2
3
4
5
6
7
8
9
 
auto createUser(dataRow& row)
{
  return {
    id = row["id"].toInt(), 
    name = row["name"].toString(), 
    age = row["age"].toInt() 
  }; 
};

* concurent algo.
par exemple une std::concurent_foreach qui exécuterai la fonction passée en paramètre dans un thread différent pour chaque element (avec éventuellement un paramètre qui donnerait le nombre max de thread, pour éviter de créer 10 000 threads par ex).

* comme déjà dit plus haut, ajout dans la stl de la gestion des sockets&co + ajout de méthodes dans la classe std::string!!! (trim, split, join, format, ...).

* Enfin, "last but not least" : ajout de capacités de reflection au compile-time

Ainsi pour sérialiser un objet, on pourrait faire un truc du style :

Code :

1
2
3
4
5
6
7
8
 
template<typename T>
serialize(std::ostream& stream, const T& obj)
{
  static_foreach(typename fieldInfo : typeof(T)::fields) {
    stream << fieldInfo::get_value(obj);
  };
}

(j'avoue sur ce coup là j'me suis laché )
L'idée est que l'operator typeof renvoie une classe générée par le compilo contenant entre autre un type fields qui est lui même une liste de type (à géré via la notion de nombre indéfini de paramètres templates j'imagine, sinon via l'introduction des typelist dans la norme), chacun étant capable par exemple de retourner la valeur du champ en question sur base de l'objet passé en paramètre.
Au final, la méthode ci-dessus permettrai de sérialiser facilement n'importe quel type d'objet.


Des avis?


EDIT : Je viens de lire le document N3326 : "Sequential access to data members and base sub-objects".
En fait, cela présente un autre moyen de faire ce que je décrivait dans mon dernier point, en permettant la représentation de n'importe quel objet sous la forme d'un tuple. Ce que j'aime là-dedans c'est que cela est géré au moment de la compilation, un peu comme mon idée.
Là-dessus, moi je dis

[Klaim]

Envoyé par bountykiler

Pour ma part

- concepts
Pas mal, mais c'est pas indispensable non plus.

Tu ne fais pas souvent de bibliothèques template pas vrai?

- module
j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.

Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

Tu suggérerais quoi de meilleur?

- filesystem
Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)


- range, coroutine, mémoire transactionnelle,
pas lu de quoi il s'agissait.

Range c'est en gros une pair d'itérateurs, de manière écrire plus facilement les manipulations de "range" de données.

Coroutines c'est en gros simuler des threads dans un seul vrai thread : on execute du code pendant un temps puis on arrete et on passe à un autre code. Très utile pour faire des languages de scripts, mais je sais pas trop pour le reste.

Mémoire transactionnelle, c'est tout simplement pouvoir dire qu'un bloc entier de code (de manipulations de la mémoier) doit se passer de manièer transactionnelle : quand on rentre dedans, on fait des modifs de la mémoire, mais elles ne sont toutes appliquées qu'une fois le bloc fini.
Ca permet aussi au thread d'executer le code, de blocker a cause d'un autre thread qui l'éxecute déjà, d'annuler ses modifs de mémoire, de revenir au départ, d'attendre un peut et de retenter le coup, sans que tu ais à coder quoi que ce soit à part dire que c'est un bloc transactionel.

En gros ça permet de faire du multithreading simple, safe, et surtout sans manipuler de lock ou de thread.

- concurrent queue
Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).

Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.

- static_if :
J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).

Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.

[bountykiler]

Envoyé par Klaim

Tu ne fais pas souvent de bibliothèques template pas vrai?

ça m'arrive, mais c'est vrai que c'est pas l'essentiel de ce que je fais.

Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

Tu suggérerais quoi de meilleur?

J'ai jamais dis que j'avais une meilleure idée . Seulement, la solution des modules ajoute de la compléxité je trouve, ce qui n'est pas top.
Sinon, il me semble avoir lu que les .mpp serait lisibles par un programmeur (ce qui serait mieux en effet).

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)

Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.

Ben pour une liste, tu peux mettre un verrou par element par exemple. Pour les maps, y'a surement moyen de faire le même style de chose. Après, possible que cela engendre trop de contraintes qui les rendent inutilisable en pratique.
Je vais essayer de jeter un oeil du coté de boost.

Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.

Je disai cela comme ça, mais j'en pas sur non plus. En fait, je pense qu'il y a moyen de faire cela autrement, sans nécessiter l'ajout de mot clé à la norme.

Sinon j'ai aussi lu la doc concernant les rich pointer. Je dirai bof bof. Je préfère de loin la solution des "Sequential access to data members and base sub-objects". (les 2 propositions ciblent le même problème à la base, à savoir l'introspection de type).

[Emmanuel Deloget]

Envoyé par cob59

on pourrait enfin croiser un dev Java sans baisser les yeux.

Bah, il suffit de lui parler de string.compare() et c'est lui qui baisse les yeux, après un soupir et une petite phrase désespérée du type "je sais...".

Envoyé par Klaim

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)

J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.

[authchir]

Envoyé par Emmanuel Deloget

J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.

Intéressant, à quoi fais-tu allusion en particulier?

[Klaim]

J'imagine qu'il parle de la conséquence d''avoir des lambda, move-semantic, type inférence, etc. Tout ce qui aide à mort syntactiquement parceque c'est vrai que tout le "bordel" a mettre en place en C++03 pour que asio marche rends le code un peut répulsif au premier regard.

[Niark13]

J'apprécierais que les concepts soient écartés au profit de template constraints à la D, qui servent au final à la même chose, tout en étant beaucoup plus légers au niveau de la syntaxe et des changements à apporter au langage :

Pour ceux qui ne connaissent pas, les templates constraints sont un simple static if à la fin d'une déclaration de template qui conditionne leur instanciation :

Code :

1
2
3
4
5
 
template Toto(T) if condition
{
    // code...
}

si la condition n'est pas remplie, cette déclaration de Toto ne sera pas utilisée pour pour l'instanciation. La condition est evaluée à la compilation. Rien n'empêche d'avoir plus loin une autre déclaration d'un autre template homonyme, mais spécialisé avec des contraintes différentes.
Si aucune condition n'est trouvée, le compilateur émet une erreur indiquant qu'il n'a plus trouver de template à instancier.

Plus d'infos : http://erdani.com/d/new-stdio/concepts.html

[Klaim]

Comme expliqué dans les propositions du commité, les concepts sont un mix de contraintes tel que dans D mais avec en plus une notion de sémantique.

Du coup théoriquement c'est plus expressif que des contraintes (et tu peux déjà voir l'interet avec ConceptClang).

[Emmanuel Deloget]

Envoyé par Klaim

J'imagine qu'il parle de la conséquence d''avoir des lambda, move-semantic, type inférence, etc. Tout ce qui aide à mort syntactiquement parceque c'est vrai que tout le "bordel" a mettre en place en C++03 pour que asio marche rends le code un peut répulsif au premier regard.

Il n'y a pas que le code qui soit un peu répulsif - de toute façon, si asio fait un jour partie de la librairie standard, on aura pas besoin de regarder le code. Il y a plein de choses dans le design d'asio qui ne me plaisent pas, mais alors pas du tout. En voici quelques exemples :

* l'utilisation nécessaire de shared_ptr dès lors qu'on traite des sockets dans une thread qui ne l'a pas créé (ce qui arrive fréquemment, dès lors qu'on fait un programme multi-threadé ou les connections entrantes sont gérées par un pool de thread) . Ce point a été récemment limité avec l'arrivée d'une sémantique de déplacement dans les sockets. A noter quand même que la sémantique de déplacement existait déjà en C++ avant l'introduction des move ctor : il suffisait de créer un constructeur "par copie" dont l'argument n'était pas const. C'est ce que faisait auto_ptr<>. Le résultat n'est pas safe dans tous les cas, mais ça a toujours été possible).

* certains objets qui n'encapsulent en fait qu'une seule fonction (avec des variantes d'implémentation). cf les classes resolver (dans ce cas précis, une fonction libre aurait été plus approprié).

* les noms d'objet qui n'ont pas de sens (exemple : io_service ; rien qu'en lisant le nom, est-ce que quelqu'un peut me dire ce que ça fait ?), ou qui engendrent une confusion avec le nom de la fonction qu'ils encapsulent (cf. les classes acceptor, qui ne font pas que l'accept() - loin de là). Cette clase est en fait pire que ça : acceptor::listen ne fait pas de listen mais mets la socket dans un état qui lui permet d'être utilisé pour faire un listen, et acceptor::accept ne fait pas le polling (qui est en fait fait par io_service).

* la gestion des io async/sync : les sockets ont des méthodes read et read_async, et l'une d'elle n'a pas de sens. Certains OS ne permettent pas la création de sockets utilisable simultanément dans les deux modes (par exemple, les OS POSIX l'autorise, mais pas Windows). Dans le princpipe, de toute façon, une socket async n'est pas une socket sync, et il n'y a pas de raison que le type de l'objet soit le même (ou pire, que la vérification de la possibilité du traitement se fasse au runtime).

Il y a encore d'autres points mineurs, mais je ne vais pas faire un inventaire à la Prévert

Après, il y a de bonnes idées : les strand, l'idée de base sur les endpoint, etc. Mais tout n'est pas bon à manger dans asio.

[Klaim]

Emmanuel> Merci pour les feedbacks! Donc ya pas que moi qui trouve cela étrangement difficile à comprendre, surtout à cause du nommage...


Sinon, il y en a ici qui participent au premier rdv post-C++11 du commité. Si oui ça serait cool qu'on ai des infos sur ce qui se dit...