striiiiiiiiiiiiiiing - Page 29

Folco (./840) :

Sasume (./837) :
Ah parce qu’à chaque fois tu empiles les appels de fonction ?

J'ai deux situations :
- Module1 fait charger Module2 par le TaskManager, et Module2 en quittant demande au TM de repasser la main au module précédant : je dois donc empiler.- Module1 fait charger Module2, mais n'attends pas de retour : le TM doit donc décharger Module1 avant de charger le 2.

Je ne suis pas sûr de comprendre ces subtilités mais globalement c’est simple : si le TaskManager doit allouer ou libérer des modules au cours de l’exécution, c’est sûrement plus simple d’allouer sur le tas.

Souci avec une liste d'initialisation d'un objet (pour changer...) :

        std::vector<Module> *m_ModuleList;
        std::vector<int> *m_TaskList;

Ces deux pointeurs sont des attributs d'un objet. Donc quand je crée cet objet, deux vecteurs sont créés, et *m_ModuleList et *m_TaskList prennent comme valeur l'adresse des-dits vecteurs.
Et donc dans ma liste d'init, je mets quoi ? Je vais pas initialiser l'adresse des vecteurs à autre chose pour le plaisir, non ? Et g++ râle si je ne mets rien...
Comment faire propre ? (à moins que je n'ai pas compris le mécanisme de la création des objets :/)

Tu ne peux rien mettre dans la liste d’initialisation, à part m_ModuleList(0), mais ça n’a pas grand intérêt. Tu dois faire l’allocation dans le corps du constructeur.Sinon (à mon avis le mieux), tu peux ne pas utiliser des pointeurs vers des vectors, mais des vectors, tout simplement. Et là tu n’as rien à mettre dans ton constructeur, les vectors seront automatiquement construits avec le constructeur par défaut (celui sans paramètre).

J'avais donc bien raté un truc, c'est pas parce que j'ai un pointeur vers un vecteur dans mes attributs que le vecteur est créé.

Sinon ok pour le point 1, merci.

    Message Messagebox;                        /* Global message box for all objects */
    Messagebox.sendMessage(ID_TASK_MANAGER, ID_TASK_MANAGER, MSG_NEW_MODULE, NULL, MODULE_INTRO);

Très rigolo ma messagerie qui se crée, le TM s'envoie un message pour s'auto-dire de charger l'intro. J'aime bien ce genre de conneries
</mylife>

Bon, je suis paumé avec ce fichu template vector

Je veux que m_ModuleList soit un pointeur sur un vector contenant des pointeurs de Module.
J'ai écrit le proto de cet attribut :
std::vector<Module*> *m_ModuleList;
Ca va ? Je dois bien mettre une astérisque il me semble ?
Et j'initialise ainsi :
std::vector<Module*> m_ModuleList;
Ca va attribuer l'adresse de mon vecteur à m_ModuleList ? Je suis sûr de rien

Folco (./844) :
Bon, je suis paumé avec ce fichu template vector

Je veux que m_ModuleList soit un pointeur sur un vector contenant des pointeurs de Module.
J'ai écrit le proto de cet attribut :
std::vector<Module*> *m_ModuleList;Ca va ? Je dois bien mettre une astérisque il me semble ?

Si tu veux que ce soit un pointeur oui.

Et j'initialise ainsi :
std::vector<Module*> m_ModuleList;
Ca va attribuer l'adresse de mon vecteur à m_ModuleList ? Je suis sûr de rien

Un pointeur vers un objet ça se crée avec new (machin* a = new machin()) si c'était bien ta question. Mais je suis même pas certain d'avoir compris t'a question, donc si tu peux reformuler, je ferai mieux

Ta déclaration est juste mais je comprends pas ce que tu veux faire après.
Pour initialiser un pointeur on fait comment?
malloc/new
Donc m_ModuleList = new type(arguments) avec '(args)' inutile ici puisqu'un vector a un constructeur sans argument (cf la doc) et 'type' quelque chose qui ressemble à std::vector<Module*>.

Golden : Bon, merci pour la première réponse, c'est bon.

Donc je veux initialiser mon vecteur, pour qu'il contienne des Module*, et que m_ModuleList pointe sur ce vecteur.
Mais je n'arrive pas à faire l'allocation, j'ai des erreurs de syntaxe et je trouve pas comment faire


Bon.
Hum...
Comment dire... euh... prochaine fois, je ferai gaffe à bien écrire std et non sdt.
Et ça ira mieux. Oui, j'ai fini par trouver, c'est la syntaxe que tu donnes Brunni :
m_ModuleList = new std::vector<Module*>;

m_ModuleList->push_back(new Module()); ?

edit : t'as édité entre temps ou j'ai mal lu ?

<Module*>();essaie avec m_ModuleList = new std::vector mais je ne garantis rien (il me semble que normalement les compilos n'aiment pas les parenthèses sur un constructeur sans argument, mais à part ça, je ne vois pas où est l'erreur)

sinon pourquoi veux-tu un pointeur vers un vecteur et pas un vecteur directement ? à moins que le pointeur soit là pour contenir une référence vers un vecteur crée par un autre objet, je ne vois pas l'intérêt du pointeur dans ce cas là

Golden -> Ah oui tiens, j'ai écrit ça :
m_ModuleList->resize(m_ModuleList->size() + 1);
puis écriture du Module* dans la dernière case, mais ta solution est meilleure. J'ai la doc de C++ ouverte, mais j'ai du mal à retenir toutes les méthodes à la fois pour choisir la meilleure. Merci bien.

edit -> en fait, ça fait :
m_ModuleList->push_back(new StaticModule());
j'ai pas encore mis la liste d'init de StaticModule.

ps -> StaticModule dérive de Module, je vais donc avoir un StaticModule* et non un Module* dans le vecteur, et il gueule pas. C'est ça le polymorphisme ?

aze (./849) :
sinon pourquoi veux-tu un pointeur vers un vecteur et pas un vecteur directement ? à moins que le pointeur soit là pour contenir une référence vers un vecteur crée par un autre objet, je ne vois pas l'intérêt du pointeur dans ce cas là

Oui, mais un pointeur c'est quoi ? Un pointeur vers un tableau (style C) ? Le pointeur est donc sur la pile si je ne fais pas de new vector<truc>. Mais le contenu du vecteur est où ? sur la pile ? en RAM ? S'il est sur la pile, comment le redimensionner ? en fait, je vois pas trop comment c'est foutu, et sur le heap, je suis sûr que c'est redimensionnable

aze (./849) :
edit : t'as édité entre temps ou j'ai mal lu ?

Désolé, j'ai édité dans tous les sens (j'ai trouvé mon erreur entre temps !) ^^

