By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,652 Members | 1,317 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,652 IT Pros & Developers. It's quick & easy.

Any difference in these array declarations

P: n/a
Hello,
can anyone please tell me if there is any difference between the two:
double Array1[10];
and
double* Array2 = new double[10];
..
..
..
delete [] Array2;
Thanks
Jan 4 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a

Vasileios Zografos wrote:
Hello,
can anyone please tell me if there is any difference between the two:

double Array1[10];
and
double* Array2 = new double[10];
delete [] Array2;


Array1 is name of an array, a constant. Array2 is simply a pointer to a
double. Array2 can be reassigned a different value, Array1 cannot be.

double pi = 3.14;
Array2 = & pi; // fine
Array1 = & pi// error. Incompatible types in assignment.

Jan 4 '06 #2

P: n/a
Vasileios Zografos wrote:
can anyone please tell me if there is any difference between the two:
double Array1[10];
and
double* Array2 = new double[10];
.
.
.
delete [] Array2;


Of course there is. 'Array1' has the type 'array of 10 double', whereas
'Array2' has the type 'pointer to double'.

V
Jan 4 '06 #3

P: n/a
different method of memory allocation,
array1 is allocated on stack,
array2 is allocated on heap.

Jan 4 '06 #4

P: n/a

"Tsubasa" <ch**********@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
different method of memory allocation,
array1 is allocated on stack,
array2 is allocated on heap.


Thanks ;)
Jan 4 '06 #5

P: n/a

Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack,

not always. May be in data section, if it is declared non-locally.

Jan 4 '06 #6

P: n/a
Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack,
I presume you meant 'Array1', not 'array1'. And where it's allocated
depends entirely on where the declaration appears.
[..]


And please quote the relevant portion of the post you're replying to.
Jan 4 '06 #7

P: n/a
Vasileios Zografos wrote:

double Array1[10];

double* Array2 = new double[10];
.
.
.
delete [] Array2;


Array1 is exception safe. Array2 is not exception safe if an uncaught
exception is thrown in the "..." section of code.
Jan 4 '06 #8

P: n/a
Neelesh Bodas wrote:
Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack,


not always. May be in data section, if it is declared non-locally.


Just to pick a nit, neither 'stack', nor 'data section', nor even 'heap'
are proper C++ terms for the area of memory where objects live. It would
be better to use 'automatic', 'static', or 'dynamic' to distinguish the
objects. The only thing known is that dynamic objects are allocated in
the "free store".

V
Jan 4 '06 #9

P: n/a
OK here goes file mou... I will try and explain the difference without
getting too technical,

Declaring an array as "double Array1[10] can be thought of as declaring
a "hard coded" array... i.e. it's size MUST be known at the time of
compilation.... For example,

const int CONST_VAL = 5;
int nVal = 6;

double Array1[10]; // valid
double Array2[CONST_VAL]; // also valid
double Array3[nVal]; // NOT valid, nVal is not known
at compilation!!
Declaring an array as "double* pArray2 = new double[10]" has the same
effect with the main difference being the size of the array can be
stated from the value contained in a variable.... For example,

const int CONST_VAL = 5;
int nVal = 6;

double* pArray1 = new double[10]; // valid
double* pArray2 = new double[CONST_VAL]; // also valid
double* pArray3 = new double[nVal]; // also valid
Whichever way the array is created, it is still accessed in the same
way

double Array1[10]; // Array 1
double pArray2 = new double[10]; // Array 2

for( int i = 0; i < 10; i++ )
{
Array1[ i ] = i;
pArray2[ i ] = i;
}

Both arrays will contain exactly the same data...

BUT remember, any memory created using the "new" keyword MUST be
deleted when finished with otherwise you risk aquiring memory
leaks!!... And also "hard coded" arrays do not require deletion as they
are automatically deleted when out of scope!!...

So Array 2 requires to be deleted as so when not required further,

delete pArray2; (or delete [] pArray2;)

Regards

Frinos

Vasileios Zografos wrote:
Hello,
can anyone please tell me if there is any difference between the two:
double Array1[10];
and
double* Array2 = new double[10];
.
.
.
delete [] Array2;
Thanks


Jan 4 '06 #10

P: n/a
Please do no top-post. Thank you. Rearranged.
http://www.parashift.com/c++-faq-lit...t.html#faq-5.4

Frinos wrote:
Vasileios Zografos wrote:
Hello,
can anyone please tell me if there is any difference between the two:
double Array1[10];
and
double* Array2 = new double[10];
.
.
.
delete [] Array2; OK here goes file mou... I will try and explain the difference without
getting too technical,

Declaring an array as "double Array1[10] can be thought of as declaring
a "hard coded" array... i.e. it's size MUST be known at the time of
compilation.... For example,

const int CONST_VAL = 5;
int nVal = 6;

double Array1[10]; // valid
double Array2[CONST_VAL]; // also valid
double Array3[nVal]; // NOT valid, nVal is not known
at compilation!!


