Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9110 > unrolled thread

Length of C++ arrays allocated by operator new[]

Back to article view | Back to comp.lang.c++

Contents

  Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-08-20 15:01 +0200
    Re: Length of C++ arrays allocated by operator new[] Richard Damon <richard@damon-family.org> - 2011-08-20 11:39 -0400
      Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-08-21 22:15 +0200
        Re: Length of C++ arrays allocated by operator new[] Richard Damon <richard@damon-family.org> - 2011-08-22 12:56 -0400
          Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-22 22:41 +0200
    Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-20 09:20 -0700
      Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-20 10:38 -0700
        Re: Length of C++ arrays allocated by operator new[] ruben safir <ruben@mrbrklyn.com> - 2011-08-21 22:33 -0400
          Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-22 03:05 -0700
            Re: Length of C++ arrays allocated by operator new[] ruben safir <ruben@mrbrklyn.com> - 2011-08-22 20:05 -0400
              Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-22 17:20 -0700
              Re: Length of C++ arrays allocated by operator new[] Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-23 08:18 +0200
              Re: Length of C++ arrays allocated by operator new[] James Kanze <james.kanze@gmail.com> - 2011-08-26 08:29 -0700
                Re: Length of C++ arrays allocated by operator new[] Noah Roberts <roberts.noah@gmail.com> - 2011-08-26 09:06 -0700
      Re: Length of C++ arrays allocated by operator new[] Juha Nieminen <nospam@thanks.invalid> - 2011-08-20 17:55 +0000
        Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-20 10:59 -0700
        Re: Length of C++ arrays allocated by operator new[] legalize+jeeves@mail.xmission.com (Richard) - 2011-08-21 03:07 +0000
    Re: Length of C++ arrays allocated by operator new[] "A" <a@a.a> - 2011-08-20 18:26 +0200
      Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-20 17:36 +0100
        Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-08-21 22:39 +0200
          Re: Length of C++ arrays allocated by operator new[] Ian Collins <ian-news@hotmail.com> - 2011-08-22 09:08 +1200
          Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-21 22:32 +0100
            Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-08-22 00:01 +0200
              Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 00:04 +0100
                Re: Length of C++ arrays allocated by operator new[] Ian Collins <ian-news@hotmail.com> - 2011-08-22 11:38 +1200
                  Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 01:14 +0100
                    Re: Length of C++ arrays allocated by operator new[] Ian Collins <ian-news@hotmail.com> - 2011-08-22 12:27 +1200
                Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-21 17:34 -0700
                  Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 01:39 +0100
                    Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-21 18:13 -0700
                      Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 12:16 +0100
                        Re: Length of C++ arrays allocated by operator new[] Paul <pchristor@yahoo.co.uk> - 2011-08-22 09:09 -0700
                          Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 17:22 +0100
                            Re: Length of C++ arrays allocated by operator new[] Oliver Jackson <chexmofo@hotmail.com> - 2011-08-22 22:50 -0700
                Re: Length of C++ arrays allocated by operator new[] Juha Nieminen <nospam@thanks.invalid> - 2011-08-22 06:10 +0000
                  Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-22 12:20 +0100
                    Re: Length of C++ arrays allocated by operator new[] Noah Roberts <roberts.noah@gmail.com> - 2011-08-26 09:03 -0700
                      Re: Length of C++ arrays allocated by operator new[] Nobody <nobody@nowhere.com> - 2011-08-27 02:05 +0100
            Re: Length of C++ arrays allocated by operator new[] Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-22 02:06 -0700
          Re: Length of C++ arrays allocated by operator new[] Juha Nieminen <nospam@thanks.invalid> - 2011-08-22 06:06 +0000
            Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-22 09:19 +0200
              Re: Length of C++ arrays allocated by operator new[] Goran <goran.pusic@gmail.com> - 2011-08-22 04:50 -0700
              Re: Length of C++ arrays allocated by operator new[] Juha Nieminen <nospam@thanks.invalid> - 2011-08-22 13:53 +0000
                Re: Length of C++ arrays allocated by operator new[] yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-23 09:40 +0000
                  Re: Length of C++ arrays allocated by operator new[] Juha Nieminen <nospam@thanks.invalid> - 2011-08-23 10:03 +0000
          Re: Length of C++ arrays allocated by operator new[] yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-22 11:26 +0000
            Re: Length of C++ arrays allocated by operator new[] Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-22 22:32 +0200
        Re: Length of C++ arrays allocated by operator new[] Noah Roberts <roberts.noah@gmail.com> - 2011-08-27 13:30 -0700
          Re: Length of C++ arrays allocated by operator new[] Leigh Johnston <leigh@i42.co.uk> - 2011-08-27 22:23 +0100
    Re: Length of C++ arrays allocated by operator new[] Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-22 02:14 -0700
    Re: Length of C++ arrays allocated by operator new[] Gerald Breuer <Gerald.Breuer@Use-Author-Supplied-Address.invalid> - 2011-08-27 22:35 +0200
      Re: Length of C++ arrays allocated by operator new[] Noah Roberts <roberts.noah@gmail.com> - 2011-08-27 15:45 -0700
        Re: Length of C++ arrays allocated by operator new[] Paavo Helde <myfirstname@osa.pri.ee> - 2011-08-28 02:00 -0500
      Re: Length of C++ arrays allocated by operator new[] "Bo Persson" <bop@gmb.dk> - 2011-08-28 16:38 +0200
        Re: Length of C++ arrays allocated by operator new[] Gerald Breuer <Gerald.Breuer@Use-Author-Supplied-Address.invalid> - 2011-08-28 16:49 +0200
          Re: Length of C++ arrays allocated by operator new[] "Bo Persson" <bop@gmb.dk> - 2011-08-28 22:44 +0200
            Re: Length of C++ arrays allocated by operator new[] Gerald Breuer <Gerald.Breuer@Use-Author-Supplied-Address.invalid> - 2011-08-28 23:03 +0200
          Re: Length of C++ arrays allocated by operator new[] James Kanze <james.kanze@gmail.com> - 2011-08-29 04:05 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#9160

