Discussion :

[Invité]

Totalement faux : avant sa normalisation, on comptait quasiment autant d'implémentations du langage que de plateformes.

Florian, j'ai le double ton âge. L'époque dont tu parles , je faisais du C 18h/j sur compilos unix Dos, cross compiler intel->6809 et deux sur Atari St.
soit une 10zaine de compilateurs.

La norme était très "normale" K&R pb:mémoire video , codage des entiers HSB LSB intel contre motorola
Mais tout ça était hors norme. En 10 ans de C, j'ai fini par comprendre la subtilité , les limites

La portabilité n'a jamais été parfaite , les #ifdef #else servaient à ça souvent et marchaient parfaitement

Désolé si j'ai exagéré mais , votre direction "philosophique" ne correspond pas à mon vécu pourtant très orienté c/c++ et très international

Vous etes faché avec C mais si vous devez choisir entre un projet sur lanceur soyouz et le C++ (vous savez pourquoi je dis ça..) vous renoncerez au projet soyouz ? ariane ? plutot que de vous abaisser au C ?

Quand je suis parti programmer ailleurs, léducation nationale faisait une fixation sur Pascal et ce "détail" m'a fait quitter la fac !!!!
Maintenant les jeunes diplomés ne touchent plus à linux ! ! je comprends mal la France , ses choix

"philosophie des langages "

[hegros]

L'article présente les défauts en deux parties. Parmi ceux qui gênent l'auteur, on trouve:

Le temps de compilation et la gestion des dépendances
La bibliothèque standard, qu'il juge réduite.
Le manque de réflexivité et la déduction des types
Les messages d'erreurs des templates
Le support de l'internationalisation sur la bibliothèque standard

1/ Pas d'accord sur le temps de compilation et d'accord avec la gestion des dépendances. D'une part parce que bien que certains programment nécessitent près de 24H pour compiler (KDE ? Gnome ? Seven ?) cela me semble normal et il serait difficile de faire mieux avec un gain important avec autre chose. Et d'autre part, la gestion des dépendances je la trouve lourde probablement à cause du manque d'outil de fichiers qu'il faut trimballer dû au mode un fichier de déclaration et un fichier d'implémentation.

2/D'accord, l'exemple le plus frappant est sur la couche UI et accès aux données (SGBD par exemple, pas un simple fichier texte) il n'y a toujours rien de standardisé à ce que je sache.

3/Plutôt d'accord, d'ailleurs je me demande si le c++ est un langage à typage fort ou qu'il n'existerait justement pas un niveau typage très fort lorsqu'il est possible de faire de la réflexivité, de l'inférence ou autre chose de plus avancé concernant la gestion des types de données (comme la sérialisation/désérialisation de type en xml par exemple)

4/Plutôt d'accord, n'étant pas un praticien assidu en C++ pour les rares occasions où j'ai utilisé ou repris des templates les messages d'erreurs ne sont pas forcément explicite. J'aurai tendance à vouloir les isoler dans un projet séparemment avec en sortie un composant comme une lib ou une dll rien que pour isoler les messages erreurs

5/Pas d'accord. Par rapport à ce qui existe autour comme langage le c++ doit resté dans la moyenne. Les moulinettes maisons pour l'internationalisation marche assez bien aussi.

Parmi les défauts souvent pointés du doigt et qui ne le gênent pas, il cite :

La gestion et la corruption de la mémoire
La gestion du multitâche
Le support des chaines de caractères
Les exceptions
STL, Boost et les templates en général

1/Cela est un peu gênant
2/Cela n'est pas gênant
3/Pour l'internationalisation oui cela pourrait être gênant
4/Cela n'est pas gênant plus que cela.
5/Cela ne me gêne pas ce sont des composants très riche de ce que l'on peux attendre d'un framework

Et pour vous, quel est le défaut le plus gênant du C++ ?

Un aspect mythique et mystique avec le C

