Discussion :

[Invité]

Bonsoir,
J'ai vraiment l'impression qu'on s'éloigne de la finalité d'un langage qui consiste à procurer une interface entre l'homme et la machine.
Par manque de compétence, je ne critique pas les options (et non pas les possibilités) du C++, mais dans la mesure où cela provoque de telles discussions, je me demande si ces limitations -cad C différent de C++ et vice versa- ont vraiment une justification.
Les différences de sémantique (j'adore ce terme) s'adressent et concernent les individus et non la machine. Par la machine la seule chose qui est une réalité est qu'un bit est activé ou non, et qu'un mot (un octet) est composé de 8 bits.
Ceci est mon avis.
Bonne nuit.

[_skip]

Pour recadrer un peu le débat, quelles sont nos chances d'un meilleur C++?
On a pu constater que le processus de normalisation est compliqué et que les cycles d'évolution sont de fait, plutôt longs (voir C++1x).

Actuellement j'ai l'impression que le C++ est un peu paralysé dans son évolution par sa volonté d'être source compatible C et surtout à cause de l'immensité des bases de codes existantes.
Y'a-t-il des gens ici qui pensent qu'il serait préférable pour le comité de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?

[hiura]

Pour recadrer un peu le débat, quelles sont nos chances d'un meilleur C++?
On a pu constater que le processus de normalisation est compliqué et que les cycles d'évolution sont de fait, plutôt longs (voir C++1x).

Actuellement j'ai l'impression que le C++ est un peu paralysé dans son évolution par sa volonté d'être source compatible C et surtout à cause de l'immensité des bases de codes existantes.
Y'a-t-il des gens ici qui pensent qu'il serait préférable pour le comité de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?

Il est bien évident que je ne suis pas un expert et de ce fait mon avis peut être erroné mais il me semble aussi que partir sur une nouvelle base aurait de bons côtés.
Mais est-ce le rôle du C++ d'évoluer vers un «C far away» (hohoho, … ) / D++ ? Ou est-ce plutôt le rôle d'un nouvel arrivant (le D par exemple) ? Je sais pas.

[Klaim]

Pour recadrer un peu le débat, quelles sont nos chances d'un meilleur C++?
On a pu constater que le processus de normalisation est compliqué et que les cycles d'évolution sont de fait, plutôt longs (voir C++1x).

Actuellement j'ai l'impression que le C++ est un peu paralysé dans son évolution par sa volonté d'être source compatible C et surtout à cause de l'immensité des bases de codes existantes.
Y'a-t-il des gens ici qui pensent qu'il serait préférable pour le comité de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?

Non.
Les deux ont des différences qui me semblent trop importantes pour qu'on en laisse un pour l'autre.

Par contre un C++ 2.0 qui aurait principalement comme absence de contrainte liée au C serait je pense plus efficace. Surtout si on en profite pour virer tout ce qui est considéré comme mauvais dans le C++11 mais qu'on ne pouvais pas enlever a cause de la rétrocompatibilité. Nettoyer le language des expressions redondantes aussi serait pas mal (par exemple ne plus avoir qu'une seule syntaxe pour les typedef, plutot using que typedef d'ailleurs. )

[befalimpertinent]

Difficile d'être d'accord avec ça étant donné que je penses que la force du C++ est justement cette ("quasi") rétrocompatibilité. Ce qui fait que le C++ soit à l'heure actuel toujours aussi présent dans l'industrie tient justement au fait qu'un code écrit il y a 20 ans compile encore avec les compilos actuels (ok a 2-3 bidouilles prêts parfois mais du uniquement au laxisme des compilos de l'époque). Casser ça c'est se tiré une balle dans le pied (ou alors par pitié ne l'appeler plus C++ mais D quelque chose ).
Encore aujourd'hui je ne suis pas loin de penser que quand on veut faire du développement un peu sérieux qui tienne la route et surtout la durée, le C++ doit être privilégier, au moins on peut avoir l'espoir qu'il compilera encore dans 15 ans.

