GCC Developers Look At Transitioning Their Codebase To C++11

[coder]

they can rely on previous gcc version to be portable

Yeah, but one can imagine a bug (or attack) in one GCC version that infects all subsequently-built versions. If you have no feasible way of bootstrapping, that's a problem. For one thing, you can't easily prove that such an attack doesn't exist, unless GCC is compilable by something other than an earlier version of GCC.

[coder]

it's advisable to forbid constant size c arrays

Unless you mean for writing (i.e. arrays of non-const elements), then why?

I'll occasionally even use stack-based arrays for writing, but I only do it when it's performance-critical code and I can prove that an out-of-bounds access can't occur.

[coder]

A glass 1/100th empty (99/100 full);
https://forge.rust-lang.org/release/...m-support.html

IMO, there's a lot to be said for having multiple, independent implementations of a language. I'll be a lot more interested in Rust, when:

1. It's fully-supported by multiple compilers.
2. It's standardized.

[coder]

not via this unique_ptr

Yes, via that unique_ptr.

Example 1:

    std::unique_ptr< int > p( new int( 42 ) );
    p.release();
    std::cout << "p = " << (*p) << "\n";

Output:

Segmentation fault (core dumped)

Boom!

Example 2:

    std::unique_ptr< int > p( new int( 42 ) );
    std::unique_ptr< int > q = std::move( p );
    std::cout << "q = " << (*q) << "\n";
    std::cout << "p = " << (*p) << "\n";

Output:

q = 42
Segmentation fault (core dumped)

Boom!

While these are obviously contrived examples, it shouldn't be hard to see how this can occur in a larger body of code, perhaps involving more functions, where such usage violations could go unnoticed.

I'm not arguing that std::unique_ptr<> is bad. Quite the contrary - I appreciate its enhancements over boost::scoped_ptr<> - including the addition of release(). I'm just pointing out that it's not fool-proof.

only if you are using obsolete standard. c++17 brings https://en.cppreference.com/w/cpp/la...ment_deduction so you can write

[COLOR=#000000]std::array vals { [/COLOR][COLOR=#09885a]1[/COLOR][COLOR=#000000], [/COLOR][COLOR=#09885a]2[/COLOR][COLOR=#000000], [/COLOR][COLOR=#09885a]3[/COLOR][COLOR=#000000] };[/COLOR]

you see, now i can argue that c array forces you to redundantly specify int as its element type

Yeah, I'm not bleeding edge.

Point taken, however AsuMagic not only beat you to it, but also made a reasonable counter-point (for compound types).

[coder]

i'd start with https://en.cppreference.com/w/cpp/ex...ector/erase_if

Good point.

I was assuming he wanted to iterate for some other reason, and also occasionally delete. I guess you can still do that with erase_if(), and just use a predicate that has whatever side-effect you're also looking to accomplish by iterating.

[coder]

is microsoft big enough company for you?

I think carewolf was talking about the typical big enterprise. Sure, you can find outliers - even among larger companies.

most of c++17 works across all compilers that matter

Enterprise distros are a few revs behind, on those compilers.

[coder]

What if I really have to pass a pointer to some C function?
(you can't do that with std::array (?))

Yes, of course people thought of that:

https://en.cppreference.com/w/cpp/container/array/data

Just take a couple minutes and read through the class: https://en.cppreference.com/w/cpp/container/array

[coder]

...us? Do many people write under your account?

No, yet multiple people are reading these posts!

Originally, I asked you to tell "us", meaning to post in the thread the results of any experiments you try. Consistent with that, I was thanking you for doing so.

The reason I didn't simply ask you to tell "me" what you found is that I thought it would seem more like a request to direct-message me. I didn't want to encourage that, since I thought there might be others also interested in your results.

I know but I would prefer not to do so.

Sure, nobody is making you use such tools, but they're provided for good reasons. It's worth understanding them and what they can do to mitigate verbosity of your code, since that hurts readability and ultimately reduces code quality.

One tip I'd share: when using deeply-nested names, I'll frequently use the using keyword at some local scope. Perhaps this is a more palatable compromise?

[coder]

Lisp has been around since like the 40s lol.

Yeah, we get that it's old. No need to exaggerate, though.

https://en.wikipedia.org/wiki/Lisp_(programming_language)#History

[coder]

in my 30 years of C++ experience I have never seen any bugs caused by arrays decaying to pointers, arrays are rarely something you pass around with ownership, so how they decay if you did is irrelevant for me, though I guess std::array is technically superior

Heh, I'll fess up.

sizeof() obviously behaves differently, depending on whether it's used on an array or pointer. An easy way to iterate over an array is to compute the end "iterator" by adding the length, which you can compute by dividing the size of the array by the size of an element (yay, macros!). So, if you have this construct in the scope of an array, and then you move it into a function where the same array is now passed in as a pointer... you've got a bug!

In fairness, this was before I knew about boost::array<> (and well before 2011). Since then, I've converted to using boost::array<> and now std::array<>. And I make sure not to pass around bare pointers to its data, except to things like (mostly C) library functions I don't control.