primitive type arrays

[Clement Courbet]

Hi,

I have a simple question concerning arrays of primitive types
allocated/deallocated via operator new[]/delete[]:
On non-primitive types, new[] will allocate memory, then call the
constructor for each object. What about primitive types ? Is there an
overhead for:

int *intPointer = new int[1000000];

compared to simple memory allocation ?

To go further, if I have a class which has an empty constructor, and
only primitive type class members, let's say

class A
{
public:
A{};
~A{};

private:
int anInt;
char aChar;
};

then will a call to

A *aPointer = new A[1000000];

generate a loop calling the useless constructor ?

thank you for your answers,

 

[robertwessel2]

Hi,

I have a simple question concerning arrays of primitive types
allocated/deallocated via operator new[]/delete[]:
On non-primitive types, new[] will allocate memory, then call the
constructor for each object. What about primitive types ? Is there an
overhead for:

int *intPointer = new int[1000000];

compared to simple memory allocation ?

To go further, if I have a class which has an empty constructor, and
only primitive type class members, let's say

class A
{
        public:
        A{};
        ~A{};

        private:
        int anInt;
        char aChar;

};

then will a call to

A *aPointer = new A[1000000];

generate a loop calling the useless constructor ?

There's nothing in the standard than mandates any particular
performance for these in any implementation, but as a practical
matter, there will (very) likely be no overhead in the POD case, and
most compilers will generate no code in the second case if the
optimizer is turned on.

But if it's important for you, inspect the generated code.

 

[Victor Bazarov]

I have a simple question concerning arrays of primitive types
allocated/deallocated via operator new[]/delete[]:
On non-primitive types, new[] will allocate memory, then call the
constructor for each object. What about primitive types ? Is there an
overhead for:

int *intPointer = new int[1000000];

compared to simple memory allocation ?

What's "simple memory allocation"? AFAIK, you can't get any simpler
than that...

To go further, if I have a class which has an empty constructor, and
only primitive type class members, let's say

class A
{
public:
A{};

That's not an empty constructor. That's a syntax error. An empty
constructor wouldn't be needed. And if you still want to provide it,
you would write

A() {}

(and no trailing semicolon either).

~A{};

Same here. You should not write and empty d-tor unless you're declaring
it virtual. Still, since d-tors are functions, they need the argument list.

~A() {}

(And lose the trailing semicolon).

private:
int anInt;
char aChar;
};

then will a call to

A *aPointer = new A[1000000];

generate a loop calling the useless constructor ?

What you're asking about is caused by "premature optimization". If you
need to figure out whether *your compiler* and on *your platform*
produces code that has some overhead with a do-nothing constructor that
*you* provided (for no apparent reason), then you need to profile your
application with and without the useless constructor. That's the only
way to know whether there's going to be any difference. Well, that and
maybe looking at the assembly...

Still, the difference would be specific to your implementation. The
standard says that the storage is initialised. If your constructor does
not really do any special initialisation, the compiler might be able to
determine that and skip calling the c-tor (IOW, optimize it away).

So, to sum up, two "don't" lessons. First, don't write functions that
you don't need. Second, to know whether there is impact on performance,
don't guess, *measure*.

V

 

[Clement Courbet]

What's "simple memory allocation"?

I meant just calling old malloc.

That's not an empty constructor. That's a syntax error.

Sure, I forgot parentheses ...

What you're asking about is caused by "premature optimization". If you
need to figure out whether *your compiler* and on *your platform*
produces

So, to sum up, two "don't" lessons. First, don't write functions that
you don't need. Second, to know whether there is impact on performance,
don't guess, *measure*.

I was simply asking whether the standard was telling something about it
(because I did'n find anything about this, except that storage was
initialized, which it seems to me sometimes makes no sense for PODs.),
so that it would be possible to write efficient code portably for any
compiler respecting the standard. I'm trying to learn.

 

[Clement Courbet]

There's nothing in the standard than mandates any particular
performance for these in any implementation, but as a practical
matter, there will (very) likely be no overhead in the POD case, and
most compilers will generate no code in the second case if the
optimizer is turned on.

Thank you very much for your answer.

But if it's important for you, inspect the generated code.

Well, I guess I will have to, if the standard does not say anything.

 