En définitive marquer certaines pratiques en "deprecated" pourquoi pas, les interdire non.

[Florian Goo]

Actuellement j'ai l'impression que le C++ est un peu paralysé dans son évolution par sa volonté d'être source compatible C et surtout à cause de l'immensité des bases de codes existantes.
Y'a-t-il des gens ici qui pensent qu'il serait préférable pour le comité de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?

J'en rêve !

D'autant plus que (comme je l'ai déjà dit ici) on pourrait continuer à profiter de la base de code existante à coups de :

Code :

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

1
2
3
4
extern "legacy-C++"
{
    /*...*/
}

[Klaim]

Difficile d'être d'accord avec ça étant donné que je penses que la force du C++ est justement cette ("quasi") rétrocompatibilité. Ce qui fait que le C++ soit à l'heure actuel toujours aussi présent dans l'industrie tient justement au fait qu'un code écrit il y a 20 ans compile encore avec les compilos actuels (ok a 2-3 bidouilles prêts parfois mais du uniquement au laxisme des compilos de l'époque). Casser ça c'est se tiré une balle dans le pied (ou alors par pitié ne l'appeler plus C++ mais D quelque chose ).
Encore aujourd'hui je ne suis pas loin de penser que quand on veut faire du développement un peu sérieux qui tienne la route et surtout la durée, le C++ doit être privilégier, au moins on peut avoir l'espoir qu'il compilera encore dans 15 ans.

En définitive marquer certaines pratiques en "deprecated" pourquoi pas, les interdire non.

On est d'accord que la compatibilité avec le C et la rétrocompatibilité globale du language est une force.

Cela n'empêche pas qu'une nettoyage du language, dans une version différente (je parle d'un fork en gros, pas d'une suite), qui serait rétro compatible avec la dernière norme C++ mais pas avec les précédentes serait aussi interessante et permettrais de se baser sur la base de code en C++03 qui n'aurait pas de "C pure".

Cela dit c'est une idée qui n'est pas réfléchie a l'extreme, il n'y a pas un commité de spécialiste dérrière.

[raphamil]

un autre que je trouve plus problématique s'admire sur la signature du main standard : int main(int argc, char **argv) et ses dérivés avec le char* argv[], on a une bibliothèque standard avec quand même pas mal de choses MAIS pour l'entrée d'un programme on régresse du c++ vers le c; pour rester dans le c++ quelque chose du style de int main(vector<string> args) aurait été plus approprié selon moi.

Code :

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

std::vector<std::string> args(argv, argv + argc);

[Invité]

Oui, effectivement, d'ailleurs, pourquoi continuer à faire simple alors qu'on pourrait faire compliqué?
Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres
Donc, mon avis, laissez le C++ comme il est. Il y une quantité d'autres langages et pour tous les goûts. Au moins, celui-là, il a fait ses preuves.

[hiura]

Oui, effectivement, d'ailleurs, pourquoi continuer à faire simple alors qu'on pourrait faire compliqué?
Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres
Donc, mon avis, laissez le C++ comme il est. Il y une quantité d'autres langages et pour tous les goûts. Au moins, celui-là, il a fait ses preuves.

ça m'est arrivé il y a pas si longtemps que ça. Du coup un petit coup de boost et c'est goal.

[Klaim]

Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramètres? Moi, ça fait bien une vingtaine d'années que je ne travaille plus qu'avec des fenêtres

C'est orthogonal : quasiment tous les jeux vidéos sur PC/windows que je fais (donc fenetrés) ont des paramettres d'execution.

