Discussion :

[mazertys17]

Bonjour.

Il se passe quelque chose d'étrange dans mon code...J'aimerais utiliser une chaîne d'objets hérités, qui pourrait être accessible pour chacun d'entre eux.
Je crée donc une class Container qui jouera le rôle d'un vector amélioré, en somme, en y mettant à l'intérieur un vector d'OBJECT.
Quand je crée un vector d'OBJECT normale, ca marche.
quand je crée un vector de std::shared_ptr d'OBJECT, ca plante.

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
 
 
class Container_OBJECT
{
 
public :
 
    Container_OBJECT() ;
    ~Container_OBJECT() ;
 
    void                                                            setSystem ( std::shared_ptr < System > system ) { _system = system ; }
    void                                                            add ( std::shared_ptr < OBJECT > object ) ;
 
    void                                                            update() ;
    void                                                            destroyed() ;
 
 
private :
 
    std::shared_ptr < System >                                              _system ;
    std::vector < std::shared_ptr < OBJECT > >                      _OBJECT ;
    OBJECT                                                                            _OBJECT_Test ; //celui ci fonctionne.
 
};

exemple d'utilisation :

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
 
 
ENGINE::ENGINE()
{
    ...
 
    std::shared_ptr < Container_OBJECT > modelC ( new Container_OBJECT ) ;
    modelC -> setSystem ( _system ) ;
 
    _Container_OBJECT = modelC ;
 
}
 
void ENGINE::load()
{
        ...
 
        _Container_OBJECT -> destroyed() ;
 
        _Container_OBJECT -> add ( _RESOURCES.getOBJECT( word ) ;
 
}

ca plante, et en débug on m'indique l'endroit du bug, dans stl_vector.h :

{ return const_iterator(this->_M_impl._M_finish); }

En revanche, si je fais la même chose avec l'objet test, qui n'est pas en std::shared_ptr, ca fonctionne.
Vu que je préfère éviter les pointeurs nu dans ce cas, même si c'est tout de même faisable vu le Container n'est pas censé disparaître, je viens vers vous en espérant avoir peut être une piste/solution/mise en avant d'erreur etc.. et vous poser cette question :

Cela peut-il être lié au fait que mon "OBJECT" soit dérivé en d'autres objets ?

Merci si vous pouvez m'aider.

[mintho carmo]

Si les messages d'erreur font plusieurs lignes, ce n'est pas pour rien, évites de donner qu'une partie.
En général, l'erreur n'est pas dans le code de la STL, mais dans le code appelant. Comme tu ne donnes pas le code de destroyed, add, get_OBJECT, on ne va pas pouvoir t'aider.

Par contre, il n'y a bien sur pas de problème a utiliser les pointeurs intelligents avec le polymorphisme d’héritage.

HS sur le style :
- je suppose que tu utilises des tabulations et pas des espaces (d'ou la mise en forme moisi sur le forum). Tu devrais configurer ton IDE pour remplacer automatiquement cela.
- noms en minuscules et majuscules. Bof (historiquement, les termes tout en majuscules correspond a des macros)
- évite les noms commençant par _ (c'est pas interdit dans ce cas la, mais cela peut l'etre dans d'autre contexte. L'habitude est de ne pas du tout faire comme cela)
- préférer make_shared plutot que new
- pourquoi créer une variable intermédiaire inutile modeleC ?
- pourquoi _Container_OBJECT est un pointeur ?
- les pointeurs intelligents permettent de sécuriser le code. Cela ne veut pas dire qu'ils font tout le boulot a la place du développeur. Il faut TOUJOURS tester un pointeur avec de l'utiliser (et plus généralement tester tes pre-conditions)

[mazertys17]

Merci pour vos réponses et tous les conseils.

En fait, il ne se passe rien d'autre que ceci, par ex, dans ma fonction destroyed ( qui a elle seul fait planter ) :

Code :

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

1
2
3
4
5
6
7
8
9
 
 
void Container_OBJECT::destroyed()
{
    if ( !_OBJECT.empty() )
    {
 
    }
}

une autre "étape" du message d'erreur :

Code :

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

1
2
3
4
5
6
7
8
9
 
      /**
       *  Returns a read-only (constant) iterator that points one past
       *  the last element in the %vector.  Iteration is done in
       *  ordinary element order.
       */
      const_iterator
      end() const _GLIBCXX_NOEXCEPT
      { return const_iterator(this->_M_impl._M_finish); }

évite les noms commençant par _ (c'est pas interdit dans ce cas la, mais cela peut l'etre dans d'autre contexte. L'habitude est de ne pas du tout faire comme cela)

Quelles sont les bonne habitudes à prendre dans ce cas ? Car il s'agit bien d'attributs d'une class. ( je fais jusqu'à présent comme on le dit dans les cours C++, sauf erreur...)

pourquoi _Container_OBJECT est un pointeur ?

En fait je suis en train de réaliser que c'est en effet inutile, vu que je pourrais pas l'implémenter dans les objets. Le but étant que chacun y ait accès. Il faudra en revanche qu'ils aient accès à son vector d'objets, pour pouvoir eux même créer d'autres objets quand ils le souhaitent. ( c'est l'objectif du moins ).
Mais bon, il n’empêche que je ne vois toujours pas pourquoi ça plante...

[mintho carmo]

une autre "étape" du message d'erreur :

Tu n'as pas compris quoi quand j'ai dit "évites de donner qu'une partie" ?

[mazertys17]

dison que la totalité c'est un peu lourd non ? ( si c'est bien ce que vous demandez ) :

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
 
 
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: C:\Users\mathieu\Documents\echappatoire\BigBangElement\BigBangElement\
Adding source dir: C:\Users\mathieu\Documents\echappatoire\BigBangElement\BigBangElement\
Adding file: C:\Users\mathieu\Documents\echappatoire\BigBangElement\BigBangElement\bin\Debug\Element.exe
Changing directory to: C:/Users/mathieu/Documents/echappatoire/BigBangElement/BigBangElement/.
Set variable: PATH=.;C:\lib;C:\lib;C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\CMake\bin;C:\Program Files\Microsoft SQL Server\110\Tools\Binn
Starting debugger: C:\Program Files (x86)\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname  -quiet  -args C:/Users/mathieu/Documents/echappatoire/BigBangElement/BigBangElement/bin/Debug/Element.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.5
Child process PID: 14296
Program received signal SIGSEGV, Segmentation fault.
At c:\program files (x86)\codeblocks\mingw\lib\gcc\mingw32\4.7.1\include\c++\bits\stl_vector.h:883

