Re: std::vector to array
michelangelo giacomelli
> Ciao a tutti.
>
> Uno std::vector alloca memoria in modo consecutivo?
> Se si' e' possibile "ritornare" un array di tipo C (o il puntatore al
> primo elemento) da uno std::vector in maniera sicura o standard?
>
> Grazie,
> sD
Da nessuna parte ho mai trovato scritto che lo standard indichi che
std::vector debba allocare memoria in modo continuo, da cui deriva che:
* non puoi assumere che std::vector allochi memoria in modo consecutivo
* non c'� un modo efficente per fare una conversione ad un array "C"
* si pu� fare in maniera inefficente:
std::vector<int> vettoreCPP(10);
int* arrayC;
arrayC = new int [vettoreCPP.size()];
copy(vettoreCPP.begin(),vettoreCPP.end(),arrayC);
...
...
...
delete [] arrayC;
confutazioni, integrazioni?
micheg
michelangelo giacomelli
Allora integro io.
se non aggiungi/rimuovi elementi al vettore e non compi ulteriori
chiamate a metodi che possono riallocare oggetti internamente, molto
probabilmente la classe vector implementer� il vettore con un array di
puntatori quindi potresti fare una cose del genere se hai davvero
bisogno di efficienza e te ne freghi dei rischi.
std::vector<int> v(10);
int* pv = &v[0];
ovviamente se v viene modificato o peggio cancellato da qualsiasi parte
del tuo software pv va a puttane.
GM
> SteD ha scritto:
>> Ciao a tutti.
>>
>> Uno std::vector alloca memoria in modo consecutivo?
>> Se si' e' possibile "ritornare" un array di tipo C (o il puntatore al
>> primo elemento) da uno std::vector in maniera sicura o standard?
>>
>> Grazie,
>> sD
>
> Da nessuna parte ho mai trovato scritto che lo standard indichi che
> std::vector debba allocare memoria in modo continuo, da cui deriva che:
Curioso.
Perch� io ho sempre dato per scontato che fosse cos�...
e non sono il solo:
cito da
http://en.wikipedia.org/wiki/Vector_(C%2B%2B)#Replacement_for_arrays
Because the elements of a vector are stored contiguously,[9] the address
of the first element of a vector can be passed to functions expecting an
array (a pointer to the first element).
poi per� sono andato a vedere quel [9] che punta al �23.2.4 para 1 dello
std dove quella cosa in effetti non c'� scritta.
Almeno non cos� direttamente. Per� � una implicazione di ...supports
random access iterators... (almeno credo)
In quanto per un "random access iterator" deve valere (�24.1.5):
a[n] <-> *(a+n) che assieme al fatto che fare (a+n) deve coincidere
semanticamente col fare a++ n volte e al fatto che tutto deve avere
complessit� amortized constant time (vedere
http://www.sgi.com/tech/stl/RandomAccessIterator.html#5 ) dovrebbe
bastare per garantire che la memoria sia tutta contigua.
O sbaglio?
(certo che scriverlo chiaramente forse sarebbe stato meglio!)
michelangelo giacomelli
> In quanto per un "random access iterator" deve valere (�24.1.5):
> a[n] <-> *(a+n) che assieme al fatto che fare (a+n) deve coincidere
> semanticamente col fare a++ n volte e al fatto che tutto deve avere
> complessit� amortized constant time (vedere
> http://www.sgi.com/tech/stl/RandomAccessIterator.html#5 ) dovrebbe
> bastare per garantire che la memoria sia tutta contigua.
> O sbaglio?
> (certo che scriverlo chiaramente forse sarebbe stato meglio!)
>
>
>
come avevo scritto nel "sotto-post" si pu� ottenere il puntatore
all'array interno:
std::vector<int> v(10);
int* pv = &v[0];
ma hai comunque un puntatore ad una struttura che tecnicamente dovrebbe
comportarsi da scatola nera se da qualche altra parte modifichi o v o pv
rischi di avere dei problemi di consistenza, senza pensare che se
cancelli v perdi anche pv, quindi se per motivi di efficienza �
necessario si fa ma a me non piace preferisco copiare i valori in un
array ex novo.
GM
...
> In quanto per un "random access iterator" deve valere (�24.1.5):
> a[n] <-> *(a+n) che assieme al fatto che fare (a+n) deve coincidere
> semanticamente col fare a++ n volte e al fatto che tutto deve avere
> complessit� amortized constant time (vedere
> http://www.sgi.com/tech/stl/RandomAccessIterator.html#5 ) dovrebbe
> bastare per garantire che la memoria sia tutta contigua.
> O sbaglio?
> (certo che scriverlo chiaramente forse sarebbe stato meglio!)
Si: sbaglio. O no?
Se qualcuno ne ha voglia si legga
http://www.velocityreviews.com/forums/t281876-is-std-vector-contiguous.html
e metta la parola fine.
Sembra che nella versione 03 dello std ci sia scritto chiaramente, e
comunque tutte le implementazioni note anche + vecchie sembra si
comportino cos�...
http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3
http://stackoverflow.com/questions/247738/is-it-safe-to-assume-that-stl-vector-storage-is-always-contiguous
http://herbsutter.wordpress.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/
GM
>
> come avevo scritto nel "sotto-post" si pu� ottenere il puntatore
> all'array interno:
> std::vector<int> v(10);
> int* pv = &v[0];
> ma hai comunque un puntatore ad una struttura che tecnicamente dovrebbe
> comportarsi da scatola nera ...
Leggi cosa dice sutter
http://herbsutter.wordpress.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/
In particolare
Why is it so important that vectors be contiguous? Because that�s what
you need to guarantee that a vector is layout-compatible with a C array,
and therefore we have no reason not to use vector as a superior and
type-safe alternative to arrays even when we need to exchange data with
C code. So vector is our gateway to other languages and most operating
systems features, whose lingua franca is the venerable C array.
And it�s not just vector: The TR1 and C++0x std::array, which implements
fixed-size arrays, is also guaranteed to be contiguous for the same
reasons. (std::array is available in Boost and, ahem, the VC++ TR1
implementation we shipped today.)
So why do people continually ask whether the elements of a std::vector
(or std::array) are stored contiguously? The most likely reason is that
they want to know if they can cough up pointers to the internals to
share the data, either to read or to write, with other code that deals
in C arrays. That�s a valid use, and one important enough to guarantee
in the standard.
michelangelo giacomelli
> So why do people continually ask whether the elements of a std::vector
> (or std::array) are stored contiguously? The most likely reason is that
> they want to know if they can cough up pointers to the internals to
> share the data, either to read or to write, with other code that deals
> in C arrays. That�s a valid use, and one important enough to guarantee
> in the standard.
>
>
beh allora direi che metta la parola fine alla discussione.
GM
Gia, di Sutter mi fido :)