C'est un peu naif de supposer que ce n'est pas utile parceque toi tu n'en as plus besoin. Même la plupart des applications windows ont des paramètres, c'est juste que toi tu n'as jamais eu a les utiliser.
Ne serait-ce que les compilateurs. Et les solutions de control de source. (les gui qui vont avec sont construits par dessus - si ces solutions n'étaient pas en ligne de commande de base, ça aurait compliqué les choses)
Et je te parle même pas des applications sous unix-like.

[Florian Goo]

En effet. Firefox lui-même a des options d'exécution très pratiques (gestion de profils multiples).

Il est également très utile de faire des petits programmes en ligne de commande pour tester une bibliothèque en développement (tests de non-régression, démonstration, tout ça).

[Invité]

Bon, je vois que ce problème de paramètres du main est très préoccupant
J'imagine bien que cela doit être très traumatisant d'avoir un programme où on a banni tous les char*, les new, où on a remplacé les simples transtypage par des <dymamic_cast> etc et qu'il puisse exister encore une ligne où il reste cette horrible chose char* d'autant plus qu'on lui en rajoute un (*) supplémentaire.
C'est d'autant plus énervant que la syntaxe de cette ligne est la même qu'en C, qu'on a réussi à rendre presque tout "différent du C", au prix de réelles complications, il est vrai, mais là, échec total .
Comme je devinais que ce devait être très important pour certains, hier j'ai pensé à préciser la méthode, suggérée par raphamil, pour arranger cela :

Code :

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

1
2
3
4
5
int main(int argc, char** argv)
{
  std::vector<std::string> args(argv, argv + argc);
  return MyMain(args);
}

Et là on aura une fonction parfaitement propre, saine et beaucoup plus claire : MyMain

Pour essayer d'être un peu plus sérieux et plus constructif, serait-il possible de dresser un résumé des points correspondants au sujet posé, c'est à dire : "Quel est pour vous le défaut le plus gênant en C++"
Moi, je mettrais comme première qualité : parce qu'il traite toutes les instructions, la logique, l'organisation etc. du C (Oh pardon, on demande les défauts )

Réponse à Florian.
Bien sûr qu'on écrit des programmes en ligne de commande. Ma question, à propos de la dernière fois que c'est arrivé, j'aurais pu la poser de cette façon : Quel pourcentage de lignes de code cela représente-t-il ? Traduction : est-ce un défaut du C++ pour que cela vaille le coup d'en parler ici?
Personnellement, j'adore la technique qui consiste à trouver une objection à un interlocuteur pour être sûr de pouvoir éviter d'aborder le sujet principal.

[Klaim]

Vu qu'il y a une bibliothèque de boost consacrée au sujet, je suppose que oui.

Sinon personellement je préfère ne pas drésser de liste parceque je ne sais pas encore clairement a quel point la nouvelle norme simplifie les choses. Cela dit, la standardisation d'un système de module (entre autre pour accélérer les compilations) et le problème du temps trop long pour implémenter le standard seraient dans le haut de ma liste des problèmes.
J'ajouterais aussi l'absence des Concepts mais bon c'est un sujet un peu difficile a discuter actuellement, tant qu'il n'y aura pas une nouvelle tentative d'implémentation.

[Florian Goo]

Réponse à Florian.
Bien sûr qu'on écrit des programmes en ligne de commande. Ma question, à propos de la dernière fois que c'est arrivé, j'aurais pu la poser de cette façon : Quel pourcentage de lignes de code cela représente-t-il ? Traduction : est-ce un défaut du C++ pour que cela vaille le coup d'en parler ici?
Personnellement, j'adore la technique qui consiste à trouver une objection à un interlocuteur pour être sûr de pouvoir éviter d'aborder le sujet principal.

Ah non, y'a méprise. Pas de tentative de manipulation de ma part, je me suis juste laissé emporté par le hors-sujet.

Pour moi, la raison d'existence du main C-style est surtout historique, la STL était apparue plus tard dans l'évolution du C++.
Autrement je ne trouve pas que ce soit un énorme problème. Au contraire, c'est même mieux comme ça : pas de création d'objets donc pas d'overhead si ce n'est pas désiré. Et si on le souhaite, une petite ligne de code suffit à créer un vector de strings.
C'est dans l'esprit du C++ : on ne paie pas pour ce qu'on n'utilise pas et on peut redescendre aussi bas niveau qu'on en a envie/besoin.

[davcha]

A noter que strnlen existe et a pour principale utilité de produire un code sûr, comme toutes les fonctions strn*.

Sinon, y'a que moi qui trouve que l'un des grands défauts du C++ est d'être semblable aux navigateurs web il y a quelques années ?
D'ailleurs, la discussion sur les strings vs tableaux de byte en témoigne : c'est un véritable bourbier où la sémantique est totalement maltraitée, battue, voire même ignorée.

Sérieusement, qui n'a jamais connu un gamin sorti d'école qui se prend pour un programmeur super-cool super-balaise, tout en produisant du code C/C++ (surtout C++) illisible ?

Pour moi, c'est ça LE gros défaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand même...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mélange pas tout sans arrêt, sinon, bonjour la prise de tête.

[ac_wingless]

Les défauts qui me (je reconnais le biais induit par mon domaine de travail, l'embarqué industriel) gênent le plus sont, dans l'ordre:

1 - la difficulté de compilation du langage, qui a pour conséquences:

1a) les petites différences entre comportements des compilateurs, d'où l'impossibilité de généraliser dans des grands projets les techniques avancées du C++ ou de Boost
1b) le manque de réactivité/qualité des outils IDE de traitement du code (exploration de classe, refactoring, etc.)
1c) les temps de compilation

