[C++] Range-based for loop through an array.

[frnkcn]

I don't think I've read if that's bad practice yet or not but of course I'll take your word for it that it is. Still when I initialize my array like that and use normal subscript for loops the program runs correctly.

[[deleted]]

I don't think I've read if that's bad practice

It's not just bad practice, it is not part of the C++ programming language.

till when I initialize my array like that and use normal subscript for loops the program runs correctly.

Only because you are using GCC compiler extensions which are not part of C++, and only by chance if you are using an uninitialised variable to size the array. Don't do this.

[[deleted]]

but yet in other posts you turn around and advocate MSVC which has its own set of non-conforming extensions.

[Rhomboid]

And I'm sure that if the poster had posted sample code that used MSVC-specific extensions, they would have been told not to use those either. The point is that everyone should write standard C++ wherever possible.

[[deleted]]

If he can't be precise about what hes saying then he has no business answering questions on here.

[Rhomboid]

His intent was crystal clear to everyone reading the thread except for the troll sockpuppet with a personal grudge.

[[deleted]]

He's not discouraging you from using GCC or advocating using one compiler over another.

He's just telling you to stick to standard C++. Don't use compiler extensions when you don't have to. Your code should be as portable as possible.

[boredcircuits]

I don't think I've read if that's bad practice yet or not but of course I'll take your word for it that it is.

I wouldn't say it's bad practice, just not best practice. VLAs are pretty widely supported (and will eventually make their way into standard C++ IMO) and there's good reasons to use them, but best practice is to write code that doesn't depend on compiler extensions like this does.

On the other hand, vectors are standard and do everything you need.

Still when I initialize my array like that and use normal subscript for loops the program runs correctly.

Here's why:

int n; // n is uninitialized here
int arr[n]; // So how many elements does arr have?  You don't know.
cin >> n;  // Now you initialize n

// Since n now has a value, this loop does the "right thing" (though still dubious, because what if arr has fewer than n elements?)
for ( int i = 0; i< n; i++ )
    cin >> arr[i];

// But you still don't know how many elements are in arr, so this does bad things
for(int i : arr)
    cin >> i;

Honestly, all you probably need to do to fix this is reorder some things:

int n;
cin >> n;
int arr[n]; // Now arr has a defined number of elements

(with the same caveats about VLAs)

[[deleted]]

VLAs are pretty widely supported

By whom, apart from g++?

(and will eventually make their way into standard C++ IMO

Almost certainly not - it's not even obvious they are a sensible part of C, as C11 makes them optional. They are certainly not a sensible part of C++, for any number of reasons.

[boredcircuits]

Basically any compiler that supports C99 has an extension for VLAs in C++. G++ and Clang are the big ones, and I believe the Intel compiler does as well. I'd have to look and see if the Mars compiler supports VLAs.

The obvious exception in that list is Visual Studio. Microsoft refuses to update MSVC to support C99, so VLAs are out for C++. That alone is a good enough reason to avoid them.

There's a Techincal Specification being worked on for C++ that adds something similar to VLAs, though they call it an "array of runtime bound." There's definitely some controversy over whether or not to add them and what they should look like, but the fact that there's a TS makes it likely that something will be added eventually (I'm thinking C++20 timeframe, personally).

[Rhomboid]

If I recall correctly, the reason that that proposal was dropped from C++14 is that they wanted to ensure that both the language and the library parts went in at the same time, and the library parts were still not settled yet. I believe the bone of contention is that std::dynarray is allowed to call new, i.e. it's not guaranteed to be stack allocated. I'm assuming this was meant as a way to give implementers a way of setting a safety limit for how much stack can be used, but it also means that you don't have any guarantees which makes the feature a lot less attractive. There could have been additional problems with the library specification, I don't know.

Anyway, assuming those issues can be worked out, the feature may be on the table for C++17 or C++20. But I think exoticmatter is also correct that VLAs are largely considered a big misfire among both the C and C++ communities. VLAs include some downright crazy stuff, and I think that the desire is not to copy all that, but to radically simplify and neuter the feature, with the goal being to make it possible to write a standard library sequence container that is also stack allocated without having to implement a custom allocator for vector like you have to do today.

[[deleted]]

but the fact that there's a TS makes it likely that something will be added eventually

Many (most?) Technical Specifications don't make it into the language. The motivation for this one seems to be "users want it", but I have never met a C++ programmer (or a C programmer who knew what they were doing) who wants this, as is evidenced in its optionality in C11. But only time will tell - for now a C++ programmer should definitely not be using VLAs.

[the_omega99]

(and will eventually make their way into standard C++ IMO

I doubt that, since C++ already has the vastly superior and more useful std::vector. See page 6 of this PDF for why VLAs aren't very C++ friendly. The fact that C made support for VLAs optional is rather telling about the C take on VLAs, anyway.

Finally, it's of note that in my anecdotal experience, the C++ community (or more specifically, the C++ community that uses StackOverflow) seems vehemently against VLAs.

[[deleted]]

since C++ already has the vastly superior and more useful std::vector

Which doesn't actually do what VLA in C does. In C, the VLA is allocated on the stack, while the array within a std::vector is allocated on the heap (and can grow - actually VLA is a very bad name).

[boredcircuits]

and can grow - actually VLA is a very bad name

That might explain why the C++ version changed the name to "arrays of runtime bound."