Juha Nieminen wrote:
> Marcel Müller <news.5.maazl@spamgourmet.org> wrote:
>> - STL causes the executable size to explode. One disadvantage of 
>> template meta programming over generics.
> 
>   Why is this urban legend so persistent? People repeat it without actually
> trying it.
> 
>   I just tested with these two programs:
> 
> //---------------------------------------------------------
> int main()
> {
>     int* array = new int[10000];
>     for(int i = 0; i < 10000; ++i) array[i] = i;
>     int value = 0;
>     for(int i = 0; i < 10000; ++i) value += array[i];
>     delete[] array;
>     return value;
> }
> //---------------------------------------------------------
> 
> //---------------------------------------------------------
> #include <vector>
> 
> int main()
> {
>     std::vector<int> array(10000);
>     for(int i = 0; i < 10000; ++i) array[i] = i;
>     int value = 0;
>     for(int i = 0; i < 10000; ++i) value += array[i];
>     return value;
> }
> //---------------------------------------------------------
> 
>   The size of the first executable? 5104 bytes.
>   The size of the second executable? 5528 bytes.
> 
>   Yeah, the size really exploded.

Use it for some dozen different types, not just int.
Use many functions of the STL containers not just the easiest ones.

Templates have to be instantiated for each unique parameter set. Even if 
90% of the generated functions do not depend on all parameters or the 
dependency ends once the compiler has done the type checks, the compiler 
will generate distinct implementations. No programmer would repeat his 
self that much without the templates (well, hopefully).


Marcel

[toc] | [prev] | [next] | [standalone]

#9171