Ensuite 1/une bibliothèque standard trop réduite 2/Une utilisation abusive ou centrale du pré-processeur 3/La séparation entre fichier d'interface et d'implémentation 4/ Un manque dans la gestion des types 5/un manque de sécurité exécution et mémoire

[Invité]

1/une bibliothèque standard trop réduite 2/Une utilisation abusive ou centrale du pré-processeur 3/La séparation entre fichier d'interface et d'implémentation 4/ Un manque dans la gestion des types 5/un manque de sécurité exécution et mémoire

le preprocesseur était un enfer sous MFC
Pourtant sous audacity , le préprocesseur est minimal

Donc à ce stade plus concret , si on ne définit pas un ensemble de projets open-source de référence, les arguments vont de oui à non sans prévenir !

J'ai codeBlocks et visualStudio installés.
Y-a-til un projet qu'on peut downloader pour illustrer ?

[hegros]

le preprocesseur était un enfer sous MFC
Pourtant sous audacity , le préprocesseur est minimal

Donc à ce stade plus concret , si on ne définit pas un ensemble de projets open-source de référence, les arguments vont de oui à non sans prévenir !

J'ai codeBlocks et visualStudio installés.
Y-a-til un projet qu'on peut downloader pour illustrer ?

Quel critères et quelle valuation à chacun pour mesurer la non-qualité du pré processeur ? C'était un enfer sous quel aspect ?

Ma remarque sur le pré-processeur c'est plutôt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fondée sur les templates. C'est là plus un défaut d'architecture de bibliothèque qu'un défaut de performances.

Il faut des critères de référence avant de choisir des projets à comparer pourquoi ne pas prendre un arbre qualimètrique ISO c'est plutôt un échange sur les +/- du langage il doit exister quelques sources de comparaison sur le pré-processeur par langage ou par environnement de développement

[Invité]

Quel critères et quelle valuation à chacun pour mesurer la non-qualité du pré processeur ? C'était un enfer sous quel aspect ?

Ma remarque sur le pré-processeur c'est plutôt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fondée sur les templates. C'est là plus un défaut d'architecture de bibliothèque qu'un défaut de performances.

Il faut des critères de référence avant de choisir des projets à comparer pourquoi ne pas prendre un arbre qualimètrique ISO c'est plutôt un échange sur les +/- du langage il doit exister quelques sources de comparaison sur le pré-processeur par langage ou par environnement de développement

MFC 6 décrivait les controles de forms dans des constantes. L'ancien activeX nécessitait un clsID, les propriétés de controles et les events stockés dans un .hpp précompilé. Celui-ci devenait énorme et instable (plusieurs dizaines de mb)

ok , une urgence en C# qui vient de tomber , je vais me raréfier sur les vieux langages mystiques (15 ans de boulot pour demain matin ) bonne chance

[pseudocode]

Le se fait de pouvoir décider de travailler selon trois paradigmes distincts, alors que d'autres langages ne donnent pas cette possibilité de choix, suffit déjà à provoquer une certaine complexité.

Et ca, c'est le prix à payer pour pouvoir apporter des solutions plus particulières à des problèmes particuliers

Je considère en effet, à l'instar de nombreux C++istes, que l'orienté objet ne résout pas tous les problèmes, et qu'une approche multi paradigme permet facilement de contourner les problèmes propres à chacun d'eux.

100% d'accord avec cette dernière phrase. Cependant le multi paradigme n'implique pas forcément de pouvoir mélanger deux langages dans un meme bloc de code, voir dans une meme ligne. Un barrière, au moins syntaxique comme le suggère Florian Goo, me paraitrait déjà un mieux. D'ailleurs, je vois de moins en moins d'encart assembleur dans les code C/C++, certainement a cause de cela.

[koala01]

100% d'accord avec cette dernière phrase. Cependant le multi paradigme n'implique pas forcément de pouvoir mélanger deux langages dans un meme bloc de code, voir dans une meme ligne. Un barrière, au moins syntaxique comme le suggère Florian Goo, me paraitrait déjà un mieux. D'ailleurs, je vois de moins en moins d'encart assembleur dans les code C/C++, certainement a cause de cela.

