Discussion :

[Emmanuel Deloget]

Le compilo C++ "assume no aliasing" par défaut désormais?
Ou comment créer des bugs...

Seulement dans le cas ou tu manipules des pointeurs vers des types différents. Si tu as deux variables pointeur du même type, alors le compilateur part du principe que l'aliasing est possible. Idem si l'un des type pointé est char*. En C11, l'ajout du mot clef restrict permet de dire au compilateur qu'il n'y a pas d'aliasing même si les données manipulées sont de même type.

(et pour le bug, j'ai déjà subi ; et ça m'a pris deux semaines pour le caractériser et le corriger...)

[Kaamui]

Je n'ai pas écrit ça sans réfléchir. Pensons en terme de services donc : celui rendu par la classe Position est de contenir les deux coordonnées qui forment une position dans l'espace (quel qu'il soit). Celui rendu par la fonction int Position::x() const est de fournir une coordonnée de cette position. Ça ne peut rien être de plus, sinon tu lui donnes trop de responsabilités. Partant de là, tu écartes donc toute idée de "tests" (suis-je au bord du monde, dois-je inverser y parce que je suis dans un miroir, etc.). Cette fonction ne feras jamais rien d'autre que de retourner la valeur de x. J'espère qu'on est d'accord jusque là.

En fait je ne suis pas d'accord, pas totalement. Je dirais la même chose que toi + "je vais séparer interface/implémentation, car on ne sais jamais quel service je pourrais avoir besoin qu'elle me rende". Et même s'il y a effectivement peu de chance que cela arrive, c'est possible, et sans que ça vienne en contradiction avec la SRP.

Je n'ai rien contre l'encapsulation. Mais si je me permets d'intervenir sur ce sujet, c'est que j'en ai déjà écrit plusieurs classes de ce type : des Vector3, des Point2, et j'en passe. Au début, suivant les conseils que j'avais pu lire sur ce forum et ailleurs, qui me disaient que l'encapsulation c'était bien, j'ai sagement caché mes données membres et utiliser des fonctions membres pour y accéder. À ce jour, ça ne m'a jamais servi à rien d'autre que de m'user les doigts. Je souhaite juste éviter ça à l'OP.

C'est, à mon sens, encore une erreur. L'OP est d'un niveau débutant (je le sais cela fait plusieurs soirs que je l'aide à installer la SFML et à apprendre à s'en servir correctement), et il est largement préférable qu'il s'use les doigts sur les principes fondamentaux de la bonne manière de programmer. Prévoir au maximum ce qu'on ne peut prévoir, commenter, documenter, encapsuler, penser service plutôt que donnée, SRP, OCP, Liskov, Interface Segregation, Dependency Inversion (merci wiki pour le D )..

Là encore, je n'ai rien contre le code verbeux (je n'utilise jamais de using namespace), mais seulement quand ça apporte quelque chose.

ça apporte une réponse à de potentiels imprévus ! Moi j'essaie juste de faire passer cette évidence dans cette conversation..

[Matthieu Brucher]

Seulement dans le cas ou tu manipules des pointeurs vers des types différents. Si tu as deux variables pointeur du même type, alors le compilateur part du principe que l'aliasing est possible. Idem si l'un des type pointé est char*. En C11, l'ajout du mot clef restrict permet de dire au compilateur qu'il n'y a pas d'aliasing même si les données manipulées sont de même type.

(et pour le bug, j'ai déjà subi ; et ça m'a pris deux semaines pour le caractériser et le corriger...)

OK, je viens de comprendre. C'est pas super utile, en tout cas pas assez dans le domaine du calcul lourd où on travaille avec des dizaines de tableaux de doubles, tous indépendants !

[Matthieu Brucher]

Seulement dans le cas ou tu manipules des pointeurs vers des types différents. Si tu as deux variables pointeur du même type, alors le compilateur part du principe que l'aliasing est possible. Idem si l'un des type pointé est char*. En C11, l'ajout du mot clef restrict permet de dire au compilateur qu'il n'y a pas d'aliasing même si les données manipulées sont de même type.

