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

#9138

On 08/22/11 08:39 AM, Marcel Müller 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.
> - STL causes the executable size to explode.

Only if you have a very poor linker.

> One disadvantage of
> template meta programming over generics. (Of course, there are many
> advantages on the other side.)

Who mentioned template meta-programming?

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

Then derived privately and only expose a subset of members.  Or simply 
write your own array class.  Either way, the "avoid naked arrays" rule 
of thumb is still valid.

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

So does vector's sized constructor.

-- 
Ian Collins

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

#9139

On 21/08/2011 21:39, Marcel Müller 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.

I don't care about old platforms unless I am being paid to care about 
old platforms.

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

Template code bloat is mostly over stated; non-template classes with 
lots of inline functions can have similar "bloat".

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

If you are worried about clients changing a vector's size then don't 
expose the vector by, for example, using private inheritance (as Ian 
said in his reply) or composition.  Reallocation behaviour of vectors is 
well known; don't blame the tools for sloppy programming.

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

Wrong; for POD and built-in types new[] can allocate storage but not 
initialize it at all; whilst a vector with N elements will have 
initialized them all: don't confuse vector::reserve with vector::resize. 
  You can not write directly to the reserved but unused (uninitialised) 
storage of a vector; you can only write to vector::size() elements.

/Leigh

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

#9140

On 21.08.11 23.32, Leigh Johnston wrote:
>> - The old platform does not support STL well.
>
> I don't care about old platforms unless I am being paid to care about
> old platforms.

:-)

>> - 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.)
>
> Template code bloat is mostly over stated; non-template classes with
> lots of inline functions can have similar "bloat".

That's not what I mean. The most bloat comes from different 
instantiations of template classes that in fact produce binary the same 
code. E.g. std::vector will most likely result in identical code for all 
pointer types (except for member function pointers, of course).

At least I have not seen a compiler that can share code between 
different template instantiations.


>> 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.
>
> If you are worried about clients changing a vector's size then don't
> expose the vector by, for example, using private inheritance (as Ian
> said in his reply) or composition.

I ended up with my own class, which is trivial for arrays that are not 
resizable.


>>> 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).
>
> Wrong; for POD and built-in types new[] can allocate storage but not
> initialize it at all; whilst a vector with N elements will have
> initialized them all:

So vector<char> initializes the storage? To zero I guess. I was not 
aware of that.


Marcel

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

#9143

On 21/08/2011 23:01, Marcel Müller wrote:
> On 21.08.11 23.32, Leigh Johnston wrote:
>>> - The old platform does not support STL well.
>>
>> I don't care about old platforms unless I am being paid to care about
>> old platforms.
>
> :-)
>
>>> - 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.)
>>
>> Template code bloat is mostly over stated; non-template classes with
>> lots of inline functions can have similar "bloat".
>
> That's not what I mean. The most bloat comes from different
> instantiations of template classes that in fact produce binary the same
> code. E.g. std::vector will most likely result in identical code for all
> pointer types (except for member function pointers, of course).
>
> At least I have not seen a compiler that can share code between
> different template instantiations.

That is the price you pay for not having to lose type information 
however you can have a std::vector<void*> if you want.  Template bloat 
is less of a concern these days due to increased memory and storage 
capacities even on smaller devices such as mobile phones.

>
>
>>> 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.
>>
>> If you are worried about clients changing a vector's size then don't
>> expose the vector by, for example, using private inheritance (as Ian
>> said in his reply) or composition.
>
> I ended up with my own class, which is trivial for arrays that are not
> resizable.
>
>
>>>> 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).
>>
>> Wrong; for POD and built-in types new[] can allocate storage but not
>> initialize it at all; whilst a vector with N elements will have
>> initialized them all:
>
> So vector<char> initializes the storage? To zero I guess. I was not
> aware of that.

It initializes *elements* in that storage:

std::vector<char> v(100); // will have 100 chars of value 0
char* a = new char[100]; // will have 100 uninitialized chars

/Leigh

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

#9144

