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]

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]

(...)

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]

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à.

[koala01]

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

C'est bien ce qu'il m'avait semblé comprendre...

Disons que, comme toute chose en programmation, ca peut etre particulièrement intéressant dans une situation donnée... mais, de là à en faire la généralité, il y a un pas que certaines gens ont trop facile à franchir

[dj.motte]

Bonjour,

Luc écrit :

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.

Dans la plupart des tables de BD le champ chaîne de caractères est représenté avec une dimension de longueur fixe. Même si cela paraît ringard, cela permet à chaque ligne de la table d' avoir une dimension déterminée. Cela permet un accés direct à la ligne calculée. C' est une des raisons qui me fait penser que les chaînes de type C sont encore plausibles. Biensûr les std::string c' est glogalement mieux.

Quant à l' impératif de portabilité, là je ne vois pas.
Je voulais tout simplement faire remarquer que si une table est définie par :

Code :

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

1
2
3
4
 
id int 
nom char[20]
etc..

cela va être ennuyant d' y accéder par

Code :

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

1
2
3
4
5
6
 
struct X
{ int id ;
   std::string nom ;
   etc...
};

Maintenant je ne connais pas bien cette notion de fichier textuel. XML me paraît naîvement un exemple. Les fichiers délimités ? Eclairez ma lanterne SVP !

Perso je trouve XML repoussant, et je doûte de ces performances, mais il paraît que c' est la grande révolution dans l' échange de données.

Maintenant certaines BD n' ont pas vocation à l' échange de leurs contenus.

Salut.

[Luc Hermitte]

Concernant la portabilité, on ne peut pas faire ce genre de choses

Code :

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

1
2
3
4
5
6
7
8
9
// je suppose sint16 un type entier 16 bits signé, etc
struct Table {
   sint16 s;
   uint32 ll;
   char s[42];
};
....
Table t = { 42, 42*42, "toto" };
file.write(reinterpret_cast<char*>(&t), sizeof(t));

Ceci est en gros la seule utilité que je pourrais voir dans mon code de tous les jours aux structures évoquées dans ce fil de discussion => à utiliser des tables bourrinement sérialisables dans des fichiers.
Seulement, ce n'est pas portable.
Si je ne me plante pas, ce code compilé sur un intel écrira ceci dans le fichier:

Code :

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

2a 00 e4 06 00 00 7a 6f 7a 6f 00 na wa k' .. ...

Le même code sur une sparc donnera

Code :

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

00 2a 00 00 06 e4 7a 6f 7a 6f 00 na wa k' .. ...

Bref, pour s'en sortir, quand on veut du portable, il faut obligatoirement sérialiser chaque champs individuellement, pour le passer à une moulinette de la famille des nttohs().
=> http://fr.wikipedia.org/wiki/Endianess


PS: J'entends par fichier texte: un fichier humainement décodable et maintenable. Que les champs soient séparées par des points-virgules, des tabulations, ou des balises bien verbeuses. Dans ces fichiers, le nombre 42 est stocké sous sa forme textuelle où chauque chiffre prend un octet, et non sa forme binaire qui tient sur un seul octet.

[David Fleury]

dj.motte:
IMHO, avec le temps (plusieurs années) une structure contenant une std::string resistera mieux au évolution (notamment des schémas de la base) qu'un char[20] car il y a le risque que le 20 devienne 25 (à moins d'une certaine rigueur qui peut couter cher).

Concernant le XML, c'est lent, assez lourd à générer (comparer à du texte simple) mais cela permet d'utiliser des outils autour (Xpath, XQuery, ... ) qui sont pratiques pour la manipulation des ces données (contrairement à un fichier plat où les champs optionnels peuvent être pénibles à matérialisé par exemple ).

Par contre, je ne comprends pas pourquoi se serait ennuyant std::string (plus que char[] ) ?

Pour les bases de données, et c'est peut être leur gros défaut, c'est peut être justement leur schéma figé dans une vision relationnelle (plutôt en ligne) des données alors qu'on pourrait envisager une vision plus hiérarchique (orienté objet si on veut), ce que permet plus facilement quelque chose comme le XML.

[dj.motte]

Bonjour,

Luc a écrit :

PS: J'entends par fichier texte: un fichier humainement décodable et maintenable. Que les champs soient séparées par des points-virgules, des tabulations, ou des balises bien verbeuses. Dans ces fichiers, le nombre 42 est stocké sous sa forme textuelle où chauque chiffre prend un octet, et non sa forme binaire qui tient sur un seul octet.

Le but des BD n' est pas d' offrir des données "humainenent décodable et maintenable". Il s' agit là de la grande illusion de MS comme de l' OS.

Bercy se moque de savoir si son fichier des contribuables est plus "communicant".

Il ne faut pas se leurrer sur l' inter-communication des fichiers.

La papate reste dans l' exportation vers un délimité texte, une sorte de migration qui vous invite à faire du C .

XML reste dans le transfert des données triviales, mais pas stratégiques.

Salut.

[loufoque]

De toutes manières les fichiers binaires utilisés dans les bases de données sont bien plus complexes que de simples écritures de PODs.

[dj.motte]

Bonjour,

Loufoque écrit :

De toutes manières les fichiers binaires utilisés dans les bases de données sont bien plus complexes que de simples écritures de PODs.

Oui mais si l' on dispose de l' architecture d' une base de données particulière, on passe vite d' une écriture en C++ dogmatique, vers une écriture plus modeste, plus au raz des paquerettes.