Je n'ai pas parlé de mélanger deux langages, mais deux paradigmes, et ca, ca se fait pour le moins régulièrement:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
template <class T>
class TBase
{
};
class Derivee : public TBase<Derivee>
{
};
/*==========================================*/
class MaClass
{
    public:
        template<iterator>
        MaClass(iterator b, iterator e):items_(b,e){}
        size_t foo() const{}
    private:
        std::vector<un_type> items_;
};
bool operator==(MaClass const & c1, MaClass const & c2)
{
    return c1.foo()==c2.foo();
}

Et ce ne sont que des exemples vite faits qui facilitent énormément les choses par rapport à l'OO "pur et dur"

[pseudocode]

Et ce ne sont que des exemples vite faits qui facilitent énormément les choses par rapport à l'OO "pur et dur"

C'est clair que c'est pratique. Quand je pense qu'en Java c'est la galère pour qu'une méthode retourne deux "int".

Après, je suis prêt a sacrifier un peu de cette puissance au profit d'une meilleure homogénéité du code. En particulier dans un contexte industriel, où la maintenance sur le long terme est tout aussi importante (voir plus) que la concision du code source.

[koala01]

C'est clair que c'est pratique. Quand je pense qu'en Java c'est la galère pour qu'une méthode retourne deux "int".

Il n'y a aucune fonction qui retourne deux int ici, il y a un opérateur qui compare le résultat d'une fonction membre particulière pour déterminer si deux instances sont égales.

Après, je suis prêt a sacrifier un peu de cette puissance au profit d'une meilleure homogénéité du code. En particulier dans un contexte industriel, où la maintenance sur le long terme est tout aussi importante (voir plus) que la concision du code source.

Cela veut-il dire que tu considère que

Code :

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

if(instance1.equal(instance2))

sera plus facilement maintenable que

Code :

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

if(instance1==instance2)

A partir du moment où l'on est d'accord sur la sémantique des opérateurs, je ne vois pas vraiment pourquoi ils s'avéreraient moins maintenable