On 08/22/11 11:04 AM, Leigh Johnston wrote:
> On 21/08/2011 23:01, Marcel Müller wrote:
>> On 21.08.11 23.32, Leigh Johnston wrote:
>>>
>>> Template code bloat is mostly over stated; non-template classes with
>>> lots of inline functions can have similar "bloat".
>>
>> That's not what I mean. The most bloat comes from different
>> instantiations of template classes that in fact produce binary the same
>> code. E.g. std::vector will most likely result in identical code for all
>> pointer types (except for member function pointers, of course).
>>
>> At least I have not seen a compiler that can share code between
>> different template instantiations.
>
> That is the price you pay for not having to lose type information
> however you can have a std::vector<void*>  if you want.  Template bloat
> is less of a concern these days due to increased memory and storage
> capacities even on smaller devices such as mobile phones.

You don't even gave to loose type safety if you specialise vector for 
void* and derive privately from there.

-- 
Ian Collins

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

#9149

On 22/08/2011 00:38, Ian Collins wrote:
> On 08/22/11 11:04 AM, Leigh Johnston wrote:
>> On 21/08/2011 23:01, Marcel Müller wrote:
>>> On 21.08.11 23.32, Leigh Johnston wrote:
>>>>
>>>> Template code bloat is mostly over stated; non-template classes with
>>>> lots of inline functions can have similar "bloat".
>>>
>>> That's not what I mean. The most bloat comes from different
>>> instantiations of template classes that in fact produce binary the same
>>> code. E.g. std::vector will most likely result in identical code for all
>>> pointer types (except for member function pointers, of course).
>>>
>>> At least I have not seen a compiler that can share code between
>>> different template instantiations.
>>
>> That is the price you pay for not having to lose type information
>> however you can have a std::vector<void*> if you want. Template bloat
>> is less of a concern these days due to increased memory and storage
>> capacities even on smaller devices such as mobile phones.
>
> You don't even gave to loose type safety if you specialise vector for
> void* and derive privately from there.

Indeed but pointers are not always the answer; the convenience and 
possible performance characteristics of using a container as a container 
of value type tend to outweigh concerns of code bloat these days IMHO 
(assuming I am not writing code for a £20 toaster).

/Leigh

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

#9150

On 08/22/11 12:14 PM, Leigh Johnston wrote:
> On 22/08/2011 00:38, Ian Collins wrote:
>> On 08/22/11 11:04 AM, Leigh Johnston wrote:
>>> On 21/08/2011 23:01, Marcel Müller wrote:
>>>> On 21.08.11 23.32, Leigh Johnston wrote:
>>>>>
>>>>> Template code bloat is mostly over stated; non-template classes with
>>>>> lots of inline functions can have similar "bloat".
>>>>
>>>> That's not what I mean. The most bloat comes from different
>>>> instantiations of template classes that in fact produce binary the same
>>>> code. E.g. std::vector will most likely result in identical code for all
>>>> pointer types (except for member function pointers, of course).
>>>>
>>>> At least I have not seen a compiler that can share code between
>>>> different template instantiations.
>>>
>>> That is the price you pay for not having to lose type information
>>> however you can have a std::vector<void*>  if you want. Template bloat
>>> is less of a concern these days due to increased memory and storage
>>> capacities even on smaller devices such as mobile phones.
>>
>> You don't even gave to loose type safety if you specialise vector for
>> void* and derive privately from there.
>
> Indeed but pointers are not always the answer; the convenience and
> possible performance characteristics of using a container as a container
> of value type tend to outweigh concerns of code bloat these days IMHO
> (assuming I am not writing code for a £20 toaster).

The £20 toaster is an interesting example.  At least one embedded tool 
chain I've used (Green Hills) when optimising for space will fold 
duplicate machine instructions into calls  Thus all vectors of pointer 
type will generate the same machine code which gets merged.  So the 
specialisation trick is unnecessary!

-- 
Ian Collins

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

#9151

On Aug 22, 12:04 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 21/08/2011 23:01, Marcel Müller wrote:
>
<snip>
> > So vector<char> initializes the storage? To zero I guess. I was not
> > aware of that.
>
> It initializes *elements* in that storage:
>
> std::vector<char> v(100); // will have 100 chars of value 0
> char* a = new char[100]; // will have 100 uninitialized chars
>
You have previoulsy argued that 'a' points to only one single char.
Are you now suggesting that 'a' points to 100 chars?

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

#9152

On 22/08/2011 01:34, Paul wrote:
> On Aug 22, 12:04 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 21/08/2011 23:01, Marcel Müller wrote:
>>
> <snip>
>>> So vector<char>  initializes the storage? To zero I guess. I was not
>>> aware of that.
>>
>> It initializes *elements* in that storage:
>>
>> std::vector<char>  v(100); // will have 100 chars of value 0
>> char* a = new char[100]; // will have 100 uninitialized chars
>>
> You have previoulsy argued that 'a' points to only one single char.
> Are you now suggesting that 'a' points to 100 chars?

"will have" does not mean "points to"; 'a' points to the first of 100 
uninitialized chars; 'a' points into an array of 100 uninitialized chars.

Also in the old thread on this topic I did say that I found the relaxed 
(i.e. not technically accurate) language of "points to an array" 
acceptable but not "pointer to an array".

Also I don't feel like trolling trolls today.

/Leigh

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

#9153

On Aug 22, 1:39 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 22/08/2011 01:34, Paul wrote:
>
> > On Aug 22, 12:04 am, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 21/08/2011 23:01, Marcel Müller wrote:
>
> > <snip>
> >>> So vector<char>  initializes the storage? To zero I guess. I was not
> >>> aware of that.
>
> >> It initializes *elements* in that storage:
>
> >> std::vector<char>  v(100); // will have 100 chars of value 0
> >> char* a = new char[100]; // will have 100 uninitialized chars
>
> > You have previoulsy argued that 'a' points to only one single char.
> > Are you now suggesting that 'a' points to 100 chars?
>
> "will have" does not mean "points to"; 'a' points to the first of 100
> uninitialized chars; 'a' points into an array of 100 uninitialized chars.
>
> Also in the old thread on this topic I did say that I found the relaxed
> (i.e. not technically accurate) language of "points to an array"
> acceptable but not "pointer to an array".
>
With a sequence you have a start point, an end point and all the rest
inbetween. The term "pointing  into an array" suggests that it's
pointing to somewhere inbetween the start and end points(non
inclusive).

I think your terminology is confusing what seems to be a simple
contextual difference in the term "is a pointer to" where it can mean
either:
"is a pointer to X memory" or "is a pointer of type pointer to T".

'a' points to the allocated memory. The allocated memory is freed by:
delete[] a;
I think it's techincally inaccurate to suggest that 'a' doesn't point
to the allocated memory(which is an array of chars).

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

#9165

On 22/08/2011 02:13, Paul wrote:
> On Aug 22, 1:39 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 22/08/2011 01:34, Paul wrote:
>>
>>> On Aug 22, 12:04 am, Leigh Johnston<le...@i42.co.uk>    wrote:
>>>> On 21/08/2011 23:01, Marcel Müller wrote:
>>
>>> <snip>
>>>>> So vector<char>    initializes the storage? To zero I guess. I was not
>>>>> aware of that.
>>
>>>> It initializes *elements* in that storage:
>>
>>>> std::vector<char>    v(100); // will have 100 chars of value 0
>>>> char* a = new char[100]; // will have 100 uninitialized chars
>>
>>> You have previoulsy argued that 'a' points to only one single char.
>>> Are you now suggesting that 'a' points to 100 chars?
>>
>> "will have" does not mean "points to"; 'a' points to the first of 100
>> uninitialized chars; 'a' points into an array of 100 uninitialized chars.
>>
>> Also in the old thread on this topic I did say that I found the relaxed
>> (i.e. not technically accurate) language of "points to an array"
>> acceptable but not "pointer to an array".
>>
> With a sequence you have a start point, an end point and all the rest
> inbetween. The term "pointing  into an array" suggests that it's
> pointing to somewhere inbetween the start and end points(non
> inclusive).

Nonsense; IMO "pointing into an array" includes the first and last elements.

>
> I think your terminology is confusing what seems to be a simple
> contextual difference in the term "is a pointer to" where it can mean
> either:
> "is a pointer to X memory" or "is a pointer of type pointer to T".