On Aug 22, 9:19 am, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
> Juha Nieminen wrote:
> > Marcel Müller <news.5.ma...@spamgourmet.org> wrote:
> >> - STL causes the executable size to explode. One disadvantage of
> >> template meta programming over generics.
>
> >   Why is this urban legend so persistent? People repeat it without actually
> > trying it.
>
> >   I just tested with these two programs:
>
> > //---------------------------------------------------------
> > int main()
> > {
> >     int* array = new int[10000];
> >     for(int i = 0; i < 10000; ++i) array[i] = i;
> >     int value = 0;
> >     for(int i = 0; i < 10000; ++i) value += array[i];
> >     delete[] array;
> >     return value;
> > }
> > //---------------------------------------------------------
>
> > //---------------------------------------------------------
> > #include <vector>
>
> > int main()
> > {
> >     std::vector<int> array(10000);
> >     for(int i = 0; i < 10000; ++i) array[i] = i;
> >     int value = 0;
> >     for(int i = 0; i < 10000; ++i) value += array[i];
> >     return value;
> > }
> > //---------------------------------------------------------
>
> >   The size of the first executable? 5104 bytes.
> >   The size of the second executable? 5528 bytes.
>
> >   Yeah, the size really exploded.
>
> Use it for some dozen different types, not just int.
> Use many functions of the STL containers not just the easiest ones.
>
> Templates have to be instantiated for each unique parameter set.

Depending on your build chain and build options, they won't be. All
vector<random_pointer_type>, and at least one integral type (e.g.
vector<int>) will all have __identical__ functions. Every single one
will match. Build chain do detect this and "fold" all these functions
into one. With such build chains, perhaps your build time will be
affected, but you will not have e.g. vector::insert(iterator, pt1),
vector::insert(iterator, pt1)... vector::insert(iterator, int). You
will have only one such insert, and that will be called for all
pointer types (pt1, pt2, ... and int).

What also happens is that you get completely different source of
functions, optimizations turn 2+ of those into same executable, and
again, only one of them goes to the final executable.

Goran.

[toc] | [prev] | [next] | [standalone]

#9175

Marcel Müller <news.5.maazl@spamgourmet.com> wrote:
> Use it for some dozen different types, not just int.
> Use many functions of the STL containers not just the easiest ones.
> 
> Templates have to be instantiated for each unique parameter set. Even if 
> 90% of the generated functions do not depend on all parameters or the 
> dependency ends once the compiler has done the type checks, the compiler 
> will generate distinct implementations. No programmer would repeat his 
> self that much without the templates (well, hopefully).

  And exactly how would it be different from using non-templated code for
each used type? If you want an array of ints and an array of doubles,
you'll have to write twice as much code to handle those arrays. The only
difference with the templated version is that you will have to write the
code only once (it's the compiler that does the duplication rather than
yourself).

  Your argument is as silly as saying "if I write two functions instead
of one, the size of the binary will increase". Of course it increases.
You are writing more code.

  The question is, however, does the size of the code "explode" when you
use several types?

  I understand "explosion" to mean that the size of the code increases
very significantly. Like if using one type would make the binary 5 kilobytes
but using two types would make it 100 kilobytes and using three would make
it 1 megabyte in size. That's an "explosion".

  Well, rather than just theoretizing, I went and tried the example program
with two different types to see if the binary size "explodes". Or even
doubles:

//--------------------------------------------------
include <vector>

int main()
{
    std::vector<int> array1(10000);
    std::vector<short> array2(10000);
    for(int i = 0; i < 10000; ++i) { array1[i] = i*3; array2[i] = i; }
    int value = 0;
    for(int i = 0; i < 10000; ++i) value += array1[i] + array2[i];
    return value;
}
//--------------------------------------------------

  The size of the executable? 5856 bytes.

  Yeah, a true explosion in size.

[toc] | [prev] | [next] | [standalone]

#9224

