Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

array bound forbidden after parenthesized type-id

57 réponses
Avatar
Lucas Levrel
Bonjour,

J'utilise des objets alloués dynamiquement comme suit :
double (*data)[3];
data=new double[t][3];

Maintenant, je voudrais en faire un tableau. J'essaye donc :

double (**tab)[3];
tab=new (double(*)[3])[n];
for(int i=0;i<n;i++) tab[i]=new double[t][3];

et le compilateur (g++) me donne l'erreur que j'ai mise en sujet.
Est-ce que le code suivant, qui compile sans erreur, est équivalent à ce
que je veux faire ?

typedef double(*data_type)[3];
data_type *tab;
tab=new data_type[n];
for...

Si oui, pourquoi le compilateur refuse-t-il le premier code et pas le
second ?

Merci d'avance.
--
LL

10 réponses

2 3 4 5 6
Avatar
Fabien LE LEZ
On Thu, 23 Jul 2009 00:11:00 -0700 (PDT), James Kanze
:

Ou simplement un vector< T >, avec calcule de l'indice.



C'est plus compliqué -- vu qu'il faut calculer l'indice à chaque
accès. Cette complication est justifiable dans certains cas (surtout
quand on se préoccupe de l'occupation mémoire), mais dans le cas
général, c'est s'emmerder pour pas grand-chose.
Avatar
Lucas Levrel
Le 23 juillet 2009, James Kanze a écrit :

Des explications détaillées et claires. Merci !

--
LL
Avatar
Lucas Levrel
Le 22 juillet 2009, Fabien LE LEZ a écrit :

Merci pour les explications sur les cast et le problème de copie avec les
new.

--
LL
Avatar
Lucas Levrel
Le 23 juillet 2009, James Kanze a écrit :

> De plus, ça m'arrange que les doubles soient contigus par paquets de t*3,
> pour faire une écriture non formatée comme :
> file_out.write((char*)tab[i],t*3*sizeof(double));

Ce qui ne marche en aucun cas. (snip)



Pourquoi ? Je parlais du cas où je fais new double[t][3]. Dans ce cas il
est garanti que les doubles sont contigus et que le pointeur retourné
pointe sur le premier de ces doubles, n'est-ce pas ?

> Tout ça m'a conduit à l'idée de faire des new double[t][3] et
> un tableau de n pointeurs vers ceux-ci.

Pourquoi le tableau de pointeurs ?



Par rapport à quoi ? Comme je ne connaissais pas vector et qu'on ne peut
pas faire new double[n][t][3], je ne voyais pas quoi faire d'autre.

Je ne sais pas encore exactement quelle structure de données tu
veux. double[n][t][3], avec la garantie que double[3][t] soit
contigu ?



Oui (enfin, double[t][3] contigu).

--
LL
Avatar
Lucas Levrel
Le 23 juillet 2009, Fabien LE LEZ a écrit :

On Thu, 23 Jul 2009 00:11:00 -0700 (PDT), James Kanze
:

>Ou simplement un vector< T >, avec calcule de l'indice.

C'est plus compliqué -- vu qu'il faut calculer l'indice à chaque
accès.



Là je ne te suis plus. Un vector< T > avec calcul d'indice, c'est pourtant
ce que tu as fait dans la classe que tu m'as proposée... Et il n'y a rien
à calculer pour l'utilisateur vu que la fonction Index est cachée dans la
classe.

Cette complication est justifiable dans certains cas (surtout
quand on se préoccupe de l'occupation mémoire),



À propos d'occupation mémoire... Ne ferais-je pas mieux d'utiliser
valarray plutôt que vector ? En regardant la doc de vector sur
www.cplusplus.com (est-ce une bonne référence ?), je n'ai pas vu de moyen
d'imposer quelque chose comme capacity==size. Je comprends pourquoi, mais
dans mon cas précis (taille constante) c'est gênant, d'autant que vector
réserve probablement capacity==alpha*size à la construction, et comme size
est grand...

--
LL
Avatar
Fabien LE LEZ
On Thu, 23 Jul 2009 12:03:29 +0200, Lucas Levrel
:

C'est plus compliqué -- vu qu'il faut calculer l'indice à chaque
accès.



Là je ne te suis plus. Un vector< T > avec calcul d'indice, c'est pourtant
ce que tu as fait dans la classe que tu m'as proposée...



Oui. Parce qu'on n'est plus dans le cas simple, vu que tu as des
besoins spéciaux (gros tableau et faible overhead).

Et il n'y a rien à calculer pour l'utilisateur



Oui, mais...

vu que la fonction Index est cachée dans la classe.



...Il a bien fallu écrire cette fonction.

Il aurait été plus simple d'utiliser un vector<vector<vector<T>>> et
de se passer d'une fonction d'index.
Et quand on a relativement peu de données, c'est ce qu'on fait.

À propos d'occupation mémoire... Ne ferais-je pas mieux d'utiliser
valarray plutôt que vector ? En regardant la doc de vector sur
www.cplusplus.com (est-ce une bonne référence ?), je n'ai pas vu de moyen
d'imposer quelque chose comme capacity==size.



Il me semble qu'en pratique, vector<> alloue juste ce qu'il faut de
mémoire, tant que tu ne changes pas la taille en cours de route. À
vérifier.
Avatar
Lucas Levrel
Le 23 juillet 2009, Fabien LE LEZ a écrit :
Il me semble qu'en pratique, vector<> alloue juste ce qu'il faut de
mémoire, tant que tu ne changes pas la taille en cours de route. À
vérifier.



Tu as raison, du moins ici c'est ce que je trouve (g++).

--
LL
Avatar
Gabriel Dos Reis
James Kanze writes:

| On Jul 22, 5:19 pm, (Pascal J. Bourguignon)
| wrote:
| > Fabien LE LEZ writes:
|
| > En fait, rien n'empêche de définir une classe (template)
| > specifique pour des tableaux multidimentionnel. C'est juste
| > une question d'imagination, mais il semble bien que les
| > programmeurs C++ n'en soit pas capables, et se ramênent
| > toujours à des vecteurs de vecteurs qu'ils ont appris à faire
| > en C...
|
| C'est plutôt une question de ne pas réinventer la roue. C'est un
| peu stupide de réécrire un tas de code, quand j'ai une
| implémentation tout faite qui marche.

ah mais, tu montres que tu es homme quand tu le fais tout seul avec tes
petites mains :-p

-- Gaby
Avatar
Gabriel Dos Reis
Fabien LE LEZ writes:

| On Thu, 23 Jul 2009 00:11:00 -0700 (PDT), James Kanze
| :
|
| >Ou simplement un vector< T >, avec calcule de l'indice.
|
| C'est plus compliqué -- vu qu'il faut calculer l'indice à chaque
| accès. Cette complication est justifiable dans certains cas (surtout
| quand on se préoccupe de l'occupation mémoire), mais dans le cas
| général, c'est s'emmerder pour pas grand-chose.

Pourquoi penses-tu que c'est une complication ?

Dans les cas où j'ai travaillé (bibliothèque d'algèbre linéaire), ne pas
représenter une matrice comme un tableau unidimensionnel est souvent u ne
complication.

-- Gaby
Avatar
Gabriel Dos Reis
Lucas Levrel writes:

[...]

| > Cette complication est justifiable dans certains cas (surtout
| > quand on se préoccupe de l'occupation mémoire),
|
| À propos d'occupation mémoire... Ne ferais-je pas mieux d'utili ser
| valarray plutôt que vector ? En regardant la doc de vector sur
| www.cplusplus.com (est-ce une bonne référence ?), je n'ai pas v u de moyen
| d'imposer quelque chose comme capacity==size. Je comprends pourq uoi, mais
| dans mon cas précis (taille constante) c'est gênant, d'autant q ue vector
| réserve probablement capacity==alpha*size à la construction , et comme size
| est grand...

Certaines implémentations de valarray sont optimisées pour la t âche pour
laquelle elles ont été conçues : opérations BLAS-1.

-- Gaby
2 3 4 5 6