Newsgroup: it.comp.lang.c++
Titolo: Array come lvalue?

  b++;    // non OK
faccio presente che e' parecchio tempo che non uso il C++ e che 
molte cose non me le ricordo, dovrei verificarle ma non ho 
al momento sotto mano lo standard.
Credo di ricordare che in C++ un array sia un tipo valido come gli 
altri e quindi anche modificabile (se non è const, ovviamente).
Quindi b=a; è valido così come b++ salvo che b++ non è definito.
Ovvero è come se scrivessi;
struct c3 {
	char m[3];
} a,b;
b=a;    // Ok
b++;    // non OK
salvo ovviamente le inizializzazioni etc.
Sono sicurissimo che questo argomento è stato dibattuto in sede di 
comitato di standardizzazione, solo non sono più certo di cosa 
dicesse la versione finale dello standard.
Uno dei problemi era l'incongruenza fra lo standard C e lo 
standard C++ che risultava da una dichiarazione del tipo:
void f( T v[k] )
dove T è un tipo e k una costante intera (compatibile con size_t).
Secondo il C credo equivalga a:
void f( T *v )
mentre in C++ sarebbe stato differente, creando problemi con 
possibile codice esistente. Se non ricordo male le necessità 
di generalizzazione (ovvero l'esistenza dei template) fecero 
pendere la bilancia verso il C++ a scapito della compatibilità 
C (as C as possible, but no more).
Quindi dovrebbe essere possibile definire:
char(&)[3] operator++( char(&r)[3] )
{
	// incrementa r, qualunque cosa ciò significhi
	return r;
}
char[3] operator++( char(&r)[3], int )
{
	char val[3]=r;
	// incrementa r, qualunque cosa ciò significhi
	return val;
}
Ripeto: può anche essere che la decisione finale non sia stata
questa. Ma se lo è allora il motivo per cui b++ non funzionava
era che non era definito, non che non poteva esserlo.
Certo sono che di compilatori che lo fanno non ne ho ancora 
visti!
-- 
Posted from 
adsl-21-135.38-151.net24.it
 [151.38.135.21] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

>  b++;    // non OK
Non avevo letto questo thread, ma mi pare di ricordare che con gli array č
definito solo l'inizializzazzione aggregata, quindi risulterebbero errori
sia la prima che la seconda istruzione.
Non sono sicuro che sia standard il seguente codice:
char a[3] = { 5, 5,6 };
char b[3] = a;
anche se il mio compilatore me lo accetta. Dopottutto č la stessa
situazione che si ha quando si passa un array ad una funzione.
Cmq come ben saprai gli array sono un tipo di dato particolare. Per dirne
una basti pensare che non puoi ritornare un array da una funzione se non
tramite puntatori o reference.
Ciao.
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
Visual C++, il meno standard dei compilatori C++.
J++, la copiatura piů riuscita.
Windows, il piů instabile.
Visual Basic, un esempio di prodotto decente della MS - forse l'unico -.
OutlookExpress, scandali su scandali.
La classifica degli "amici" coglioni:
Stefano Zanchi, il miglior lamer del mondo.
 

tramite puntatori o reference.
se la decisione finale č quella che credo io, puoi.


 tramite puntatori o reference.
... o incapsulandoli in una struttura ...
Domenico Barra

 se la decisione finale è quella che credo io, puoi.
Certo, eliminerebbe la differenza di trattamento tra array e altri tipi
di dati (e questo sarebbe positivo) ma sarebbe un disastro per la
compatibilità con il vecchio codice. Quale sarà il male minore?...
EMG


Infatti sono assolutamente certo che questo fu il fulcro della
discussione
in ambito di comitato. Almeno da quello che diceva che ne faceva (fa!)
parte
Solo che non ricordo il risultato finale!
Forse Andrea Griffini ci può dire qualche cosa in proposito.


>... o incapsulandoli in una struttura ...
Forse non è come sparare con un cannone ad una zanzara, cmq mi sembra già
un po' macchinoso questo modo di procedere.
Cmq proverò a vedere se mi piace.
Thanks.
Ciao.
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
Visual C++, il meno standard dei compilatori C++.
J++, la copiatura più riuscita.
Windows, il più instabile.


compatibilità con il vecchio codice. Quale sarà il male minore?...
Per quanto riguarda il male hai ragione, ma dobbiamo sempre basarci sul
codice scritto in precedenza?
Infatti non sembra che questo contribuisca a rallentare i miglioramenti del
C++?
Cmq ammettendo il caso che potessimo usare un array come un qualsiasi altro
tipo di dato, non credete che passarlo per valore ad una funzione sia un
po' pesantuccio?


po' pesantuccio?
Dipende dalla dimensione dell'array, ovviamente.
Non credi che passare per valore:
struct S {
   int v[100];
};
sia pesantuccio? Pero' e' possibile. Se non lo fosse non potresti
passare
neppure:
struct Point {
  double x,y,z;
};
E se puoi passare Point perche non devi poter passare:
typedef double AnotherPoint[3];


Forse Andrea Griffini ci pu=F2 dire qualche cosa in proposito.
No. Io avevo iniziato a guardare il C++ molto tempo fa ma lo
avevo abbandonato perche' non lo ritenevo sufficientemente
stabile e portabile da poter usato seriamente. Per anni ho
scritto codice object oriented in C o al massimo utilizzando
solo una parte del C++ (C con le classi).
Mi sono messo a studiare seriamente il C++ solo da qualche mese;
non conosco i retroscena delle scelte fatte (anche se da alcune
apprentemente incomprensibili incongruenze nel linguaggio credo
che il travaglio dello standard sia stato lungo e doloroso).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

visti!
Dubito che mai ne vedrai (anche se tutto e' possibile).
HTH


 po' pesantuccio?
Nella maggioranza dei casi sicuramente si. Ma si può sempre passarlo
tramite puntatore o reference.
EMG

>Dipende dalla dimensione dell'array, ovviamente.
Pienamente d'accordo, ma di solito non si lavora con un array di 2
elementi.
Cmq vedremo cosa deciderà lo standard a proposito.


Cmq vedremo cosa deciderà lo standard a proposito.
Che io sappia lo standard ha gia' deciso. Se solo riuscissi a 
ritrovare il mio "reference" e a ripassarlo!!!


ritrovare il mio "reference" e a ripassarlo!!!
Ehm, nel qual caso che tu lo trovassi potresti inviarlo anche al
sottoscritto?
Ringrazio in anticipo.
