Serialisation portable d'obj connu

Bonjour,

Je dois dans un cadre scolaire développer une classe capable de sérialiser une classe connue afin d'enregistrer tout ses occurences dans un seul et même fichier binaire.
J'inisite que je connais à quel type de classe je vais devoir sauvegarder via read/write de iostream.

Avant de commencer à coder cette classe, voici les questions que je me pose:

Comment peut-on éditer une des occurences du fichier de sauvegarde binaire sans devoir réécrire tout le fichier (bah oui, j'ai des char* = taille nonf-fixe> débordement sur un autre obj déja sérializé)
La seule solution que j'ai: recharger tout les occurences dans un vecteur (template home-made), éditer celle que je veux et tout réécrire.

Comment faire en sorte que les fichiers sérialisés fonctions sur les archtectures SPARC & i386 sans traitments des fichiers au changement de plateforme. Je crois que la représentation des entiers et d'autres choses peuvent poser problème. Existe t'il des "parades" à ce genre de problème?

Ce travail est dans le but scolaire afin d'obtenir une matrise sur ostream & la sérialisation. Je ne peut ni utiliser boost ni la stl.

Quelqu'un aurait-il une idée pour m'aider à résoudre les deux problèmes évoqués ci-dessus.

PS: si mon titre n'est pas assez "parlant" ne pas hésiter à le modifier ou déplacer le topic

Salut,

Il faut savoir que, l'un dans l'autre, un fichier binaire a toutes les chances de ne jamais être compatible entre architectures différentes...

Que ce soit parce qu'un caractère risque de ne pas utiliser le même nombre de bits, parce qu'il y a un problème de boutisme, ou... les raisons sont nombreuses pour en arriver à ce point.

La solution pourrait passer par un encodage de type "TCP/IP", par lequel tu déciderais une bonne fois pour toute d'une taille et d'un boutisme particulier pour maintenir les informations dans ton fichier de sauvegarde.

A ce moment là, ce sera cependant le programme qui devra être adapté à l'architecture (avec une éventuelle conversion little endian<-->big endian si l'architecture sur laquelle le fichier est lu n'est pas celle sur laquelle le fichier est créé), éventuellement par directives préprocesseurs, si tu ne veux pas avoir à maintenir deux codes différents.

Pour ce qui est de la conversion big<-->little endian, tu peux te tourner vers les fonction htons et ntohs.

D'un autre coté, si je peux comprendre un prof qui demande de ne pas utiliser boost (quoi que, j'attendrai de connaitre ses motivations avant de le laisser faire sans réagir), je ne comprendrai jamais un prof qui refuse que tu utilise la STL, surtout si c'est pour essayer de faire des programmes portables.

Ceci dit, l'avantage d'un fichier binaire, c'est que tu sais normalement précisément la taille que pourra prendre une structure donnée.

Si même tu te retrouve avec une chaine de caractères, le mieux est de faire un nombre de caractères correspondant à la taille maximale de celle-ci.

Cela occasionnera sans doute une "perte d'espace", dans le sens où, si tu prévois 50 caractères pour ta chaine et que le mot tient en 10, tu te retrouvera avec 40 caractères '\0', mais cela te permettra d'effectuer un parcours indexé sur les structures enregistrées ;)

Il te sera donc éventuellement possible (pour la lecture, non pour l'écriture) de te dire que, si tu veux accéder au Neme élément du fichier, tu dois partir du début, passer l'éventuelle en-tete que tu aurais fournies (dont, entre autres, le nombre d'éléments qu'il contient, voire, des informations concernant la structure), puis aller à l'index correspondant à (N-1)*taille de la structure sauvegardée.

Pour l'écriture, tu n'aura pas le choix: un fichier est toujours "gravé dans le marbre": si tu veux apporter la moindre modification à l'intérieur du fichier (l'ajout en fin de fichier est possible), il faudra... casser la dalle et le recommencer ;)

M.E.R.CI pour la réponse.

