std::array and std::vector

[ResidentBiscuit]

Quote from Mark Ruzon @ stackoverflow:

It's called a vector because Alex Stepanov, the designer of the Standard Template Library, was looking for a name to distinguish it from built-in arrays. He admits now that he made a mistake, because mathematics already uses the term 'vector' for a fixed-length sequence of numbers. Now C++0X will compound this mistake by introducing a class 'array' that will behave similar to a mathematical vector.

Am I the only who finds this a little funny?

[zb0S216C]

Funny in what way?

_Wazzak

[rapidcoder]

Now C++0X will compound this mistake by introducing a class 'array' that will behave similar to a mathematical vector.

What?! ROTFL.

// edit: oh, I just checked it, it really isn't a joke - they really made std::array :D

[Catfish2]

What's funny is that GCC (4.7.1) still issues a missing braces warning for stuff like:
std::array<int, 3> ia{1, 2, 3};
Which is supposed to be valid code.

[helios]

To be fair, for such a commonly used type, "vector" is more sensible than "dynamic_array".

[Telion]

I always compile with Wno-missing-braces to fix the array warnings without making my code non-portable.

I find it funny that they "solved" the "problem" of having too many ways to initialize variables by creating a new system that still doesn't always work. Try creating a vector of 10 integers with uniform initialization syntax.

[LB]

Why do languages strive for reverse compatibility when people will use different versions anyway? It's turned Java into a mess and made C++ seem scary to those new to programming.

My point is, they should've swapped std::vector and std::array's names in C++11 so that people would have to write programs to update their C++03 code to C++11 :D

[Cubbi]

Catfish2 wrote:

What's funny is that GCC (4.7.1) still issues a missing braces warning for stuff like:
std::array<int, 3> ia{1, 2, 3};
Which is supposed to be valid code.

This is invalid code, per C++11 as published (although it's likely to change in a future revision, since it's likely to become a common language extension)

On the other hand, std::array<int, 3> ia = {1, 2, 3}; is supposed to be valid code.

[Catfish2]

L B wrote:

My point is, they should've swapped std::vector and std::array's names in C++11 so that people would have to write programs to update their C++03 code to C++11

I think they should've renamed vector to array, and overload it for a length parameter.

Telion wrote:

Try creating a vector of 10 integers with uniform initialization syntax.

Could you give example code, and the compiler and its version, that you're using?

@ Cubbi:
I deal with that warning by putting extra braces around the initializer list. But it always seemed awkward. I see Stroustrup avoids the issue altogether in the C++11 section of his FAQ.
http://www2.research.att.com/~bs/C++0xFAQ.html#std-array

[Gaminic]

Now C++0X will compound this mistake by introducing a class 'array' that will behave similar to a mathematical vector.

It's not "compounding". An array has always been the equivalent of a mathematical vector. All existing C++ literature use the term array for fixed-length storage.

They could change the name of std::vector, but I can't imagine anyone was ever confused by this.

[rapidcoder]

Why do languages strive for reverse compatibility when people will use different versions anyway? It's turned Java into a mess and made C++ seem scary to those new to programming.

Backwards compatibility is important for industry. Scala and Python are criticized for breaking backwards-compatibility too often. Industry doesn't want to rewrite code over and over again, because someone thought out a prettier initialization construct (anyway, I really don't understand why a language needs any special syntax for initialization - many languages do without it and are more readable).

[LB]

I suppose I should have clarified; I was kidding (I put smilies in my posts when I am kidding). I know why backwards compatibility is better, I just don't like it.

[Gaminic]

I'm not entirely following the backwards compatibility story. The code is already finished and compiled, no? Why do future updates matter? If you're going to add on or rework part of the code, use the old compiler. Yes, it might be a bit messy to keep 3~4 compilers around for different programs, but
a) it's more messy to force everyone to use constructs invited in the 90s for modern code, and
b) forcing a bit of rework on 10y old code isn't really a bad idea, to be honest.

[rapidcoder]

@Gaimic, code is *never* finished. Programs need usually some maintenance. Imagine your customer found a bug. You debug it, and you find it is a bug not in your code, but in some external library you use. Ok, no problem - get a newer version of the library and recompile / relink. Should be easy, shouldn't it? Ok, so you download a newer version of the library, recompile, and bang, 20 errors. The library authors moved to a new language / standard library version and now their code doesn't compile with the old build stack. Ok, fine, so you upgrade your compiler/build stack to the one supported. Bang, 1000 errors. The library compiles fine, but your code and another librariy doesn't any more. Well, so you upgrade that library... You may as well end up porting whole project to the newer version of the language.

Even languages/frameworks very, very careful about backwards compatibility like Java, both on API and ABI level, sometimes break it due to bugs or very subtle changes in behaviour. That is why evolving a mature language is very hard.

[Cubbi]

The library authors moved to a new language / standard library version and now their code doesn't compile with the old build stack. Ok, fine, so you upgrade your compiler/build stack to the one supported. Bang, 1000 errors. The library compiles fine, but your code and another librariy doesn't any more. Well, so you upgrade that library.

That's exactly the trap Sun Studio ended up in: they first released a badly rushed C++ compiler (version 5.0) in 1998 with important parts of the language still missing and (stupidly, in my opinion) #ifdef'd out the parts of the standard library (which they didn't write themselves, it was licensed) which couldn't be compiled by that incomplete compiler. The very next version of the compiler (5.1) supported the missing language features, but the #defines are still there today, in 2012, because if they are ever removed, not only the newly-compiled programs won't link with old libraries, old programs won't *run* at all (unless statically linked).

They offer another standard library (since 2002) and an option to download and install yet another, but they aren't the defaults, again, because newly compiled code would not link against old libraries.

[Telion]

@Catfish2:

std::vector <int> v{10};

Creates a vector holding a single int initialized to 10. I'm pretty sure this is standard behavior.

[Catfish2]

So I guess you'd like to be able to do something like this?

std::vector<int> vi(10) = {1, 2, 3, 4}; // vi = {1, 2, 3, 4, 0, 0, 0, 0, 0, 0}

[Telion]

No, I'd like to be able to do this:

std::vector <int> v{10};

while having the same behavior as this:

std::vector <int> v(10);

Uniform initialization is supposed to provide a single syntax for initializing anything, but it confuses constructor arguments with initializer lists. This makes it impossible to use curly braces for all of your initializations, which makes the whole idea pretty stupid.

[rapidcoder]

Constructors are a bad idea in general. I wonder why they do not use factory methods for that, like most other OOP languages are doing for years. Then the confusion could be easily avoided:

auto v1 = std::vector.ofSize<int>(10);   //  v1 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
auto v2 = std::vector.withElements(10);  // v2 = { 10 }
auto v3 = std::vector.withElements(1, 2, 3);  // v2 = { 1, 2, 3 }