Discussion :

[dj.motte]

Bonjour,

A vrai dire je n' ai rien contre les string de la stl. Mais dans certains cas on préfère :

Code :

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

1
2
3
4
 
typedef struct personne 
{ char id [10]  ;  
} personne ;

à

Code :

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

1
2
3
4
 
typedef struct personne
{ string id ;
} personne;

Je sais les typedef ne servent à rien. Mais la première version de "personne" se laisse mieux manipuler dans des lecture-écritures sur des fichiers typés, des FILE*, ou des fstream...

Le "std::string" résoud le problème du "char * fou", mais ne résoud pas la question des structures de données à dimensions fixes.

On peut certes créer des flux pour l' entrée comme pour la sortie d' une structure définie par l' utilisateur. Mais quelle perte de temps, et de prolifération de code !

Votre avis ?

Salut.

[Luc Hermitte]

En ce qui me concerne, la perte de temps est dans les char[].
=> plus de vérifications et de réflexion sont nécessaires pour avoir un code robuste.
Même un débutant aura du mal à se tirer dans le pieds avec des std::string. Chose importante sur un projet conséquent sur lequel plusieurs personnes travaillent.

Mon expérience est aussi que les fichiers que l'on disait "structurés" (du temps du Pascal) ne sont plus aussi répandus.
D'un, cela introduit des limitations inacceptables aujourd'hui, les informaticiens qui s'auto-imposaient des longueurs max pour les chaînes sont bien moins nombreux que les utilisateurs qui ne comprendraient pas les raisons de ces limitations.

De deux, même des informaticiens savent que l'on ne peut pas sérialiser brutalement de façon sérieuse. Cf les problèmes d'endianness ("boutisme" pour les allergiques aux anglicismes).

Sans parler de la sur-consommation sur le disque.

Bref, c'est un format que je trouve dépassé. P.ex., des trucs comme l'XML sont bien plus à la mode. Pas forcément un bien, mais bon.


Pour des bases plus sérieuses, en particulier volumineuses, et où les temps d'accès sont critiques et où l'on ne peut pas tout charger, bien justement, il y a des bases de données pour cela.

[loufoque]

Il n'est pas propre de sérialiser des objets à partir de leur valeur binaire.

[dj.motte]

Bonjour,

Luc écrit :

Bref, c'est un format que je trouve dépassé. P.ex., des trucs comme l'XML sont bien plus à la mode. Pas forcément un bien, mais bon.

Ben oui c' est plus à la mode de faire dans l' XML. Mais c' est une régression par rapport à l' architecture précise des bases de données. Aprés tout, toutes les bases données stockent leurs données selon une structure, un schéma, ou un plan.

C' est lorsque l' on découvre le plan du stockage des données, que se pose la question d' un schéma universel. On réduit à l' universel, ce qui est plus performant dans la logique propriétaire. Mais sans garantie de performances...

Excusez-moi mais XML n' est pas synomyme de performance !

Salut.

[koala01]

(...)

C' est lorsque l' on découvre le plan du stockage des données, que se pose la question d' un schéma universel. On réduit à l' universel, ce qui est plus performant dans la logique propriétaire. Mais sans garantie de performances...

Excusez-moi mais XML n' est pas synomyme de performance !

Salut.

Tu remarqueras que luc n'a jamais dit que le XML était d'office meilleur... Il a juste dit que c'est "plus à la mode"...

Et, ceci dit, rien n'empeche jamais d'ouvrir un fichier en mode std::bin, et de gérer les valeurs dans leur format (propriétaire ou non)

A vrai dire, j'ai réellement l'impression que tu ressent les string comme la cause de tous tes malheurs, alors qu'elles sont faites, comme le reste de la S(T)L, uniquement pour te faciliter la vie... mais que, fatalement, ca signifie, peut etre, de bousculer les habitudes - chose qu'on ne fait jamais de bon coeur -

[koala01]

Salut,

Une fois n'est pas coutume, je suis tout à fait d'accord avec l'avis de Luc...

L'argument majeur est le meme: avant de faire une betise avec les string, il faut vraiment le vouloir...