Je ne poste plus le temps que ça se tasse, et en attendant un éclaircissement à mon problème de ./851 (je comprends rien à ces vecteurs )

le contenu du vector est sur le tas, même si l'objet vector est lui même sur la pile

tu te poses trop de questions
la doc te dit qu'il est redimensionnable, donc il l'est même s'il est sur la pile. le vector se démerde en interne. Il faut faire confiance aux classes externes que tu utilises et ne pas essayer de deviner comment ça pourrait fonctionner en interne. surtout si tu apprends le c++. tu peux dois les considérer comme des boites noires et focaliser ton énergie sur le fonctionnement de ton appli ^^

Un vecteur c'est une classe qui t'assure que tous les éléments que tu fous dedans sont enregistrés de maniere consécutive, comme dans un tableau C
donc tu as cette propriété qui est identique pour un vector et pour un tableau :

v std::vector<A>;
&v[i] == &v[0] + i;
// mais
&v[0] != &v;

v2 A[42];
&v2[i] == &v2[0] + i;

mais attention, &v[0] != &v, en interne le vector va allouer de la mémoire dans lequel il va placer des éléments. l'objet vector à proprement dit contient que l'adresse de la zone de mémoire alloués, sa taille, le nb d'éléments et surement d'autres métadonnées, mais pas les éléments eux-mêmes

Folco (./850) :
Golden -> Ah oui tiens, j'ai écrit ça :
m_ModuleList->resize(m_ModuleList->size() + 1);
puis écriture du Module* dans la dernière case, mais ta solution est meilleure. J'ai la doc de C++ ouverte, mais j'ai du mal à retenir toutes les méthodes à la fois pour choisir la meilleure. Merci bien.

