Thread: Create vector of floats in a for-loop

Originally Posted by grumpy

TR1 was a set of proposed extensions to the standard. Although it was a standard, it was never formally a C++ standard. Features in it became part of the C++ standard in C++-11.

But the point is, it was a standard, not just some compiler extension. Any compiler that implements TR1 supports it.

Life is not that simple in the real world. Good practice can involve disciplined and effective use of available features, avoiding misuse, etc. I've seen enough "bad practice" that involves misuse of ostensibly safe features coupled with over-confidence since "it is safe, isn't it, so I can do what I like without checking". Including, in some cases, with misuse of std::array.

There is also the inconvenient fact that std::array is just a wrapper that provides an alternative interface for a normal array anyway. It is designed as a means of convenience, not a safety mechanism. It can be used in safe ways, or unsafe ways.

My point exactly. Yes, C++-11 features are useful. Yes, they can be safer. They are not, however, a safety net. And they can still be misused.

Unfortunately, the intelligence and skill of the C++ standards committee - although considerable - is bounded and finite. In contrast, the propensity of programmers to misuse language features has no known upper bound.

Anything can be misused. But the point is, it is harder to do so, and that is what we want. To catch more errors earlier.
While we cannot teach newbies all good practices, don'ts and dos, we can at least provide some measures to help them become better programmers, by teaching them of security tools that exist (and refer them to use them by default).
std::array contains such a security feature, just like vector.

I disagree. His post was immediately after your post that mentioned std::array. By your logic, you had the obligation to mention C-style arrays as well, so his post should not have been necessary. Such an argument cuts both ways.

However, in forums, we don't aim for completeness - because we can't - unless there is a particular reason to. We provide options and discussion, not definitive or complete descriptions of everything.

Never did it say it complemented the post. In my eyes, it seemed like it was completely disregarding it.
Had there been some clause saying "In addition, there is this...", then I would have been satisfied (unless, of course, it mandated the use of such features of std::array if such an implementation is available).

I'm not alone in suggesting that. Recent teaching materials from people like Stroustrup do it too - although it is easier to take a staged approach to teaching when you can control the materials. A staged approach is not really practical in a forum with multiple independent contributors, but your approach of advocating the "latest, greatest, and allegedly safest while nagging those who provide alternatives" is not the answer to that problem.

We are just going to have to learn to disagree on this. Unless there is a particular reason why someone cannot use the latest and greatest, that is what we should teach, IMO.
Security comes before all, and a newbie should not have to be bothered with this until the time comes to delve into security in depth.

Originally Posted by iMalc

I think that arguments for std::array are in general pretty weak. The cases where it is of significant benefit tend to be few and far between in reality.
std::string on the other hand adds a lot of useful functionality, and is worth knowing about sooner rather than later.

So you would rather skip std::array simply because it does not any significant benefits? This is a rather silly argument.
std::array have the iterator concept, size (at both run and compile time if constexpr is supported), and an optional check against out-of-bounds access.
You want to disregard all this and teach users C arrays, just so later they have to learn std::array (and likely using it by default later)?
Why not just teach them std::array from the beginning, and save all the trouble?

They should probably learn what it is that .at() is protecting them against, because they'll run into raw arrays pretty soon, and what they give up for that protection (*some* amount of performance and extra compilation time).
You've also worded your argument for .at() poorly, because no matter what you use, it isn't true that you can avoid having to think about out-of-bounds access, in most cases. I.e. if you have an off-by-one then the result is going to be an incorrect program either way. You're gonna have to think about it and get it right sooner or later.

Yes! You should know these things. I am not against that. But you are going to have to remember that this is a topic of security. Security is all-important these days, and should be a formal subject anyone should learn, and not just bits and pieces. So I find this a very good topic to discuss when discussing security in-depth.
Regardless, if the newbie does not know so much about security, I'd rather have them learn to use .at() than C-arrays with buffer overflows and out-of-bounds access.
If you want to teach them both worlds, go right ahead. I have no qualms. I simply want std::array to be mentioned as the preferred choice to reduce security risks and make C++ more like other modern languages that do bounds checking.
On modern computers, bounds checking is cheap. So, unless you really need the extra performance, you should make your program safer by using safer mechanisms. This is what I strongly believe.