Jvé m'attaquer dès ce soir au problème de l'architecture et voir htons et ntohs.
Saurais tu me me dire comment détecter si l'os est solaris ou si l'architecture est sparc ?
Ici une réponse interessante. Dois-je continuer à chercher ? :)

Coté fichier, je vais essayer de faire une segmentation assez large pour que tout mes objets "rentrent" dans chaque segment (barbare un jour,.... toujours).

L'interet de ne pas utiliser la stl ? Laisser les petits élèves vivre sans string... et donc faire des setters à la noix pour y mettre des new & strcpy. Aussi pour nous apprendre à créer nous même un conteneur template valable de A à Z pour nos types créés avec nos petits doigts. Si on donne tout aux élèves le copier coller est trop vite fait et la démarche intellectuelle est absente. Mais j'aime bien, cela nous fait prendre conscience des mécanismes qui sont déja mit en place pour nous.

Citation:

---

Envoyé par Haknaton

Comment faire en sorte que les fichiers sérialisés fonctions sur les archtectures SPARC & i386 sans traitments des fichiers au changement de plateforme. Je crois que la représentation des entiers et d'autres choses peuvent poser problème. Existe t'il des "parades" à ce genre de problème?

---

Oui partiellement.
1- Décider du format qu'aura chaque type de donnée dans le fichier sérialisé (dans quel ordre les bytes seront écrits...), sans se préoccuper trop de la manière dont c'est représenté sur une machine particulière
2- N'écrire dans le fichier que des unsigned char ou tableaux d'unsigned char, jamais de types plus évolués

Ex : Sauver un int i sur 4 octets :
unsigned char buffer[4];
buffer[0] = i;
buffer[1] = i >> 8;
buffer[2] = i >> 16;
buffer[3] = i >> 24;
Puis on sauve buffer.


Pourquoi partiellement seulement ?

- Parce qu'il sera difficile/impossible de trouver un tel format neutre pour les flottants si les deux machines ne respectent pas la même norme de représentation (mais ça devrait être très rare).

- Parce que si la structure contient des types qui n'ont pas le même intervalle de valeur possible d'une machine à l'autre (ex un int qui serait 32 bits d'un côté, 64 bits de l'autre), je ne vois pas ce qu'on peut faire.

Citation:

---

Envoyé par koala01

D'un autre coté, si je peux comprendre un prof qui demande de ne pas utiliser boost (quoi que, j'attendrai de connaitre ses motivations avant de le laisser faire sans réagir), je ne comprendrai jamais un prof qui refuse que tu utilise la STL, surtout si c'est pour essayer de faire des programmes portables.

---

Le seul intérêt que je peux voir, c'est susciter l'intérêt et l'envie par l'interdiction... De façon à ce que, quand elle est levée, les élèves se ruent sur le fruit défendu...

Et les fonction de conversion htonl/ntohl proposées par koala01 ne résolvent pas mon problème ? Il me semble d'ailleur qu'elle font leur job (si necessaire) suivant l'achitecture sans détection préable de celle-ci
Il faut absolument passer par des char pour avoir une compatibilité sur nos unix i386 et les jolis solaris sparc de mon école ?

