new() and memcpy()

[barcaroller]

Is it safe to use the result of 'new int[100]' in a memcpy().

Example:

int* cpp_block = new int[100];
int* c_block = some_c_function ();

memcpy(cpp_bloc k, c_block, 100);
I suspect cpp_block may be pointing to more than just a simple array of
integers.

If it's not safe, I could use a vector instead of the 'new int[100]' but how
do I initialize the vector using the C-style array without having to iterate
over the vector one integer at a time?

[pmouse]

barcaroller wrote:

Is it safe to use the result of 'new int[100]' in a memcpy().

Example:

int* cpp_block = new int[100];
int* c_block = some_c_function ();

memcpy(cpp_bloc k, c_block, 100);
I suspect cpp_block may be pointing to more than just a simple array of
integers.

If it's not safe, I could use a vector instead of the 'new int[100]' but how
do I initialize the vector using the C-style array without having to iterate
over the vector one integer at a time?

If you haven't overloaded the new operator, this is what it does
(pseudo code):
int* cpp_block = (int*)malloc( sizeof(int) * 100 );
for ( int i = 0; i < 100; ++i )
cpp_block[i]::int();

so yes, there is nothing more magical about the default new operator.
It is safe to copy it around (obviously the size of not 100, but
sizeof(int)*100 , but i assume that you know what your doing)

run this code to see:

int * new_arr = new int[100];
int * old_arr = (int*)malloc( sizeof(int)*100 );
memset( old_arr, 0, sizeof(int)*100 );

unsigned char* new_begin = (unsigned char*)new_arr;
unsigned char* old_begin = (unsigned char*)old_arr;

for ( int i = 0; i < sizeof(int)*100 ; ++i )
{
if ( *new_begin++ != *old_begin++ )
cout << "problem!" << endl;
}

delete[] new_arr;
free(old_arr);
On May 4, 6:21 pm, "barcarolle r" <barcarol...@mu sic.netwrote:

Is it safe to use the result of 'new int[100]' in a memcpy().

Example:

int* cpp_block = new int[100];
int* c_block = some_c_function ();

memcpy(cpp_bloc k, c_block, 100);

I suspect cpp_block may be pointing to more than just a simple array of
integers.

If it's not safe, I could use a vector instead of the 'new int[100]' but how
do I initialize the vector using the C-style array without having to iterate
over the vector one integer at a time?

[Markus Schoder]

barcaroller wrote:

Is it safe to use the result of 'new int[100]' in a memcpy().

Example:

int* cpp_block = new int[100];
int* c_block = some_c_function ();

memcpy(cpp_bloc k, c_block, 100);

Make that memcpy(cpp_bloc k, c_block, 100 * sizeof(int)) and it should be
ok.

I suspect cpp_block may be pointing to more than just a simple array
of integers.

Nope. Just an array.

If it's not safe, I could use a vector instead of the 'new int[100]'
but how do I initialize the vector using the C-style array without
having to iterate over the vector one integer at a time?

Using a vector is recommended because it will also do the deallocation
for you. Initialization is easy:

#include <vector>

std::vector<int cpp_block(c_blo ck, c_block + 100);

of if you need to initialize later:

#include <vector>
#include <algorithm>

std::vector<int cpp_block(100);

....

std::copy(c_blo ck, c_block + 100, cpp_block.begin ());

--
Markus

[barcaroller]

"Markus Schoder" <a3************ *@yahoo.dewrote in message
news:46******** **************@ newsspool2.arco r-online.net...

>I suspect cpp_block may be pointing to more than just a simple array
of integers.

Nope. Just an array.

But doesn't C++ (unlike C) need to keep track of the size of the array?
Hence the difference between delete and delete[].

[Ian Collins]

barcaroller wrote:

"Markus Schoder" <a3************ *@yahoo.dewrote in message
news:46******** **************@ newsspool2.arco r-online.net...

>>I suspect cpp_block may be pointing to more than just a simple array
of integers.