De plus, tu parles d'une perte de temps, mais, à bien y réfléchir, je n'en vois qu'une: les quelques minutes qui sont nécessaires pour s'habituer aux différentes méthodes offertes par les string... et qui seront tres rapidement regagnées par la suite...

En effet, quand on y réfléchit corrrectement:

• il n'y a rien que tu puisse faire avec une chaine C style que tu ne puisse pas faire avec une string
• Tu subiras, comme l'a signalé luc, beaucoup moins de restrictions avec les string qu'avec les chaine C style
• Il n'y a qu'avec les noms de fichiers - et je n'ai personnellement jamais compris pourquoi, il n'ont jamais surchargé l'ouverture de fichier pour supporter les string - et les fonctions "pure C" que tu pourrais devoir transformer une string en chaine C style... et cela se fait très facilement grace à la methode c_str()...

Enfin, je ne vois vraiment pas ce qui peut changer entre un code (non orienté objet) -hormis, bien sur, la sécurité apportée par les string... ce qui est un argument en défaveur des chaine C style - du genre de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
typedef struct personne 
{ 
    char id [10]  ;
    typebase blabla;// AKA: n'importe quel type de base, autre qu'une chaine
} personne ;
 
bool Save(const char* filename,const personne& pers)
{
    std::ofstream ofs(filename);
   ofs<<pers.id<<" "<<blabla;
}

et le meme code sous la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
typedef struct personne 
{ 
    string id 
    typebase blabla;// AKA: n'importe quel type de base, autre qu'une chaine
} personne ;
 
bool Save(const string& filename,const personne& pers)
{
    std::ofstream ofs(filename.c_str());
    ofs<<pers.id<<" "<<blabla;
}

Et ce, d'autant plus qu'il n'y a jamais guere eu qu'en DOS que les noms de fichiers étaient limité à 8+3 caractères
[EDIT]D'ailleurs, si tu parcourres ne serait-ce que les premieres pages du forum, tu trouveras quantité de sujets qui ont trait à différents problèmes liés à l'utilisation des chaines C style et qui auraient facilement pu etre évités en utilisant les string [/EDIT]

[dj.motte]

Bonjour,

Les messages se sont croisés.
Koala01 y apporte des choses qu' il a inventé.

Salut.

[koala01]

Bonjour,

Les messages se sont croisés.
Koala01 y apporte des choses qu' il a inventé.

Salut.

Heuu... qu'ai-je inventé

Bien sur, j'ai, entre autre, parlé des noms de fichiers et des *fstream... ce qui est normal, pour aller jusqu'au bout d'un raisonnement...

Mais, à part cela, je n'ai rien inventé du tout... (car je n'ai jamais dit que TU présentais les choses sous l'angle que j'utilisais)

[Luc Hermitte]

Koala, ce qui chagrinait dj.motte, c'est l'inadéquation entre les std::string et les fichiers dits "structurés".
Il est effectivement plus simple de revenir à une structure POD dépourvue d'indirections pour sérialiser comme des bourrins.

De mon point de vue de développeur dont le coeur de métier ne me fait pas travailler chez Oracle ou tout autre éditeur de BD.
- Les fichiers textuels offrent beaucoup plus de souplesse
- La quantité de données que je manipule directement est bien moindre, (et quand il s'agit de fiches "binaires", leur longueur est variable, ou alors je dois passer par xerces-c ) ; ou alors je m'interface à Oracle via OCCI ce qui me permet d'échanger std::string et autres std::vector directement (au détail des blobs et des clobs )
- Les problèmes de portabilité pouraient se poser. Ou plus exactement, des problèmes d'échange de données entre des machines dont les choix d'endianness diffèrent.

Après, effectivement, dans le code d'une BD, je ne doute pas que les structures à taille fixe soient toujours utilisées. Mais, de toutes façons, l'impératif de portabilité fera qu'ils ne sérializeront pas comme des bourrins.


De fait, les fichiers structurés ne m'apportent rien dans mes développements, je peux en toute quiétude utiliser un type robuste et simple à utiliser.

PS: je ne suis pas un fana de l'XML. Loin de là.