(et pour le bug, j'ai déjà subi ; et ça m'a pris deux semaines pour le caractériser et le corriger...)

Dingue... Si ca se trouve, c'est exactement ce qui vient de m'arriver... Le compilateur Intel ne recharge pas la valeur d'un tableau qui a ete modifie par un autre pointeur et qui fait crasher le programme par la suite... Et avec un display ca passe parce qu'on recharge l'element pointe...

[Iradrille]

Dingue... Si ca se trouve, c'est exactement ce qui vient de m'arriver... Le compilateur Intel ne recharge pas la valeur d'un tableau qui a ete modifie par un autre pointeur et qui fait crasher le programme par la suite... Et avec un display ca passe parce qu'on recharge l'element pointe...

Probable oui, foutu en cache pour optimiser les performance (c'est bien pour ça que le compilo intel est connu =), et après l'avoir testé je ne peux qu'approuver)

En tout cas, ce genre de débat est sympa, ça montre bien que même à haut niveau, tout le monde n'est pas d'accord sur la façon de faire.

[germinolegrand]

En tout cas, ce genre de débat est sympa, ça montre bien que même à haut niveau, tout le monde n'est pas d'accord sur la façon de faire.

Heureusement, sinon on pourrait se faire remplacer par des programmes Sans parler que le développement perdrait son côté artistique ...

[Matthieu Brucher]

Probable oui, foutu en cache pour optimiser les performance (c'est bien pour ça que le compilo intel est connu =), et après l'avoir testé je ne peux qu'approuver)

En tout cas, ce genre de débat est sympa, ça montre bien que même à haut niveau, tout le monde n'est pas d'accord sur la façon de faire.

Attends, le pire, c'est qu'il est plus lent que gcc sur ce code...

[Kalith]

En fait je ne suis pas d'accord, pas totalement. Je dirais la même chose que toi + "je vais séparer interface/implémentation, car on ne sais jamais quel service je pourrais avoir besoin qu'elle me rende". Et même s'il y a effectivement peu de chance que cela arrive, c'est possible, et sans que ça vienne en contradiction avec la SRP.

Ok je vois. Je pense qu'on peut dire que c'est une démarche prudente. À mon avis elle l'est un peu trop, mais ça me semble n'être qu'une question de goûts finalement, cf. ci-dessous 3ème citation.

C'est, à mon sens, encore une erreur. L'OP est d'un niveau débutant (je le sais cela fait plusieurs soirs que je l'aide à installer la SFML et à apprendre à s'en servir correctement), et il est largement préférable qu'il s'use les doigts sur les principes fondamentaux de la bonne manière de programmer. Prévoir au maximum ce qu'on ne peut prévoir, commenter, documenter, encapsuler, penser service plutôt que donnée, SRP, OCP, Liskov, Interface Segregation, Dependency Inversion (merci wiki pour le D )..

Je comprends tout à fait l'objectif. Mais il y a un aspect qu'il faut aussi garder à l'esprit : la motivation. Quand on apprend un langage (ou simplement la programmation dans son ensemble), il est facile de se démotiver, surtout quand on s'attaque à des langages pointus comme le C++. J'ai peur que, en essayant de respecter tous ces principes dès la première heure, et donc d'être amené à écrire du code étrange et lourd comme celui qui a déjà été présenté dans les posts précédents, on finisse par penser que "écrire du C++ c'est pénible, la syntaxe n'est pas naturelle, il y a plein de mots et de caractères inutiles" (inutiles = dans un monde parfait, je n'aurais pas à les écrire).

Alors qu'en codant différemment (i.e. en se permettant de violer explicitement des "règles" comme l'encapsulation, le principe de Demeter, ...), et, il faut l'avouer, surtout depuis l'arrivée du C++11 (en particulier avec auto, les lambdas et les listes d'initialisations, et plus indirectement avec les autres features comme la sémantique de mouvement ou les templates variadiques), je trouve qu'on peut s'approcher très près du "monde parfait" où chaque atome du code a un sens d'abord pour le lecteur plutôt que pour la machine, tout en s'assurant les performances quasi-optimales d'un langage compilé. À mon humble avis, c'est ça qui rend le C++ différent de tous les autres langages, et c'est ce pourquoi je l'apprécie autant.

Maintenant, comme il a déjà été dit plusieurs fois sur ce forum (peut être pas encore sur cette discussion, pardon si c'est le cas), avant d'enfreindre les règles, il faut savoir qu'elles existent, quel est leur but et quand on peut s'en passer. Donc il est clair que plus tôt on se frotte à ces règles, mieux c'est.

ça apporte une réponse à de potentiels imprévus ! Moi j'essaie juste de faire passer cette évidence dans cette conversation..

Je pense que tout le monde est d'accord là dessus J'ai l'impression que le débat tourne plus autour du seuil de tolérance de chacun quand à l'improbabilité d'un imprévu. Si j'ai bien compris, ton point de vue est que tout imprévu, aussi potentiel et improbable soit-il, est un imprévu, et donc tu fais donc en sorte que ton code soit affecté au minimum si jamais il venait à se produire. De mon point de vue, il y a des imprévus tolérables, et parmi eux, certains dont je juge qu'ils nécessiteraient trop d'effort pour s'en protéger, et je décide donc de privilégier la lisibilité et la simplicité du code.

[Emmanuel Deloget]

En fait je ne suis pas d'accord, pas totalement. Je dirais la même chose que toi + "je vais séparer interface/implémentation, car on ne sais jamais quel service je pourrais avoir besoin qu'elle me rende". Et même s'il y a effectivement peu de chance que cela arrive, c'est possible, et sans que ça vienne en contradiction avec la SRP.

(...)

ça apporte une réponse à de potentiels imprévus ! Moi j'essaie juste de faire passer cette évidence dans cette conversation..

Autant je suis d'accord avec toi sur le fond du fond, autant je soutiens quand même que bien apprendre, c'est aussi apprendre la simplicité. Deux acronymes importants : YAGNI (you ain't gonna need it) et KISS (keep it simple, stupid).

Le premier (YAGNI), parce que essayer de prévoir des besoins non connus pour plus tard, c'est se tirer une balle dans le pied. Poussé à l’extrême, ça veut dire qu'on ne code jamais, parce que le logiciel peut potentiellement tout faire, hors il est impossible de prévoir l'architecture d'un logiciel qui peut tout faire. Ramené dans des proportions normales, ça veut juste dire qu'on va plus que probablement écrire du code qui ne servira jamais (code mort donc, jamais testé, et source potentielle de problème), ou qui servira mais de façon modifiée par rapport à ce qu'on a déjà écrit (ce qui revient à écrire deux fois le même code).

Le second (KISS), parce que plus un code est complexe, plus il a de chances d'être perclus de bugs. De plus, si le code est intelligent et qu'il est buggé, alors il faudra être deux fois plus intelligent pour le débugger. Donc autant écrire du code bête, ça le ramène à notre portée pour le debuggage (le pire, c'est que je suis très sérieux quand je dis ça).

De plus, lorsqu'on code, il est tout de même relativement facile de voir que certaines données n'ont pas de comportements intrinsèques, ou que l'abstraction générale est plus aisée à comprendre si les traitements sur un type particulier sont extrinsèque à ce type. Dans le cadre de la programmation d'un jeu (2D, 3D...), il sera certainement plus aisé de manipuler une structure vector3d qu'une classe vector3d avec toutes les méthodes possibles et imaginables ; le fait d'avoir une structure peut même être assez bénéfique, dans le sens ou les API graphiques sous-jacentes sont très dépendantes de l'organisation interne de ce type de données (c'est d'ailleur l'API qui est prescriptrice dans ce cas). Après, rien n'empêche de coder quelques fonctions d'aide (méthode statique de création d'un vecteur unitaire...).

[Kaamui]

Ok je vois. Je pense qu'on peut dire que c'est une démarche prudente. À mon avis elle l'est un peu trop, mais ça me semble n'être qu'une question de goûts finalement, cf. ci-dessous 3ème citation.


Je comprends tout à fait l'objectif. Mais il y a un aspect qu'il faut aussi garder à l'esprit : la motivation. Quand on apprend un langage (ou simplement la programmation dans son ensemble), il est facile de se démotiver, surtout quand on s'attaque à des langages pointus comme le C++. J'ai peur que, en essayant de respecter tous ces principes dès la première heure, et donc d'être amené à écrire du code étrange et lourd comme celui qui a déjà été présenté dans les posts précédents, on finisse par penser que "écrire du C++ c'est pénible, la syntaxe n'est pas naturelle, il y a plein de mots et de caractères inutiles" (inutiles = dans un monde parfait, je n'aurais pas à les écrire).

Alors qu'en codant différemment (i.e. en se permettant de violer explicitement des "règles" comme l'encapsulation, le principe de Demeter, ...), et, il faut l'avouer, surtout depuis l'arrivée du C++11 (en particulier avec auto, les lambdas et les listes d'initialisations, et plus indirectement avec les autres features comme la sémantique de mouvement ou les templates variadiques), je trouve qu'on peut s'approcher très près du "monde parfait" où chaque atome du code a un sens d'abord pour le lecteur plutôt que pour la machine, tout en s'assurant les performances quasi-optimales d'un langage compilé. À mon humble avis, c'est ça qui rend le C++ différent de tous les autres langages, et c'est ce pourquoi je l'apprécie autant.

Maintenant, comme il a déjà été dit plusieurs fois sur ce forum (peut être pas encore sur cette discussion, pardon si c'est le cas), avant d'enfreindre les règles, il faut savoir qu'elles existent, quel est leur but et quand on peut s'en passer. Donc il est clair que plus tôt on se frotte à ces règles, mieux c'est.


Je pense que tout le monde est d'accord là dessus J'ai l'impression que le débat tourne plus autour du seuil de tolérance de chacun quand à l'improbabilité d'un imprévu. Si j'ai bien compris, ton point de vue est que tout imprévu, aussi potentiel et improbable soit-il, est un imprévu, et donc tu fais donc en sorte que ton code soit affecté au minimum si jamais il venait à se produire. De mon point de vue, il y a des imprévus tolérables, et parmi eux, certains dont je juge qu'ils nécessiteraient trop d'effort pour s'en protéger, et je décide donc de privilégier la lisibilité et la simplicité du code.

Alors là +1.

Je ne vois pas quoi ajouter, pour moi tu as très bien résumé la situation : tout dépend d'où chacun trouve son équilibre entre simplicité et prudence. Je n'utilise jamais les structures personnellement, je considère (c'est vraiment personnel comme point de vue, aucune raison technique) que les structures sont des versions obsolètes des classes, alors même quand je conçois en terme de donnée (ce qui est instinctivement plus naturel pour tout le monde je penses), j'utilise des classes... tout est une question d'habitude finalement.

Autant je suis d'accord avec toi sur le fond du fond, autant je soutiens quand même que bien apprendre, c'est aussi apprendre la simplicité. Deux acronymes importants : YAGNI (you ain't gonna need it) et KISS (keep it simple, stupid).

Le premier (YAGNI), parce que essayer de prévoir des besoins non connus pour plus tard, c'est se tirer une balle dans le pied. Poussé à l’extrême, ça veut dire qu'on ne code jamais, parce que le logiciel peut potentiellement tout faire, hors il est impossible de prévoir l'architecture d'un logiciel qui peut tout faire. Ramené dans des proportions normales, ça veut juste dire qu'on va plus que probablement écrire du code qui ne servira jamais (code mort donc, jamais testé, et source potentielle de problème), ou qui servira mais de façon modifiée par rapport à ce qu'on a déjà écrit (ce qui revient à écrire deux fois le même code).

Alors ça c'est très discutable de mon point de vue. Car poussé à l'extrême dans l'autre sens également, on ne prévois rien, et on va devant de très gros problèmes (typiquement, on avance tant qu'on peut une fois qu'on est coincé on recommence).

Le second (KISS), parce que plus un code est complexe, plus il a de chances d'être perclus de bugs. De plus, si le code est intelligent et qu'il est buggé, alors il faudra être deux fois plus intelligent pour le débugger. Donc autant écrire du code bête, ça le ramène à notre portée pour le debuggage (le pire, c'est que je suis très sérieux quand je dis ça).

Je trouve, encore une fois d'un point de vue personnel, que même si je comprends, je trouve que ce type de raisonnement fait office de véritable frein à l'évolution intellectuelle d'une personne dans le domaine où elle applique ce dit raisonnement.

De plus, lorsqu'on code, il est tout de même relativement facile de voir que certaines données n'ont pas de comportements intrinsèques, ou que l'abstraction générale est plus aisée à comprendre si les traitements sur un type particulier sont extrinsèque à ce type.

Pas compris.

Dans le cadre de la programmation d'un jeu (2D, 3D...), il sera certainement plus aisé de manipuler une structure vector3d qu'une classe vector3d avec toutes les méthodes possibles et imaginables ; le fait d'avoir une structure peut même être assez bénéfique, dans le sens ou les API graphiques sous-jacentes sont très dépendantes de l'organisation interne de ce type de données (c'est d'ailleur l'API qui est prescriptrice dans ce cas). Après, rien n'empêche de coder quelques fonctions d'aide (méthode statique de création d'un vecteur unitaire...).

Je ne penses pas car une classe vector3d pourra être générique et fournir des opérateurs mathématiques très utiles pour manipuler des vecteurs. Avec une structure c'est plus compliqué je penses.

[Bousk]

Je ne penses pas car une classe vector3d pourra être générique et fournir des opérateurs mathématiques très utiles pour manipuler des vecteurs. Avec une structure c'est plus compliqué je penses.

Une structure étant strictement identique à une classe, à la visibilité par défaut près. En quoi une structure serait "plus compliquée" qu'une classe ?
Une structure Vector3D a tout son sens, avec les 3 membres x,y,z et des méthodes pour agir sur le vector ou en générer un nouveau, addition etc.
Le fait que ce soit une structure, avec un accès à ses membres xyz direct, n'interdit en rien d'avoir des méthodes pour le manipuler.

[Kaamui]

Une structure étant strictement identique à une classe, à la visibilité par défaut près. En quoi une structure serait "plus compliquée" qu'une classe ?
Une structure Vector3D a tout son sens, avec les 3 membres x,y,z et des méthodes pour agir sur le vector ou en générer un nouveau, addition etc.
Le fait que ce soit une structure, avec un accès à ses membres xyz direct, n'interdit en rien d'avoir des méthodes pour le manipuler.

non je voulais dire des "opérateurs mathématiques (génériques) très utiles ...". peut on faire une structure générique simplement avec une structure ?

[Bousk]

Encore une fois, structure ou classe sont strictement identiques. Tout ce qu'une classe peut faire, une structure le fait aussi.

Voir par exemple le Vector3 de Ogre, un Vector3 des plus classiques.

[Kaamui]

Encore une fois, structure ou classe sont strictement identiques. Tout ce qu'une classe peut faire, une structure le fait aussi.

euh.... non surement pas ? Pas de notion de portée dans une structure, pas de notion d'héritage (et qu'on vienne pas me dire "si ! on peut jouer avec les vtables !" ), pas de notion de généricité je crois.

Voir par exemple le Vector3 de Ogre, un Vector3 des plus classiques.

Encore une fois, je ne vois qu'un vecteur de flottants. Ce dont je parle c'est d'un vector3<T> avec T = int, float, etc..

[Emmanuel Deloget]

euh.... non surement pas ? Pas de notion de portée dans une structure, pas de notion d'héritage (et qu'on vienne pas me dire "si ! on peut jouer avec les vtables !" ), pas de notion de généricité je crois.

Tu oublies un point : en C++, les structures telles que le C les défini n'existent pas. Une struct est un classe, avec un contrôle d'accès par défaut différent. Ces deux codes sont strictement équivalents (enfin presque: par défaut, on hérite d'une classe en private et d'une struct en public) :

Code :

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

1
2
3
4
5
6
7
 
class toto
{
  int m_titi;
public:
  toto(int titi) : m_titi(titi) { }
};

Code :

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

1
2
3
4
5
6
7
 
struct toto
{
  toto(int titi) : m_titi(titi) {*}
private:
  int m_titi;
};

Encore une fois, je ne vois qu'un vecteur de flottants. Ce dont je parle c'est d'un vector3<T> avec T = int, float, etc..

Code :

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

1
2
3
4
5
 
template <class T>
struct vector3 {
  T x, y, z;
};

[Kaamui]

Tu oublies un point : en C++, les structures telles que le C les défini n'existent pas. Une struct est un classe, avec un contrôle d'accès par défaut différent. Ces deux codes sont strictement équivalents (enfin presque: par défaut, on hérite d'une classe en private et d'une struct en public) :

Code :

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

1
2
3
4
5
6
7
 
class toto
{
  int m_titi;
public:
  toto(int titi) : m_titi(titi) { }
};

Code :

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

1
2
3
4
5
6
7
 
struct toto
{
  toto(int titi) : m_titi(titi) {*}
private:
  int m_titi;
};

Code :

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

1
2
3
4
5
 
template <class T>
struct vector3 {
  T x, y, z;
};

Ah d'accord, je ne savais pas. Même l'héritage est possible avec une struct ?

Mais du coup, si c'est aussi identique qu'une classe, à part le contrôle d'accès par défaut différent, on est en train de faire tout un débat pour savoir quel mot clé chacun préfère utiliser ? Aussi, a quoi cela sert-il d'avoir deux choses aussi identiques, avec deux noms et une règle par défaut différents ?

[r0d]

euh.... non surement pas ? Pas de notion de portée dans une structure, pas de notion d'héritage (et qu'on vienne pas me dire "si ! on peut jouer avec les vtables !" ), pas de notion de généricité je crois.

J'ai loupé quelque chose ou tu dis là une grosse bêtise? (Je prend des précautions car en ce moment, j'en dit beaucoup des grosses bêtises )

La notion de portée est la même pour les classes et les structures. De même que l'héritage. En fait, une structure EST une classe, seul la visibilité par défaut (public/private) change.

[Emmanuel Deloget]

Ah d'accord, je ne savais pas. Même l'héritage est possible avec une struct ?

Mais du coup, si c'est aussi identique qu'une classe, à part le contrôle d'accès par défaut différent, on est en train de faire tout un débat pour savoir quel mot clé chacun préfère utiliser ? Aussi, a quoi cela sert-il d'avoir deux choses aussi identiques, avec deux noms et une règle par défaut différents ?

Presque, mais pas tout à fait

Le débat est en fait celui-ci: est-ce que toutes les entités (class ou struct) d'un programme (ou librairie) doivent être présentés sous la forme d'objets encapsulés (qui, donc, fournissent une interfaces proposant des services) ou peut-on intégrer dans un programme (ou une librairie) des entités qui ne sont pas encapsulées (et donc, ne fournissent pas de services) ? Si tel est le cas, quelles sont les conditions que doit remplir selon vous une telle entité ?

[r0d]

Ah d'accord, je ne savais pas. Même l'héritage est possible avec une struct ?

Oui. Même l'héritage privé. Si tu tiens à en avoir le coeur net, essaie (tu dois bien avoir un compilateur à portée de clavier).

[r0d]

Le débat est en fait celui-ci: est-ce que toutes les entités (class ou struct) d'un programme (ou librairie) doivent être présentés sous la forme d'objets encapsulés (qui, donc, fournissent une interfaces proposant des services) ou peut-on intégrer dans un programme (ou une librairie) des entités qui ne sont pas encapsulées (et donc, ne fournissent pas de services) ? Si tel est le cas, quelles sont les conditions que doit remplir selon vous une telle entité ?

J'ai l'impression qu'il y a également une discussion parallèle et qui concerne l'interprétation que nous avons de la notion de service. En gros, "est-ce qu'il suffit de faire un accesseur à une donnée pour en faire un service?"

Derrière cela, se pose aussi la question de la classification entité/valeur dans le cadre d'une conception en terme de services. Est-ce qu'une classe à sémantique de valeur peut être implémentée sous forme de service?

Après, je ne comprend pas tout dans cette histoire, donc il est fort possible que mon interprétation du débat soit erronée.