C'est toute la faiblesse du C, personne n'est au courant qu'il existe des alternatives plus efficaces dans la plupart des cas...
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Le soucis c'est que tu as :
- un gain en perf : ce n'est pas toujours intéressant, il y a beaucoup de code ou la manipulations des chaines représente un pouillème du temps total ;
- un gain en sécurité : celui-ci est indéniable ;
- une dépendance de plus : donc des galères suppléméentaire quand tu déplois ton application ;
- une perte en portabilité : car la plupart de ces libs ne sont pas vraiment portable. Il n'y a pas besoin d'assembleur pour ne pas être portable, beaucoup d'entre elles suppose que les int sont sur 32bit ou bien en little-endian.
Donc dans beaucoup de cas, les gens trouvent que ça ne vaut pas le coup. Il n'y aurrait rien de base, les gens utiliserais forcement une lib, et celle-ci aurait surement fait plus d'éffort pour la simplicité et la portabilité.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête typedef struct string_s { char *str; unsigned len; } string_t;
Et pourtant ça peut êtrela pire des solutions... Si tes chaines sont toutes très petites le surcout en mémoire est important. Il suffit de regarder les chiffres sur la page ttp://www.and.org/ustr/ pour s'en convaincre. (très bonne lib soit dit en passant)
Le truc surtout c'est que recoder soit même une gestion des chaine c'est souvent s'exposer à encore plus de problèmes.
[^] # Re: Humm...
Posté par beagf . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Le soucis c'est que tu as :
- un gain en perf : ce n'est pas toujours intéressant, il y a beaucoup de code ou la manipulations des chaines représente un pouillème du temps total ;
- un gain en sécurité : celui-ci est indéniable ;
- une dépendance de plus : donc des galères suppléméentaire quand tu déplois ton application ;
- une perte en portabilité : car la plupart de ces libs ne sont pas vraiment portable. Il n'y a pas besoin d'assembleur pour ne pas être portable, beaucoup d'entre elles suppose que les int sont sur 32bit ou bien en little-endian.
Donc dans beaucoup de cas, les gens trouvent que ça ne vaut pas le coup. Il n'y aurrait rien de base, les gens utiliserais forcement une lib, et celle-ci aurait surement fait plus d'éffort pour la simplicité et la portabilité.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête
typedef struct string_s { char *str; unsigned len; } string_t;Et pourtant ça peut êtrela pire des solutions... Si tes chaines sont toutes très petites le surcout en mémoire est important. Il suffit de regarder les chiffres sur la page ttp://www.and.org/ustr/ pour s'en convaincre. (très bonne lib soit dit en passant)
Le truc surtout c'est que recoder soit même une gestion des chaine c'est souvent s'exposer à encore plus de problèmes.