In article <4e525f3f$0$2822$7b1e8fa0@news.nbl.fi>,
Juha Nieminen  <nospam@thanks.invalid> wrote:
>Marcel Müller <news.5.maazl@spamgourmet.com> wrote:
>> Use it for some dozen different types, not just int.
>> Use many functions of the STL containers not just the easiest ones.
>> 
>> Templates have to be instantiated for each unique parameter set. Even if 
>> 90% of the generated functions do not depend on all parameters or the 
>> dependency ends once the compiler has done the type checks, the compiler 
>> will generate distinct implementations. No programmer would repeat his 
>> self that much without the templates (well, hopefully).
>
>  And exactly how would it be different from using non-templated code for
>each used type? If you want an array of ints and an array of doubles,
>you'll have to write twice as much code to handle those arrays. The only
>difference with the templated version is that you will have to write the
>code only once (it's the compiler that does the duplication rather than
>yourself).
>
>  Your argument is as silly as saying "if I write two functions instead
>of one, the size of the binary will increase". Of course it increases.
>You are writing more code.

<Irony on>
Ah, but there are two fantastic alternatives to templates:

1- 
Actually type the code for each types that are being used manually
(well maybe using copy-paste too).  That way, you can line count your
source files in a much more reliable way.  

The fact that you have duplication in your code base.  That this is
harder to maintain and that you could even make an error in one of the
type-specific implementation is negligeable compared to the
incredible benefits of avoiding templates.

2-
Implement a generic container using void *.  That way, your code size
will be a few % points smaller.

The fact that you are loosing type safety (introducing a whole lots
of bug oppurtunities) is negligeable compared to the benefit of
avoiding templates and avoid your executable size to have *exploded* by
a couple of % points. 

<Irony off>

OK, more seriously:

for a trivial program that does nothing useful but only use some
templated container, you may very well be able to notice a significant
increase in size between:

#include <vector>
int main()
{
  std::vector<int> v;
}

and 

#include <vector>
int main()
{
  std::vector<int> v;
  std::vector<char> v;
  std::vector<double> v;
  std::vector<bool> v;
}

etc.

But for a real application that does real work and is composed of
thousands of lines of code, I really doubt that the template
instantiation would make such a significant difference in your
executable size.  This all sounds like premature optimisation to me.
especially with the use of the biased "explode" for executable size
without any figures to back it up. 


Yan

[toc] | [prev] | [next] | [standalone]

#9226

Yannick Tremblay <yatremblay@bel1lin202.(none)> wrote:
> Implement a generic container using void *.  That way, your code size
> will be a few % points smaller.

  That's actually how generic containers are implemented in most other
OO languages (and even some non-OO ones). Of course it's much safer in
those because the language hides the details behind the safer syntax.

  The problem is that yes, the executable size decreases a bit, but at
the cost of significantly increasing memory consumption (usually by
significantly more than the reduction in binary size). That's because
all the objects have to be allocated dynamically, adding memory
management overhead, and handled through references/pointers (which
are inexistent when dealing with objects by value, as in the case
of a std::vector having objects as elements).

  (As a side-effect of this the data container becomes polymorphic,
which is sometimes nice, but in practice this is actually needed much
less frequently than containers with uniform elements.)

  When people complain about the executable size growing, they seldom
seem to offer a viable alternative that wouldn't trade executable size
with an order of magnitude or two of increased memory usage.

[toc] | [prev] | [next] | [standalone]

#9169

In article <4e516d11$0$7610$9b4e6d93@newsspool1.arcor-online.net>,
Marcel Müller  <news.5.maazl@spamgourmet.org> wrote:
>On 20.08.11 18.36, Leigh Johnston wrote:
>> On 20/08/2011 17:26, A wrote:
>>>> SomeClass* array = new SomeClass[10];
>>>>
>>>> size_t length = get_length_of_array(array); // Impossible
>>>
>>> any particular reason you don't want to use vector instead and then use
>>> vect::size ?
>
>- The old platform does not support STL well.