Et puis, un code proche de celui que je propose (surtout pour l'opérateur ==) est il vraiment si peu homogène, sachant que cela permet la réflexibilité de l'opérateur ( A==B est identique à B==A, même si une conversion implicite a lieu )

[Florian Goo]

Vous etes faché avec C mais si vous devez choisir entre un projet sur lanceur soyouz et le C++ (vous savez pourquoi je dis ça..) vous renoncerez au projet soyouz ? ariane ? plutot que de vous abaisser au C ?

Non non, je ne suis pas du tout fâché avec le C !
Certes, la dernière fois que j'ai eu l'occasion de coder en C remonte à 2 ou 3 ans, mais j'ai réalisé quelques projets fort sympathiques comprenant l'écriture de firmwares en C sur microcontrôleurs. Je dois même reconnaître que ça me manque un peu.

La seule chose avec laquelle je suis fâché, c'est l'amalgame C/C++ que certains membres prônent, selon moi, à tort.

(vous savez pourquoi je dis ça..)

Désolé, je n'ai pas saisi !

Quand je suis parti programmer ailleurs, léducation nationale faisait une fixation sur Pascal et ce "détail" m'a fait quitter la fac !!!!
Maintenant les jeunes diplomés ne touchent plus à linux ! ! je comprends mal la France , ses choix

J'écris ce message depuis ma distribution Linux préférée .
Je sors d'une école d'ingénieurs où l'initiation à la programmation se fait en C, avec des TP réalisés sous Linux. Je pense que la fixation sur le Pascal n'est plus d'actualité.

En revanche, je rejoignais totalement ton propos sur le sujet « Les développeurs peuvent-ils faire de bons managers ? ». La vision de la France sur ce plan est vraiment absurde.

Sur le coup (Linux, Pascal et le principe de Peter) tu ne peux pas m'associer à ce que tu perçois de la philosophie française .

[pseudocode]

Il n'y a aucune fonction qui retourne deux int ici, il y a un opérateur qui compare le résultat d'une fonction membre particulière pour déterminer si deux instances sont égales.

Yes. J'ai beau pas être un virtuose du C++, j'avais remarqué.

Ma remarque était pour accentuer le fait que le mono-paradigme OO de Java empêche de retourner l'équivalent d'une "struct" mais impose de retourner une instance d'objet. Ce qui est tout de meme très gênant d'un point de vue conceptuel, car il n'y a pas de raison sémantique de définir une classe pour résoudre ce qui n'est qu'un problème de code.

Cela veut-il dire que tu considère que

Code :

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

if(instance1.equal(instance2))

sera plus facilement maintenable que

Code :

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

if(instance1==instance2)

A partir du moment où l'on est d'accord sur la sémantique des opérateurs, je ne vois pas vraiment pourquoi ils s'avéreraient moins maintenable

C'est justement parce qu'il n'y a pas de moyen d'être d'accord sur la sémantique des opérateurs à moins de faire une revue exhaustive du code source. A partir du moment où il est permis de redéfinir un opérateur, voir un mot clé du langage, il n'y a pas possibilité de présupposer de ce que fait une simple comparaison.

Pour moi, la première forme (.equal()) peut renvoyer true, false, 0, -1, "hello world", voir lever une exception, afficher du texte, ou faire un exit(). Bref tout ce que peut faire un appel de méthode.

Mais en fait, la deuxième aussi. Sauf que c'est moins visible au premier coup d'oeil. Et donc le risque est plus grand de faire l'impasse sur toutes ces possibilités, et de se contenter de croire que le "==" est un opérateur du langage qui compare deux valeurs et renvoie un booléen.

Dans un contexte de dev projet, je préfère un langage qui me permet facilement de savoir ce que peut faire (ou ne pas faire) une ligne de code. Dans un contexte de dev perso, évidemment ca s'applique moins, étant donné que j'ai naturellement tendance a me faire confiance.

[cyrianox]

J'ai toujours adoré la syntaxe C/C++ : propre, concise et précise.
Par contre, pour ceux qui codent dans plusieurs langage, revenir au C/C++ après quelques mois d'autre chose, ce n'est pas évident.. (surtout quand on s'habitue au confort des editeurs qui affichent en temps réel les erreurs possibles).

[hiura]

Pour:
Une référence par jour éloigne du docteur.
Le polymorphisme est très subtile et précis. (Pas comme JAVA, voir discussion sur virtual plus haut, héritage multiple.)
La S(T)L est très bien conçue (heureusement me diriez vous!) : pas d'interdépendances dans TOUS les sens comme avec l'API JAVA.
Le mot clef const. (Pas besoin de se farcir deux version (mutable/immutable) de chaque outils.)
La séparation .h(pp)/.c(pp) qui permet d'avoir l'API publique à porté de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos…)

Neutre: (voire remarque de koala (désolé si j'écorche, les iPod c'est pas pratique pour tout) ; en résumé ce n'est pas C++ qu'il faut blâmer mais les dev.)
L'enseignement médiocre voire absent ! Quand j'ai appris que les ingénieurs "computer science" de l'EPFL n'avaient pas de cours sur le C++ je suis tombé des nues! Par contre on est bombardé de JAVA

Contre:
La S(T)L est petite.
[discutable]Pas de norme graphique -> trop de maux pour faire du portable. Mais ceci est discutable pour deux raisons :
1) Est-ce au langage de s'occuper de ça ?
2) Veut-on se retrouver avec un sosie de JAVA ?

[pseudocode]