IMO "is a pointer to" is a description of type; the key parts of this 
term are the words "is a".

>
> 'a' points to the allocated memory. The allocated memory is freed by:
> delete[] a;
> I think it's techincally inaccurate to suggest that 'a' doesn't point
> to the allocated memory(which is an array of chars).

It is technically accurate to say that 'a' points to the start of the 
allocated array.

/Leigh

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

#9176

On Aug 22, 12:16 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 22/08/2011 02:13, Paul wrote:
>
>
>
>
>
> > On Aug 22, 1:39 am, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 22/08/2011 01:34, Paul wrote:
>
> >>> On Aug 22, 12:04 am, Leigh Johnston<le...@i42.co.uk>    wrote:
> >>>> On 21/08/2011 23:01, Marcel Müller wrote:
>
> >>> <snip>
> >>>>> So vector<char>    initializes the storage? To zero I guess. I was not
> >>>>> aware of that.
>
> >>>> It initializes *elements* in that storage:
>
> >>>> std::vector<char>    v(100); // will have 100 chars of value 0
> >>>> char* a = new char[100]; // will have 100 uninitialized chars
>
> >>> You have previoulsy argued that 'a' points to only one single char.
> >>> Are you now suggesting that 'a' points to 100 chars?
>
> >> "will have" does not mean "points to"; 'a' points to the first of 100
> >> uninitialized chars; 'a' points into an array of 100 uninitialized chars.
>
> >> Also in the old thread on this topic I did say that I found the relaxed
> >> (i.e. not technically accurate) language of "points to an array"
> >> acceptable but not "pointer to an array".
>
> > With a sequence you have a start point, an end point and all the rest
> > inbetween. The term "pointing  into an array" suggests that it's
> > pointing to somewhere inbetween the start and end points(non
> > inclusive).
>
> Nonsense; IMO "pointing into an array" includes the first and last elements.

This is not what "into" means. To point into something means you point
inside it, which is not the same as pointing to the beginning of it.
>
>
>
> > I think your terminology is confusing what seems to be a simple
> > contextual difference in the term "is a pointer to" where it can mean
> > either:
> > "is a pointer to X memory" or "is a pointer of type pointer to T".
>
> IMO "is a pointer to" is a description of type; the key parts of this
> term are the words "is a".
>
>
>
> > 'a' points to the allocated memory. The allocated memory is freed by:
> > delete[] a;
> > I think it's techincally inaccurate to suggest that 'a' doesn't point
> > to the allocated memory(which is an array of chars).
>
> It is technically accurate to say that 'a' points to the start of the
> allocated array.
>
You say here that it's technically accurate to say that it points to
the beginning of the array.
Yet you have previously said it's technically inaccurate to say that
its pointing to an array.

If it points to an array how can it be inaccurate to say that it's
pointing to an array?
And, what you find not only technically inaccurate but unacceptable,
if it points to an array, how can it not be a pointer to an array?

I think your ideas fundamentally flawed.
The one and only meaning you find acceptable is that of the pointer
type. This is simply a different context and it does not imply the
"what it points to" context is in any way technically inaccurate.
The "what it points to" context is the more commonly used context and
is probably more techincally accurate because to say:
"a is a pointer to a single char" is techincally inaccurate because it
points to a sequnce of chars not one single char.
It would however be technically accurate to say:
"a's type is pointer to char" or " a is a pointer to char type".
Notice that the accurate way to refer to the type context is to use
the word "type", omitting this word naturally implies the "what is
pointed to" context i.e:
"a points to a char" , which implies what is pointed to. The pointer
could be a void pointer or some other type in theory but would
generally be asusmed to be a char* .

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

#9177