Bah pour répondre à ça et à ton ./851 du même coup.
Un vecteur C++ c'est une liste variable d'éléments (je ne sais pas vraiment pourquoi ils ont apellé ça vecteur d'ailleurs, pour moi un vecteur c'est un truc d'algèbre/géométrie, mais bon…), autrement interprétable comme étant un tableau de taille variable. En réalité tableau de taille variable, c'est l'implémentation (ça pourrait être une liste chaînée, mais ce n'est pas le cas de vector), la liste variable d'éléments, c'est le comportement. Et ce qui t'importe, c'est le comportement.
Bref, une liste:
1. Ordonnée, donc tu peux accéder aux éléments avec un indice et un ordre défini, donc tu peux également parcourir cette liste en long en large et en travers (itérateurs).
2. Variable, donc tu peux ajouter et retirer des éléments.
3. Ordonnée et variable, donc tu peux insérer et supprimer des éléments à un endroit précis.
Toute les méthodes que dont pourrais avoir besoin pour chacune de ces opérations doivent exister. Cherche l'opération qui correspond à ce que tu veux faire, puis cherche la méthode qui correspond à cette opération (quand elle existe).

Plus généralement, c'est une des structures de base de la programmation, tout comme les piles ou les listes chaînées. Il existe des classes pour chacune de ces structures. En C++, et dans la plupart des langages objets.

ps -> StaticModule dérive de Module, je vais donc avoir un StaticModule* et non un Module* dans le vecteur, et il gueule pas. C'est ça le polymorphisme ?

Oui, c'est même la base !
Sans cette bête fonctionnalité, rien d'autre ne serait possible.
Si B dérive de A, alors tout élément de type B est aussi un élément de type A.
Dont on dérive: si B dérive de A, alors tout élément de type B* est également un élément de type A*.

Ok, merci pour tout encore une fois.

Oui, je me prends trop la tête en effet.

STRIIIINNNNG !!! \o/



\o\
\o/
/o/
_o/
\o_
_o_
/o\
\o/

Folco (./822) :
Et ça vous arrive de créer un bloc juste pour obtenir la destruction d'un objet ?

Oui.

GoldenCrystal (./827) :
mais beaucoup moins depuis la mort de la mémoire partagée entre processus

Ce n'est pas mort du tout, le shared memory.

mais c'est sale.

Folco: Fais moi plaisir et prend des bonnes habitudes.
Je te conseille vivement de lire ce livre:
Le C++ efficace de Scott Meyers

Bah, les règles décrites dans ce livre sont loin d'être uniformément acceptées. Cf. aussi -Weffc++, qui n'est pas activé par défaut et pour lequel la doc dit clairement que les headers de a libstdc++ n'y sont pas conformes. (Et seules certaines de ces règles sont automatiquement vérifiables par g++.)

Ce n'est pas parce que libstdc++ ne respecte pas ces regles qu'il n'est pas utile de les respecter pour son propre code

squalyl (./859) :
mais c'est sale.

Pourquoi ?

juste comme ça, mais personne a rebondi dessus ^^

Merde moi j’ai sauté dedans

JackosKing (./860) :
Folco: Fais moi plaisir et prend des bonnes habitudes.
Je te conseille vivement de lire ce livre:
Le C++ efficace de Scott Meyers

http://www.amazon.fr/C-efficace-Scott-Meyers/dp/271178682X

Oué ben au prix de l'efficace pour un simple amateur, on va attendre un poil, ya des priorités

Mais je retiens, c'est con si c'était que le fait de le lire ça serait torché dans la semaine

Kevin Kofler (./858) :

Folco (./822) :
Et ça vous arrive de créer un bloc juste pour obtenir la destruction d'un objet ?

Oui.

GoldenCrystal (./827) :
mais beaucoup moins depuis la mort de la mémoire partagée entre processus

Ce n'est pas mort du tout, le shared memory.

Sur les vrais OS en tout cas, ça l'est (à peu de choses près). C'est pour ça qu'on utilise des fichiers mappés en mémoire à la place. Seulement, eux, ils sont libérés quand plus personne ne s'en sert
C'est d'ailleurs une des raisons pour lesquelles la mémoire partagée est crade ( ./863 ), mais on peut en énumérer d'autres.
C'est enfantin de corrompre les données partagées. => Si un processus plante ou se fait hacker, il peut pourrir tous ses copains.
La mémoire partagée n'est pas utile dans la plupart des applications. Elle n'est utile que pour des mécanismes d'IPC avancés, mais dans le reste du temps, on peut sagement laisser l'OS gérer la mémoire comme il faut et partager la mémoire quand il doit le faire.
Ça rend également la synchronisation plus complexe, car ce n'est plus un thread qui verrouille de la mémoire vis à vis d'autres threads dans le même processus, mais un thread qui doit verrouiller la mémoire vis à vis d'autres threads dans d'autres processus.

Alors qu'à côté de ça on a des mécanismes d'IPC comme les pipe qui gèrent la synchronisation inter-processus tout seuls, …

niveau latence ça lagge pas trop les pipes?