OVH Cloud OVH Cloud

allocation dynamique sur la pile ?

34 réponses
Avatar
philou2109
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

10 réponses

1 2 3 4
Avatar
Fabien LE LEZ wrote:
On Sun, 05 Dec 2004 15:50:05 +0100, drkm :


En regard de ma réponse à Fabien, ne serait-il pas évident
d'interdir cette construction ?



Yep. D'autant que l'utilité d'introduire les VLA en C++, c'est la
compatibilité avec des headers écrits en C -- et de tels headers ne
risquent pas de parler d'héritage.


C'est une des utilités, et effectivement, l'héritage n'y entre pas en
ligne de compte. L'autre utilité, c'est comme remplacement à alloca,
dans les declarations des tableaux locaux. Et là, je vois des problèmes
si l'objet dans le tableau a un constructeur.

Plus généralement, le problème, ce n'est pas qu'on ne peut pas interdire
les cas où il y a des problèmes ; le problème, c'est qu'il faut que
quelqu'un fasse l'effort pour les identifier -- la présence des
constructeurs et des destructeurs (parmi d'autres choses) fait qu'on ne
peut pas simplement réprendre le texte de la norme C telle que. Il y a
donc un effort à fournir. Et si personne ne le fournit...

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34


Avatar
Gabriel Dos Reis
drkm writes:

| Fabien LE LEZ writes:
|
| > On Sun, 05 Dec 2004 06:10:20 +0100, drkm :
|
| >> struct B
| >> {
| >> char tableau [*]; // Pas sûr de la syntaxe
| >> int i;
|
| > Illégal, si j'en crois James : "Une VLA peut, par exemple, être le
| > dernier élément d'un struct."
|
| Je viens de vérifier dans la norme. 6.7.2.1/2 dit :
|
| A structure or union shall not contain a member with incomplete or
| function type [...], except that the last member of a structure
| with more than one named member may have incomplete array type;
| such a structure (and any union containing, possibly recursively,
| a member that is such a structure) shall not be a member of a
| structure or an element of an array.
|
| Il me semble que la transposition naturelle en C++ serait bien
| d'interdir l'héritage : « such a structure [...] shall not be a member
| of a structure ».

La transposition naturelle en C+ serait de banir cette abomination.

-- Gaby
Avatar
Gabriel Dos Reis
drkm writes:

| Gabriel Dos Reis writes:
|
| > drkm writes:
|
| > | Tu as des exemples précis en tête ?
|
| > struct A {
| > int a[];
| > };
|
| > struct B : A {
| > };
|
| En regard de ma réponse à Fabien, ne serait-il pas évident
| d'interdir cette construction ?

Oui, avec les VLA aussi.

-- Gaby
Avatar
Gabriel Dos Reis
"@(none)" <""kanze"@(none)"> writes:

| Fabien LE LEZ wrote:
| > On Sun, 05 Dec 2004 15:50:05 +0100, drkm :
|
| >>En regard de ma réponse à Fabien, ne serait-il pas évident
| >>d'interdir cette construction ?
|
| > Yep. D'autant que l'utilité d'introduire les VLA en C++, c'est la
| > compatibilité avec des headers écrits en C -- et de tels headers ne
| > risquent pas de parler d'héritage.
|
| C'est une des utilités, et effectivement, l'héritage n'y entre pas en
| ligne de compte.

Oui, mais et le système de type ?

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
drkm writes:

| Fabien LE LEZ writes:

| > On Sun, 05 Dec 2004 06:10:20 +0100, drkm
| > :

| >> struct B
| >> {
| >> char tableau [*]; // Pas sûr de la syntaxe
| >> int i;

| > Illégal, si j'en crois James : "Une VLA peut, par exemple, être le
| > dernier élément d'un struct."

| Je viens de vérifier dans la norme. 6.7.2.1/2 dit :

| A structure or union shall not contain a member with incomplete
| or function type [...], except that the last member of a
| structure with more than one named member may have incomplete
| array type; such a structure (and any union containing, possibly
| recursively, a member that is such a structure) shall not be a
| member of a structure or an element of an array.

| Il me semble que la transposition naturelle en C++ serait bien
| d'interdir l'héritage : « such a structure [...] shall not be a
| member of a structure ».

La transposition naturelle en C+ serait de banir cette abomination.


Pratiquement, je crois que ce choix-là ne nous est pas ouvert.

--
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

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > drkm writes:
|
| > | Fabien LE LEZ writes:
|
| > | > On Sun, 05 Dec 2004 06:10:20 +0100, drkm
| > | > :
|
| > | >> struct B
| > | >> {
| > | >> char tableau [*]; // Pas sûr de la syntaxe
| > | >> int i;
|
| > | > Illégal, si j'en crois James : "Une VLA peut, par exemple, être le
| > | > dernier élément d'un struct."
|
| > | Je viens de vérifier dans la norme. 6.7.2.1/2 dit :
|
| > | A structure or union shall not contain a member with incomplete
| > | or function type [...], except that the last member of a
| > | structure with more than one named member may have incomplete
| > | array type; such a structure (and any union containing, possibly
| > | recursively, a member that is such a structure) shall not be a
| > | member of a structure or an element of an array.
|
| > | Il me semble que la transposition naturelle en C++ serait bien
| > | d'interdir l'héritage : « such a structure [...] shall not be a
| > | member of a structure ».
|
| > La transposition naturelle en C+ serait de banir cette abomination.
|
| Pratiquement, je crois que ce choix-là ne nous est pas ouvert.

Ah, parce que pratiquement le choix de pervertir le système de type de
C++ t'est ouvert ?

-- Gaby
Avatar
James Kanze
Gabriel Dos Reis wrote:
writes:


| Gabriel Dos Reis wrote in message
| news:...
| > drkm writes:


| > | Fabien LE LEZ writes:


| > | > On Sun, 05 Dec 2004 06:10:20 +0100, drkm
| > | > :


| > | >> struct B
| > | >> {
| > | >> char tableau [*]; // Pas sûr de la syntaxe
| > | >> int i;


| > | > Illégal, si j'en crois James : "Une VLA peut, par exemple,
être le

| > | > dernier élément d'un struct."


| > | Je viens de vérifier dans la norme. 6.7.2.1/2 dit :


| > | A structure or union shall not contain a member with incomplete
| > | or function type [...], except that the last member of a
| > | structure with more than one named member may have incomplete
| > | array type; such a structure (and any union containing,
possibly

| > | recursively, a member that is such a structure) shall not be a
| > | member of a structure or an element of an array.


| > | Il me semble que la transposition naturelle en C++ serait bien
| > | d'interdir l'héritage : « such a structure [...] shall not be a
| > | member of a structure ».


| > La transposition naturelle en C+ serait de banir cette abomination.


| Pratiquement, je crois que ce choix-là ne nous est pas ouvert.


Ah, parce que pratiquement le choix de pervertir le système de type de
C++ t'est ouvert ?


Parce que pratiquement, il faut qu'on interface avec des API
définies en C, et que dans la mésure que C offre la possibilité, et
que c' est utile, il faut supposer qu'il y aurait des API qui s'en
servent.

Du coup, que le comité l'adopte ou non, les compilateurs
l'implémenterait.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
James Kanze
Gabriel Dos Reis wrote:
"@(none)" <""kanze"@(none)"> writes:


| Fabien LE LEZ wrote:
| > On Sun, 05 Dec 2004 15:50:05 +0100, drkm
:


| >>En regard de ma réponse à Fabien, ne serait-il pas évident
| >>d'interdir cette construction ?


| > Yep. D'autant que l'utilité d'introduire les VLA en C++, c'est la
| > compatibilité avec des headers écrits en C -- et de tels headers ne
| > risquent pas de parler d'héritage.


| C'est une des utilités, et effectivement, l'héritage n'y entre pas en
| ligne de compte.


Oui, mais et le système de type ?


Je dirais qu'en ce qui concerne les tableaux de type C, le système
de type n'est pas à ça près.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > writes:
|
| > | Gabriel Dos Reis wrote in message
| > | news:...
| > | > drkm writes:
|
| > | > | Fabien LE LEZ writes:
|
| > | > | > On Sun, 05 Dec 2004 06:10:20 +0100, drkm
| > | > | > :
|
| > | > | >> struct B
| > | > | >> {
| > | > | >> char tableau [*]; // Pas sûr de la syntaxe
| > | > | >> int i;
|
| > | > | > Illégal, si j'en crois James : "Une VLA peut, par exemple,
| être le
| > | > | > dernier élément d'un struct."
|
| > | > | Je viens de vérifier dans la norme. 6.7.2.1/2 dit :
|
| > | > | A structure or union shall not contain a member with incomplete
| > | > | or function type [...], except that the last member of a
| > | > | structure with more than one named member may have incomplete
| > | > | array type; such a structure (and any union containing,
| possibly
| > | > | recursively, a member that is such a structure) shall not be a
| > | > | member of a structure or an element of an array.
|
| > | > | Il me semble que la transposition naturelle en C++ serait bien
| > | > | d'interdir l'héritage : « such a structure [...] shall not be a
| > | > | member of a structure ».
|
| > | > La transposition naturelle en C+ serait de banir cette abomination.
|
| > | Pratiquement, je crois que ce choix-là ne nous est pas ouvert.
|
| > Ah, parce que pratiquement le choix de pervertir le système de type de
| > C++ t'est ouvert ?
|
| Parce que pratiquement, il faut qu'on interface avec des API
| définies en C, et que dans la mésure que C offre la possibilité, et
| que c' est utile, il faut supposer qu'il y aurait des API qui s'en
| servent.

Pratiquement, s'il faut que tu interfaces avec des API définies en C,
pratiquement cela ne doit pas dire que tu dois écrire ton API avec
des VLA. Est-ce que tu te plains au comité C que tu dois pratiquement
interfacer avec des API C++ donc, il faut qu'ils adoptent les classes
abstraites ?

Pratiquement, il faut d'abord comprendre ce que la norme C définit
comme VLA, « variably modified types » en C, puis le système de type
C++ et l'interaction entre les deux. As close as possible, but not closer.

Le comité C a défini C99 de manière incompatible avec C90 sans
différents axes sans apparemment se soucier des problèmes de
compatibilités.

|
| Du coup, que le comité l'adopte ou non, les compilateurs
| l'implémenterait.

Les compilateurs implémentent déjà plein de trucs non adoptés par le
comité.

Il y a des gens qui pensent que si le comité C a adopté quelque choque
alors le comité C++ doit le faire aussi. C'est une attitude que
je trouve naïve parce qu'il n'y a pas de politique commune de
compatibilité et le comité C n'a pas l'air de se soucier de cela. Donc
les solutions qui leur conviennent ne conviennent pas forcément à C++.

-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > "@(none)" <""kanze"@(none)"> writes:
|
| > | Fabien LE LEZ wrote:
| > | > On Sun, 05 Dec 2004 15:50:05 +0100, drkm
| :
|
| > | >>En regard de ma réponse à Fabien, ne serait-il pas évident
| > | >>d'interdir cette construction ?
|
| > | > Yep. D'autant que l'utilité d'introduire les VLA en C++, c'est la
| > | > compatibilité avec des headers écrits en C -- et de tels headers ne
| > | > risquent pas de parler d'héritage.
|
| > | C'est une des utilités, et effectivement, l'héritage n'y entre pas en
| > | ligne de compte.
|
| > Oui, mais et le système de type ?
|
| Je dirais qu'en ce qui concerne les tableaux de type C, le système
| de type n'est pas à ça près.

C'est peut-être ce qu'ils pensent en C ; mais de ce côté ci, le système
de type est important pour ceux qui se soucient des programmes écrits
en C++. Enin de compte, si tu veux écrire en Ada, tu sais où le
trouver. La même chose est vrais aussi pour C99.

-- Gaby
1 2 3 4