Tout les types doivent être dissolus en char ? Sinon quels sont ceux qui échapent à cette transformation ? Qui des chaines de caractères (sachant qu'elles sont Très nombreuses dans mes objets *à mort le char :evilred: *, avec string ça aurait été pire :/ string -> char[] -> version portable)

Je me demande au final si je suis pas en train de me compliquer vachement la tache pour ne pas me casser la tête a avoir 2 lots de fichier de data raw.


Pour répondre encore à la question de l'enseignement: si on ne comprend pas les bases, inutile de voir plus loin. Laisser des élèves ne sachant pas ce que c'est une classe utiliser la STL ou Boost ça serait de la folie pur. Mais après 6 mois du dur labeur nous auront droit de l'utiliser. Chouette :D

Citation:

---

Envoyé par Haknaton

Et les fonction de conversion htonl/ntohl proposées par koala01 ne résolvent pas mon problème ?

---

Elle le font probablement, la méthode que je propose a les avantages suivants :
- Elle marche pour d'autres types que long et short
- Elle ne demande pas l'utilisation d'une bibliothèque non standard (qui plus est dédiée au réseau, et non à la sérialisation...) (et ce qui me semblait t'être interdit)
- Elle permet d'écrire un fichier à un format spécifié, si on doit s'adapter à un format existant, au lieu d'imposer le format "réseau".

Citation:

---

Envoyé par Haknaton

Il me semble d'ailleur qu'elle font leur job (si necessaire) suivant l'achitecture sans détection préable de celle-ci

---

Il n'y a pas non plus de détection d'architecture dans ma méthode, pour peu que les architectures soient suffisamment semblables (ce qui est nécessaire aussi avec hton*). Il y en a même moins, car la localisation du header décrivant les hton* n'étant pas standard, tu vas devoir faire du code platform spécifique pour l'inclure ;)

Je veux pas faire le casse pied .... mais ....

Si le nombre d'octet utilisés pour un type change d'une plateforme à l'autre ? on fait comment ?

Il faudra que je me renseigne car je crois que c'est le cas sous les sparc de l'école.

Prochaine lecture à l'aube sous les néons du labo ....

Citation:

---

Envoyé par Haknaton

Je veux pas faire le casse pied .... mais ....

Si le nombre d'octet utilisés pour un type change d'une plateforme à l'autre ? on fait comment ?

Il faudra que je me renseigne car je crois que c'est le cas sous les sparc de l'école.

Prochaine lecture à l'aube sous les néons du labo ....

---

A ce moment là, le mieux est de penser au "plus grand commun multiple"...

Si on considère qu'un byte fait d'office 8 bits (et donc que l'on ne risque pas de se retrouver avec des caractères de 6 ou 7 bits ;)), et que d'une architecture à l'autre, l'entier fait 4 ou 8 caractères, ou que le réel en fait 8 ou 12, tu prend comme valeur la plus petite à chaque fois, pour avoir la certitude que tu ne souffrira pas de perte de données.

Pour les entiers, cela ne posera pas de problème, étant donné que "qui peut le plus, peut le moins", tu n'aura "qu'à" gérer le boutisme de manière correcte.

Pour ce qui est des réels, ils sont généralement représentés sous la forme de mantisse + exposant + signes.

Il faudra donc prendre la mantisse et l'exposant le plus petit des deux (même si l'une est issue d'un système et l'autre de l'autre) et t'assurer du fait que les bonnes valeurs aillent au bon endroit ;) ( et donc que 123 en mantisse et -1255 en exposant soient correctement représentés quel que soit le système :D)

Pour les structures de données pouvant être sérialisées, je conseille plutôt d'employer uniquement des types à taille fixe.
Il n'y a rien de standard pour ça en C++98, mais tu peux utiliser des typedefs qui dépendent de la plate-forme.

Et ensuite, dans tes structures, il n'est plus question de short, int ou long, mais de int16_t, int32_t, etc.

Citation:

---

Envoyé par Haknaton

M.E.R.CI pour la réponse.

Jvé m'attaquer dès ce soir au problème de l'architecture et voir htons et ntohs.
Saurais tu me me dire comment détecter si l'os est solaris ou si l'architecture est sparc ? (snip)

---

• Pour ce qui est des os, tu trouvera ton bonheur ==>ici<==
• Pour ce qui est des compilateurs, tu trouvera une liste bien complete ==> ici <==
• Enfin, pour ce qui en est des architectures, c'est la page d'à coté: elle se trouve ==> ici <==

J'ai trouvé une perle ! Comment faire toutes les transformations de type sans prise de tête direction une FAQ ?

Et maintenant je planche sur comment faire une classe qui va se charger de sérialiser & faire les read/write du fichier.
Je suis en train de me casser la tête pour avoir une classe template, que je peux hériter et qui devra gerer l'enregistrement de plusieurs objets dans en fichier en ce souciant de réécrire sur l'objet si il existait déja.

J'ai pris l'option de segmenter mon fichier à la taille de mon plus "gros" objet que je peux obtenir. J'ai calculé la taille du segment à l'aide de la taille des buffers que j'utilise pour saisir mes char* + marge d'erreur ... pas très compliqué au final.

Mais je ne vois pas comment créer une classe qui pourra serialiser mes objets sans les connaitres. En fait je ne sais pas trop comment orienter la chose. Si je dois faire une classe qui s'occupe du boulot ou si je doit faire une classe dont peuvent hériter mes objets.

Vous avez des idées pour un étudier qui doit réinventer la roue ?
Une petite idée de pattern ou un truc du genre?

Merci déja à tous pour les réponses que vous m'avez fournit.

Regarder boost::serialization peut donner des idées, même s'il est difficile de tout faire dans un programme d'exemple.

Justement! J'ai bien signalé que dans le cadre de l'étude, je suis interdit de l'utilisation de la stl (on réinvente le string & container template à la main...) et histoire de bosser la sérialisation .... pas de boost.

Je sais pas si j'ai le "niveau" pour aller lire des source de boost coté sérialisation :/

Donc je cherche toujours...

Il ne s'agit pas tant de lire les sources que la documentation, qui présente les idées mises en place dans la biblitohèque pour simplifier l'écriture de la fonction de sérialisation, ainsi que les différentes difficultés rencontrées.

Bonsoir!

Je viens d'aller voir l'utilisation de Boost serialize, du bêton la classe!
Mais je me pose quelques question afin de pouvoir utiliser mes classe comme eux le font.

Si je fait une classe Store et que je veux lui jeter un élément Bidule que j'ai créé. Store
Puis faire un opérateur d'insertion membre sur ma classe qui prend n'importe quoi en paramètre et qui accepterais d'appeler la fonction serialize dessu ?

Code:

---

1 2 3 4 5 6 7 8 9 10

class Store { public: Store& operator<<(N'Importequoi & N) }; Store& Store::operator<<(N'Importequoi & N) { N.Serialize(); }

---

Code:

---

template <class T> Store& operator<<(T & t);

---

?

Citation:

---

Envoyé par JolyLoic

Code:

---

template <class T> Store& operator<<(T & t);

---

?

---

De faite... suis-je bête :( Merci JolyLoic !
Mais bon je n'ai vu en cours que les classes template et pas les les fonctions template et donc la question est la suivante:

Doit-on pré-initialiser les fonctions template comme je le fesais avec les class template via les pragma ou l'autre méthode dont j'ai oublié le nom ....

et si cette fonction devient polymorphique pour s'adapter au types connus (int, char, char*, ...) et qu'elle est déclarée plus loin en template ... le compilateur saura t'il qu'il doit appeler la fonction template pour un objet qu'il ne connais pas ?

Désolé si ces questions peuvent sembler tès bête par rappport à tout les précédantes mais là je ne maitrise pas trop les fonctions templates/non-template à la sauce polymorphique...

Encore merci de m'aider à mener si bien mon projet. Je sens que le but est proche, une classe ressemblant à boost serialize sur des fichier binaires segmenté, portable 386/sparc, capable de fonctionner sur des types non connus en adaptant mon objet à sauvegarder de quelques lignes et qui répond à ce que l'énnoncé me demande.

Citation:

---

Envoyé par Haknaton

Doit-on pré-initialiser les fonctions template comme je le fesais avec les class template via les pragma ou l'autre méthode dont j'ai oublié le nom ....

---

Je ne vois pas du tout à quoi tu fais allusion... :(

Citation:

---

Envoyé par Haknaton

et si cette fonction devient polymorphique pour s'adapter au types connus (int, char, char*, ...) et qu'elle est déclarée plus loin en template ... le compilateur saura t'il qu'il doit appeler la fonction template pour un objet qu'il ne connais pas ?

---

Une fonction template et virtuelle, ça ne peut pas exister. Je ne vois pas trop pourquoi tu en aurais besoin ici ?

Pour être précis, une fonction plus template que sa classe et virtuelle, ça ne peut pas exister.

Désolé désolé, j'avais d'oublier que la spécialisation de template existait...
il faudrais que je me remette un peux a chercher comme un grand avant de faire huler tout le monde :mouarf:

Je veux juste que l'opérateur réagisse différement suivant le type de l'obj.
Si c'est un type primitif, je l'écrit sur le fichier. Sinon l'objet est une de mes classe, j'exécute donc sa fonction sérialise !

Jvé enfin pouvoir passer sur pc !

Je viens de commencer à coder et le problème des templates me rattrape encore :/ Sale crasse ce truc sur un vieux g++
Serialize.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#ifndef SERIALIZE_MAIN_ #define SERIALIZE_MAIN_ #include "iostream.h" #include "stdlib.h" #include "fstream.h" class Serialize { public: Serialize(const char * nomFichier, int tailleSegment=0); template <class B> void operator<<(const B & b) { cerr<<"Operateur d'insert"<<endl; } private: int _tailleSegment; Serialize(); }; #endif

---

Serialize.cpp

Code:

---

1 2 3 4 5

#include "Serialize.h" Serialize::Serialize(const char * nomFichier, int tailleSegment) { cerr<<"[SERIALIZE] Constructeur"<<endl; }

---

Mais mon prof ne trouve vraiment pas ça joli d'avoir une fonction implémentée dans un .h... seule fonction template de tout ma classe :evilred:

J'essaye ceci:
Serialize.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#ifndef SERIALIZE_MAIN_ #define SERIALIZE_MAIN_ #include "iostream.h" #include "stdlib.h" #include "fstream.h" class Serialize { public: Serialize(const char * nomFichier, int tailleSegment=0); template <class B> void operator<<(const B & b); private: int _tailleSegment; Serialize(); }; #endif

---

Serialize.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include "Serialize.h" Serialize::Serialize(const char * nomFichier, int tailleSegment) { cerr<<"[SERIALIZE] Constructeur"<<endl; } template <class B> void Serialize::operator<<(const B & b) { cerr<<"[SERIALIZE] <int> Operateur d'insertion"<<endl; } //Problème ici !! template void Serialize::operator<<(const int & b);

---

Mais je suis obliger d'instancier mes templates ainsi:

Code:

---

template void Serialize::operator<<(const int & b);

---

Car sinon mon main me répond:

Code:

---

undefined reference to `void Serialize::operator<< <int>(int const&)

---

C'est moche ... quel est l'interet des templates alors ?
Comment concerver la séparation .h/.cpp
sachant que le compilateur que j'ai à l'école est incapable de faire de l'instentiation automatique... donc il compile le template et puis arriver au main il ne va plus voir le template qui est compilé une seule et unique fois et se crache comme un c** à l'édition des liens. Je par à la recherche d'un mécanisme de manière à forcer une recompilation...

Dis à ta prof de revoir sa copie, une fonction template est toujours définie dans un .h.

Ou dans un fichier à part (l'extension .tpp semble populaire) inclus par le .h.
Il ne peut en être autrement à moins d'utiliser les export templates, qui ne sont pas supportés partout pareil.

Et, de manière générale, évite les fichiers d'en-tete standard avec l'extension .h...

Préfère leur la version sans extension, qui t'assure qu'ils prennent en compte - bien qu'à leur manière - la norme ;)
Utilise donc de préférence

• <iostream> pour remplacer iostream.h
• rien (pas besoin) pour remplacer stdlib.h
• <fstream> pour remplacer fstream.h

La simple différence réside dans le fait que les différentes classes déclarées dans ces fichiers sont accessibles dans l'espace de noms std ;)

Citation:

---

Envoyé par koala01

Et, de manière générale, évite les fichiers d'en-tete standard avec l'extension .h...

Préfère leur la version sans extension, qui t'assure qu'ils prennent en compte - bien qu'à leur manière - la norme ;)
Utilise donc de préférence

• <iostream> pour remplacer iostream.h
• rien (pas besoin) pour remplacer stdlib.h
• <fstream> pour remplacer fstream.h

La simple différence réside dans le fait que les différentes classes déclarées dans ces fichiers sont accessibles dans l'espace de noms std ;)

---

Ca je savais :p mais j'ai pas trop envie de m'amuser avec le namespace std pour li'nstant. Avec ou sans extension quel sont les réels changement ? car la majorité des EDI sont capable de faire des groupage de fichier suivant extension que je trouve bien pratique. Le fait d'avoir l'extension permet aussi de savoir ce qu'il y a dedans. Pourquoi la version sans extension respecte plus la "norme" ?

Citation:

---

Envoyé par Médinoc

Dis à ta prof de revoir sa copie, une fonction template est toujours définie dans un .h.

Ou dans un fichier à part (l'extension .tpp semble populaire) inclus par le .h.
Il ne peut en être autrement à moins d'utiliser les export templates, qui ne sont pas supportés partout pareil.

---

A bon ?! Moi qui croyais pourtant qu'il serait possible de définir une fonction template membre dans la classe et de l'implémenter dans le .cpp correspondant.
J'ai essayé la version ".tpp" comme tu appeles ça. J'ai utilisé le modèle de la FAQ ... et je ne sais pourquoi mais dans mon cas, ça ne marche pas. Il faut que seul la fonction membre soit dans ce fichier ? Donc ça me ferais 2fichier par classe + autant de fichier que de fonction membre. Exact ?

Pour en revenir à des librairies existantes dont je suis censé m'inspirer "intelligemment" savez vous comment elles gèrent les templates ? (boost & stl)

Encore merci de partager vos connaissance qui nous sont utile pour parfois combler le manque de précision dans nos syllabus !

Citation:

---

Envoyé par Haknaton

Ca je savais :p mais j'ai pas trop envie de m'amuser avec le namespace std pour li'nstant. Avec ou sans extension quel sont les réels changement ? car la majorité des EDI sont capable de faire des groupage de fichier suivant extension que je trouve bien pratique. Le fait d'avoir l'extension permet aussi de savoir ce qu'il y a dedans. Pourquoi la version sans extension respecte plus la "norme" ?

---

En fait, la version avec l'extension a été utilisée de manière propre à chaque compilateur avant qu'il n'y ait l'idée d'une normalisation.

Pour éviter les problèmes de compatibilité et d'ambiguité (un truc qui serait déclaré dans un fichier d'en-tête sur un compilateur particulier et dans un autre sur un autre compilateur) la norme a décidé de n'utiliser aucune extension, et de tout mettre dans un espace de noms particulier

Finalement, qu'il s'agisse de la version avec ou sans extension, tu peux toujours ouvrir le fichier d'en-tete avec n'importe quel éditeur de texte... La seule différence se retrouvant sous windows où, ne disposant pas d'extension, il est impossible de demander à windows de décider automatiquement l'outil à utiliser pour les ouvrir ;)

Quant à l'utilisation de l'espace de nom std en elle-même, il "suffit" de prendre l'habitude d'utiliser le nom long (std::cout, std::string, ...) au lieu de la version abrégée (cout, string, ...)... Et encore, en dehors des fichiers d'en-tête, rien ne t'interdit d'utiliser la directive using namespace, bien que cela enlève tout l'attrait des espaces de noms, du fait que tu ne saura plus faire la différence entre la classe vector de la STL et ta propre classe vector :P

Citation:

---

A bon ?! Moi qui croyais pourtant qu'il serait possible de définir une fonction template membre dans la classe et de l'implémenter dans le .cpp correspondant.
J'ai essayé la version ".tpp" comme tu appeles ça. J'ai utilisé le modèle de la FAQ ... et je ne sais pourquoi mais dans mon cas, ça ne marche pas. Il faut que seul la fonction membre soit dans ce fichier ? Donc ça me ferais 2fichier par classe + autant de fichier que de fonction membre. Exact ?

---

Le principe d'une classe (ou fonction) template, c'est que l'on y indique tout sauf... le type d'objet réellement géré.

Du coup, le compilateur ne peut pas crééer un implémentation réelle du code des différentes fonctions, vu qu'il ne sait pas... quelle taille donner à l'objet.

Il ne créera le code propre à un type particulier qu'une fois qu'il saura... quel type est à utiliser, et donc sa taille en mémoire :P

Mais pour pouvoir créer le code "exécutable" de la fonction, il faut qu'il soit en mesure... de trouver le code C++ de cette fonction, et donc, que cette implémentation soit accessible par le fichier d'en-tête.

Comme il est généralement admis que les fichier ayant l'extension cpp sont des fichier d'implémentation qui sont de nature à permettre la création d'un fichier objet, il est également admis "l'interdiction" d'inclure un fichier de cette extension avec la directive #include

C'est la raison pour laquelle le meilleur conseil à donner est, si tu ne veux pas présenter l'implémentation d'une fonction (méthode) template directement dans le fichier d'en-tête, d'utiliser une extension de ton choix autre que cpp ou toute extension communément admise pour représenter un type de fichier particulier (xml, jpg, htm...)

C'est la raison pour laquelle on propose régulièrement tpp (Template cPP) impl (IMPLementation) ou autre ;)

Citation:

---

Pour en revenir à des librairies existantes dont je suis censé m'inspirer "intelligemment" savez vous comment elles gèrent les templates ? (boost & stl)

---

en un mot: incontournable.

Tout (ou presque) passe par l'utilisation de template, tant dans boost que dans la stl.

Quant à la manière dont c'est implémenté, cela peut très bien varier entre la définition de la fonction directement dans la déclaration de la classe et l'implémentation dans un fichier particulier (tpp, impl ou... n'importe quoi tant que ce n'est pas un *.cpp ou une des extensions régulièrement admise pour représenter un type de fichier particulier)

Citation:

---

Envoyé par Médinoc

Dis à ta prof de revoir sa copie, une fonction template est toujours définie dans un .h.

Ou dans un fichier à part (l'extension .tpp semble populaire) inclus par le .h.
Il ne peut en être autrement à moins d'utiliser les export templates, qui ne sont pas supportés partout pareil.

---

Je parlais bien de l'implémentation! qui malheureusement doit être faite dans le .h afin de ne pas devoir instancer manuellement les templates :(

Question pour les amateurs de boost.

Comment boost détecte t'il que la taille de la chaine qu'il va désérialiser si on lui passe un char * ?
Car je suis callé sur ce point et j'hésite à lire tout char par char jusque arriver au 0 de fin de chaine ... serait t'il possible d'utiliser la lecture avec un fstream jusqu'un délimiteur ?

Par défaut, boost ne sérialise pas les char*, c'est trop casse gueule (surtout à la désérialisation : La mémoire doit-elle être allouée par new, par malloc, par autre-chose, ne pas être allouée,... ?).

Pour les chaînes string, de mémoire, il sauve d'abord la taille, puis la chaîne.

Merci de la réponse JolyLoic
J'ai donc pris une décision. On nous a cassé les pieds pour qu'on utilise des char* je sauvegarderais donc des char * et puis je ferais des new.
Et comme il est facile de distinguer char * et const char* je sais où je dois faire des strcpy et où je dois faire des new.

edit: ouich, comme l'histoire du serpent qui se mort la queue...

Détecter un tableau en const char* c'est bien ... mais une fois que j'ai lu ce que je devait récupérer dans le fichier pour faire une désérialisation, comment faire un strcpy sur un const char* ....

Je patauge...

------------------------------------------------------------
J'ai testé avec des casts barbares de (char*) ... c'est puant, ça à marché (30sec) pour les tableau. Qd j'ai du passer aux chaines dynamique je me suis rendu compte que je devait jouer avec des pointeurs de pointeurs... (double free sinon)

Impossible de faire du bon travail sans de bon outils. Avec string ça aurait fonctionné ... mais bon les prof veulent que l'on soit au courant des mécanismes internes du cpp (char* + allocation dynamique) et pas de string. Moi qui voulait avoir une super librairie, je dépose les armes.

Direction le délestage du forum ...
Histoire d'un étudiant rebelle ou perfectionniste :/ ?