IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage C++ Discussion :

Constructeur & shared_from_this


Sujet :

Langage C++

  1. #1
    Membre régulier Avatar de GrosLapin
    Homme Profil pro
    Ingénieur et Etudiant
    Inscrit en
    avril 2013
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur et Etudiant

    Informations forums :
    Inscription : avril 2013
    Messages : 47
    Points : 85
    Points
    85
    Par défaut Constructeur & shared_from_this
    Bonjour à tous,

    Débutant avec les pointeurs intelligents (vieux motard que jamais ) j'ai rencontrer un problème qui a soulevé plusieurs questions.

    Je vous pose le contexte de maniérè très simplifié : Je suis en train de créer un petit "tower défense" (dans un but pédagogique) qui contient des Cases qui contiennent des "éléments de jeu" (dans une collection quelconque de weak_ptr puisque la Case ne souhaite pas gérer la mémoire mais uniquement pouvoir regarder s'il y a des gens dedans). Une case est dite "occupé" si il y a au moins un élément de jeu dedans. J'ai ensuite créé une Tour qui est un élément de jeu et qui prend en paramètre du constructeur une case.
    Et voila, le drame arrive :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    Tour(Case& maCase)
    {
        [...]
        maCase.addElementJeu(shared_from_this());
    }
    Et c'est le Bad_Weak_Ptr \o/

    Un coup de google, on me dit que mon objet est pas completement construit et que je peux pas faire ça... Ok. Bon pas dramatique je vais faire une fonction statique [type de retour à réfléchir] CreerTour(Case&), un constructeur en protected et j'aurais ce que je veux.

    Cependant j'ai deux questions que j'arrive pas résoudre :
    1. Comment la fonction shared_from_this sait que j'ai pas fini le constructeur, je veux dire, elle vient d'une classe mère qui devrait être initialisé avant de rentrer dans le constructeur, comment elle sait que l'objet est pas fini d’être construit ?
    2. Qu'est ce que ça veux dire ne pas être complétement construit ? Qu'est ce que mon objet a concrètement de plus entre la dernière ligne de mon constructeur et le moment ou il est construit ?
    3. Ce que je faisais avant (quand j'utilisais pas les qqch_ptr) aurait était de faire maCase.addElementJeu(this) je suppose qu'il doit aussi y avoir un problème d'objet mal construit mais je vois pas lequel...

    Et oui ça fait trois questions \o/

    Si vous pouvez m'éclairer, je suis preneur

    GrosLapin

  2. #2
    Membre expérimenté Avatar de Trademark
    Profil pro
    Inscrit en
    février 2009
    Messages
    762
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2009
    Messages : 762
    Points : 1 396
    Points
    1 396
    Par défaut
    Est-ce que ton objet Tour est instancié dans un shared_ptr<Tour> ?

  3. #3
    Membre régulier Avatar de GrosLapin
    Homme Profil pro
    Ingénieur et Etudiant
    Inscrit en
    avril 2013
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur et Etudiant

    Informations forums :
    Inscription : avril 2013
    Messages : 47
    Points : 85
    Points
    85
    Par défaut
    J'ai pas mon code sous les yeux mais ça je crois pas.
    En version minimaliste :
    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
    21
    22
    23
    24
     
    using namespace std;
     
    struct Tour;
    struct Case
    {
        vector<weak_ptr<Tour>> vecTour;
        void addTour(weak_ptr<Tour> wpT) { vecTour.push_back(wpT);}
    };
     
    struct Tour : public enable_shared_from_this<Tour>
    {
        Tour (Case& uneCase)
        {
            uneCase.addTour(shared_from_this());
        }
    };
     
    int main ()
    {
        Case uneCase;
        Tour uneTour(uneCase);  // call un std::bad_weak_ptr
        shared_ptr<Tour> test = make_shared<Tour>(uneCase); // call un std::bad_weak_ptr
    }
    J'ai testé aussi en le mettant dans un shared_ptr comme tu le suggères mais ça change rien

    Ps : Ceci étant à part si j'ai loupé quelque chose d’énorme (ce qui peut tout à fait être le cas) je cherche plus des réponses aux questions qu'une solution pour mon code ^^

  4. #4
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 711
    Points : 4 437
    Points
    4 437
    Par défaut
    Hello,

    Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.
    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
    21
    22
    23
    using namespace std;
     
    struct Tour;
    struct Case {
    	vector<weak_ptr<Tour>> vecTour;
    	void addTour(weak_ptr<Tour> wpT) { vecTour.push_back(wpT);}
    };
     
    struct Tour : public enable_shared_from_this<Tour> {
    	static shared_ptr<Tour> create(Case& c) {
    		auto t = make_shared<Tour>();
    		c.addTour(weak_ptr<Tour>(t));
    		return t;
    	}
     
    private:
    	Tour ()	{ }
    };
     
    int main () {
        Case uneCase;
        auto tour = Tour::create(uneCase);
    }
    (Le nom "Case" est à éviter : risque de confusion avec le mot-clef)

  5. #5
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 195
    Points : 9 413
    Points
    9 413
    Par défaut
    un petit lien peut-être utile : Checked delete

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    Citation Envoyé par Iradrille Voir le message
    Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.
    La partie importante est que shared_from_this ne peut etre appele que sur un objet qui est deja géré par un shared_ptr (c'est la creation de ce shared_ptr qui va initialiser le weak_ptr a l'interieur du enable_shared_from_this).

    Or dans le constructeur, l'objet n'est pas encore géré par un shared_ptr, donc son weak_ptr n'est pas initialisé, d'où l'erreur que tu reçois.

    Mais de façon générale, tu devrais eviter les shared_ptr autant que faire ce peux. La majorité du temps, tu devrais pouvoir trouver qui "possède" un certain objet. Dans ton cas, il me semble qu'il serait naturelle que la case possède la Tour, et donc aie un unique_ptr.

  7. #7
    Membre régulier Avatar de GrosLapin
    Homme Profil pro
    Ingénieur et Etudiant
    Inscrit en
    avril 2013
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur et Etudiant

    Informations forums :
    Inscription : avril 2013
    Messages : 47
    Points : 85
    Points
    85
    Par défaut
    Merci pour vos réponses et désolé pour mon temps de réponse, j'avais pas le net

    @Iradrille
    Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.
    Yep, effectivement, mais ce que je comprends pas c'est comment il sait que je suis encore dans le constructeur ?

    @foetus
    Je suis pas sur d'avoir bien compris :'( l'astuce du checked delete c'est pour quand on ne connais pas encore le type (déclaration incomplète) si j'ai bien compris ton lien. Ca voudrais dire qu'on ne connait pas la taille d'un type dans son constructeur ?

    @TropMDR
    Mais de façon générale, tu devrais eviter les shared_ptr autant que faire ce peux.
    Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)

    GrosLapin

  8. #8
    Membre expérimenté Avatar de Trademark
    Profil pro
    Inscrit en
    février 2009
    Messages
    762
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2009
    Messages : 762
    Points : 1 396
    Points
    1 396
    Par défaut
    Citation Envoyé par GrosLapin Voir le message
    Merci pour vos réponses et désolé pour mon temps de réponse, j'avais pas le net

    @Iradrille
    Yep, effectivement, mais ce que je comprends pas c'est comment il sait que je suis encore dans le constructeur ?
    Comme l'a dit TropMDR, tu ne peux appeler shared_from_this que si l'objet en question est déjà géré par un shared_ptr, or vu que tu es dans le constructeur, l'objet n'est pas encore créé est donc pas encore géré par un shared_ptr.

    Citation Envoyé par GrosLapin Voir le message
    Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)
    GrosLapin
    Tu peux utiliser une référence pour utiliser ce unique_ptr, quel serait le problème ?

  9. #9
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Pour l'utilisation des pointeurs nus, la bonne pratique actuelle est de ne pas utiliser de pointeurs nus qui auraient un rôle dans la durée de vie des objets pointés. Là, tu ne fais qu'observer les données, donc pas de soucis. Il y a une proposition en cours pour ajouter un pointeur dont le rôle serait d'être plus explicite sur le fait qu'il ne fait qu'observer, mais ce n'est pas encore fait.

    Pour le shared_from_this depuis un constructeur, moi aussi j'avais du mal à comprendre au début. Mais en fait, il faut bien voir que la construction se fait en deux étapes : On crée l'objet, qui peut très bien ne jamais être géré ni par pointeur shared_ptr, ni même par pointeur nu (mais simplement comme une variable locale, par exemple), on réserve juste dans cet objet un peu de place pour plus tard. Par la suite, quand on construit un shared_ptr en lui passant en argument l'adresse de l'objet, à ce moment là uniquement on sait que l'objet va être géré par le shared_ptr, et c'est donc ce dernier qui va utiliser cet espace mémoire réservé afin de permettre à shared_from_this de marcher.

    Donc, la règle n'est pas : "pas de shared_from_this dans le constructeur" mais "pas de shared_from_this avant d'avoir créé un shared_pointeur pointant sur cet objet."

    Tu vas me dire : Très bien, mais dans mon cas, les objets seront toujours gérés par shared_ptr, je m'en moque qu'il puisse prendre en compte des variables locales, j'aimerais qu'il fasse le travail quoi qu'il arrive. Ce à quoi je répondrais : Très bien, l'idiome pour t'assurer que c'est effectivement le cas consiste justement à créer une fonction factory retournant un shared_ptr, et rendre le constructeur non accessible.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  10. #10
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par Trademark Voir le message
    Tu peux utiliser une référence pour utiliser ce unique_ptr, quel serait le problème ?
    Le fait qu'une référence soit non-réaffectable est souvent problématique, et le pointeur nu reste justifié dans ce genre de cas.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  11. #11
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 195
    Points : 9 413
    Points
    9 413
    Par défaut
    Citation Envoyé par GrosLapin Voir le message
    @foetus
    Je suis pas sur d'avoir bien compris :'( l'astuce du checked delete c'est pour quand on ne connais pas encore le type (déclaration incomplète) si j'ai bien compris ton lien. Ca voudrais dire qu'on ne connait pas la taille d'un type dans son constructeur ?
    Tu te demandais ce qu'est un type incomplet. Ne pas avoir de destructeur propre (dû essentiellement a une déclaration incomplète) est une réponse.
    Et rien qu'avec un sizeof on le détecte

    Et comme l'a dit Iradrille (mettre un shared_from_this dans un constructeur c'est [sûrement] un problème connu) et comme l'a expliqué JolyLoic (une construction en plusieurs étapes) tout ceci explique le pourquoi du comment

  12. #12
    Membre éprouvé
    Profil pro
    Inscrit en
    mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    Citation Envoyé par GrosLapin Voir le message
    Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)
    Il n'y a aucun problème à utiliser les pointeurs nus. L'idée avec un unique_ptr, c'est d'exprimer qui a la possession du pointeur, et que cette possession est unique. Mais ca ne veux pas dire que personne d'autre ne peux accéder au pointeur, juste que la durée de vie de l'objet pointé est définie par la durée de vie du unique_ptr. Par exemple, le code suivant est parfaitement acceptable
    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
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    #include <iostream>
    #include <map>
    #include <memory>
    #include <string>
     
    // Je suis contre l'ouverture de namespace, mais ici, ca ira.
    using namespace std;
     
    template <typename K, typename V>
    class MyMap {
     public:
      MyMap() {}
      // Prends possession du pointeur.
      void Insert(const K& k, unique_ptr<V> v) {
        map_[k] = move(v);
      }
     
      // L'appelant n'a pas possession du pointeur.
      V* Get(const K& k) {
        auto iter = map_.find(k);
        if (iter == map_.end()) {
          return nullptr;
        } else {
          return iter->second.get();
        }
      }
     
      // L'appelant prend possession du pointeur.
      unique_ptr<V> Release(const K& k) {
        auto iter = map_.find(k);
        if (iter == map_.end()) {
          return nullptr;
        } else {
          unique_ptr<V> result;
          result.swap(iter->second);
          map_.erase(iter);
          return result;
        }
      }  
     
     private:
      map<K, unique_ptr<V>> map_;
    };
     
     
    int main() {
      MyMap<int, string> my_map;
      my_map.Insert(1, unique_ptr<string>(new string("number one")));
      cout << *(my_map.Get(1)) << endl;
      unique_ptr<string> content = my_map.Release(1);
      if (my_map.Get(1) == nullptr) {
        cout << "C'est bien null!" << endl;
      }
    }
    où l'usage de pointeur nu vs unique_ptr exprime le passage de possession (ownership)

  13. #13
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Dans ton exemple, la méthode Get pourrait renvoyer une référence. Je pense que cela a plus de sens sémantiquement.

    Comme l'a dit JolyLoic :
    Citation Envoyé par JolyLoic Voir le message
    Le fait qu'une référence soit non-réaffectable est souvent problématique, et le pointeur nu reste justifié dans ce genre de cas.
    Dans ce cas, il faudrait un autre pointeur intelligent qui dit que l'objet existe forcément (et qu'on n'a pas la responsabilité de la mémoire) (un truc qui pourrait s'appeler ref_ptr par exemple :E).

  14. #14
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    5 154
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 5 154
    Points : 16 976
    Points
    16 976
    Par défaut
    Ce n'est pas plus ou moins le role du weak_ptr?
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  15. #15
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    weak_ptr est à utiliser avec shared_ptr.
    La sémantique de weak_ptr n'est pas : «l'objet existe forcément» (contrairement au "ref_ptr" que je propose).

  16. #16
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 715
    Points : 3 461
    Points
    3 461
    Par défaut
    std::reference_wrapper ?

  17. #17
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Oui j'avais zappé que l'opérateur de copie faisait ce que l'on voulait ici :s
    (j'aurais, peut être, préféré que non)

  18. #18
    Membre régulier Avatar de GrosLapin
    Homme Profil pro
    Ingénieur et Etudiant
    Inscrit en
    avril 2013
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur et Etudiant

    Informations forums :
    Inscription : avril 2013
    Messages : 47
    Points : 85
    Points
    85
    Par défaut
    Encore merci pour ces réponses,

    Je pense avoir mieux compris donc je tag en résolu.

    @JolyLoic
    Pour le shared_from_this depuis un constructeur, moi aussi j'avais du mal à comprendre au début. Mais en fait, il faut bien voir que la construction se fait en deux étapes : On crée l'objet, qui peut très bien ne jamais être géré ni par pointeur shared_ptr, ni même par pointeur nu (mais simplement comme une variable locale, par exemple), on réserve juste dans cet objet un peu de place pour plus tard. Par la suite, quand on construit un shared_ptr en lui passant en argument l'adresse de l'objet, à ce moment là uniquement on sait que l'objet va être géré par le shared_ptr, et c'est donc ce dernier qui va utiliser cet espace mémoire réservé afin de permettre à shared_from_this de marcher
    C'est ce qui me manquait
    Edit : Est ce que par hasard tu aurais un lien qui rentre plus dans le détail de la construction des objets (je dois pas avoir les bons mots clés je suis pollué par les articles pour les grands débutants)

    @JolyLoic + @TropMDR
    Pour l'utilisation des pointeurs nus, la bonne pratique actuelle est de ne pas utiliser de pointeurs nus qui auraient un rôle dans la durée de vie des objets pointés. Là, tu ne fais qu'observer les données, donc pas de soucis.
    Ok j’intègre ça dans mes bonnes pratiques

    @jo_link_noir
    std::reference_wrapper ?
    Le problème du reference_wrapper c'est que j'ai besoin d'avoir un tableau (std::array) dans l'une de mes classe et que je peux pas faire un std::array de reference_wrapper... enfin plus exactement je peux pas faire un tableau qui ne soit pas complétement rempli, or dans mon cas ça a un sens d'avoir un tableau qui fasse "NULL, NULL, qqch, qqch, NULL , qqch" il faudrait peut être que je cherche vers le std::optional mais ça me semblait compliquer beaucoup mon code pour juste éviter un pointeur.

    Encore merci pour vos réponses.

    GrosLapin

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 10
    Dernier message: 14/06/2010, 10h58
  2. [VB6]Déclaration d'un Constructeur Spécialisé
    Par TagadaTsoin dans le forum VB 6 et antérieur
    Réponses: 21
    Dernier message: 26/05/2004, 14h09
  3. Capture d'exception dans un constructeur
    Par declencher dans le forum Composants VCL
    Réponses: 8
    Dernier message: 03/02/2004, 12h52
  4. pb constructeurs classes dérivant classe abstraite
    Par Cornell dans le forum Langage
    Réponses: 2
    Dernier message: 10/02/2003, 19h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo