Bonjour,
Est-il possible d'allouer sur la pile des tableaux dont la taille est
connue à l'exécution ?
raison : gain de performances par rapport au tas.
Merci
Donc les solutions qui leur conviennent ne conviennent pas forcément à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes d'adaptation. Non ?
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
[...]
Donc
les solutions qui leur conviennent ne conviennent pas forcément à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
fournir avant de l'utiliser en C++), elle se doit de bannir les
incompatibilités entre ces deux langages ou de fournir des mécanismes
d'adaptation. Non ?
Donc les solutions qui leur conviennent ne conviennent pas forcément à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes d'adaptation. Non ?
--drkm
Gabriel Dos Reis
drkm writes:
| Gabriel Dos Reis writes: | | [...] | | > Donc | > les solutions qui leur conviennent ne conviennent pas forcément à C++. | | Et pratiquement, si une interface se veut utilisable à la fois en C | et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à | fournir avant de l'utiliser en C++), elle se doit de bannir les | incompatibilités entre ces deux langages ou de fournir des mécanismes | d'adaptation. Non ?
Cela me semble évident.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| [...]
|
| > Donc
| > les solutions qui leur conviennent ne conviennent pas forcément à C++.
|
| Et pratiquement, si une interface se veut utilisable à la fois en C
| et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
| fournir avant de l'utiliser en C++), elle se doit de bannir les
| incompatibilités entre ces deux langages ou de fournir des mécanismes
| d'adaptation. Non ?
| Gabriel Dos Reis writes: | | [...] | | > Donc | > les solutions qui leur conviennent ne conviennent pas forcément à C++. | | Et pratiquement, si une interface se veut utilisable à la fois en C | et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à | fournir avant de l'utiliser en C++), elle se doit de bannir les | incompatibilités entre ces deux langages ou de fournir des mécanismes | d'adaptation. Non ?
Cela me semble évident.
-- Gaby
kanze
drkm wrote:
Gabriel Dos Reis writes:
[...]
Donc les solutions qui leur conviennent ne conviennent pas forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces qui se moquent complétement de C++. (Posix me vient à l'esprit, encore que dans leur cas, il y a une légère réconnaissance que le C++ existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C, je crois que C++ a tout à gagner à maintenir une compatibilité avec le C au niveau de ce qui peut raisonablement apparaître dans une interface de C. Mais je reconnais que ce n'est pas toujours facile -- par exemple, je ne sais pas comment les implémentations traitent le cas de complex actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme variable locale serait utile. Mais surtout pour des raisons de performance. (C'est la seule avantage d'un VLA par rapport à une std::vector.) Et ce sont des cas qui ne se présentent pas dans mes applications. Alors, comme j'ai dit, je crois comme ça que ça ne serait pas mal, mais je ne m'y intéresse pas assez pour y travailler moi-même, et que si personne d'autre n'a envie de s'adresser aux problèmes non plus, ça ne se fera pas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
drkm wrote:
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
[...]
Donc les solutions qui leur conviennent ne conviennent pas
forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en
C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail
à
fournir avant de l'utiliser en C++), elle se doit de bannir les
incompatibilités entre ces deux langages ou de fournir des
mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces
qui se moquent complétement de C++. (Posix me vient à l'esprit,
encore
que dans leur cas, il y a une légère réconnaissance que le C++
existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C,
je
crois que C++ a tout à gagner à maintenir une compatibilité avec le
C au
niveau de ce qui peut raisonablement apparaître dans une interface de
C.
Mais je reconnais que ce n'est pas toujours facile -- par exemple, je
ne
sais pas comment les implémentations traitent le cas de complex
actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme
variable locale serait utile. Mais surtout pour des raisons de
performance. (C'est la seule avantage d'un VLA par rapport à une
std::vector.) Et ce sont des cas qui ne se présentent pas dans mes
applications. Alors, comme j'ai dit, je crois comme ça que ça ne
serait
pas mal, mais je ne m'y intéresse pas assez pour y travailler
moi-même,
et que si personne d'autre n'a envie de s'adresser aux problèmes non
plus, ça ne se fera pas.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
Donc les solutions qui leur conviennent ne conviennent pas forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces qui se moquent complétement de C++. (Posix me vient à l'esprit, encore que dans leur cas, il y a une légère réconnaissance que le C++ existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C, je crois que C++ a tout à gagner à maintenir une compatibilité avec le C au niveau de ce qui peut raisonablement apparaître dans une interface de C. Mais je reconnais que ce n'est pas toujours facile -- par exemple, je ne sais pas comment les implémentations traitent le cas de complex actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme variable locale serait utile. Mais surtout pour des raisons de performance. (C'est la seule avantage d'un VLA par rapport à une std::vector.) Et ce sont des cas qui ne se présentent pas dans mes applications. Alors, comme j'ai dit, je crois comme ça que ça ne serait pas mal, mais je ne m'y intéresse pas assez pour y travailler moi-même, et que si personne d'autre n'a envie de s'adresser aux problèmes non plus, ça ne se fera pas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
kanze
drkm wrote:
Gabriel Dos Reis writes:
[...]
Donc les solutions qui leur conviennent ne conviennent pas forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces qui se moquent complétement de C++. (Posix me vient à l'esprit, encore que dans leur cas, il y a une légère réconnaissance que le C++ existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C, je crois que C++ a tout à gagner à maintenir une compatibilité avec le C au niveau de ce qui peut raisonablement apparaître dans une interface de C. Mais je reconnais que ce n'est pas toujours facile -- par exemple, je ne sais pas comment les implémentations traitent le cas de complex actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme variable locale serait utile. Mais surtout pour des raisons de performance. (C'est la seule avantage d'un VLA par rapport à une std::vector.) Et ce sont des cas qui ne se présentent pas dans mes applications. Alors, comme j'ai dit, je crois comme ça que ça ne serait pas mal, mais je ne m'y intéresse pas assez pour y travailler moi-même, et que si personne d'autre n'a envie de s'adresser aux problèmes non plus, ça ne se fera pas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
drkm wrote:
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
[...]
Donc les solutions qui leur conviennent ne conviennent pas
forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en
C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail
à
fournir avant de l'utiliser en C++), elle se doit de bannir les
incompatibilités entre ces deux langages ou de fournir des
mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces
qui se moquent complétement de C++. (Posix me vient à l'esprit,
encore
que dans leur cas, il y a une légère réconnaissance que le C++
existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C,
je
crois que C++ a tout à gagner à maintenir une compatibilité avec le
C au
niveau de ce qui peut raisonablement apparaître dans une interface de
C.
Mais je reconnais que ce n'est pas toujours facile -- par exemple, je
ne
sais pas comment les implémentations traitent le cas de complex
actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme
variable locale serait utile. Mais surtout pour des raisons de
performance. (C'est la seule avantage d'un VLA par rapport à une
std::vector.) Et ce sont des cas qui ne se présentent pas dans mes
applications. Alors, comme j'ai dit, je crois comme ça que ça ne
serait
pas mal, mais je ne m'y intéresse pas assez pour y travailler
moi-même,
et que si personne d'autre n'a envie de s'adresser aux problèmes non
plus, ça ne se fera pas.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
Donc les solutions qui leur conviennent ne conviennent pas forcément
à C++.
Et pratiquement, si une interface se veut utilisable à la fois en C
et en C++ (si ce n'est pas le cas, il y a de toute façon du travail à
fournir avant de l'utiliser en C++), elle se doit de bannir les incompatibilités entre ces deux langages ou de fournir des mécanismes
d'adaptation. Non ?
Oui, mais c'est un gros si. Actuellement, il y a pas mal d'interfaces qui se moquent complétement de C++. (Posix me vient à l'esprit, encore que dans leur cas, il y a une légère réconnaissance que le C++ existe.)
Dans l'ensemble, pour s'adresser à la question de la compatibilité C, je crois que C++ a tout à gagner à maintenir une compatibilité avec le C au niveau de ce qui peut raisonablement apparaître dans une interface de C. Mais je reconnais que ce n'est pas toujours facile -- par exemple, je ne sais pas comment les implémentations traitent le cas de complex actuellement.
Personnellement, je peux aussi concevoir les cas où un VLA comme variable locale serait utile. Mais surtout pour des raisons de performance. (C'est la seule avantage d'un VLA par rapport à une std::vector.) Et ce sont des cas qui ne se présentent pas dans mes applications. Alors, comme j'ai dit, je crois comme ça que ça ne serait pas mal, mais je ne m'y intéresse pas assez pour y travailler moi-même, et que si personne d'autre n'a envie de s'adresser aux problèmes non plus, ça ne se fera pas.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
