Est-on assur=E9 que les =E9l=E9ments d'un std::vector se suivent en m=E9moi=
re?
Je veux utiliser un vector pour me d=E9charger de l'allocation dynamique
t'un tableau temporaire de caract=E8res.
Ca marche sous VC++ 2003.
Mais est-ce standard et/ou portable?
J'ai aussi essay=E9 ceci, mais =E7a ne marche pas dans tous les cas et
=E9clanche parfois des exceptions. Je soupsonne l'impl=E9mentation de ne
pas vraiment effectuer le reserve().
Rq: je ne peux pas me permettre d'utiliser les iostreams pour des
raisons de performance. La fonction parser doit interpr=E9ter des
fichiers de plusieurs centaines de ko de texte.
Ah oui, et le second const est sans intérêt, puisque les arguments sont passés ici par valeur.
[...] Quel est le pb?
En plus de l'argumentation de James, je trouve que mettre un "const" avant ce à quoi il s'applique, et un autre "const" après ce à quoi il s'applique, est un peu bancal et peu lisible.
Mébon, c'est juste une impression personnelle, qui n'engage que moi.
On 18 Mar 2007 01:54:45 -0700, "hyronn@gmail.com" <hyronn@gmail.com>:
void parse1(const char* const txt_buffer)
Ah oui, et le second const est sans intérêt, puisque les arguments sont
passés ici par valeur.
[...]
Quel est le pb?
En plus de l'argumentation de James, je trouve que mettre un "const"
avant ce à quoi il s'applique, et un autre "const" après ce à quoi il
s'applique, est un peu bancal et peu lisible.
Mébon, c'est juste une impression personnelle, qui n'engage que moi.
Ah oui, et le second const est sans intérêt, puisque les arguments sont passés ici par valeur.
[...] Quel est le pb?
En plus de l'argumentation de James, je trouve que mettre un "const" avant ce à quoi il s'applique, et un autre "const" après ce à quoi il s'applique, est un peu bancal et peu lisible.
Mébon, c'est juste une impression personnelle, qui n'engage que moi.
James Kanze
On Mar 18, 5:07 pm, Mathias Gaunard wrote:
Un pile usuelle fait dans les 8k
Une pile usuelle de 1980 ? Un compilateur pourrait a priori détecter, modulo l'usage de la récursivité, de quelle taille la pile doit être et t'avertir dans l e cas où la pile nécessaire serait trop grande.
C'est ce que faisait des compilateurs anno 1980. On y est un peu revenu parce que les tailles qu'ils trouvaient étaient exhorbitantes. En fait, ce que le compilateur sait trouver, c'est la taille qu'utilise chaque fonction. Ensuite, il faut analyser tous les chemins dans la graphe des appels pour en trouver le plus long.
Dans la pratique, évidemment, sur une machine moderne, la taille de la pile ne serait pas 8 Ko, mais 8 Mo, ou plus. Je me démande, d'ailleurs, si le posteur original ne s'est pas trompé d'unités. Chez moi, on précise bien que la taille de la pile, c'est 8192 sur une machine, 10240 sur l'autre. Mais l'unité, c'est des Ko, et non des octets. (Et évidemment, on peut l'agrandir si besoin y est.)
et MAX_PATH (constante windowsienne similaire) fait 32k
Un chemin et un nom de fichier c'est pas exactement la même chose.
Auriez-vous l'aimabilité de rapporter la valeur de FILENAME_MAX sur vos implémentation ;-)
Le plus long nom possible que j'ai trouvé en regardant les caractéristiques des systèmes de fichiers c'est 4032 octets.
Mais 255 est quand même une valeur récurrente.
J'ai 1024 sur une machine, 4096 sur l'autre. VC++ dit 260, mais je me démande... Qu'est-ce qui se passe si je monte un système de fichiers qui a des noms plus longs. Sous Posix, évidemment, j'utiliserais plutôt « pathconf( dirname, _PC_NAME_MAX ) », de façon à savoir pour le système de fichiers en question, mais je ne connais pas l'équivalent sous Windows. (Il doit bien en avoir ; sinon, le système serait difficilement utilisable dans un reseau.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 18, 5:07 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
Un pile usuelle fait dans les 8k
Une pile usuelle de 1980 ?
Un compilateur pourrait a priori détecter, modulo l'usage de la
récursivité, de quelle taille la pile doit être et t'avertir dans l e cas
où la pile nécessaire serait trop grande.
C'est ce que faisait des compilateurs anno 1980. On y est un peu
revenu parce que les tailles qu'ils trouvaient étaient
exhorbitantes. En fait, ce que le compilateur sait trouver,
c'est la taille qu'utilise chaque fonction. Ensuite, il faut
analyser tous les chemins dans la graphe des appels pour en
trouver le plus long.
Dans la pratique, évidemment, sur une machine moderne, la taille
de la pile ne serait pas 8 Ko, mais 8 Mo, ou plus. Je me
démande, d'ailleurs, si le posteur original ne s'est pas trompé
d'unités. Chez moi, on précise bien que la taille de la pile,
c'est 8192 sur une machine, 10240 sur l'autre. Mais l'unité,
c'est des Ko, et non des octets. (Et évidemment, on peut
l'agrandir si besoin y est.)
et MAX_PATH (constante windowsienne
similaire) fait 32k
Un chemin et un nom de fichier c'est pas exactement la même chose.
Auriez-vous l'aimabilité de rapporter la valeur de FILENAME_MAX sur
vos implémentation ;-)
Le plus long nom possible que j'ai trouvé en regardant les
caractéristiques des systèmes de fichiers c'est 4032 octets.
Mais 255 est quand même une valeur récurrente.
J'ai 1024 sur une machine, 4096 sur l'autre. VC++ dit 260, mais
je me démande... Qu'est-ce qui se passe si je monte un système
de fichiers qui a des noms plus longs. Sous Posix, évidemment,
j'utiliserais plutôt « pathconf( dirname, _PC_NAME_MAX ) », de
façon à savoir pour le système de fichiers en question, mais je
ne connais pas l'équivalent sous Windows. (Il doit bien en
avoir ; sinon, le système serait difficilement utilisable dans
un reseau.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Une pile usuelle de 1980 ? Un compilateur pourrait a priori détecter, modulo l'usage de la récursivité, de quelle taille la pile doit être et t'avertir dans l e cas où la pile nécessaire serait trop grande.
C'est ce que faisait des compilateurs anno 1980. On y est un peu revenu parce que les tailles qu'ils trouvaient étaient exhorbitantes. En fait, ce que le compilateur sait trouver, c'est la taille qu'utilise chaque fonction. Ensuite, il faut analyser tous les chemins dans la graphe des appels pour en trouver le plus long.
Dans la pratique, évidemment, sur une machine moderne, la taille de la pile ne serait pas 8 Ko, mais 8 Mo, ou plus. Je me démande, d'ailleurs, si le posteur original ne s'est pas trompé d'unités. Chez moi, on précise bien que la taille de la pile, c'est 8192 sur une machine, 10240 sur l'autre. Mais l'unité, c'est des Ko, et non des octets. (Et évidemment, on peut l'agrandir si besoin y est.)
et MAX_PATH (constante windowsienne similaire) fait 32k
Un chemin et un nom de fichier c'est pas exactement la même chose.
Auriez-vous l'aimabilité de rapporter la valeur de FILENAME_MAX sur vos implémentation ;-)
Le plus long nom possible que j'ai trouvé en regardant les caractéristiques des systèmes de fichiers c'est 4032 octets.
Mais 255 est quand même une valeur récurrente.
J'ai 1024 sur une machine, 4096 sur l'autre. VC++ dit 260, mais je me démande... Qu'est-ce qui se passe si je monte un système de fichiers qui a des noms plus longs. Sous Posix, évidemment, j'utiliserais plutôt « pathconf( dirname, _PC_NAME_MAX ) », de façon à savoir pour le système de fichiers en question, mais je ne connais pas l'équivalent sous Windows. (Il doit bien en avoir ; sinon, le système serait difficilement utilisable dans un reseau.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain Togni
wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
-- Sylvain Togni
hyronn@gmail.com wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il
puisse effectuer une optimisation dont je n'ai peut être pas
connaissance.
Petite précision : le mot-clé const n'a aucune incidence
sur les performances, il sert juste à éviter certains bugs
et à améliorer la lisibilité du code.
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
-- Sylvain Togni
hyronn
On 19 mar, 10:55, Sylvain Togni <"sylvain.togni at visionobjects.com"> wrote:
wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
D'autres confirment? Ca serait très décevant de la part des compilateurs.
Par exemple: on fixe une valeur et par la suite on a besoin de sa racine: const float pi = 7; float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itératio n, il est pas très malin puisque pi et sqrt sont connues au moment de la compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour assurer la lisibilité du code, soient remplacée par l'équivalent en langage machine de float f = 1.772004515;
* sqrt n'est pas vraiment "connue" au moment de la compilation, c'est une fonction surement déclarée hors de l'unité de traduction courrant. Mais GCC compile jusqu'en 3 passes (-O3) et Visual C++ retarde une partie de la compilation au liage de l'application ("whole program optimizations"). Il y a donc, dans les 2cas, moyen de "remplacer" sqrt(pi) par 1.77.
Est-ce que je surestime les compilateurs?!?
On 19 mar, 10:55, Sylvain Togni <"sylvain.togni at visionobjects.com">
wrote:
hyr...@gmail.com wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il
puisse effectuer une optimisation dont je n'ai peut être pas
connaissance.
Petite précision : le mot-clé const n'a aucune incidence
sur les performances, il sert juste à éviter certains bugs
et à améliorer la lisibilité du code.
D'autres confirment?
Ca serait très décevant de la part des compilateurs.
Par exemple:
on fixe une valeur et par la suite on a besoin de sa racine:
const float pi = 7;
float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itératio n,
il est pas très malin puisque pi et sqrt sont connues au moment de la
compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour
assurer la lisibilité du code, soient remplacée par l'équivalent en
langage machine de
float f = 1.772004515;
* sqrt n'est pas vraiment "connue" au moment de la compilation, c'est
une fonction surement déclarée hors de l'unité de traduction courrant.
Mais GCC compile jusqu'en 3 passes (-O3) et Visual C++ retarde une
partie de la compilation au liage de l'application ("whole program
optimizations"). Il y a donc, dans les 2cas, moyen de "remplacer"
sqrt(pi) par 1.77.
On 19 mar, 10:55, Sylvain Togni <"sylvain.togni at visionobjects.com"> wrote:
wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
D'autres confirment? Ca serait très décevant de la part des compilateurs.
Par exemple: on fixe une valeur et par la suite on a besoin de sa racine: const float pi = 7; float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itératio n, il est pas très malin puisque pi et sqrt sont connues au moment de la compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour assurer la lisibilité du code, soient remplacée par l'équivalent en langage machine de float f = 1.772004515;
* sqrt n'est pas vraiment "connue" au moment de la compilation, c'est une fonction surement déclarée hors de l'unité de traduction courrant. Mais GCC compile jusqu'en 3 passes (-O3) et Visual C++ retarde une partie de la compilation au liage de l'application ("whole program optimizations"). Il y a donc, dans les 2cas, moyen de "remplacer" sqrt(pi) par 1.77.
Est-ce que je surestime les compilateurs?!?
hyronn
On 18 mar, 17:07, Mathias Gaunard wrote:
Un chemin et un nom de fichier c'est pas exactement la même chose. Je sais, mais je n'ai pas trouvé l'équivalent de MAX_PATH en C
standart. Il va falloir que je me tourne donc vers Posix (cf le mail de Mr Kanze)
Auriez-vous l'aimabilité de rapporter la valeur de FILENAME_MAX sur vos implémentation ;-)
Le plus long nom possible que j'ai trouvé en regardant les caractéristiques des systèmes de fichiers c'est 4032 octets.
Mais 255 est quand même une valeur récurrente. Merci !
On 18 mar, 17:07, Mathias Gaunard <loufo...@gmail.com> wrote:
Un chemin et un nom de fichier c'est pas exactement la même chose.
Je sais, mais je n'ai pas trouvé l'équivalent de MAX_PATH en C
standart.
Il va falloir que je me tourne donc vers Posix (cf le mail de Mr
Kanze)
Auriez-vous l'aimabilité de rapporter la valeur de FILENAME_MAX sur
vos implémentation ;-)
Le plus long nom possible que j'ai trouvé en regardant les
caractéristiques des systèmes de fichiers c'est 4032 octets.
Mais 255 est quand même une valeur récurrente.
Merci !
Pour ceux que ça interesse: http://leapfrog.freeshell.org/Projects/path_max_name_max.shtml
Michel Decima
wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
MD.
hyronn@gmail.com wrote:
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il
puisse effectuer une optimisation dont je n'ai peut être pas
connaissance.
Petite précision : le mot-clé const n'a aucune incidence
sur les performances, il sert juste à éviter certains bugs
et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const
qualifier whenever possible" dans la section "Coding Techniques That Can
Improve Performance".
D'un autre coté, le titre de la section dit que ca _peut_ améliorer les
choses, pas que ca le fait systématiquement.
J'indique au compilateur que txt_buffer ne sera pas modifié afin qu'il puisse effectuer une optimisation dont je n'ai peut être pas connaissance.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
MD.
Sylvain Togni
wrote:
Par exemple: on fixe une valeur et par la suite on a besoin de sa racine: const float pi = 7; float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itération, il est pas très malin puisque pi et sqrt sont connues au moment de la compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour assurer la lisibilité du code, soient remplacée par l'équivalent en langage machine de float f = 1.772004515;
Oui, peut-être que le compilateur fera l'optimisation, mais il la fera aussi bien si la variable pi n'est pas déclarée const.
Les compilateurs, dans la plupart des cas, savent mieux que le programmeur quelle variable est constante et quelle ne l'est pas. Preuve en est, ils émettent une erreur quand on essaie de modifier une variable const.
-- Sylvain Togni
hyronn@gmail.com wrote:
Par exemple:
on fixe une valeur et par la suite on a besoin de sa racine:
const float pi = 7;
float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itération,
il est pas très malin puisque pi et sqrt sont connues au moment de la
compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour
assurer la lisibilité du code, soient remplacée par l'équivalent en
langage machine de
float f = 1.772004515;
Oui, peut-être que le compilateur fera l'optimisation, mais
il la fera aussi bien si la variable pi n'est pas déclarée
const.
Les compilateurs, dans la plupart des cas, savent mieux que
le programmeur quelle variable est constante et quelle ne
l'est pas. Preuve en est, ils émettent une erreur quand
on essaie de modifier une variable const.
Par exemple: on fixe une valeur et par la suite on a besoin de sa racine: const float pi = 7; float f = sqrt(pi).
Si un compilateur soit disant évolué appelle sqrt à chaque itération, il est pas très malin puisque pi et sqrt sont connues au moment de la compilation*. Je m'attend à ce que ces 2 lignes, écrites ainsi pour assurer la lisibilité du code, soient remplacée par l'équivalent en langage machine de float f = 1.772004515;
Oui, peut-être que le compilateur fera l'optimisation, mais il la fera aussi bien si la variable pi n'est pas déclarée const.
Les compilateurs, dans la plupart des cas, savent mieux que le programmeur quelle variable est constante et quelle ne l'est pas. Preuve en est, ils émettent une erreur quand on essaie de modifier une variable const.
-- Sylvain Togni
Sylvain Togni
Michel Decima wrote:
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en utilisant const on est assez souvent amené à définir deux fois certaines fonctions comme les getteurs, une version const et une version non-const, ce qui augmente la taille du code et diminue un peu la vitesse pour des raisons de localité.
-- Sylvain Togni
Michel Decima wrote:
Petite précision : le mot-clé const n'a aucune incidence
sur les performances, il sert juste à éviter certains bugs
et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const
qualifier whenever possible" dans la section "Coding Techniques That Can
Improve Performance".
D'un autre coté, le titre de la section dit que ca _peut_ améliorer les
choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en
utilisant const on est assez souvent amené à définir deux fois
certaines fonctions comme les getteurs, une version const et
une version non-const, ce qui augmente la taille du code et
diminue un peu la vitesse pour des raisons de localité.
Petite précision : le mot-clé const n'a aucune incidence sur les performances, il sert juste à éviter certains bugs et à améliorer la lisibilité du code.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en utilisant const on est assez souvent amené à définir deux fois certaines fonctions comme les getteurs, une version const et une version non-const, ce qui augmente la taille du code et diminue un peu la vitesse pour des raisons de localité.
-- Sylvain Togni
Michel Decima
Michel Decima wrote:
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en utilisant const on est assez souvent amené à définir deux fois certaines fonctions comme les getteurs, une version const et une version non-const, ce qui augmente la taille du code et diminue un peu la vitesse pour des raisons de localité.
Je ne sais pas non plus, je n'ai jamais fait de tests dans ce sens. Et la doc. en question ne dit pas si'il faut utiliser const sur des variables, des arguments de fonction ou des fonction membres pour obtenir un effet, ni quel effet d'ailleurs. Peut etre que l'optimiseur est un peu benêt, il ne sais pas detecter les constantes tout seul, et il faut l'aider un peu... mais j'ai un gros doute quand meme, faut pas sous-estimer les capacités de ce genre d'engins.
Michel Decima wrote:
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const
qualifier whenever possible" dans la section "Coding Techniques That
Can Improve Performance".
D'un autre coté, le titre de la section dit que ca _peut_ améliorer
les choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en
utilisant const on est assez souvent amené à définir deux fois
certaines fonctions comme les getteurs, une version const et
une version non-const, ce qui augmente la taille du code et
diminue un peu la vitesse pour des raisons de localité.
Je ne sais pas non plus, je n'ai jamais fait de tests dans ce sens.
Et la doc. en question ne dit pas si'il faut utiliser const sur
des variables, des arguments de fonction ou des fonction membres pour
obtenir un effet, ni quel effet d'ailleurs.
Peut etre que l'optimiseur est un peu benêt, il ne sais pas detecter
les constantes tout seul, et il faut l'aider un peu... mais j'ai un
gros doute quand meme, faut pas sous-estimer les capacités de ce genre
d'engins.
La documentation de mon compilateur (xlC-6/AIX) me dit "Use the const qualifier whenever possible" dans la section "Coding Techniques That Can Improve Performance". D'un autre coté, le titre de la section dit que ca _peut_ améliorer les choses, pas que ca le fait systématiquement.
Je ne sais pas, la seule différence que je vois c'est qu'en utilisant const on est assez souvent amené à définir deux fois certaines fonctions comme les getteurs, une version const et une version non-const, ce qui augmente la taille du code et diminue un peu la vitesse pour des raisons de localité.
Je ne sais pas non plus, je n'ai jamais fait de tests dans ce sens. Et la doc. en question ne dit pas si'il faut utiliser const sur des variables, des arguments de fonction ou des fonction membres pour obtenir un effet, ni quel effet d'ailleurs. Peut etre que l'optimiseur est un peu benêt, il ne sais pas detecter les constantes tout seul, et il faut l'aider un peu... mais j'ai un gros doute quand meme, faut pas sous-estimer les capacités de ce genre d'engins.