On 22/08/2011 17:09, Paul wrote:
> On Aug 22, 12:16 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 22/08/2011 02:13, Paul wrote:
>>
>>
>>
>>
>>
>>> On Aug 22, 1:39 am, Leigh Johnston<le...@i42.co.uk>    wrote:
>>>> On 22/08/2011 01:34, Paul wrote:
>>
>>>>> On Aug 22, 12:04 am, Leigh Johnston<le...@i42.co.uk>      wrote:
>>>>>> On 21/08/2011 23:01, Marcel Müller wrote:
>>
>>>>> <snip>
>>>>>>> So vector<char>      initializes the storage? To zero I guess. I was not
>>>>>>> aware of that.
>>
>>>>>> It initializes *elements* in that storage:
>>
>>>>>> std::vector<char>      v(100); // will have 100 chars of value 0
>>>>>> char* a = new char[100]; // will have 100 uninitialized chars
>>
>>>>> You have previoulsy argued that 'a' points to only one single char.
>>>>> Are you now suggesting that 'a' points to 100 chars?
>>
>>>> "will have" does not mean "points to"; 'a' points to the first of 100
>>>> uninitialized chars; 'a' points into an array of 100 uninitialized chars.
>>
>>>> Also in the old thread on this topic I did say that I found the relaxed
>>>> (i.e. not technically accurate) language of "points to an array"
>>>> acceptable but not "pointer to an array".
>>
>>> With a sequence you have a start point, an end point and all the rest
>>> inbetween. The term "pointing  into an array" suggests that it's
>>> pointing to somewhere inbetween the start and end points(non
>>> inclusive).
>>
>> Nonsense; IMO "pointing into an array" includes the first and last elements.
>
> This is not what "into" means. To point into something means you point
> inside it, which is not the same as pointing to the beginning of it.

Of course it is what into means; if you point at the top item in a box 
you are still pointing into a box.

>>
>>
>>
>>> I think your terminology is confusing what seems to be a simple
>>> contextual difference in the term "is a pointer to" where it can mean
>>> either:
>>> "is a pointer to X memory" or "is a pointer of type pointer to T".
>>
>> IMO "is a pointer to" is a description of type; the key parts of this
>> term are the words "is a".
>>
>>
>>
>>> 'a' points to the allocated memory. The allocated memory is freed by:
>>> delete[] a;
>>> I think it's techincally inaccurate to suggest that 'a' doesn't point
>>> to the allocated memory(which is an array of chars).
>>
>> It is technically accurate to say that 'a' points to the start of the
>> allocated array.
>>
> You say here that it's technically accurate to say that it points to
> the beginning of the array.

Of course; pointing to the first element of an array is equivalent to 
saying pointing to the start of an array.

> Yet you have previously said it's technically inaccurate to say that
> its pointing to an array.

"Pointing to an array" and "pointing to the start of an array" are not 
necessarily the same thing.

>
> If it points to an array how can it be inaccurate to say that it's
> pointing to an array?

Because we are talking about pointers which have a type.

> And, what you find not only technically inaccurate but unacceptable,
> if it points to an array, how can it not be a pointer to an array?

"pointer to an array" is part of a description of a pointer's type.

>
> I think your ideas fundamentally flawed.
> The one and only meaning you find acceptable is that of the pointer
> type. This is simply a different context and it does not imply the
> "what it points to" context is in any way technically inaccurate.

Of course my position is the technically accurate position:

int* p1 = 0; // p1 is a pointer to an int
int (*p2)[42] = 0; // p2 is a pointer to an array of int

> The "what it points to" context is the more commonly used context and
> is probably more techincally accurate because to say:
> "a is a pointer to a single char" is techincally inaccurate because it
> points to a sequnce of chars not one single char.

No; it points to a single char this being dictated by its type.

> It would however be technically accurate to say:
> "a's type is pointer to char" or " a is a pointer to char type".
> Notice that the accurate way to refer to the type context is to use
> the word "type", omitting this word naturally implies the "what is
> pointed to" context i.e:
> "a points to a char" , which implies what is pointed to. The pointer
> could be a void pointer or some other type in theory but would
> generally be asusmed to be a char* .

In your opinion mate; in my opinion "a pointer to an array" is distinct 
from "a pointer to a scalar".

/Leigh

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

#9214

On Aug 22, 9:22 am, Leigh Johnston <le...@i42.co.uk> wrote:
> > This is not what "into" means. To point into something means you point
> > inside it, which is not the same as pointing to the beginning of it.
>
> Of course it is what into means; if you point at the top item in a box
> you are still pointing into a box.

