Discussion :

[Florian Goo]

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.

C'est pour cela qu'on fait la distinction entre les classes à sémantique de valeur et celles à sémantique d'entité !
Il n'y a pas d’ambiguïté dès lors que la sémantique d'une classe est bien définie.

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 .

C'est simplement parce que tu détournes la signification (ou sémantique) de l'opérateur. « || » signifie OU logique, pas parallélisme.

[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...

pointeurs : Tu me fais de la peine
Quand sun a sorti java, son marketing présentait les références comme plus "modernes" puisque elle ne permettent pas au développeur (animal imprévisible et parfois bizarre) de crasher la machine !

Comme dit Koala, les ref sont des pointeurs, mais les pointeurs ne sont pas des ref !!
Le pointeur , c'est le truc qu'on utilise pas quand on débute et dont on abuse quand on devient aguerri
Sa raison d'être est qu'il correspond aux adresses que le processeur manipule, on retrouve sa valeur dans le binaire désassemblé d'un debugger binaire.
Sa puissance est immense et les risques aussi !
exemple : la recherche dans une string (indexOF en C#, strchr() en C) retourne un pointeur sur la 1re occurrence ou NULL si non trouvé. Ainsi pour chaque occurrence, un accès à l'intérieur de la chaine originale sera possible . En C# , on récupère un offset qui ne permet d'accéder à la sous-chaine qu'après l'avoir copiée dans une autre string(subString()). En C , pas de copie, l'accès est implicite. En C++ , les CString ressemblent au C# et la même manipulation exige une conversion.

Bref de tous les languages, C est le seul qui ne convertit rien, ne copie rien , et ne fait pas un new String pour stocker le résultat.. (malloc() en fait) resultat : C = 0 CPU consommé pour le traitement des chaines.

Maintenant , si aucune occurrence n'est trouvée, et que le pointeur null est retourné , toute tentative de lecture ou écriture à cette adresse provoque une erreur irrécupérable (kill task sous XP) . On écrit à l'adresse 0 !
En fait l'adresse 0 est convertie par le memory manager unit en adresse de segment de données , ce qui est moins "grave" que l'adresse physique 0, mais crashe tout quand même !

Le préprocesseur me manque cruellement en C#.. comme il ne manipule que le texte du source, le compilateur ne voit que ce qu'il produit, c'est un immense avantage dans certains cas. et un désastre parfois (MFC5 apr exemple)
Il faut savoir que le mode d'adressage le plus rapide des CPU est le mode direct :
la valeur est écrite en clair dans le binaire. Le préprocesseur permet de le faire et remplace donc la variable qui est plus lente à l'execution..

@+

[Invité]

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 ?

C'est à double tranchant. D a voulu se passer de préprocesseur et fait exactement ca.

#ifdef => version
#if => static if
macros => strings mixinx + CTFE
#include => import

Il y a les avantages que l'on imagine en terme de parsing et de vitesse de compilation.

Mais il y a un inconvénient pervers à ne pas avoir de préprocesseur. Tout les chemins de code, même non compilés, doivent être parsés quand même. Hors le principal avantage du préprocesseur est de permettre à des compilateurs différents / pas à jour / du futur de marcher quand même...

Par exemple, écrire du code compatible D version 1 et D version 2 est pénible à cause de ça...

[gl]

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

Oui, extraire les commentaires n'est pas ce qu'il y a de plus compliqué.

Par contre savoir ce qui doit être extrait dans le .h public, ce qui doit l'être dans un .h privé, ce qui ne doit pas l'être, etc; cela devient vite très compliqué à moins de rajouter pas mal de mécanique pour indiquer quoi faire. Ce qui au final risque d'être plus compliquer que d'écrire soit même les .h.

[gl]

La seule exception que je connaisse au principe de garder une sémantique identique est celle de boost::serialize qui utilise l'opérateur & dans une sémantique qui n'est pas habituelle.

On pourrait aussi citer boost::spirit ainsi que certains DSL mais là on s'éloigne de la sémantique C++ pour se rapprocher de la sémantique du domaine d'application, ce qui me semble plutôt être une bonne chose.

[Invité]

Merci pour vos remarques, mais je ne comprend pas toujours en quoi le pré-processeur est indispensable.

Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.

Concernant le ; après la déclaration d'une classe, union, etc... je ne savais pas qu'on pouvait créer et instancié une structure anonyme comme ça, on en apprend tout les jours. Mais dans le cas ou on ne s'en sert pas... pourquoi ne pas le rendre optionnel ?

[gorgonite]

Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.

cites-moi un langage objet "mainstream" qui le fasse...

[koala01]

Merci pour vos remarques, mais je ne comprend pas toujours en quoi le pré-processeur est indispensable.

Parce qu'un compilateur ne connait que ce qu'il a déjà rencontré...

Quand tu écrit, dans un fichier (qu'il soit *.h ou *.cpp) une directive comme

Code :

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

#include "fichier.h"

Le compilateur va copier récursivement le contenu de fichier.h à la place de la directive.

(comprend par "récursivement le fait que, s'il rencontre une directive include lui demandant d'inclure un autre fichier, il fera exactement pareil).

De plus, c'est un moyen extrêmement puissant pour "tuner" l'application en fonction de certaines configurations, voire, pour permettre une compatibilité accrue.

Imaginons (car c'est un cas fréquent) que l'on souhaite sur une bibliothèque pour laquelle on souhaite fournir une version statique (compilateur dépendante) et une version dynamique / partagée (dll).

Le code sera identique à un point près: un __declpsec précédera les fonctions que l'on veut exporter.

Tu ne va pas commencer à écrire deux fois l'implémentation (une avec et l'autre sans le declspec) et trois fois le fichier d'en-tête (une sans __declspec pour la version statique, une avec __declspec(dllexport) pour la compilation de la dll et une avec __declspec(dllimport) pour l'utilisation de la dll).

Par contre, le préprocesseur est un outil génial pour gérer cela.

Il te suffit en effet d'écrire quelque lignes, et de passer une option de compilation pour gérer cela:

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
 
#if defined(BUILD_MYDLL)
    #define MY_ABI __declspec(dllexport)
#else 
    #if defined(USE_MYDLL)
        #define MY_ABI __declspec(dllimport)
    #else
        #define MY_ABI
    #endif
#endif
/* pour toutes les fonctions devant être exportées dans la dll */
 
type_de_retour MY_ABI nomFonction(/* paramètres éventuels */)
{
    /* corps de la fonction */
}

Lorsque tu compilera ta bibliothèque sous la forme de:

Code :

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

g++  fichier.cpp -o fichier.o

tu compilera la version statique de ta bibiliothèque.

Lorsque tu compilera ta bibliothèque sous la forme de

Code :

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

g++ fichier.cpp -DUSE_MYDLL -o fichier.o

tu compilera la version dynamque de ta bibliothèque
Lorsque tu utilisera le fichier d'en-tête sous la forme de
g++ un_autre_fichier.cpp -o un_autre_fichier.o
(on considère que un_autre_fichier.cpp inclu fichier.h ) tu préparera le terrain pour une utilisation de la version statique de la bibliothèque

Et, enfin, lorsque tu utilisera le fichier d'en-tête sous la forme de

Code :

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

g++ un_autre_fichier.cpp -DUSE_MYDLL -o un_autre_fichier.o

(même remarque que précédemment ) tu préparera le terrain pour une utilisation de la version dynamique de la bibliothèque.

Tu pourrais trouver des applications similaires pour la gestion des compilateurs ne respectant pas trop la norme.

Ainsi, les anciennes versions de borland ne supportent pas le spécificateur d'exception (throw() ) alors qu'il est obligatoire pour d'autres.

Tu peux facilement contourner le problème sous une forme proche de

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
#if defined(__BORLANDC__)
#define NOTHROW
#else
#define NOTHROW throw()
#endif
 
/* une classe qui sert d'exception */
class MyException
{
    const char* what() NOTHROW;
    ~MyException() NOTHROW;
}

Tout cela tend à rendre le préprocesseur nécessaire.

Il y aurait peut être d'autre moyens d'y parvenir, mais je ne vois vraiment pas lesquels

Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.

Aucun langage ne le fait, et aucun langage n'oblige d'ailleurs à récupérer la valeur de retour d'une fonction

Concernant le ; après la déclaration d'une classe, union, etc... je ne savais pas qu'on pouvait créer et instancié une structure anonyme comme ça, on en apprend tout les jours. Mais dans le cas ou on ne s'en sert pas... pourquoi ne pas le rendre optionnel ?

Tu imagines un peu le bordel que cela foutrait dans le malheureux esprit du programmeur

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
class MaClass
{
    /* ... */
} // chouette, pas besoin de ";"
 
class MaClass2
{
   class Nested
   {
        /* ... */
   } // il faut, ou pas le ; 
   class OtherNested
   {
        /* ... */
   } m_other // et là ??
   class
   {
        /*...*/
   } m_anonymus //là, je suis presque sur qu'il en faut un :P
} // et ici ?

Non, sincèrement, le plus facile est de ne faire qu'une règle, qui ne souffre aucune exception, non

[Guulh]

koala, Je te remercie d'apporter toutes ces précisions

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é.

Est-ce une feature ou une limitation ? Du fait de la (relative) ancienneté de C / C++, il ne m'est pas toujours facile de distinguer les choix de design volontaires des choix "faute de mieux".

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

Je connais le concept d'encapsulation et de modularisation du code, et je sais que les différents langages le permettent de différentes façons Mais strict, c'est vite dit, les membres privés et inline sont aussi présents, non ? Y'a quand même mieux qu'un .h, pour présenter l'interface d'un module à un consommateur. Sans parler de pimpl.

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

Ca serait un gain certain de productivité, non ? Et une preuve de plus que le header n'est qu'une contrainte du mode de compilation ?
'fin, je veux dire, les langages évoluent pour nous faciliter la vie, théoriquement (et les IDE suivent pour boucher les trous)

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.

Je ne vois toujours pas le lien entre le fait que ce soit du natif ou du byte code d'un côté, et le fait que les méta-données soient présentes ou pas. On peut bien imaginer qu'un binaire C++ contienne aussi l'équivalent des .h ?

[gorgonite]

Mais strict, c'est vite dit, les membres privés et inline sont aussi présents, non ? Y'a quand même mieux qu'un .h, pour présenter l'interface d'un module à un consommateur. Sans parler de pimpl.

et qui te dit que le .h(pp) présenté à l'utilisateur d'une bibliothèque correspondra à son contenu réel ?

dans mon labo, on trafique ce genre de chose assez souvent, et pas toujours à fin d'ofuscation...

[koala01]

koala, Je te remercie d'apporter toutes ces précisions
Est-ce une feature ou une limitation ? Du fait de la (relative) ancienneté de C / C++, il ne m'est pas toujours facile de distinguer les choix de design volontaires des choix "faute de mieux".

C'est, très certainement historique, mais peut être aussi une contrainte de compilation...

N'oublie pas que tout ce qui est utilisé par le processeur nécessite une certaine taille en mémoire pour être représenté.

Une machine virtuelle peut s'occuper de mettre de l'ordre dans tout cela, mais, lorsqu'il n'y a pas cette couche intermédiaire, il faut que les choses soient exactement là où elles sont attendues

Je connais le concept d'encapsulation et de modularisation du code, et je sais que les différents langages le permettent de différentes façons Mais strict, c'est vite dit, les membres privés et inline sont aussi présents, non ? Y'a quand même mieux qu'un .h, pour présenter l'interface d'un module à un consommateur. Sans parler de pimpl.

Effectivement, j'aurais du dire "aussi peu que possible", car il est, actuellement du moins, difficile de faire en sorte de n'avoir qu'une définition de classe partielle à un endroit donné, et d'avoir le reste de cette définition ailleurs (quoi que c'est à peu près le rôle de pimpl )

Ca serait un gain certain de productivité, non ? Et une preuve de plus que le header n'est qu'une contrainte du mode de compilation ?
'fin, je veux dire, les langages évoluent pour nous faciliter la vie, théoriquement (et les IDE suivent pour boucher les trous)

C'est, effectivement, une évolution logique...

Tu sais ce qu'il te reste à faire

Je ne vois toujours pas le lien entre le fait que ce soit du natif ou du byte code d'un côté,

Reprenons:

Lorsque tu utilise un langage basé sur du bytecode et une machine virtuelle (comme java), le compilateur va faire "la moitié du travail" seulement:

Il va, par exemple, transformer toutes les instructions qu'il peut en instructions processeur, mais va laisser une partie d'informations qui devront être... transformées par la machine virtuelle.

Ce seront, entre autres, des parties qui permettront, justement, à la machine virtuelle de retrouver fichiers de bytecode correspondant aux autres classes, et donc de les mettre en relation.

D'une certaine manière, le bytecode est... un code binaire mal fini

Par contre, le code binaire natif est destiné à... ne plus être modifié d'une quelconque manière une fois qu'il a été créé (hormis modification dans le code source suivie d'une recompilation).

C'est la raison pour laquelle il se doit d'être "aussi épuré que possible".

Les différents types ne sont plus considérés que... comme l'espace mémoire qui est nécessaire pour les représenter, et les membres des structures ou classes ne sont plus reconnus que par... le décalage depuis le début du type en question qui est nécessaire pour y accéder.

et le fait que les méta-données soient présentes ou pas. On peut bien imaginer qu'un binaire C++ contienne aussi l'équivalent des .h ?

Ce serait catastrophique

Tu imagine le nombre de données inutiles qu'il faudrait placer dans un fichier qui est, en toute logique, destiné uniquement au processeur

Entre le nom des types eux-mêmes, le nom et le type des membres et la signature des différentes fonctions, tous les exécutables verraient sans doute leur taille doubler ou tripler sans le moindre effort

Le pire, c'est que ce serait purement et simplement inutile, car, comme je l'ai indiqué, le code binaire exécutable n'est pas susceptible d'être modifié autrement qu'au travers de la modification des sources et la recompilation, et parce qu'il n'y a rien de prévu pour accéder à ces informations

[bioinfornatics]

cites-moi un langage objet "mainstream" qui le fasse...

je suis pas sûr d'avoir bien compris, mais si c'est d'adapté le type de la variable selon le type de retour de la fonction, le D le fait grace au mot clé auto (le vala aussi)

Code :

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

auto maVar = funcReturnChar();

[stardeath]

si je ne dis pas de bêtise c'est que par exemple :

Code :

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

int getValue(int, long);

aura la même signature que :

Code :

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

float getValue(int, long);

[koala01]

je suis pas sûr d'avoir bien compris, mais si c'est d'adapté le type de la variable selon le type de retour de la fonction, le D le fait grace au mot clé auto (le vala aussi)

Code :

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

auto maVar = funcReturnChar();

Ca, la prochaine norme le prévoit aussi

Je crois que ce que reproche abdelite (n'hésite pas à me détromper ), c'est que le compilateur ne considère pas les fonctions

Code :

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

1
2
int foo(A a, B b, C c)

et

Code :

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

std::string foo(A a, B b, C c)

comme deux fonctions différentes du fait d'un type de retour différent.

En effet, seul le nom, le nombre et le type des arguments est pris en compte pour la signature d'une fonction, et le compilateur n'acceptera jamais d'avoir deux fonctions ayant le même nom mais des types de retours différents

Et cela a quelque chose de logique, dans le sens où le nom d'une fonction doit indiquer le service que l'on peut en attendre, et que le fait de changer le type de retour tend à laisser croire que le service rendu change également

[EDIT] Ceci dit, il y a parfois des choses sympa à faire :

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <iostream>
#include <string>
template<typename RT,typename VAL = RT>
RT foo(VAL v)
{
    return v;
}
using namespace std;
int main()
{
    cout<<foo<std::string>("salut")<<" "<<foo<int>(15);
    return 0;
}

La seule chose, c'est que l'évaluation d'un type de retour n'est pas automatique, comme ca peut être le cas pour les paramètres
[/EDIT]

[bioinfornatics]

Ca, la prochaine norme le prévoit aussi

La prochaine norme a fini par êtres moins innovante que ce qu'elle voulait au début.
De plus le temps que tout le monde se mettent a utiliser la norme il va se passer 10 ans, dans 5 ans 70% . Surtout que le C++ a un cycle long de standardisation.
La nouvelle norme prévoyait la lune au final on a des fragment lunaires ... dommage

j'étais également impatient des retombé de cette normes et au final ....
j'aime le c++ mais dans l'avenir je me tournerais vers le D.
Mais je reconnais qu'en D il y a moins de bibliothèques c'est normales, la jeunesse.
D'ailleurs je vais me lancer dans la création de quelques bibliothèques.

[guillaume07]

moi il n'y a rien qui me dérange dans ce langage, je le trouve quasi parfait

[atttchoum]

Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.

imaginons que tu ais :

Code :

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
int foo(){
    return 2;
}

string foo(){
    return "une chaine";
}

int main(){
    int i = foo();//dans cette logique tu aurai i = 2
    string s = foo();//ici tu aurai s = "une chaine"

    foo()//arf x( j'apelle quelle fonction ??!

    return 0;
}

C'est pas un problème lié au C++

[pseudocode]

imaginons que tu ais :

Code :

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
int foo(){
    return 2;
}

string foo(){
    return "une chaine";
}

int main(){
    int i = foo();//dans cette logique tu aurai i = 2
    string s = foo();//ici tu aurai s = "une chaine"

    foo()//arf x( j'apelle quelle fonction ??!

    return 0;
}

C'est pas un problème lié au C++

Hum... comme l'a dit koala01, c'est surtout un problème conceptuel plus que technique. Le polymorphisme sert a offrir une interface de service unique pour des types de paramètres différents. Il est donc sous entendu que le service rendu (= le résultat, et donc le type de retour) soit toujours le même.

Ce n'est pas un problème technique dans le sens où le problème se pose même pour les paramètres.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
int foo(int i){
    return 1;
}

int foo(float f){
    return 2;
}

int main(){
    double value = 100.0;
    foo(value);

    return 0;
}

Sans définition explicite de ce que veut faire le développeur, il est nécessaire de définir dans le langage des règles pour gérer ce genre de cas (covariance/contravariance).

[befalimpertinent]

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

Son processus très lent de normalisation. J'ai l'impression qu'il se passe un peu la même chose qu'avec l'OpenGL 3.0. ça fait maintenant un paquets d'années qu'on entend parler de C++0X puis C++1X sans en voir le bout (2010 ou 2011 c'est promis !) donc les attentes sont grandes vu que pendant ce laps de temps les language concurrent (C#) progresse rapidement et par bonds importants (Linq, WPF, ...).
En plus de même qu'avec l'OpenGL (je sais que les deux approches ne sont pas tout a fait comparables) il y a un risque d'obtenir un consensus mou au final : concepts exclu de la prochaine norme par exemple.
J'utilise pourtant avec le compilo de VS2010 les nouveautés du draft (auto, rvalue, lambda expression principalement ) mais il me manque encore le GC facultatif notamment.

Signé un C++iste impatient qui voit autour de lui les nouveaux projets démarrer en C# et qui craint de devenir le dernier des mohicans.

[Invité]

Dans ce cas comme pour les templates, il faudrait indiquer au compilateur quelle version prendre quand l'ambiguïté est présente...

Code :

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
int foo()
{
    return 2;
}

string foo()
{
    return "une chaine";
}

int main()
{
    int i = foo();
    string s = foo();

    (int)foo()//être explicite dans ce cas, crochet, parenthèses, etc...

    return 0;
}