conversion double* to vector<double> and vice versa

[J.M.]

I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored as
vector<doublefrom the STL and need to pass a double* and the dimension of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive option?

Thanks in advance for any help.

Jan

[Jim Langston]

"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

>I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored as
vector<doublefrom the STL and need to pass a double* and the dimension
of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive option?

Thanks in advance for any help.

Jan

Going into the functions, yes. Vectors are guaranteed to store their data
contiguously and so can be used where arrays are expected. That is, you can
pass &MyVector[0] and MyVector.size(). &MyVector.front() is also used
sometimes.

Coming out of the functions, I don't see how. You are given a pointer to an
array of doubles. The only way to get this into a vector, as far as I know,
is to copy the data. There may be some constructor for vector that takes a
pointer to data and a length, I just don't know (but tend to doubt it?).

[J.M.]

Jim Langston schrieb:

"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

>>I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored
as vector<doublefrom the STL and need to pass a double* and the
dimension of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive option?

Thanks in advance for any help.

Jan

Going into the functions, yes. Vectors are guaranteed to store their data
contiguously and so can be used where arrays are expected. That is, you
can
pass &MyVector[0] and MyVector.size(). &MyVector.front() is also used
sometimes.

Coming out of the functions, I don't see how. You are given a pointer to
an
array of doubles. The only way to get this into a vector, as far as I
know,
is to copy the data. There may be some constructor for vector that takes
a pointer to data and a length, I just don't know (but tend to doubt it?).

Thanks, but that is precisely what I needed :-). Actually, the software
package takes as argument double* and returns the result in the same array
by overwriting, so in this case, I do not actually need to convert back to
vector<double>... I just hope I am not doing something dangerous... Thanks.

Jan

[Jim Langston]

"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

Jim Langston schrieb:

>"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

>>>I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored
as vector<doublefrom the STL and need to pass a double* and the
dimension of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive option?

Thanks in advance for any help.

Jan

Going into the functions, yes. Vectors are guaranteed to store their
data
contiguously and so can be used where arrays are expected. That is, you
can
pass &MyVector[0] and MyVector.size(). &MyVector.front() is also used
sometimes.

Coming out of the functions, I don't see how. You are given a pointer to
an
array of doubles. The only way to get this into a vector, as far as I
know,
is to copy the data. There may be some constructor for vector that takes
a pointer to data and a length, I just don't know (but tend to doubt
it?).

Thanks, but that is precisely what I needed :-). Actually, the software
package takes as argument double* and returns the result in the same array
by overwriting, so in this case, I do not actually need to convert back to
vector<double>... I just hope I am not doing something dangerous...
Thanks.

Jan

Nothing dangerous, just make sure that the software package doesn't try to
resize the array itself. And make sure it's sized proper when you go in.
But as you say it accepts a size parameter so I suspect it respects the
limits.

[Jacek Dziedzic]

Jim Langston wrote:

"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

>I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored as
vector<doublefrom the STL and need to pass a double* and the dimension
of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive option?

Thanks in advance for any help.

Jan

Going into the functions, yes. Vectors are guaranteed to store their data
contiguously and so can be used where arrays are expected. That is, you can
pass &MyVector[0] and MyVector.size(). &MyVector.front() is also used
sometimes.

Coming out of the functions, I don't see how. You are given a pointer to an
array of doubles. The only way to get this into a vector, as far as I know,
is to copy the data. There may be some constructor for vector that takes a
pointer to data and a length, I just don't know (but tend to doubt it?).

As a side note, on return from the function, would it be OK to
resize the vector appropriately, and then writing to &vec[0]
(passing this pointer to the function). The memory in the vector
is guaranteed to be continuous and if you resize it in advance,
then would this work? I think so.

- J.

[J.M.]

Jim Langston schrieb:

"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...

>Jim Langston schrieb:

>>"J.M." <jm***@gmx.dewrote in message
news:es**********@news2.rz.uni-karlsruhe.de...
I am trying to use a software package in my program, the problem being
different methods are used to store vectors. I have "my" vectors stored
as vector<doublefrom the STL and need to pass a double* and the
dimension of
the vector to the software package. On return, I get a double* plus
dimension, but need vector<double>. Is there anyway that this can be
achieved *without* copying the data, as this is a very expensive
option?

Thanks in advance for any help.

Jan

Going into the functions, yes. Vectors are guaranteed to store their
data
contiguously and so can be used where arrays are expected. That is, you
can
pass &MyVector[0] and MyVector.size(). &MyVector.front() is also used
sometimes.

Coming out of the functions, I don't see how. You are given a pointer
to an
array of doubles. The only way to get this into a vector, as far as I
know,
is to copy the data. There may be some constructor for vector that
takes a pointer to data and a length, I just don't know (but tend to
doubt it?).

Thanks, but that is precisely what I needed :-). Actually, the software
package takes as argument double* and returns the result in the same
array by overwriting, so in this case, I do not actually need to convert
back to vector<double>... I just hope I am not doing something
dangerous... Thanks.

Jan

Nothing dangerous, just make sure that the software package doesn't try to
resize the array itself.

Yup, I figured that this would be a bad idea... But I know for a fact that
that it does not (or can be told not to do so). It seems to work fine now,
although not much testing has been done. Thanks for your help.

Jan

And make sure it's sized proper when you go in.
But as you say it accepts a size parameter so I suspect it respects the
limits.