Re: Length of C++ arrays allocated by operator new[]
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