Emmanuel Delahaye wrote:Je ne sais pas ce que c'est 'mingw'.
Minimalist Gcc for Windows. T'as cassé ton Google, vilain garçon ?La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Emmanuel Delahaye wrote:
Je ne sais pas ce que c'est 'mingw'.
Minimalist Gcc for Windows. T'as cassé ton Google, vilain garçon ?
La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Emmanuel Delahaye wrote:Je ne sais pas ce que c'est 'mingw'.
Minimalist Gcc for Windows. T'as cassé ton Google, vilain garçon ?La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Emmanuel Delahaye wrote:La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Emmanuel Delahaye wrote:
La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Emmanuel Delahaye wrote:La question n'est pas là, elle fonctionnent bien en principe. Chqrlie
vilipende strcat(), mais a priori elles font ce que dit le manuel.
Le problème c'est qu'elles portent sur de strings terminés par 0,
elles travaillent sur des char et font des copy etc. char par char,
ce qui coute cher.
Le problème n'est pas dans les fonctions, mais dans la choix qui a été
fait d'implémenter les chaines avec une sentinelle.
Je suis tout à fait d'accord sur ce point, c'est ce que je viens
d'écrire.
Mais il y a aussi le choix des fonctions, dans ce choix
d'implémentation, certaines fonctions s'imposent comme strc[n]py,
str[n]cat (au risque d'aggraver l'ulcère de Chqrlie), mais si on
cherche un peu plus sophistiqué, on trouve souvent des fonctions qui
répondrait presque au besoin mais qui en fait n'y répondent pas, comme
strtok, strspn (une gourmande aussi celle-là) etc.
Cela me semble typique d'une implémentation qui a précédé la conception.
Je ne jete pas la pierre, il y a aussi des impératifs comme la
deadline, le problème c'est que 1/4 de siècle après, il n'y a pas dans
le langage de substitut aux null terminated strings et que les
fonctions absconses str* tiennent le haut du pavé tout en étant plutôt
inutiles.
Jean-Marc Bourguet wrote:L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.
Au fait, les tests faits en connaissant l'implementation ne permettent
pas de discerner les deux premiers cas mais on peut esperer que le
troisieme ne s'y trouve pas :-)
Si tu savais combien il est difficile de faire des test suite qui
évitent de dévoiler des bugs !
Jean-Marc Bourguet wrote:
L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.
Au fait, les tests faits en connaissant l'implementation ne permettent
pas de discerner les deux premiers cas mais on peut esperer que le
troisieme ne s'y trouve pas :-)
Si tu savais combien il est difficile de faire des test suite qui
évitent de dévoiler des bugs !
Jean-Marc Bourguet wrote:L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.
Au fait, les tests faits en connaissant l'implementation ne permettent
pas de discerner les deux premiers cas mais on peut esperer que le
troisieme ne s'y trouve pas :-)
Si tu savais combien il est difficile de faire des test suite qui
évitent de dévoiler des bugs !
Je le sais trop bien. Un de mes problemes en la matiere est de faire
des tests qui testent mon code mais pas celui des autres...
Je le sais trop bien. Un de mes problemes en la matiere est de faire
des tests qui testent mon code mais pas celui des autres...
Je le sais trop bien. Un de mes problemes en la matiere est de faire
des tests qui testent mon code mais pas celui des autres...
Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
scanf en particulier est une horreur absolue :
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
scanf en particulier est une horreur absolue :
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
scanf en particulier est une horreur absolue :
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Eric Deveaud wrote:Harpo wrote:La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.
pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté
il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
~~~~~~~~~~~~~~~~~
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine.
ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique,
c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
Eric Deveaud wrote:
Harpo wrote:
La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.
pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté
il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
~~~~~~~~~~~~~~~~~
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine.
ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique,
c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
Eric Deveaud wrote:Harpo wrote:La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.
pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté
il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
~~~~~~~~~~~~~~~~~
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine.
ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique,
c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
Jean-Marc Bourguet wrote:Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
Jean-Marc Bourguet wrote:
Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
Jean-Marc Bourguet wrote:Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est
possible.
pas possible pour les raisons suivantes
BUGS
The alloca function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
e
RESTRICTIONS
Because the alloca() function requires inclusion of <alloca.h> in
order to work correctly, this function is not portable.
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est
possible.
pas possible pour les raisons suivantes
BUGS
The alloca function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
e
RESTRICTIONS
Because the alloca() function requires inclusion of <alloca.h> in
order to work correctly, this function is not portable.
Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est
possible.
pas possible pour les raisons suivantes
BUGS
The alloca function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
e
RESTRICTIONS
Because the alloca() function requires inclusion of <alloca.h> in
order to work correctly, this function is not portable.
Harpo writes:Jean-Marc Bourguet wrote:Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
J'ai ecris que c'est un de mes problemes, j'aurais peut-etre mieux
fait d'ecrire une de mes preoccupations quand j'ecris des tests. Cela
fait longtemps que je travaille sur des gros projets, a multiple
equipes, gros historique, gros clients, plus proche de 20000 fichiers
sources que de 20000 lignes (j'ai compte une fois les fichiers .cpp,
.c et lisp auxquels j'avais acces sans me demener outre mesure, je
suis arrive a 13000 -- donc pour un code incomplet sans les en-tetes,
sans les autres langages, on a au minimum encore un peu de Fortran et
de Java). Je deviens chaque jour meilleur a eliminer les sources
d'instabilites dans mes tests (c'est bizarre, c'est toujours les memes
equipes qui introduisent de l'instabillite; parfois c'est lie a la
nature de ce qu'ils font, parfois lie a la nature des gens et de leur
management direct :-()
Harpo <trashcan@hotmail.com> writes:
Jean-Marc Bourguet wrote:
Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
J'ai ecris que c'est un de mes problemes, j'aurais peut-etre mieux
fait d'ecrire une de mes preoccupations quand j'ecris des tests. Cela
fait longtemps que je travaille sur des gros projets, a multiple
equipes, gros historique, gros clients, plus proche de 20000 fichiers
sources que de 20000 lignes (j'ai compte une fois les fichiers .cpp,
.c et lisp auxquels j'avais acces sans me demener outre mesure, je
suis arrive a 13000 -- donc pour un code incomplet sans les en-tetes,
sans les autres langages, on a au minimum encore un peu de Fortran et
de Java). Je deviens chaque jour meilleur a eliminer les sources
d'instabilites dans mes tests (c'est bizarre, c'est toujours les memes
equipes qui introduisent de l'instabillite; parfois c'est lie a la
nature de ce qu'ils font, parfois lie a la nature des gens et de leur
management direct :-()
Harpo writes:Jean-Marc Bourguet wrote:Je le sais trop bien. Un de mes problemes en la matiere est de
faire des tests qui testent mon code mais pas celui des autres...
Il se trouve qu'on a besoin du code des autres et il faut faire avec
ses défaut, c'est la vie...
J'ai ecris que c'est un de mes problemes, j'aurais peut-etre mieux
fait d'ecrire une de mes preoccupations quand j'ecris des tests. Cela
fait longtemps que je travaille sur des gros projets, a multiple
equipes, gros historique, gros clients, plus proche de 20000 fichiers
sources que de 20000 lignes (j'ai compte une fois les fichiers .cpp,
.c et lisp auxquels j'avais acces sans me demener outre mesure, je
suis arrive a 13000 -- donc pour un code incomplet sans les en-tetes,
sans les autres langages, on a au minimum encore un peu de Fortran et
de Java). Je deviens chaque jour meilleur a eliminer les sources
d'instabilites dans mes tests (c'est bizarre, c'est toujours les memes
equipes qui introduisent de l'instabillite; parfois c'est lie a la
nature de ce qu'ils font, parfois lie a la nature des gens et de leur
management direct :-()
Charlie Gordon wrote:Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Sans doute, mais ce n'est pas un défaut inhérent aux fonctions.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
Il est toujours possible de développer des lib mieux construites, et
cela a déjà été fait, mais l'inconvénient est leur prolifération et le
fait qu'aucune ne peut dire être un standard même de fait.
La prolifération de ces libs est justement un résultat des lacunes et
des approximations fonctionnelles de la libc.
scanf en particulier est une horreur absolue :
J'ai utilisé très très rarement et jamais sans qu'il ne me reste un
doute sur la validité du code. Je ne comprends pas qu'on apprenne des
trucs pareils à des débutants.
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Je ne suis pas vraiment d'accord. Des fonctions comme strcat/strncat
sont des ogres pour le CPU, surtout si on les utilise inconsidérément
après les avoir fait précèder de strlen[s] pour allouer la taille
nécessaire.
Charlie Gordon wrote:
Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Sans doute, mais ce n'est pas un défaut inhérent aux fonctions.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
Il est toujours possible de développer des lib mieux construites, et
cela a déjà été fait, mais l'inconvénient est leur prolifération et le
fait qu'aucune ne peut dire être un standard même de fait.
La prolifération de ces libs est justement un résultat des lacunes et
des approximations fonctionnelles de la libc.
scanf en particulier est une horreur absolue :
J'ai utilisé très très rarement et jamais sans qu'il ne me reste un
doute sur la validité du code. Je ne comprends pas qu'on apprenne des
trucs pareils à des débutants.
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Je ne suis pas vraiment d'accord. Des fonctions comme strcat/strncat
sont des ogres pour le CPU, surtout si on les utilise inconsidérément
après les avoir fait précèder de strlen[s] pour allouer la taille
nécessaire.
Charlie Gordon wrote:Elles font certes ce que dit le manuel, mais rares sont ceux qui
lisent le manuel car il croient déjà savoir, et plus rares encore sont
ceux qui comprennent ce que dit vraiment le manuel à leur sujet.
Sans doute, mais ce n'est pas un défaut inhérent aux fonctions.
Quant à la lib C, elle a au fil des normalisations pris un embonpoint
conséquent et souvent discutable, mais reste désespérément loin du
minimum nécessaire pour
les taches courantes, en particulier des programmeurs débutants.
Il est toujours possible de développer des lib mieux construites, et
cela a déjà été fait, mais l'inconvénient est leur prolifération et le
fait qu'aucune ne peut dire être un standard même de fait.
La prolifération de ces libs est justement un résultat des lacunes et
des approximations fonctionnelles de la libc.
scanf en particulier est une horreur absolue :
J'ai utilisé très très rarement et jamais sans qu'il ne me reste un
doute sur la validité du code. Je ne comprends pas qu'on apprenne des
trucs pareils à des débutants.
il est toujours aussi
facile de piéger un débutant sur des problèmes simples d'entrées
sorties, qu'il est d'ailleurs
souvent difficile de régler correctement et efficacement. Le fait que
les chaines soient implémentées avec une sentinelle n'est pas bien
grave en regard de ces lacunes.
Je ne suis pas vraiment d'accord. Des fonctions comme strcat/strncat
sont des ogres pour le CPU, surtout si on les utilise inconsidérément
après les avoir fait précèder de strlen[s] pour allouer la taille
nécessaire.