Discussion :

[ml17330]

J'ai utilisé C++ comme du C pour développer des logiciels financiers à une époque où le choix était reduit.
Aujourd'hui je ne développe plus que des jeux vidéo et j'utilise pour ça des outils bien plus adaptés

[JeitEmgie]

C'est quand même formidable de voir le nombre de post qui se plaignent que les interfaces et les implémentations ne sont pas séparées dans des fichiers distincts en java... Notez quand même:

1) on n'a besoin de l'interface que pour des raisons de "documentation" (au sens large), c'est à dire pour comprendre comment utiliser telle ou telle objet... En java il y a la javadoc, très répandue et très pratique, et bien plus claire qu'un fichier .h, sinon il y a les vues "outline" dans les éditeur, qui permettent de filtrer
Mais par pitié, arrêtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration

j'ai déjà dit plus haut pourquoi on ne peut se passer de fichiers .h (et équivalents) avec des langages compilés en natif… et çà n'a rien à voir avec les seuls besoins de documentation pour l'humain qui lit le code… c'est indispensable lors de la compilation…

et de fait ils sont totalement inutiles avec des langages qui génèrent du byte code qui contient toutes les informations de "Reflection" nécessaires…

[pseudocode]

Exactement:

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
#include <iostream>
class MaClass
{
   /* n'importe quoi */
};
int main()
{
    MaClass c1;
    MaClass c2;
    if(c1==c2)
    {
        std::cout<<"c1 et c2 sont identiques"<<std::endl;
    }
}

provoque l'erreur

Code SHELL :

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

main.cpp|10|error: no match for 'operator==' in 'c1 == c2'|

Il en va de même pour les fonctions...

Ah, exact. Dans ma tête je pensais plus à un "MaClass *c1 = new MaClass();". La (mauvaise) habitude de Java sans doute.

Ce que tu appelle permissivité, j'aurais tendance à l'appeler libre arbitre.

Tu remarqueras que c'est encore une question de point de vue

Tout a fait. C'est 100% une histoire de point de vue, mais c'est un peu ce qui est demandé dans les questions du 1er post.

[Oussapik]

Mais par pitié, arrêtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration

Je pense, il faudrait hiura confirme, qu'il ne cherchait pas à se plaindre de l'absence des fichiers .h (ou équivalent) en java. Il s'agit plutôt de débattre (visiblement, il y a des pour et des contre) de l'importance de leur présence en C++. L'évocation de Java ne sert ici que de comparaison. Le but de ce topic n'est pas de se plaindre du Java

[Guulh]

j'ai déjà dit plus haut pourquoi on ne peut se passer de fichiers .h (et équivalents) avec des langages compilés en natif… et çà n'a rien à voir avec les seuls besoins de documentation pour l'humain qui lit le code… c'est indispensable lors de la compilation…

et de fait ils sont totalement inutiles avec des langages qui génèrent du byte code qui contient toutes les informations de "Reflection" nécessaires…

J'ai pratiqué le C# bien plus que le C++, ma question pourra donc paraître naïve, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?
Je comprends bien la nécessité des headers, en l'absence dans les fichiers compilés d'informations de réflexion. Mais pourquoi doit-on encore se carrer ça à la main ?

