conception d'un type texte
Bonjour,
Je suis en train de créer une abstraction légère au-dessus des string / char* / char[] de C. C'est juste une
struct {char * octets ; int count}(le détail est légèrement différent, mais le principe est là). Le but est de m'afrranchir de la myriade de problèmes, bogues, defauts mémoire et aussi certaines inefficacités dont la litérature à propos de C est remplie. Quelques avantages:
* Le compte est toujours connu --> pas de param supplémentaire, pas d'appel strlen().
* Pas de dépassement de tampon possible.
* Peut stocker des caractères NUL.
* Utilisation de fonctions mem* au lieu de str* (plus simple et efficace).
* Pas de surallocation ; taille exacte.
* Certains bound-checkings (*) deviennent inutiles (car on sait, en interne).
* Possibilité de supprimer les autres bound-checkings pour la release (*).
* Pas de problème de sécurité (par dépassement de tampon et tout ça).
* Abstraction unicode / utf8 préparée.
Désavantages:
* Allocation sur le tas en général (questions sur le sujet à venir).
* Un int/uint/size_t supplémentaire par objet.
Connaissez-vous libmib? (http://www.mibsoftware.com/libmib/) Ils font plus ou moins ça sans stocker le compte. Donc il y a forcément des appels à strlen partout, mais la différence est que c'est abstrait par des fonctions (et non un type) d'un niveau légèrement supérieur à celles de string.h. Ils font ça avec des objets qui sont des char** et non des char*. Rusé, comme solution, mais je me demande si le coût (en complication, appels à strlen(), autres...) n'est pas supérieur au gain de stocker le compte et avoir une interface qui dit clairement ce qu'elle est et ce qu'elle fait.
Alors voilà, j'ai plein de problèmes de conception et implémentation de ce truc-là. Comme certains sont indépendants (ou orthogonaux, comme disent les computer scientists ;)), je vais plutôt les aborder en plusieurs discussions, pour pas vous inonder. Le thème du jour : représentation d'un texte vide.
1. Devrais-je représenter ça par {NULL, 0} ou par {pointeur_sur_chaine_vide, 0} ?
Quelques réflexions :
+++ Pas d'allocation du tout.
+++ Les textes vides sont très courants.
--- Impossible d'intéragir directement avec les routines C, du genre
Code:
puts (texte.octets) ; // segfault si texte vide
Il faut donc traiter spécialement le cas texte vide à tout plein d'endroits.
On ne peut pas laisser le code applicatif s'occuper de choses comme ça avec de tels bugs en puissance, et non détectés si les tests ne traitent pas le cas vide. Donc, il faut une interface qui fournit toutes ces fonctionnalités. Et même là, est-ce que la complication (interne) n'est pas un prix trop élévé à payer pour cette optimisation du cas texte vide ?
Note: les langages "semi-bas-niveau" que je connais (comme D) font cette optimisation. (Aussi souvent pour des tableaux vides.)
2. Est-ce qu'il devrait y avoir un unique objet texte vide ?
Alors ça, c'est un drôle de point. Ca peut alléger largement le prog en temps et en espace. Et aussi faciliter et accélérer toutes les comparaisons avec le texte vide, du moins dans le cas où celui-ci n'est pas représenté par {NULL, 0} (auquel cas t_est_vide <=> t.octets == NUL)).
PS: Je me rends compte que je suis en train de tomber en partie dans les pièges de l'optimisation prématurée ;). Alors je vais progresser avec la conception la plus simple et la plus claire. Mais ça n'empèche de penser et discuter par ailleurs. (En fait, prévoir des modifs / optimisations potentielles permet aussi de faciliter leur implantation si jamais... je crois).
Merci de vos attention,
Denis
(*) Comment on dit bounds checking en français ? Et release ?