Pour:
Une référence par jour éloigne du docteur.
Le polymorphisme est très subtile et précis. (Pas comme JAVA, voir discussion sur virtual plus haut, héritage multiple.)
La S(T)L est très bien conçue (heureusement me diriez vous!) : pas d'interdépendances dans TOUS les sens comme avec l'API JAVA.
Le mot clef const. (Pas besoin de se farcir deux version (mutable/immutable) de chaque outils.)
La séparation .h(pp)/.c(pp) qui permet d'avoir l'API publique à porté de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos…)

hum... Meme si Java a des défauts, faut quand meme pas en rajouter. Critiquer autant la librairie standard de Java, c'est un peu "too much", sachant que l'une des premières choses qu'on fait généralement quand on débute un projet d'envergure en C++ c'est de se choisir une bonne librairie additionnelle.

Ceci dit, c'est vrai que la précision qu'on peut définir sur les structures de données est un gros + du C++ . Le prix a payer étant une syntaxe souvent compliquée, avec moult symboles et mots-clés.

[divxdede]

a- Parfois j'ai l'impression que les gens critiquent les vélos parce qu'ils ne sont pas adaptés aux escaliers et que du coup il faudrait toujours se balader à pieds.
Oui, il y a aura toujours des garnements qui utiliseront de travers ce qu'ont leur met à disposition. Reste que c'est bien plus agréable à utiliser que les interfaces SAXPYiennes des BLAS, ou même de ce que l'on trouvera en Java.

b- Bien au contraire. Je me permets de copier-coller de la prose que j'avais écrite pour un doc de qualité:


Un petit exemple qui illustre cela : les listes et les listes triées. Quelqu'un d'un peu naïf pourra croire qu'il suffit de dériver une classe liste pour définir une classe listetriée après avoir redéfini la fonction d'insertion pour insérer au bon endroit. Sauf que cela sabotera complètement le contrat de la liste.