[mzdude]

What you're asking about is caused by "premature optimization".  If you
need to figure out whether *your compiler* and on *your platform*
produces code that has some overhead with a do-nothing constructor that
*you* provided (for no apparent reason), then you need to profile your
application with and without the useless constructor.  That's the only
way to know whether there's going to be any difference.  Well, that and
maybe looking at the assembly...

Would profiling give you a correct answer? The default ctor
will be generated by the compiler and therefor still called.

 

[Alexander Terekhov]

I have a simple question concerning arrays of primitive types
allocated/deallocated via operator new[]/delete[]:
On non-primitive types, new[] will allocate memory, then call the
constructor for each object. What about primitive types ? Is there an
overhead for:

int *intPointer = new int[1000000];

compared to simple memory allocation ?

What's "simple memory allocation"? AFAIK, you can't get any simpler
than that...

I * i = new I[...];

No?

regards,
alexander.

 

[Thomas J. Gritzan]

int *intPointer = new int[1000000];

compared to simple memory allocation ?

What's "simple memory allocation"? AFAIK, you can't get any simpler
than that...

I suppose that he is talking about malloc() (or ::new), assuming that
the regular new[] goes over the allocated ints and initializes them all
to zero (while malloc() and ::new() only allocate the space but do
nothing to it).

new[] only initializes to zero if you add parenthesis:

int *p = new int[1000000]();
// ^^

 

[Clement Courbet]

What's "simple memory allocation"? AFAIK, you can't get any simpler
than that...

I suppose that he is talking about malloc() (or ::new), assuming that
the regular new[] goes over the allocated ints and initializes them all
to zero (while malloc() and ::new() only allocate the space but do
nothing to it).

That is what I had in mind.

new[] only initializes to zero if you add parenthesis:

int *p = new int[1000000]();

OK, so if I understand correctly,

int *p = new int[1000000];
should not compile as a loop, while
int *p = new int[1000000]();
will.

Thank you all for your answers.

 

[Victor Bazarov]

Victor Bazarov wrote:
What's "simple memory allocation"? AFAIK, you can't get any simpler
than that...
I suppose that he is talking about malloc() (or ::new), assuming that
the regular new[] goes over the allocated ints and initializes them all
to zero (while malloc() and ::new() only allocate the space but do
nothing to it).

That is what I had in mind.

new[] only initializes to zero if you add parenthesis:

int *p = new int[1000000]();

OK, so if I understand correctly,

int *p = new int[1000000];
should not compile as a loop, while
int *p = new int[1000000]();
will.

Nowhere in the Standard does it say "a loop". For all we know the
processor might have an instruction to zero so many memory locations
starting from the given address. And there can be architectures in
which it probably not linearly dependent on the number of locations to zero.

It is *implementation-defined*, and you should not give it more thought
than that. You initialise the memory if you have to, you leave it
uninitialised if you can. As to how much more time the machine spends
initialising that dynamic array, it's unknown and impossible to
conclude. You need to measure.

V

 

[Bart van Ingen Schenau]

Juha Nieminen schrieb:
Victor Bazarov wrote:
What's "simple memory allocation"?  AFAIK, you can't get any simpler
than that...
  I suppose that he is talking about malloc() (or ::new), assuming that
the regular new[] goes over the allocated ints and initializes them all
to zero (while malloc() and ::new() only allocate the space but do
nothing to it).

That is what I had in mind.

new[] only initializes to zero if you add parenthesis:
int *p = new int[1000000]();

OK, so if I understand correctly,

int *p = new int[1000000];
should not compile as a loop, while
int *p = new int[1000000]();
will.

Nowhere in the Standard does it say "a loop".  For all we know the
processor might have an instruction to zero so many memory locations
starting from the given address.  And there can be architectures in
which it probably not linearly dependent on the number of locations to zero.

And for all we know, if you don't explicitly initialise the memory,
the implementation uses the output from a random number generator to
fill the memory with random values.

It is *implementation-defined*, and you should not give it more thought
than that.  You initialise the memory if you have to, you leave it
uninitialised if you can.  As to how much more time the machine spends
initialising that dynamic array, it's unknown and impossible to
conclude.  You need to measure.

V

Bart v Ingen Schenau