C Array VS C++ Array??

[vib.cpp]

Is there any new features added to the chapter of 'array', I read
though this chapter and do not see much new items different from C
language;

 

[amrollahi.saeed]

Is there any new features added to the chapter of 'array', I read
though this chapter and do not see much new items different from C
language;

Hi

AFAIK, there is no major addition or extension to C array. Of course I
found an item
in TheC++PL special edition by B. Stroustrup:
"Taking a pointer to the element one beyond the end of an array is
guaranteed to work.
This is important for many algorithms".
As you may be know the genric algorithms located in STL works with
standard containers (vector, map, ...)
and built-in arrays. Thease algorithms/containers implemented by a
pair iterators (begin() and end()) and end()
points to one-beyond-the-last element. So for built-in arrays the one-
beyond-the-end-of-array has special
meaning.
The advanced usage of arrays are appeared in standard containers like
vector, list and map, and they are really
major additions to C array.

Regards,
Saeed Amrollahi

 

[Maxim Yegorushkin]

Don't know which book you are reading, but C arrays are to a large extent
superseded by std::vector

C-array and std::vector<> are quite different beasts.

The most important difference is that std::vector<> always stores
elements in a heap allocated array, whereas C-style array can be
allocated statically, on the stack and the heap.

and other STL containers in C++.

This is tr1::array<> which can be said to supersede C-style array.

 

[red floyd]

On Jan 5, 7:59 am, Paavo Helde <[email protected]> wrote:

The most important difference is that std::vector<> always stores
elements in a heap allocated array, whereas C-style array can be
allocated statically, on the stack and the heap.

Not quite true. If you use the default allocator, then yes. But you
can define a custom
allocator which doesn't use free store, and declare

std::vector<T, my_allocator> v;

 

[Maxim Yegorushkin]

Not quite true.  If you use the default allocator, then yes.  But you
can define a custom
allocator which doesn't use free store, and declare

std::vector<T, my_allocator> v;

You are quite correct.

Speaking practically, however, when you have a block of memory
allocated somehow, it is rather unlikely that you would want to wrap
it in an std::vector<> with a custom allocator simply because there
may be no good reason to do so. Due to the custom allocator that
vector will be incompatible with existing interfaces that accept
std::vector<T> with the default allocator, for example. Or am I
missing something?

 

[Maxim Yegorushkin]

I disagree.  This is absolutely not the most important difference.

http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1

The heap vs stack allocated is a rather secondary difference.

It depends on the application domain.

In desktop application development programmers productivity may be
more important than application performance. (In that case you may
even prefer using some other language).

In real-time application development performance is paramount and, as
you may well know, dynamic memory allocation is one of the four major
performance killers (the other free being data copying, lock
contention and context switching).

The most common reason to allocate statically on the stack an array
in C is so that you don't need to manage the memory.

Not really. There is simply no point of using heap allocated memory
when a stack-allocated C-style array is enough.

This is taken care
for you by std::vector<>.  If you still really really need for the
data to be on the stack, you can use a self defined allocator as
suggested.  

Are you suggesting using std::vector<> with a custom allocator to
allocate arrays on the stack?

 

[Noah Roberts]

tr1::array came much later and has fixed length, so it's poorer
featurewise than std::vector.

Again, quite different beasts. tr1::array allocates on the stack and
allows {} initialization. I could say that means std::vector is poorer,
featurewise, but that would be as fallacious as your claim.

 

[Noah Roberts]

An ordinary C array can be created on stack, and initialized with {}, so I
do not quite see any new features introduced by C++ here ;-)

Sorry to hear that. Perhaps you should look into the object a bit more.