QUESTION a un PRO en C++

Le 30 mai 2021 à 23:11:20 :

Le 30 mai 2021 à 23:08:20 gatias a écrit :

Le 30 mai 2021 à 23:04:12 :

Le 30 mai 2021 à 23:01:13 gatias a écrit :
<code>#include <bits/stdc++.h>

using namespace std;

struct A {
virtual void print();
};

struct B : public A {
void print() override {
cout << "OK\n";
}
};

struct C: public A {
void print() override {
cout << "OKK\n";
}
};

int main() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
C test;
test.print();

return 0;
}</code>

Tu ne comprends pas quoi ?

Merci, en fait je suis embrouillé par virtual, quel est l'interet de mettre virtual sur chacun des attributs plutôt que de spécifier la classe comme étant abstraite ?
putain ce que c'est laid le c++

Tu peux avoir des méthodes qui ne sont pas abstraites donc il faut spécifier quelle méthode va l'être, c'est comme ça.
Je ne vois pas en quoi le C++ est moche, quand on ne comprend rien ça peut faire peur mais il n'y a rien de moche.

Ok mais si je fais virtual ça change quoi par rapport à une fonction normale que je redéfinie plus tard ?

disons que c'est très peu verbeux par rapport à un langage genre c# et pas aussi simple que le C.
De toute façon c'est le langage le plus puissant donc osef

Imagine que tu as une classe parent et que tu as plusieurs sous-classes qui en hérite.

Tu aimerais les stocker dans un tableau et que chaque sous-classe implémente x méthodes d'une manière spécifique, et bien c'est ce que permettent les fonctions virtuelles.

#include <bits/stdc++.h>
 
using namespace std;

struct A {
  virtual void print() const = 0;
};

struct B : public A {
   void print() const override {
    cout << "OK\n";
  }
};

struct C: public A {
  void print() const override {
    cout << "OKK\n";
  }
};
 
int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);
  C test;
  vector<unique_ptr<A>> v;
  v.push_back(make_unique<C>());
  v.push_back(make_unique<B>());
  for (const auto& i: v) {
    i->print();
  }
  
  return 0;
}

Le 30 mai 2021 à 23:23:40 Ass2Trefle a écrit :
Je comprend rien au c++, déjà que j'ai du mal avec le c

une fois que t'as compris la mémoire c'est bon

Le 30 mai 2021 à 23:24:24 gatias a écrit :

Le 30 mai 2021 à 23:11:20 :

Le 30 mai 2021 à 23:08:20 gatias a écrit :

Le 30 mai 2021 à 23:04:12 :

Le 30 mai 2021 à 23:01:13 gatias a écrit :
<code>#include <bits/stdc++.h>

using namespace std;

struct A {
virtual void print();
};

struct B : public A {
void print() override {
cout << "OK\n";
}
};

struct C: public A {
void print() override {
cout << "OKK\n";
}
};

int main() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
C test;
test.print();

return 0;
}</code>

Tu ne comprends pas quoi ?

Merci, en fait je suis embrouillé par virtual, quel est l'interet de mettre virtual sur chacun des attributs plutôt que de spécifier la classe comme étant abstraite ?
putain ce que c'est laid le c++

Tu peux avoir des méthodes qui ne sont pas abstraites donc il faut spécifier quelle méthode va l'être, c'est comme ça.
Je ne vois pas en quoi le C++ est moche, quand on ne comprend rien ça peut faire peur mais il n'y a rien de moche.

Ok mais si je fais virtual ça change quoi par rapport à une fonction normale que je redéfinie plus tard ?

disons que c'est très peu verbeux par rapport à un langage genre c# et pas aussi simple que le C.
De toute façon c'est le langage le plus puissant donc osef

Imagine que tu as une classe parent et que tu as plusieurs sous-classes qui en hérite.

Tu aimerais les stocker dans un tableau et que chaque sous-classe implémente x méthodes d'une manière spécifique, et bien c'est ce que permettent les fonctions virtuelles.

#include <bits/stdc++.h>
 
using namespace std;

struct A {
  virtual void print() const = 0;
};

struct B : public A {
   void print() const override {
    cout << "OK\n";
  }
};

struct C: public A {
  void print() const override {
    cout << "OKK\n";
  }
};
 
int main() {
  ios::sync_with_stdio(false);
  cin.tie(nullptr);
  C test;
  vector<unique_ptr<A>> v;
  v.push_back(make_unique<C>());
  v.push_back(make_unique<B>());
  for (const auto& i: v) {
    i->print();
  }
  
  return 0;
}

merci encore mais je sais ce que c'est une classe abstraite, je comprenais juste pas comment sont représentée les objets abstraits en C++ mais c'est bon maintenant

Le 30 mai 2021 à 23:25:20 MaryseLepen2 a écrit :
Go polymorphisme

inutile quand les classes héritent toutes d'une même classe et qu'aucune des classes doit ne pas avoir l'attribut en question, c'est pour ça que je parle de classe abstraite

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Le 30 mai 2021 à 23:32:11 gatias a écrit :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

tu peux développer ça m'intéresse

Une classe abstraite sert de model et evite la duplication d’une classe inutilement par exemple.

Tu crées une classe voiture en abstraite qui elle ne sera jamais instancier et puis via le biais de l’heritage tu fais voiture ford etc etc Go checker les design Pattern ca va pas mal t’aider

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Le 30 mai 2021 à 23:32:58 :

Le 30 mai 2021 à 23:32:11 gatias a écrit :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

tu peux développer ça m'intéresse