Really?  What's that old platform?  I was using the STL in
old compilers in the last century simply by adding STLPort to the
project. 

>- STL causes the executable size to explode. One disadvantage of 
>template meta programming over generics. (Of course, there are many 
>advantages on the other side.)

"Explode" is a bit strong.  But yes, it will increase a bit but you
seem to totally ignore the "Of course, there are many advantages on
the other side."   Don't just say it.  Seriously consider it.

>> Yes, well said. std::vector should be preferred over dynamic arrays for
>> most cases;
>
>std::vector has the major disadvantage that any piece of code that has 
>write access to its elements can also change its size and, more 
>importantly, cause reallocations. That's sometimes not wanted and could 
>cause hard to find bugs with UB, especially if the array is shared 
>between threads.

Euh, how is it different from raw dynamic arrays?  They have been
source of hard to find bugs for as long as programming has existed.
Bad programming is bad programming.  At least std::vector gives you
the tools to encourage or event enforce better programming.

The problems you list above can be handled simply be controlling
access (using const by default unless write access is needed) or as
proposed elsewhere by offering a more constrained interface via
composition.

If you really share raw arrays between threads directly, I suggest that
you have a much more fundamental problem to address that the possible
reallocation that a std::vector may do.  

Yan

[toc] | [prev] | [next] | [standalone]

#9200

none Yannick Tremblay wrote:
>> - The old platform does not support STL well.
> 
> Really?  What's that old platform?  I was using the STL in
> old compilers in the last century simply by adding STLPort to the
> project. 

IBM Visual Age C++ 3.0. AFAIR around 1996. Some fixes are from 1999.
The template support of this old compiler is surprisingly good. But it 
can't parse "using" nor "namespace".

>> - STL causes the executable size to explode. One disadvantage of 
>> template meta programming over generics. (Of course, there are many 
>> advantages on the other side.)
> 
> "Explode" is a bit strong.  But yes, it will increase a bit but you
> seem to totally ignore the "Of course, there are many advantages on
> the other side."   Don't just say it.  Seriously consider it.

It is not an option because of the above restriction.


>>> Yes, well said. std::vector should be preferred over dynamic arrays for
>>> most cases;
>> std::vector has the major disadvantage that any piece of code that has 
>> write access to its elements can also change its size and, more 
>> importantly, cause reallocations. That's sometimes not wanted and could 
>> cause hard to find bugs with UB, especially if the array is shared 
>> between threads.
> 
> Euh, how is it different from raw dynamic arrays?  They have been
> source of hard to find bugs for as long as programming has existed.

Not if you keep track of their size with a small wrapper class. Boundary 
checks could be restricted to debug builds.

It is a long time ago when I had occasionally problems with UB because 
of out of bounds data access. Using reasonable string classes solved 
many of the problems, consequently using smart pointers fixed the rest. 
I prefer smart pointers for non-resizable array types that keep track of 
the size. But they always need to allocate an additional word for the 
size. That's why asked the question. The smart array pointer can only 
take objects that can be destroyed by delete[] anyway.


> The problems you list above can be handled simply be controlling
> access (using const by default unless write access is needed) or as

Of course I use const frequently. But I also like lock-free data 
structures. They really dislike to be moved around in memory. 
Nevertheless, at the first glance they happen to work, but with ugly 
race conditions waiting to fire.

> proposed elsewhere by offering a more constrained interface via
> composition.

Yes. But this is much of work, and I am a bit lazy too.


> If you really share raw arrays between threads directly, I suggest that
> you have a much more fundamental problem to address that the possible
> reallocation that a std::vector may do.

No serious problem, if the elements are of atomic size (pointer to 
something, including intrusive smart pointers). With a few tricks you 
will even get strong thread safety this way. And if your favorite string 
class works this way too, you have a lock-free, fully thread-safe array 
of strings. Well, as long as you do not move it around.

