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 1 of 3  [1] 2 3  Next page →

#9110 — Length of C++ arrays allocated by operator new[]

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?


Marcel

[toc] | [next] | [standalone]

#9113

On 8/20/11 9:01 AM, Marcel Müller 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?
>
>
> Marcel


Because array could also have been set by:

class SomeClass
{ //
};

SomeClass element;

SomeClass* array = &element;


or you could have even changed you example to have been

SomeClass* array = (new SomeClass[10])[4];


In either of these cases there is no "length" to get.

Also, the runtime isn't always required to keep track of how many 
elements are in the array, if SomeClass has a trivial destructor (like 
all of its members are base types and no explicit destructor is defined) 
than by the "as-if" rule, the run time doesn't need to know or store the 
number of elements (new probably still needs to somewhere store the 
allocation size for delete, but that is a different issue).

Allowing this help minimize the overhead in things like new char[10]

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

#9135

On 20.08.11 17.39, Richard Damon wrote:
>> 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?
>
> Because array could also have been set by:
>
> class SomeClass
> { //
> };
>
> SomeClass element;
>
> SomeClass* array = &element;
>
>
> or you could have even changed you example to have been
>
> SomeClass* array = (new SomeClass[10])[4];
>
>
> In either of these cases there is no "length" to get.

Fine. But requesting the length of all these objects is no more 
undefined behavior than applying delete[] to them. I only expect a 
reasonable length information if I could use operator delete[]. In all 
other cases it would be obviously a serious overhead.


> Also, the runtime isn't always required to keep track of how many
> elements are in the array, if SomeClass has a trivial destructor (like
> all of its members are base types and no explicit destructor is defined)
> than by the "as-if" rule, the run time doesn't need to know or store the
> number of elements (new probably still needs to somewhere store the
> allocation size for delete, but that is a different issue).

I am in doubt if any recent implementation uses anything else than the 
allocation size for the invocation of the destructors.


> Allowing this help minimize the overhead in things like new char[10]

That's the point. I see no additional overhead.


Marcel

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

#9178

On 8/21/11 4:15 PM, Marcel Müller wrote:
> On 20.08.11 17.39, Richard Damon wrote:
>>> 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?
>>
>> Because array could also have been set by:
>>
>> class SomeClass
>> { //
>> };
>>
>> SomeClass element;
>>
>> SomeClass* array = &element;
>>
>>
>> or you could have even changed you example to have been
>>
>> SomeClass* array = (new SomeClass[10])[4];
>>
>>
>> In either of these cases there is no "length" to get.
>
> Fine. But requesting the length of all these objects is no more
> undefined behavior than applying delete[] to them. I only expect a
> reasonable length information if I could use operator delete[]. In all
> other cases it would be obviously a serious overhead.
>
>
>> Also, the runtime isn't always required to keep track of how many
>> elements are in the array, if SomeClass has a trivial destructor (like
>> all of its members are base types and no explicit destructor is defined)
>> than by the "as-if" rule, the run time doesn't need to know or store the
>> number of elements (new probably still needs to somewhere store the
>> allocation size for delete, but that is a different issue).
>
> I am in doubt if any recent implementation uses anything else than the
> allocation size for the invocation of the destructors.
>
>
>> Allowing this help minimize the overhead in things like new char[10]
>
> That's the point. I see no additional overhead.
>
>
> Marcel

For no overhead, since the C++ specification currently does NOT require 
that new char[10] save the number of elements allocated (since char has 
a trivial destructor which can thus be elided) adding an operator that 
returns the number of elements from such a allocation would now add that 
overhead to such an allocation.

Also, remember that new[] can be user defined, so to add an array size 
operator like this would require that classes that use a user defined 
operator new[] would also need to provide their own version of this new 
length operator (admittedly, unless they knew their destructor was 
trivial and thus able to be elided they would have to have stored it 
somewhere too)

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

#9202