FUUUUUUUUCK YOOOOOOUUUUUUUUUUUU!!!1!!!11

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

#9158

Leigh Johnston <leigh@i42.co.uk> wrote:
> Template bloat 
> is less of a concern these days due to increased memory and storage 
> capacities even on smaller devices such as mobile phones.

  What "template bloat"? Why do people keep repeating this mantra as
if it was a self-evident given?

  Perhaps people get confused by having compiled programs in debug mode,
with the compiler adding debug information into the executable. Template
code tends to produce significantly longer names than basic types.

  However, you don't want to compile a release version with debug info
in the executable, especially on an embedded system.

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

#9167

On 22/08/2011 07:10, Juha Nieminen wrote:
> Leigh Johnston<leigh@i42.co.uk>  wrote:
>> Template bloat
>> is less of a concern these days due to increased memory and storage
>> capacities even on smaller devices such as mobile phones.
>
>    What "template bloat"? Why do people keep repeating this mantra as
> if it was a self-evident given?
>
>    Perhaps people get confused by having compiled programs in debug mode,
> with the compiler adding debug information into the executable. Template
> code tends to produce significantly longer names than basic types.
>
>    However, you don't want to compile a release version with debug info
> in the executable, especially on an embedded system.

Template bloat usually refers to code being emitted for each template 
specialization over and above that emitted inline for, for example, 
inline functions; nothing to do with debug info.

/Leigh

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

#9346

On Aug 22, 4:20 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 22/08/2011 07:10, Juha Nieminen wrote:
>
> > Leigh Johnston<le...@i42.co.uk>  wrote:
> >> Template bloat
> >> is less of a concern these days due to increased memory and storage
> >> capacities even on smaller devices such as mobile phones.
>
> >    What "template bloat"? Why do people keep repeating this mantra as
> > if it was a self-evident given?

I hear you.  I was recently playing with a recursive call metaprogram
that recreates a switch statement...because I had nothing better to
do.  I implemented the switch version, a function address lookup table
version, and the type based metaprogram version.  I compiled all into
ASM and checked out the output.  I'm not an expert on asm by any
measure but I noticed some rather interesting things.  The smallest of
all the versions was the metaprogram version.  Although it and the
switch version ended up being functionally equivelent, the main
section of ASM was exactly the same, the switch version had a lot of
extra stuff going on outside of main that I couldn't figure out what
it was or did, if anything.  It also had function definitions that
were never used, while it the templated output they were discarded.

Completely useless technique to be sure, unless you were in some
embedded environment looking for every ounce of memory space...which
is exactly the kind of people that are scared of C++ "bloat" the most.

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

#9357

On Fri, 26 Aug 2011 09:03:29 -0700, Noah Roberts wrote:

> Completely useless technique to be sure, unless you were in some
> embedded environment looking for every ounce of memory space...which
> is exactly the kind of people that are scared of C++ "bloat" the most.

I'm not so sure. The kind of programmer that likes to consider themselves
a cut above the CRUD-ers worries about C++ bloat. People who actually have
experience with low-level work know that you don't actually know until
you've looked at the assembly.

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

#9161

On Aug 21, 10:32 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 21/08/2011 21:39, Marcel Müller 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.
>
> I don't care about old platforms unless I am being paid to care about
> old platforms.
>
> > - 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.)
>
> Template code bloat is mostly over stated; non-template classes with
> lots of inline functions can have similar "bloat".
>
>
>
> >> 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.
>
> If you are worried about clients changing a vector's size then don't
> expose the vector by, for example, using private inheritance (as Ian
> said in his reply) or composition.  Reallocation behaviour of vectors is
> well known; don't blame the tools for sloppy programming.

or use boost array?


> >> 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).
>
> Wrong; for POD and built-in types new[] can allocate storage but not
> initialize it at all; whilst a vector with N elements will have
> initialized them all: don't confuse vector::reserve with vector::resize.
>   You can not write directly to the reserved but unused (uninitialised)
> storage of a vector; you can only write to vector::size() elements.
>
> /Leigh

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

#9157

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.

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

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

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

csiph-web