Et ce que j'ai mis précédemment, c'est de code direct de la stl, là ou le débug m'indique que ca plante.

[mintho carmo]

Des messages d'erreurs un peu "lourd", c'est plusieurs milliers de lignes. Dans ce cas, ok, il faut pas toutes les donner. Mais la, tu as 20 lignes, c'est pas la mort.

Cela permet au moins de savoir que la pile des erreurs n'est pas complète. Je n'utilises pas trop Code::Block, mais il faut que le debug s’arrête lors de l'erreur et affiche la pile d'appel des fonctions qui ont causer l'erreur

Il faut la fenêtre d'appel des fonctions

[ternel]

La, tu as exclusivement une segfault.

Ca veut dire que tu utilise un pointeur invalide.

Il y a deux grandes causes possibles: un pointeur non initialisé, une copie de pointeur vers un bloc déjà libéré.

Code :

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

1
2
3
4
5
6
7
void Container_OBJECT::destroyed()
{
    if ( !_OBJECT.empty() )
    {
 
    }
}

Cette fonction me semble très suspecte.
destroyed est un adjectif, on s'attend avec un tel nom à ce que la fonction retourne un booléan disant si oui ou non *this est "destroyed".

Du coup, je me demande ce que peut être le _OBJECT membre de Container_OBJECT.
Et aussi pourquoi ne pas l'avoir appelé inner, internal, contained, ou data.

[ternel]

Ton code ne montre pas le problème.
Pourrais-tu faire un "code court compilable" montrant le problème, s'il te plait?

[Iradrille]

Hello,

Çà ne répond pas vraiment à la question, mais pourquoi autant de std::shared_ptr ?
Les objets sont tous réellement partagés, ou c'est par simplicité ?