développer quoi ?

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Le 30 mai 2021 à 23:38:46 :

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Oui mais c'est pareil avec la composition, tu peux avoir un code impossible à maintenir sans utiliser d'héritage.

Il faut juste réfléchir et ne pas l'utiliser à tout va et l'éviter aux endroits où l'on souhaite de la performance.

Le 30 mai 2021 à 23:46:10 :

Le 30 mai 2021 à 23:38:46 :

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Oui mais c'est pareil avec la composition, tu peux avoir un code impossible à maintenir sans utiliser d'héritage.

Il faut juste réfléchir et ne pas l'utiliser à tout va et l'éviter aux endroits où l'on souhaite de la performance.

Non, la composition simplifie justement cela comparé à l'héritage
Quand t'arrives à des grappes d'objets hérités sur 10 niveaux, c'est impossible à débugguer.

Le 30 mai 2021 à 23:11:20 :

Le 30 mai 2021 à 23:08:20 gatias a écrit :

Le 30 mai 2021 à 23:04:12 :

Le 30 mai 2021 à 23:01:13 gatias a écrit :
<code>#include <bits/stdc++.h>

using namespace std;

struct A {
virtual void print();
};

struct B : public A {
void print() override {
cout << "OK\n";
}
};

struct C: public A {
void print() override {
cout << "OKK\n";
}
};

int main() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
C test;
test.print();

return 0;
}</code>

Tu ne comprends pas quoi ?

Merci, en fait je suis embrouillé par virtual, quel est l'interet de mettre virtual sur chacun des attributs plutôt que de spécifier la classe comme étant abstraite ?
putain ce que c'est laid le c++

Tu peux avoir des méthodes qui ne sont pas abstraites donc il faut spécifier quelle méthode va l'être, c'est comme ça.
Je ne vois pas en quoi le C++ est moche, quand on ne comprend rien ça peut faire peur mais il n'y a rien de moche.

Ok mais si je fais virtual ça change quoi par rapport à une fonction normale que je redéfinie plus tard ?

disons que c'est très peu verbeux par rapport à un langage genre c# et pas aussi simple que le C.
De toute façon c'est le langage le plus puissant donc osef

Si tu redéfinie une méthode non virtuelle tu risque d'avoir pas mal de problème.

Si je me rappelle bien, si ton objet est du type ou la méthode est redéfinie, ça va appelé la méthode redéfinie. Si ton objet est du type de la classe abstraite, ça va appeler la méthode de la classe abstraite sans appeler la méthode rédéfinie

Le 30 mai 2021 à 23:47:43 about_crash a écrit :

Le 30 mai 2021 à 23:46:10 :

Le 30 mai 2021 à 23:38:46 :

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Oui mais c'est pareil avec la composition, tu peux avoir un code impossible à maintenir sans utiliser d'héritage.

Il faut juste réfléchir et ne pas l'utiliser à tout va et l'éviter aux endroits où l'on souhaite de la performance.

Non, la composition simplifie justement cela comparé à l'héritage
Quand t'arrives à des grappes d'objets hérités sur 10 niveaux, c'est impossible à débugguer.

quelle idée aussi de faire ça sur 10 niveaux

Le 30 mai 2021 à 23:49:44 :

Le 30 mai 2021 à 23:47:43 about_crash a écrit :

Le 30 mai 2021 à 23:46:10 :

Le 30 mai 2021 à 23:38:46 :

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Oui mais c'est pareil avec la composition, tu peux avoir un code impossible à maintenir sans utiliser d'héritage.

Il faut juste réfléchir et ne pas l'utiliser à tout va et l'éviter aux endroits où l'on souhaite de la performance.

Non, la composition simplifie justement cela comparé à l'héritage
Quand t'arrives à des grappes d'objets hérités sur 10 niveaux, c'est impossible à débugguer.

quelle idée aussi de faire ça sur 10 niveaux

Legacy code khey
J'ai vu ça sur un des premiers sites de ecommerce de l'époque quand j'y bossais il y a 10 ans.

Heureusement depuis je fais que du from scratch

Le 30 mai 2021 à 23:47:43 :

Le 30 mai 2021 à 23:46:10 :

Le 30 mai 2021 à 23:38:46 :

Le 30 mai 2021 à 23:37:18 :

Le 30 mai 2021 à 23:32:42 :

Le 30 mai 2021 à 23:32:11 :

Le 30 mai 2021 à 23:28:39 :
L'héritage
La composition

Pour l'héritage multiple oui mais sinon non.

L'héritage permet de faciliter beaucoup de choses et d'avoir un code plus simple à lire.

Apres oui, si tu as besoin de performances, il faut bannir l'héritage et préférer les templates mais l'héritage n'est pas non plus à jeter tant que ça n'est pas utilisé n'importe comment

https://en.wikipedia.org/wiki/Composition_over_inheritance

Et donc ?

Réfléchir à deux fois avant de faire de l'héritage.
Même si c'est un concept à maîtriser.

Sans parler des librairies qui gèrent mal l'héritage (typiquement les ORM, lib de serialization etc..).

Oui mais c'est pareil avec la composition, tu peux avoir un code impossible à maintenir sans utiliser d'héritage.

Il faut juste réfléchir et ne pas l'utiliser à tout va et l'éviter aux endroits où l'on souhaite de la performance.

Non, la composition simplifie justement cela comparé à l'héritage
Quand t'arrives à des grappes d'objets hérités sur 10 niveaux, c'est impossible à débugguer.

Et écrire une fonction de 10 000 lignes va être plus difficile à débugger, qu'une fonction de 3 lignes.
Toujours partir dans des extrêmes pour critiquer une fonctionnalité.....