Les std::string comme les flux du C++ sont parfois des handicapes à une meilleure gestion des fichiers binaires.

Mais vous me direz comme Luc que le fichier binaire est ringard ?

Luc se trompe dans la mesure où il extend sa pratique professionnelle en règles généralles.

Salut.

[loufoque]

boost.serialization a un système intéressant.

[David Fleury]

Mais vous me direz comme Luc que le fichier binaire est ringard ?

Il ne facilite pas l'interopérabilité que ce soit entre OS et surtout entre applications.

[Edit]
Il ne facilite pas non plus les évolutions futures de sa structure.

[Luc Hermitte]

Le but des BD n' est pas d' offrir des données "humainenent décodable et maintenable". Il s' agit là de la grande illusion de MS comme de l' OS.

C'est bien pour cela que je parlais et fichiers textes "humainement décobles et maintenables". Et non de BD.

Bercy se moque de savoir si son fichier des contribuables est plus "communicant".

Si Bercy gère ses données sous forme de fichiers et non de BD, Bercy s'est faite rouler. Et nous par la même occasion.

Il ne faut pas se leurrer sur l' inter-communication des fichiers.

C'est un besoin qui peut se déclarer. Et parfois se taper l'inscruste. J'ai comme le soupçon que le changement de processeurs des macs va avoir des effet de bords sur les codes de programmes sérialisant bourrinement leur données. Je peux me tromper. Ce n'est qu'un soupçon fort de ma part. Des mangeurs de pommes dans le coin ? Mon ami google semble confirmer.

Mais vous me direz comme Luc que le fichier binaire est ringard ?

C'est vrai que je n'ai peut-être pas été entièrement clair.
Il faut distinguer deux choses:
- les fichiers binaires -- que je manipule professionnellement parlant,
- les fichiers structurés qui sont généralement des fichiers binaires (Liskov?) ; ils ont ceci de particulier que chaque fiche occupe une taille définie et immuable dans le fichier. (cela fait un paquet de temps que je n'en ai plus manipulés, c'était en Turbo Pascal)

Quand on manipule des fichiers binaires, le problème d'endianess peut se taper l'inscruste dès le début, ou en cours de route, ou même jamais. Quand ce problème doit être pris en compte, alors il est impossible de sérialiser d'un coup plusieurs données. Toutes les données doivent être sérialisées les unes après les autres.

Corrolaire. Un fichier structuré, pour lequel il y a une contrainte d'endianness à prendre à compte, ne peut pas recourrir à la feinte (un "hack" comme on dit) de sérialiser brutalement la fiche en un seul coup. En conséquence, avoir un tableau de caractères ou une std::string dans le type C++ associé à la fiche ne change vraiment pas grand chose aux deux fonctions de (de/)sérialization de ces fiches -- vu qu'il faut sérialiser champ par champ.

Sans la contrainte. C'est parfait, le hack évoqué dès le début du fil est acceptable et valable.


Accessoirement, je ne crois pas que cela a été dit. On va devoir manipuler à plusieurs endroits des tableaux de chaines, et donc faire attention aux débordements de buffers et autres détails qui demandent un minimum de lucidité quand on code -- chose que tout le monde ne peut pas assurer en permanence, moi le premier. Tout ça pour gagner en simplicité sur deux petites fonctions qui pourraient devoir être à reprendre le jour où le soft devra tourner sur une autre mouture de processeur UNIX-ophile, ...

Bref, je ne suis pas sûr de la pertinence de la chose (chose == le hack). A part si on se limite à un marché x86 peut-être.


Concernant la pertinence des fichiers structurés (je ne parlais pas du tout de cela dans les précédents paragraphes de ce post).
Ma vision, relativement à mes besoins usuels, c'est :
- une BD quand il y a profusion de données à gérer
- des fichiers lisibles et modifiables via un simple éditeur de textes, quand il y a relativement peu de choses à manipuler
- des fichiers binaires pour des données numériques, comme p.ex. de la télémétrie que l'on reçoit sous un format brut non textuel qu'il ne faut pas altérer
- réfléchir pour les cas intermédiaires

NB: ne bossant pas sur le code d'une BD je n'ai pas à réfléchir sur la pertinence des fichiers structurés. Fichiers structurés qui offrent quantités d'avantages, je le reconnais bien volontier -- facilité pour accéder directement à un enregistrement, pour altérer des données, et même retirer des fiches sans avoir à réécrire l'intégralité du fichier.

Seulement, il en coute des limitations. Je me vois mal pour une ludothèque personnelle archivant livres/BDs/Jeux/Films/... de devoir limiter le nombre de caractères pouvant être mis dans des champs (commentaires, titre(s), auteur(s), ...). Comme je l'ai signalé, plus personne ne comprendra, aujourd'hui, que le titre d'un livre ne doive pas dépasser 42 caractères. Quant à sortir une BD pour une application de ce calibre, à usage personnel, cela me perturbe également.

<disgression>
En mélangeant les deux technologies XML (pour les données) + ASL (d'adobe pour l'IHM), je ne serais pas surpris que l'on puisse obtenir une ludothèque dont les champs des fiches, et même les types de fiches, soient modifiables sans avoir à recompiler l'exécutable.
(C'est le genre de cas où je respecte l'XML)
</>

Luc se trompe dans la mesure où il étend sa pratique professionnelle en règles généralles.

Il me semblait justement avoir précisé à plusieurs reprises ce qu'il en était dans mon cas. Histoire que chacun soit à même de saisir qu'il existe d'autres situations où d'autres solutions sont parfaitement valables.