Discussion :

[olivier]]

Bonjour.

J'aimerais savoir s'il est possible qu'un constructeur, si une conditon n'est pas validée, ne crée pas l'instance ?
Par exemple,

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
 class Personne
{
public:
  ... 
  Personne()=delete; //pour ne pas utiliser le constructeur pas défaut
  Personne(std::string nom; std::string prenom);
  ...
private:
  ...
  std::string nom;
  std::string prenom;
 ...
}
 
...
Personne personne1 {"","toto"};
...

le constructeur voit que nom est vide et donc ne crée pas l'instance.

Est-ce possible? sinon comment faut-il procéder?

Olivier]

[Bousk]

Tu peux lancer une exception, ou utiliser une factory.

[Luc Hermitte]

Note: De base, si tu définis le moindre constructeur, le constructeur dit "par défaut" (i.e. sans paramètres) n'est plus généré. Techniquement, le = delete est redondant ici.

Tu veux interdire Personne("", "toto"), c'est ça?
Peut-être avec de la méta-prog on peut reconnaitre le cas où tu reçois un "" vide, mais ça ne vaut que pour les littéraux, pas pour les char const* vers des "", ou même des chaines vides. Ca va vite être compliqué pour pas grand chose AMA.

En m'inspirant de gsl::not_null<>, ça pourrait ressembler à ça: https://godbolt.org/z/6PrYMoseq -- la partie meta-prog est très certainement simplifiable (je la trouve compliquée à cause de l'ambiguité entre la référence vers tableau de caractères et le pointeur vers caractères, j'ai fait au plus rapide) ; j'exploite aussi très certainement des notions peu familières: référence vers tableau VS pointeur, require, static_assert, héritage privé, invariant garantis par construction ; et ça manque possiblement d'explicit.


Ton type Personne serait ensuite construit à partir de 2 non_empty_string.

Par contre... ces machins dès qu'on les déplace (tu verras ça plus tard, ou dans un autre cours post-débutant), ils ne seront plus garantis non-vides...

Bref, la conclusion: ici des exceptions, c'est bien

[Mat.M]

comme l'écrit Bousk il faut gérer une exception.

[fred1599]

Hello,

comme l'écrit Bousk il faut gérer une exception.

Ah mais Bousk ne dit pas "il faut", pourquoi il faut ?

Moi je vois plein d'autres solutions, par exemple en C++ 17 on pourrait utiliser std::optional non ?

ou via un pointeur intelligent ?

[Luc Hermitte]

Salut,

Moi je vois plein d'autres solutions, par exemple en C++ 17 on pourrait utiliser std::optional non ?

ou via un pointeur intelligent ?

Ha! Bien vu.

Mais... ne serait-pas une erreur de programmation dans le contexte de son désign? Du coup plutôt que d'introduire du code à vocation de traiter des erreurs de progs, quid d'une assertion des familles?

[fred1599]

Vous connaissez le besoin du PO ? Et que comprenez vous de ce "design" ?

Si la condition détermine si l'objet doit être créé ou ne pas exister du tout, je trouve que std::optional plutôt intéressant, en tout cas une solution à proposer...