Side issue - don't use ALL_CAPS identifiers for anything except macros.
That way you protect yourself from macros destroying your code before
the compiler sees it.
Declaring an array as "double* pArray2 = new double[10]" has the same
effect with the main difference being the size of the array can be
stated from the value contained in a variable.... For example,

const int CONST_VAL = 5;
int nVal = 6;

double* pArray1 = new double[10]; // valid
double* pArray2 = new double[CONST_VAL]; // also valid
double* pArray3 = new double[nVal]; // also valid
double* pArray2 = new double[10] does *not* declare an array. It
declares a pointer and initialises that pointer with the address of the
first element of an array of 10 doubles. Maybe that's more technical
than you were trying to be, but it's important to note that, by your
declarations, Array is an array while pArray is a pointer.

Arrays and pointers are not the same thing.

<snip>
BUT remember, any memory created using the "new" keyword MUST be
deleted when finished with otherwise you risk aquiring memory
leaks!!... And also "hard coded" arrays do not require deletion as they
are automatically deleted when out of scope!!...

So Array 2 requires to be deleted as so when not required further,

delete pArray2; (or delete [] pArray2;)


You seem to suggest that either of those options is valid.

delete pArray2 is incorrect. delete and delete [] are different things.
Mixing them up causes undefined behavior. Every new must be matched
with a delete. Every new [] (as you have been using) must be matched
with a delete [].

Gavin Deane

Jan 5 '06 #11

P: n/a
Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack, not always. May be in data section, if it is declared non-locally.


"in data section"? you mean public variable or static variable?

Jan 5 '06 #12

P: n/a

Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack,

not always. May be in data section, if it is declared non-locally.


"in data section"? you mean public variable or static variable?


I meant that automatic storage is allocated on stack , and global or
static storatge is allocated in data segment. But as Victor suggested,
"stack, data, heap" are not terms used by std C++. So to rephrase, what
I meant was that the location where the storage is allocated depends on
the place where ithe variable's declaration appears. (automatic /static
storage area and free store are probably better terms)

Jan 5 '06 #13

P: n/a
Tsubasa wrote:
Tsubasa wrote:
different method of memory allocation,
array1 is allocated on stack,


not always. May be in data section, if it is declared non-locally.

"in data section"? you mean public variable or static variable?


On some systems at least, globals, statics, constants, string literals,
etc. will be stored in a "data" section that is separate from the stack
and heap. There may even be separate sections for read-only and
writable globals.

Of course, this is all system-dependent, and C++ knows nothing about any
of it.

Rennie deGraaf
Jan 5 '06 #14

P: n/a
Sorry for the previous top post, (I'm sure you can excuse first time
posters!!.... )...

With regards to using CAPS, there are no do's and dont's.... it's just
preference and following your coding standards....

With regards to declaring the array I suppose its bad use of words on
my part, maybe I should have used the word "create" rather than
declare.....
In one case you declare the array (which also creates it... double
Array[10])..... In the other case, you declare a pointer to a double
and assign it with the address of the first element of the "newly"
created array... double* pArray = new double[10]).... In both cases an
array is created but the important thing to note is that with the first
array, its memory is reserved during compilation and with the other
array, it is created dynamically at run time and therefore the memory
reserved for it must be deleted...

With regards to array deletion your statement is not necessarily the
case, delete can be used just as well as delete[] when used with the
new[] operator...... It all depends on your compiler and if it allows
it. I think the C++ standards have changed in this area..... I use
MSVC++6.0 and does not give me errors or undefined behaviour, but I do
guess its better to get into the habit of using delete[] with new[]...

Regards

Frinos

Jan 5 '06 #15

P: n/a

Frinos wrote:
Sorry for the previous top post, (I'm sure you can excuse first time
posters!!.... )...
I can :-)

Another thing - please quote some context in your messages. You've
replied to various of my points here, but you haven't included any of
what I said. Someone reading your message won't know what you're
referring to.

To quote from Google, don't use the Reply button. Click Show Options at
the top, then use the Reply option revelaed there.
With regards to using CAPS, there are no do's and dont's.... it's just
preference and following your coding standards....
Yes, my "don't" was meant as advice. Clearly if you are following
someone else's coding standards (your employer for example) you do what
they say. But if you are writing code under your own rules it is a very
good idea to invent a 'namespace' convention for macros to protect your
code. ALL_CAPS for macros is the only widespread convention I've
encountered.
With regards to declaring the array I suppose its bad use of words on
my part, maybe I should have used the word "create" rather than
declare.....
In one case you declare the array (which also creates it... double
Array[10])..... In the other case, you declare a pointer to a double
and assign
initialise, not assign
it with the address of the first element of the "newly"
created array... double* pArray = new double[10]).... In both cases an
array is created but the important thing to note is that with the first
array, its memory is reserved during compilation and with the other
array, it is created dynamically at run time and therefore the memory
reserved for it must be deleted...
I suspected you understood what you were saying, but I made the
correction for the benefit of the OP and anyone else reading your post.
Confusion between arrays and pointers is a common problem in learning
C++. That sort of correctness is highly valued here.