Nope. Just an array.

But doesn't C++ (unlike C) need to keep track of the size of the array?
Hence the difference between delete and delete[].

In this case, it doesn't matter, you are just copying block of memory.

The C++ runtime may be doing housekeeping under the hood, but that's not
your problem, you just see a contiguous block of memory 100*sizeof(int)
long.

--
Ian Collins.

[Default User]

barcaroller wrote:

>
"Markus Schoder" <a3************ *@yahoo.dewrote in message
news:46******** **************@ newsspool2.arco r-online.net...

I suspect cpp_block may be pointing to more than just a simple
array of integers.

Nope. Just an array.

But doesn't C++ (unlike C) need to keep track of the size of the
array? Hence the difference between delete and delete[].

More likely the OS keeps track of it. From the standpoint of the user
it's plain block of memory, in this case aligned for use as an array of
ints.


Brian

[Jim Langston]

"barcarolle r" <ba*********@mu sic.netwrote in message
news:f1******** **@aioe.org...

>
"Markus Schoder" <a3************ *@yahoo.dewrote in message
news:46******** **************@ newsspool2.arco r-online.net...

>>I suspect cpp_block may be pointing to more than just a simple array
of integers.

Nope. Just an array.

But doesn't C++ (unlike C) need to keep track of the size of the array?
Hence the difference between delete and delete[].

It may, it may not. But if it does it's transparent to you. Maybe the
number it allocated is kept in an extra bit of memory before the pointer you
are returned, or after the block. Either way, the pointer you have points
to a block of 100 ints. It's not safe to use free to release a block of
memory obtained with new for possible housekeeping reasons though because
the pointer you are given by new[] is not neccessarily the pointer to the
memory allocated (it may point to sizeof size_t after the start for
instance).

[James Kanze]

On May 5, 12:31 am, pmouse <pmo...@cogeco. cawrote:

barcaroller wrote:

Is it safe to use the result of 'new int[100]' in a memcpy().

Example:

int* cpp_block = new int[100];
int* c_block = some_c_function ();

memcpy(cpp_bloc k, c_block, 100);

I suspect cpp_block may be pointing to more than just a simple array of
integers.

There's obviously more somewhere, but cpp_block points to the
first of 100 consecutive int's.

If it's not safe, I could use a vector instead of the 'new int[100]' but how
do I initialize the vector using the C-style array without having to iterate
over the vector one integer at a time?

If you haven't overloaded the new operator, this is what it does
(pseudo code):
int* cpp_block = (int*)malloc( sizeof(int) * 100 );
for ( int i = 0; i < 100; ++i )
cpp_block[i]::int();

Where do you get this from? There's no guarantee that operator
new uses malloc (although it is a frequent implementation) . And
operator new certainly isn't required to initialize the ints
with 0; most of the ones I've seen don't.

--
James Kanze (Gabi Software) email: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Rolf Magnus]

Default User wrote:

barcaroller wrote:

>>
"Markus Schoder" <a3************ *@yahoo.dewrote in message
news:46******* *************** @newsspool2.arc or-online.net...

I suspect cpp_block may be pointing to more than just a simple
array of integers.

Nope. Just an array.

But doesn't C++ (unlike C) need to keep track of the size of the
array? Hence the difference between delete and delete[].

More likely the OS keeps track of it.

I'd say that's rather unlikely.

From the standpoint of the user it's plain block of memory, in this case
aligned for use as an array of ints.

Isn't it even aligned for any use?

[James Kanze]

On May 5, 1:08 pm, Rolf Magnus <[e-mail]:

Default User wrote:

[...]

From the standpoint of the user it's plain block of memory, in this case
aligned for use as an array of ints.

Isn't it even aligned for any use?

It's not guaranteed. The return value of the operator new()
function must be sufficiently aligned for any use, as must new
of a character type, but for the others, all that's guaranteed
is sufficient alignment for the allocated type.

--
James Kanze (Gabi Software) email: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]