Similar things apply to array elements that are heavy weight or 
non-copyable. I prefer not to move objects around in memory. In fact 
many of them are non-copyable. This is a no-go for std::vector. AFAIK 
even if you don't use the dynamic resizing.
OK, most of the time complex and non-copyable objects should be used as 
reference objects.

Another point is temporary storage in an algorithms. In this cases the 
array size usually will not change, once it is constructed. Even tough 
vector will do the job, I prefer fixed size array classes for this 
purpose. The tell the reader more, namely that they are not intended to 
grow (or shrink) somewhere in the backwaters of the code.


Marcel

[toc] | [prev] | [next] | [standalone]

#9369

On Aug 20, 9:36 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 20/08/2011 17:26, A wrote:
>
> >> SomeClass* array = new SomeClass[10];
>
> >> size_t length = get_length_of_array(array); // Impossible
>
> > any particular reason you don't want to use vector instead and then use
> > vect::size ?
>
> Yes, well said.  std::vector should be preferred over dynamic arrays for
> most cases; about the only case where one still needs to use dynamic
> arrays is if you want to allocate but not initialize a buffer.

std::vector<AType> vect;
vect.reserve(100);

There you go.  Space is allocated but not initialized.

[toc] | [prev] | [next] | [standalone]

#9371

On 27/08/2011 21:30, Noah Roberts wrote:
> On Aug 20, 9:36 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 20/08/2011 17:26, A wrote:
>>
>>>> SomeClass* array = new SomeClass[10];
>>
>>>> size_t length = get_length_of_array(array); // Impossible
>>
>>> any particular reason you don't want to use vector instead and then use
>>> vect::size ?
>>
>> Yes, well said.  std::vector should be preferred over dynamic arrays for
>> most cases; about the only case where one still needs to use dynamic
>> arrays is if you want to allocate but not initialize a buffer.
>
> std::vector<AType>  vect;
> vect.reserve(100);
>
> There you go.  Space is allocated but not initialized.

Don't be thick.  Space is allocated yes but the vector logically has no 
elements and you cannot write to that allocated space without first 
creating elements in that space.  With the array you can directly write 
to the uninitialized space.

/Leigh

[toc] | [prev] | [next] | [standalone]

#9162

On Aug 20, 2:01 pm, Marcel Müller <news.5.ma...@spamgourmet.org>
wrote:

> AFAIK it is impossible to detect the original length of an array from
> the object pointer.
>
> class SomeClass
> { // ...
>
> };
>
> SomeClass* array = new SomeClass[10];
>
> size_t length = get_length_of_array(array); // Impossible
>
> But the runtime needs to keep track of the number of elements anyway, to
> call the appropriate number of destructors at delete[]. Why does the
> language not allow to access this internal field?

1. backwards compatibility with C
2. new may allocate more memory than specified (though to call the
right number of DTORs it needs to know how many objects are actually
allocated)
3. no way to distinguish new'ed from other allocations


void fred(T* a)
{
    for (i = 0; i < get_length_of_array(a); i++)
        do_stuff (a[i]);
}

this won't work for

   a = (T*)malloc(n*sizeof(a));
   T a[n];

[toc] | [prev] | [next] | [standalone]

#9370

The length of the allocated array must be stored somewhere
by new so that delete[] knows how many destructors to call.
But theres no standard way to get this length.

[toc] | [prev] | [next] | [standalone]

#9377

On Aug 27, 1:35 pm, Gerald Breuer <Gerald.Bre...@Use-Author-Supplied-
Address.invalid> wrote:
> The length of the allocated array must be stored somewhere
> by new so that delete[] knows how many destructors to call.
> But theres no standard way to get this length.

That is not completely correct.  You can override the new operator to
use an allocator that will provide you with that information.  This
would all indeed be quite within the standard.  It is also, of course,
why there can never be a *generic* method of accessing this
information.