I corrected your 'assign' to 'initialise' for the same reason.
Assignment and Initialisation are precisely defined concepts in C++ and
mixing them up can be another source of confusion in learning the
language.
With regards to array deletion your statement is not necessarily the
case, delete can be used just as well as delete[] when used with the
new[] operator...... It all depends on your compiler and if it allows
it. I think the C++ standards have changed in this area..... I use
MSVC++6.0 and does not give me errors or undefined behaviour, but I do
guess its better to get into the habit of using delete[] with new[]...


Unless the rules have changed in C++03 (which I highly doubt), then my
statement is correct. new [] paired with delete *is* illegal and it
does cause undefined behaviour. new [] has to go with delete [] and new
has to go with delete. Incidentally, VC++6 is a very old compiler - it
predates even the original C++ standard from 1998 and is non-conformant
in a lot of respects.

Undefined Behaviour means *absolutely anything* can happen. The program
could crash, it could add 1 to all the int variables currently in
existence, it could print rude messages on the screen, it could
reformat your hard drive. Or it could do exactly what you expected it
to do. You were unlucky and happened to get the last example.

Gavin Deane

Jan 5 '06 #16

P: n/a
With regards to declaring the array I suppose its bad use of words on
my part, maybe I should have used the word "create" rather than
declare.....
In one case you declare the array (which also creates it... double
Array[10])..... In the other case, you declare a pointer to a double
and assign
initialise, not assign
Initialisation is the first time a variable is "assigned" a value....
But since we are using the "assignment" operator to perform the
initialisation the variable is also "assigned" a value which happens to
be the address of the first double in the dynamically created array....
With regards to array deletion your statement is not necessarily the
case, delete can be used just as well as delete[] when used with the
new[] operator...... It all depends on your compiler and if it allows
it. I think the C++ standards have changed in this area..... I use
MSVC++6.0 and does not give me errors or undefined behaviour, but I do
guess its better to get into the habit of using delete[] with new[]...

Unless the rules have changed in C++03 (which I highly doubt), then my
statement is correct. new [] paired with delete *is* illegal and it
does cause undefined behaviour. new [] has to go with delete [] and new
has to go with delete. Incidentally, VC++6 is a very old compiler - it
predates even the original C++ standard from 1998 and is non-conformant
in a lot of respects.


OK I agree, I was unlucky.... and of course I will discourage the use
of the delete operator used with arrays created using new[]...

Regards

Frinos

Jan 5 '06 #17

P: n/a

Frinos wrote:
With regards to declaring the array I suppose its bad use of words on
my part, maybe I should have used the word "create" rather than
declare.....
In one case you declare the array (which also creates it... double
Array[10])..... In the other case, you declare a pointer to a double
and assign


initialise, not assign


Initialisation is the first time a variable is "assigned" a value....
But since we are using the "assignment" operator to perform the
initialisation the variable is also "assigned" a value which happens to
be the address of the first double in the dynamically created array....


In C++ the definitions of initialisation and assignment are more
precise that that. Initialisation is what happens when a new object is
created. Assignment is what happens when an object already in existence
is given a new value. The two are mutually exclusive. The use of = is a
misleading feature of the syntax.

For any type T, in a statement of the form

T the_variable = some_value;

the concept of assignment (including the assignment operator for
user-defined types) never applies.

For user-defined types, which have constructors (including a copy
constructor) and an assignment operator, what happens is:
An unnamed temporary object of type T is constructed diretly from
some_value.
That unnamed temporary object is used to copy-construct the_variable.

The compiler is allowed to elide the use of the temporary and directly
construct the_variable from some_value (but the copy constructor must
still be visible).

Built-in types don't have copy constructors and assignment operators,
but conceptually the same thing is happening - initialisation of a
brand new object, not the overwriting of the value of an already
created object.

Given this class

class T
{
public:
T() {}

// copy constructor
T(const T& rhs) {}

private:
// assignment operator is inaccessible
T& operator=(const T& rhs);
};

the following program compiles, despite the fact that T does not permit
assignment

int main()
{
T some_value;
T the_variable = some_value; // initialisation

return 0;
}

However, change the class definiton so that assignment is supported but
copy construction isn't

class T
{
public:
T() {}

// assignment operator now accessible
T& operator=(const T& rhs);

private:
// copy constructor now inaccessible
T(const T& rhs) {}
};

and the program no longer compiles.

Gavin Deane

Jan 5 '06 #18

P: n/a
You are absolutely correct Gavin.... well done.... thanks for the
info...
I have to say that I didn't realise the assignment operator is not at
all used during a variables initialisation even though it appears in
the syntax...

Regards
Frinos

Jan 5 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.