Et quel est le lien entre le fait que le code soit natif ou pas, et le fait que les binaires soient autosuffisants ? (là encore, la question n'est pas rhétorique)

[befalimpertinent]

je trouve SGI et MSDN très brouillon (enfin j'avoue que j'ai jamais été foutu de comprendre comment MSDN était rangée).
Quant à roguewave, je ne connaissais pas et je découvre en ce moment même.

Chacun ses gouts mais personnellement, je préfère cplusplus/reference


Pour ceux qui est des .h, bien que ça ne m'ait jamais vraiment dérangé on peut reprocher au C++ l'inconvénient de devoir rajouter (quand on fait ça proprement) un .i.h pour les inlines par exemples ou un .t.h pour les templates sans avoir l'élégance des class partiels du C#

[hiura]

Je pense, il faudrait hiura confirme, qu'il ne cherchait pas à se plaindre de l'absence des fichiers .h (ou équivalent) en java. Il s'agit plutôt de débattre (visiblement, il y a des pour et des contre) de l'importance de leur présence en C++. L'évocation de Java ne sert ici que de comparaison. Le but de ce topic n'est pas de se plaindre du Java

Techniquement je peux pas dire que c'est bien les headers en C++ et que c'est (aussi) bien de pas en avoir en JAVA. Donc dans un sens je critique bien JAVA.

Mais bien sûr que l'idée n'est pas là. Ce n'est qu'un exemple pour comparer, comme l'exemple avec l'Objective-C.

[ManusDei]

J'ai pratiqué le C# bien plus que le C++, ma question pourra donc paraître naïve, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?

Moi je mets des commentaires, destinés à un utilisateur qui n'aura pas nécessairement accès au .cpp mais qui se sert des fonctions.

[hiura]

Chacun ses goûts mais personnellement, je préfère cplusplus/reference

Si je ne dis pas de bêtise (merci de me corriger si c'est le cas), SGI, MSDN, et compagnie, sont des implémentations tandis que cplusplus n'est qu'une doc (avec des erreurs). Si tu veux une doc fiable, tu as dinkumware certes un peu abrupte au début.

[Guulh]

Moi je met des commentaires, destinés à un utilisateur qui n'aura pas nécessairement accès au .cpp mais qui se sert des fonctions.

S'il existe un outil qui extrait un h à partir d'un cpp, il sera tout aussi capable d'extraire les commentaires.

[Invité]

Les principaux reproches que je fais au langage C++ sont principalement d'un point de vue syntaxique...

Les indispensables après une accolade fermante d'une déclaration de classe, union, énumération, etc...

La notion d'itérateurs... Ça serait magnifique qu'un mot-clé C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit déjà présente...

Les directives de pré-processeur... Pourquoi ne pas tout simplement utiliser des mot-clés pour les quelques opérations dont le pré-processeur se charge ?

Les pointeurs... Il serait intéressant de mettre plus en avant les références, à la manière du Java un peu...

L'impossibilité de séparer déclaration et implémentation de fonctions template, statique...

Laisser le choix entre les paradigmes orientés objet et procédural pour des fonctions tel que le main.

En gros il faudrait passer à Java ou à D...

[Florian Goo]

Les principaux reproches que je fait au langage C++ sont principalement d'un point de vue syntaxique...

Les ; indispensables après une accolade fermante d'une déclaration de classe, union, énumération, etc...

C'est lié au fait que l'on peut écrire ceci :

Code :

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

1
2
3
4
5
class
{
    //…
} mon_objet;

La notion d'itérateurs... Ça serait magnifique qu'un mot-clé C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit déjà présente...

Ce sera dans le prochain standard (C++0x) :

Code :

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

1
2
3
4
5
int my_array[5] = {1, 2, 3, 4, 5};
for(int& x : my_array)
{
    x *= 2;
}

(fonctionne avec tous les conteneurs fournissant des itérateurs)

Les pointeurs... Il serait intéressant de mettre plus en avant les références, à la manière du Java un peu...

Les références en Java SONT des pointeurs. C'est juste qu'on ne peut pas agir sur eux aussi librement qu'en C++.
Les références (les vraies) existent en C++.

L'impossibilité de séparer déclaration et implémentation de fonctions template, statique...

C'est une nécessité de la compilation.

Laisser le choix entre les paradigmes orienté objet et procédural pour des fonctions tel que le main.

Histoire d'avoir un public static int main() comme en Java ? Quel intérêt ?

[pseudocode]

Histoire d'avoir un public static int main() comme en Java ? Quel intérêt ?

J'avoue que je ne vois pas non plus. Ou alors c'est histoire de pouvoir en mettre un par classe sans que le linker ne râle ?

[koala01]

J'ai pratiqué le C# bien plus que le C++, ma question pourra donc paraître naïve, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?

Les déclarations des fonctions et des classes.

Cela n'a l'air de rien, mais le compilateur ne connait que ce qu'il a déjà rencontré.

Dans les langages à base de bytecode / machine virtuelle ou pour lesquels l'implémentation des fonctions de fait dans le même fichier que la déclaration de celles-ci, il y a moins de problèmes, dans le sens où il y a une "machinerie extérieure" (les import de java, par exemple) qui fera le lien entre les différents fichiers.

Cette "machinerie extérieure" est divisée en deux parties en C et en C++:

1. Le préprocesseur, qui s'assurait (grâce à la directive #include et toute sa clique) que le compilateur connaitra ce qu'il faut au moment où il le faut et
2. l'éditeur de liens qui s'assurera, une fois que tout aura été compilé, que les appels de fonctions pointent bien vers... la fonction adéquate (qui peut se trouver dans un fichier "objet" différent)

D'un autre côté, la séparation entre la déclaration et l'implémentation permet, quant à elle, de ne fournir que le "stricte minimum" à l'utilisateur d'une classe / structure / fonction :

Lorsque tu décides d'utiliser une classe ou une fonction créée par quelqu'un d'autre, ce qui t'importe, c'est "l'interface" (dans le sens générique du terme et non dans le sens java ) quelle propose: elle te présente tel ou tel service, correspondant à telle ou telle fonction.

A la limite, la manière dont la fonction fournit son résultat, tu n'en as strictement rien à faire, et tu choisis de faire confiance à celui qui a programmé la classe ou la fonction pour qu'elle rende correctement le service attendu.

Il n'y a donc, a priori, aucune raison pour que tu aies accès à ce genre d'information (qui, bien souvent, ne t'intéresse de toutes manières pas, hormis )

Je comprends bien la nécessité des headers, en l'absence dans les fichiers compilés d'informations de réflexion. Mais pourquoi doit-on encore se carrer ça à la main ?

Parce que personne n'a encore eu l'idée de faire en sorte qu'un environnement de développement le fasse automatiquement, éventuellement après avoir posé une question sur l'accessibilité de la fonction

Et quel est le lien entre le fait que le code soit natif ou pas, et le fait que les binaires soient autosuffisants ? (là encore, la question n'est pas rhétorique)

Quand tu as un code binaire natif, tu n'as, en gros, qu'une "succession sans queue ni tête" de bytes, dans laquelle tu ne disposes d'aucune information permettant de faire le lien avec "trucs" écrits en langage humain, et qui ne prend un sens que pour le processeur.

Il devient donc difficile, pour ne pas dire impossible, de retrouver des informations permettant d'aider... l'humain au départ de ce code binaire.

Les langages basés sur du bytecode permettent de garder "suffisamment d'informations" pour les retransmettre à l'humain, mais nécessitent, en retour, un nouveau "passage à la moulinette" pour permettre au processeur de travailler.

Ce n'est pas tout à fait juste, et cela n'utilise sans doute pas les bons termes, mais cela permet de comprendre l'idée, non

Les principaux reproches que je fais au langage C++ sont principalement d'un point de vue syntaxique...

Les indispensables après une accolade fermante d'une déclaration de classe, union, énumération, etc...

Ma première réaction a été d'être d'accord, avant de me rappeler que l'on pouvait décider de créer une instance nommée d'une classe / structure / union non nommée

La notion d'itérateurs... Ça serait magnifique qu'un mot-clé C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit déjà présente...

La fonction foreach apparait en C++1x.

La notion d'itérateur est présente depuis longtemps

Les directives de pré-processeur... Pourquoi ne pas tout simplement utiliser des mot-clés pour les quelques opérations dont le pré-processeur se charge ?

Quelle différence y aurait-il à avoir un mot clé import qui permettrait d'écrire

Code :

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

import une_classe

plutôt que

Code :

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

#include <une_classe.h>

D'autant plus que cela poserait un problème assez bête dans le sens où la moindre classe, y compris une classe vide, devrait être définie dans un fichier tout à fait séparé.

Tu imagines, avoir un fichier nulltype, un autre voidtype et un troisième flagtype, alors que ces structures seraient toutes proches de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
struct NullType
{
    /* structure vide */
};
struct VoidType
{
    /* structure vide */
}; 
struct FlagType
{
    /*structure vide*/
};

Sans compter les structures dérivées de FlagType

Tu te retrouverais avec une quantité impressionnante de fichiers qui rendrait la gestion de ceux-ci encore plus compliquée qu'elle ne l'est

Les pointeurs... Il serait intéressant de mettre plus en avant les références, à la manière du Java un peu...

Ça, c'est encore un problème d'apprentissage.

Il faut réellement insister sur le fait qu'il faut utiliser les références partout où c'est possible et les pointeurs uniquement lorsque l'on n'a pas le choix

Il faut bien penser que les pointeurs permettent des choses que les références ne permettent pas

L'impossibilité de séparer déclaration et implémentation de fonctions template, statique...

Ce sont des problèmes dus au processus de compilation.

Pour ce qui est des fonctions template, par exemple, le compilateur doit disposer du type réel pour fournir le code binaire correspondant.

Comment faire pour qu'il arrive à fournir ce code binaire si... il ne dispose pas du code (source) quand il dispose du type réel

Laisser le choix entre les paradigmes orienté objet et procédural pour des fonctions telles que le main.

Je sais que java permet, effectivement, de définir une fonction principale dans plusieurs classes.

Mais c'est la machine virtuelle qui permet de décider d'appeler l'une plutôt que l'autre.

Et les systèmes d'exploitation ne présentent, actuellement, pas ce genre d'opportunité

[Invité]

La surcharge de l'opérateur == a été longuement évoquée, sauf sur un aspect : que veut dire EGAL, ça peut vouloir dire IDENTIQUE, PAREIL, MEME-VALEUR etc.
Une exemple : une ligne est une succession de points. Un point est caractérisé par son matricule et ses coordonnées.
Si je compare 2 points de même coordonnées, mais pas de même matricule, ils sont superposés, mais ce ne sont pas les mêmes points. Or pour qu'une ligne soit une zone il FAUT qu'elle se referme sur le même point.
On peut aller un peu plus loin : deux points sont considérés identiques si leurs coordonnées diffèrent de moins de 3 unités de base.
En conclusion, pour une classe simple (ma classe Point3D) et qui en gros ne comporte que des constructeurs, j'avais 3 façons différentes de surcharger ==. Je n'ai donc pas surchargé l'opérateur.

Par contre, j'ai une classe Vecteur, et le test de parallélisme "||" me semble bien adapté, puisqu'il répond à des critères précis. A l'occasion d'un exemple, j'ai mis ce bout de code et on m'a dit que c'était à éviter, mais sans me dire pourquoi d'ailleurs .
Donc j'ai un peu de mal à comprendre. Mais à voir le nombre de réactions, je constate qu'au moins la moitié des membres a du mal à comprendre ce que dit l'autre moitié

[hiura]

Ce sont des problèmes dus au processus de compilation.

Pour ce qui est des fonctions template, par exemple, le compilateur doit disposer du type réel pour fournir le code binaire correspondant.

Comment faire pour qu'il arrive à fournir ce code binaire si... il ne dispose pas du code (source) quand il dispose du type réel

Ça n'en reste pas moins un point négatif (rien que du fait que ce ne soit pas homogène avec la pratique de séparation définition/implémentation utilisable pour le reste). Non (Je pose réellement la question (sur le «négatif») car pour l'instant je n'ai pas pratiquer les templates assez pour avoir une réelle expérience avec eux et donc je ne suis pas apte à définir l'impact que le regroupement obligatoire définition/implémentation a (temps de compilation/complexité de lecture par l'humain/…).)

[koala01]

Ça n'en reste pas moins un point négatif (rien que du fait que ce ne soit pas homogène avec la pratique de séparation définition/implémentation utilisable pour le reste). Non (Je pose réellement la question (sur le «négatif») car pour l'instant je n'ai pas pratiquer les templates assez pour avoir une réelle expérience avec eux et donc je ne suis pas apte à définir l'impact que le regroupement obligatoire définition/implémentation a (temps de compilation/complexité de lecture par l'humain/…).)

Cela peut, effectivement, être considéré comme un point négatif du point de vue de l'homogénéité du développement.

La nécessité qui est faite de rompre avec une habitude de séparation stricte des déclarations et des implémentation est assez "malheureuse" dirons nous.

Je ne vois, en l'état actuel, malheureusement pas comment nous pourrions y remédier.

Et puis, l'approche basée sur les template est une approche tout à fait particulière et fait malgré tout (pour celui qui fait plus qu'utiliser des classes template "toutes faite") appel à un savoir faire assez particulier

j'aurais donc tendance à dire que c'est effectivement un problème pour celui qui "débarque" dans ce monde étrange qu'est la programmation générique, mais que cela n' handicape pas outre mesure celui qui l'utilise régulièrement

[hiura]

Et de ce que j'en ai vu les templates sont à elles seules un point bien positif du C++ donc ce petit désagrément n'est qu'un détail.

Je suis une girouette!

[koala01]

Et de ce que j'en ai vu les templates sont à elles seules un point bien positif du C++ donc ce petit désagrément n'est qu'un détail.

Je suis une girouette!

Pas forcément, car je comprend ton point de vue

Vu "de l'extérieur", la rupture des pratiques de séparations est effectivement un aspect négatif.

Par contre, si on élargit son point de vue, on se rend compte de l'énorme flexibilité que peuvent apporter les template, et l'on se dit que ce "léger désagrément" est très largement contrebalancé par le bénéfice que l'on peut retirer de la programmation générique.

Après, libre à tout un chacun de déterminer ce qui lui importe le plus

[jblecanard]

De plus, on peut quand même séparer l'interface des templates et leur implémentation dans deux fichiers, en n'oubliant pas d'inclure le fichier d'implémentation à la fin du header. Comme ça, on évite l'entorse intellectuelle.