Richard Damon wrote:
> For no overhead, since the C++ specification currently does NOT require 
> that new char[10] save the number of elements allocated (since char has 
> a trivial destructor which can thus be elided) adding an operator that 
> returns the number of elements from such a allocation would now add that 
> overhead to such an allocation.

Well, I guess any implementation of the memory management must keep 
track of the total size for other reasons.


> Also, remember that new[] can be user defined,

But you are right. This is a show stopper. It will prohibit any internal 
interaction between the C++ runtime library and the standard allocator. 
Now you are back to the char[10] problem above.


Marcel

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

#9115

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?
>
You could cast the return from new into a pointer of type... Someclass
(*p)[10].

HTH.

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

#9118

On Aug 20, 5:20 pm, Paul <pchris...@yahoo.co.uk> wrote:
> 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?
>
> You could cast the return from new into a pointer of type... Someclass
> (*p)[10].
>
An example:

struct Someclass{};

template<typename T, size_t N>
void foo(T(&t)[N] ){
	std::cout<<"The array is of size "<<N<<std::endl;
}

int main() {
	Someclass(*p)[10] = reinterpret_cast<Someclass(*)[10]>(new
Someclass[10]);
	foo(*p);
	//p needs to be dereferenced.

	//Create a ref and no need to dereference, see below.
	Someclass(&r)[10] = *p;
	foo(r);

	delete[] p;
}

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

#9154