2 - la coexistence des chaines destinées aux humains (Unicode) et aux API (char *) n'est pas bien gérée par la bibliothèque standard. On y arrive, mais c'est loin d'être aussi propre que dans d'autres environnements.

3 - les exceptions ne sont pas acceptés dans les projets industriels embarqués, et il faut admettre que c'est pour de bonnes raisons. Il faut vraiment que le standard explore d'autres possibilités. Malheureusement il faut aussi reconnaitre que les solutions industrielles alternatives sont très loin d'être unifiées.

4 - la méta-programmation trop complexe. Ce sont des béquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes. Mais outre ce que j'ai évoqué en 1a, j'ai constaté un manque de productivité net pour les programmeurs non-experts lorsqu'ils découvrent ces techniques. Je dois me battre sur les check-ins de certains pour interdire la recherche de l'élégance pour l'élégance, qui est parfois bénéfique dans la plupart des portions de code mais PAS dans la méta-programmation complexe.


Les faux défauts pour moi:
1 - le mauvais diagnostic des erreurs de méta programmation. C'est plus rigolo que gênant. Les stagiaires se la pètent à celui qui fera la plus grosse, mais dans la vraie vie ce n'est pas une source perceptible de perte de temps.

2 - les erreurs de pointeurs. Ça fait des années que nous n'avons pas eu de retour client sur ce genre de bug. Et pourtant, nous travaillons dans l'embarqué, on est loin d'avoir les Go de matelas des applications PC.

3 - la bibliothèque standard réduite ne gêne pas dans l'embarqué.

[gl]

A noter que strnlen existe et a pour principale utilité de produire un code sûr, comme toutes les fonctions strn*.

Ce n'est pas du C++ standard (ni du C ou Posix) mais une extension GNU.

Pour moi, c'est ça LE gros défaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand même...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mélange pas tout sans arrêt, sinon, bonjour la prise de tête.

Et pourtant, cette caractéristique du C++ (pouvoir choisir le niveau d'abstraction utilisé ou mixer les niveaux d'abstraction) est assez souvent vu plutôt comme un avantage que comme un inconvénient.

Ce sont des béquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes.

A quoi fais-tu allusion ici ?

[davcha]

Et pourtant, cette caractéristique du C++ (pouvoir choisir le niveau d'abstraction utilisé ou mixer les niveaux d'abstraction) est assez souvent vu plutôt comme un avantage que comme un inconvénient.

En temps normal, je dirais que c'est un avantage, en effet. Mais dans le cas présent... Trop de mauvais devs, sûrement.

[®om]

Le plus gênant dans le C++, c'est qu'il soit utilisé par les terroristes