Accessoirement, la liaison tardive n'est qu'un des aspects du polymorphisme (d'inclusion -- mine de rien, le C++ en supporte 3 autres). virtual n'est pas nécessaire pour utiliser en place de.

Je ne suis pas d'accord.
Soit on autorise la surcharge d'une méthode par une classe fille et dans ce cas on met en jeu la liaison tardive (polymorphisme), soit on empeche la surcharge de la méthode.
Mais rendre une méthode surchargeable par une classe fille mais executer le code sous-jacent selon le type connu statiquement de ton objet, ca reste dans mon esprit une hérésie. Or en C++ une méthode est toujours suchargeable par une classe fille (il n'y a pas de possibilité d'indiquer qu'une méthode est "final").

Je comprends les critères qui on poussés à ce genre de choix (une méthode sans virtual ne prends pas de cout d'execution a cause de la vTable) mais j'estime qu'il manque une notion derrière de concept de "virtual", celle de pouvoir interdir la surcharge d'une méthode par une classe fille.

[jblecanard]

Je comprends les critères qui on poussés à ce genre de choix (une méthode sans virtual ne prends pas de cout d'execution a cause de la vTable) mais j'estime qu'il manque une notion derrière de concept de "virtual", celle de pouvoir interdir la surcharge d'une méthode par une classe fille.

Je suis complètement d'accord, c'est un petit truc en plus qui ferait plaisir.

[gl]

Or en C++ une méthode est toujours suchargeable par une classe fille (il n'y a pas de possibilité d'indiquer qu'une méthode est "final").

La présence du mot-clé final et l'interdiction de surcharger un méthode non virtuel n'ont pas réellement de rapport.

Le mot clé final est juste le pendant du mot clé virtual dans des langages ayant fait le choix du virtuel par défaut.
L'interdiction de surcharger des méthodes non virtuelles dans une classe fille peut se faire sans la présence de final.

Le seul intérêt qu'il pourrait y avoir en C++ à introduire le mot clé final serait d'empêcher la propagation de la virtualité d'une méthode en dessous d'un certain niveau de la chaîne d'héritage. Je ne suis pas certain de l'intérêt de la chose (personnellement, je n'ai jamais rencontré se besoin. Il est possible que d'autres si).

mais j'estime qu'il manque une notion derrière de concept de "virtual", celle de pouvoir interdire la surcharge d'une méthode par une classe fille.

Je laisse de côté le cas particulier du destructeur qui est plus problèmatique.

Est-il vraiment souhaitable de l'interdire ? N'y a-t-il absolument aucun cas où la surcharge dans une classe fille d'une méthode non virtuelle serait légitime ?

Qu'un avertissement soit émis par le compilateur dans ce cas est vraisemblablement une bonne chose, mais de là à interdire complétement la construction, je me demande si ce n'est pas une solution trop extrême.



PS: Les questions ci-dessus sont de vrais questions, pas un simple effet de style. Car certes, je n'ai jamais rencontré le besoin de surcharger une fonction non virtuelle et ça me "choque" de songer à le faire. Mais jugeant essentiellement au vue de mon expérience, il est possible que je passe à côté de quelque chose.

[Invité]

C++ est un langage que je trouve très bien fait et qui respecte à la lettre ses principes de bases (on ne paye pas pour ce qu'on utilise pas).

Les problèmes :
- pas de système de module, inclusion textuelle pas toujours pertinente

- très dur à parser

C++ isn't hard to parse because it requires arbitrary lookahead; that's an easy problem to solve. It's hard to parse because a particular sequence of tokens can produce multiple totally different parse trees, depending on what some of the symbols are declared as. Even worse, many of those symbols aren't known at parse time, because they aren't declared yet. So it has to be parsed into some indeterminate state that gets "fixed" later.

This issue makes it impossible to correctly parse C++ code without building most of a C++ compiler front end, including all the hard stuff. - Walter Bright

- productivité mauvaise (ça se discute évidemment)

[S(ô.Ô)B]

Je suis tout à fait d'accord avec pseudocode pour la surcharge de l'opérateur == !

La séparation .h(pp)/.c(pp) qui permet d'avoir l'API publique à porté de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos…)

Par contre pour ça je ne suis pas d'accord, mais pas du tout. Car déjà si tu n'as à ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde où tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associée qui va bien

Après je vous rejoins pour les cours de C++, j'aurais adoré faire des TP de C++ avec QT par exemple, malheureusement on en n'a même pas entendu parlé en cours...

[gl]

C'est justement parce qu'il n'y a pas de moyen d'être d'accord sur la sémantique des opérateurs à moins de faire une revue exhaustive du code source. A partir du moment où il est permis de redéfinir un opérateur, voir un mot clé du langage, il n'y a pas possibilité de présupposer de ce que fait une simple comparaison.

Pour moi, la première forme (.equal()) peut renvoyer true, false, 0, -1, "hello world", voir lever une exception, afficher du texte, ou faire un exit(). Bref tout ce que peut faire un appel de méthode.

Mais en fait, la deuxième aussi. Sauf que c'est moins visible au premier coup d'oeil. Et donc le risque est plus grand de faire l'impasse sur toutes ces possibilités, et de se contenter de croire que le "==" est un opérateur du langage qui compare deux valeurs et renvoie un booléen.

Mais ce n'est ni plus ni moins que le même problème que celui du choix des noms (de méthodes, variables).

Si tu tombes sur une méthode equal() tu t'attends à ce qu'elle fasse un test d'égalité. Si finalement elle fait tout à fait autre chose, tu vas être surpris et estimer (à juste titre à mon avis) que celui qui l'a faite est un imbécile.
C'est pareil pour la surcharge d'un opérateur, si l'opérateur surchargé n'a pas une sémantique logique et s'éloigne du fonctionnement des opérateurs de base c'est que le choix de cet opérateur n'était clairement pas bon, mais cela ne remet pas, à mon sens, en cause la surcharge des opérateurs.

Et à titre personnel, je trouve bien plus logique d'utiliser les opérateurs de comparaison pour faire une comparaison, l'opérateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.