On 08/20/2011 01:38 PM, Paul wrote:
> void foo(T(&t)[N] ){


what is &t?

You have no t object to address.

Ruben

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

#9163

On Aug 22, 3:33 am, ruben safir <ru...@mrbrklyn.com> wrote:
> On 08/20/2011 01:38 PM, Paul wrote:
>
> > void foo(T(&t)[N] ){
>
> what is &t?
>
> You have no t object to address.
>
> Ruben


This function take one argument of type T(&)[N]. A referernce to an
array of N T's
It doesn't take the address of t , t is the function param name.

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

#9211

On 08/22/2011 06:05 AM, Paul wrote:
> On Aug 22, 3:33 am, ruben safir<ru...@mrbrklyn.com>  wrote:
>> On 08/20/2011 01:38 PM, Paul wrote:
>>
>>> void foo(T(&t)[N] ){
>>
>> what is&t?
>>
>> You have no t object to address.
>>
>> Ruben
>
>
> This function take one argument of type T(&)[N]. A referernce to an
> array of N T's
> It doesn't take the address of t , t is the function param name.


I don't know how your parsing that, but if you wrote that code, I'd 
likely fire you.

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

#9213

On Aug 23, 1:05 am, ruben safir <ru...@mrbrklyn.com> wrote:
> On 08/22/2011 06:05 AM, Paul wrote:
>
> > On Aug 22, 3:33 am, ruben safir<ru...@mrbrklyn.com>  wrote:
> >> On 08/20/2011 01:38 PM, Paul wrote:
>
> >>> void foo(T(&t)[N] ){
>
> >> what is&t?
>
> >> You have no t object to address.
>
> >> Ruben
>
> > This function take one argument of type T(&)[N]. A referernce to an
> > array of N T's
> > It doesn't take the address of t , t is the function param name.
>
> I don't know how your parsing that, but if you wrote that code, I'd
> likely fire you.

Personally I think you should be fired for thinking a reference to an
array is taking the address of a non-existent object.

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

#9215

ruben safir wrote:

> On 08/22/2011 06:05 AM, Paul wrote:
>> On Aug 22, 3:33 am, ruben safir<ru...@mrbrklyn.com>  wrote:
>>> On 08/20/2011 01:38 PM, Paul wrote:
>>>
>>>> void foo(T(&t)[N] ){
>>>
>>> what is&t?
>>>
>>> You have no t object to address.
>>>
>>> Ruben
>>
>>
>> This function take one argument of type T(&)[N]. A referernce to an
>> array of N T's
>> It doesn't take the address of t , t is the function param name.
> 
> 
> I don't know how your parsing that, but if you wrote that code, I'd
> likely fire you.

If you can't parse that, maybe _you_ should be fired? Seriously, this 
continuous bragging of putative "code reviewers" about their small position 
of power is annoying.

I must say I'm glad that I'm not in the coding business and the opinion of 
people like you costs me not more than an shrug.

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

#9344

On Aug 23, 1:05 am, ruben safir <ru...@mrbrklyn.com> wrote:
> On 08/22/2011 06:05 AM, Paul wrote:

> > On Aug 22, 3:33 am, ruben safir<ru...@mrbrklyn.com>  wrote:
> >> On 08/20/2011 01:38 PM, Paul wrote:

> >>> void foo(T(&t)[N] ){

> >> what is&t?

> >> You have no t object to address.

> > This function take one argument of type T(&)[N]. A referernce to an
> > array of N T's
> > It doesn't take the address of t , t is the function param name.

> I don't know how your parsing that, but if you wrote that code, I'd
> likely fire you.

That code is a standard idiom, and I can't imagine a C++
application which didn't contain at least one instance of it.
(The most frequent use is now part of the standard library, but
it was in everyone's tool kit before that.)

--
James Kanze

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

#9348

On Aug 26, 8:29 am, James Kanze <james.ka...@gmail.com> wrote:
> On Aug 23, 1:05 am, ruben safir <ru...@mrbrklyn.com> wrote:
>
> > On 08/22/2011 06:05 AM, Paul wrote:
> > > On Aug 22, 3:33 am, ruben safir<ru...@mrbrklyn.com>  wrote:
> > >> On 08/20/2011 01:38 PM, Paul wrote:
> > >>> void foo(T(&t)[N] ){
> > >> what is&t?
> > >> You have no t object to address.
> > > This function take one argument of type T(&)[N]. A referernce to an
> > > array of N T's
> > > It doesn't take the address of t , t is the function param name.
> > I don't know how your parsing that, but if you wrote that code, I'd
> > likely fire you.
>
> That code is a standard idiom, and I can't imagine a C++
> application which didn't contain at least one instance of it.
> (The most frequent use is now part of the standard library, but
> it was in everyone's tool kit before that.)

It's something that should be known for sure, but it's really not all
that common from what I've seen.

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

#9119

Paul <pchristor@yahoo.co.uk> wrote:
> 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?
>>
> You could cast the return from new into a pointer of type... Someclass
> (*p)[10].

  Exactly how does that help determining how many elements there are in
a dynamically allocated array?

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

#9120

On Aug 20, 6:55 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Paul <pchris...@yahoo.co.uk> wrote:
> > 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?
>
> > You could cast the return from new into a pointer of type... Someclass
> > (*p)[10].
>
>   Exactly how does that help determining how many elements there are in
> a dynamically allocated array?- Hide quoted text -
>
See the example I added.

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

#9122

[Please do not mail me a copy of your followup]

Juha Nieminen <nospam@thanks.invalid> spake the secret code
<4e4ff518$0$3063$7b1e8fa0@news.nbl.fi> thusly:

>  Exactly how does that help determining how many elements there are in
>a dynamically allocated array?

If the number of elements in the array is known at compile time, the
size of the array can then be known at compile time as long as the
size of the array is included in the type signature for a pointer to
the elements.

If the number of elements allocated is determined at runtime, then the
type signature can't know how many elements are in the array and
template tricks can't determine it either.

If you have fixed sized arrays that are dynamically allocated, then
you can use the type signature/template trick to determine the number
of elements.

If you have variable sized arrays that are dynamically allocated, then
use std::vector and access the element count with the size member.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

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

#9116

> 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 ? 

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

#9117

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.

HTH.

/Leigh

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

#9136

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.
- 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.)

> 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.

> about the only case where one still needs to use dynamic
> arrays is if you want to allocate but not initialize a buffer.

Why? vector will always initialize /less/ or same than operator new[]. 
The allocation size of the vector may be larger than logical size, 
containing additional uninitialized storage. new[] in contrast always 
invokes the standard constructors (if any).


Marcel

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web