[toc] | [prev] | [next] | [standalone]

#9392

Noah Roberts <roberts.noah@gmail.com> wrote in news:74a0f16a-95f8-4b9c-
9e30-e4d868be2df5@t30g2000prm.googlegroups.com:

> On Aug 27, 1:35 pm, Gerald Breuer <Gerald.Bre...@Use-Author-Supplied-
> Address.invalid> wrote:
>> The length of the allocated array must be stored somewhere
>> by new so that delete[] knows how many destructors to call.
>> But theres no standard way to get this length.
> 
> That is not completely correct.  You can override the new operator to
> use an allocator that will provide you with that information.  This
> would all indeed be quite within the standard.  It is also, of course,
> why there can never be a *generic* method of accessing this
> information.

It's not so trivial. The argument the operator new[] is called with does 
not specify the number of objects; it specifies the number of bytes to 
allocate. This can include unknown amount of extra memory used by the 
implementation, which most probably varies for different types and can in 
principle vary for each invocation. Demo:

#include <iostream>

class A {
public:
	void *__cdecl operator new[](size_t n) {
		std::cout << "A::operator new: n=" << n << ", overhead=" << n-
100*sizeof(A) <<" bytes\n";
		return ::operator new[](n);
	}
	~A() {}
};

class B {
public:
	void *__cdecl operator new[](size_t n) {
		std::cout << "B::operator new: n=" << n << ", overhead=" << n-
100*sizeof(B) <<" bytes\n";
		return ::operator new[](n);
	}
	~B() {}
private:
	double x;
};

class C {
public:
	void *__cdecl operator new[](size_t n) {
		std::cout << "C::operator new: n=" << n << ", overhead=" << n-
100*sizeof(C) <<" bytes\n";
		return ::operator new[](n);
	}
private:
	double x;
};

int main() {
	A* a = new A[100];
	B* b = new B[100];
	C* c = new C[100];
}


--- output ---
A::operator new: n=104, overhead=4 bytes
B::operator new: n=808, overhead=8 bytes
C::operator new: n=800, overhead=0 bytes

[toc] | [prev] | [next] | [standalone]

#9401

Gerald Breuer wrote:
> The length of the allocated array must be stored somewhere
> by new so that delete[] knows how many destructors to call.
> But theres no standard way to get this length.

So the standard decided to provide std::vector instead of trying to 
fix the broken C style arrays.


Bo Persson

[toc] | [prev] | [next] | [standalone]

#9403

Am 28.08.2011 16:38, schrieb Bo Persson:

> So the standard decided to provide std::vector instead of trying to
> fix the broken C style arrays.

There's nothing broken with C style arrays.

[toc] | [prev] | [next] | [standalone]

#9416

Gerald Breuer wrote:
> Am 28.08.2011 16:38, schrieb Bo Persson:
>
>> So the standard decided to provide std::vector instead of trying to
>> fix the broken C style arrays.
>
> There's nothing broken with C style arrays.

Right, except that people try to determine their length?


Bo Persson

[toc] | [prev] | [next] | [standalone]

#9417

Am 28.08.2011 22:44, schrieb Bo Persson:

>> There's nothing broken with C style arrays.

> Right, except that people try to determine their length?

A missing functionality doesn't make something broken.

[toc] | [prev] | [next] | [standalone]

#9431

On Aug 28, 3:49 pm, Gerald Breuer <Gerald.Bre...@Use-Author-Supplied-
Address.invalid> wrote:
> Am 28.08.2011 16:38, schrieb Bo Persson:

> > So the standard decided to provide std::vector instead of trying to
> > fix the broken C style arrays.

> There's nothing broken with C style arrays.

Except that they're not first class types.   C uses value
semantics for objects (C++ too, by default).  Except when the
object is an array, in which case, there is an implicit
conversion to an unrelated type (except when there isn't).

--
James Kanze

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web