Originally posted by pal666
View Post
Announcement
Collapse
No announcement yet.
GCC Developers Look At Transitioning Their Codebase To C++11
Collapse
X
-
-
Originally posted by pal666 View Postit's advisable to forbid constant size c arrays
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.
Comment
-
Originally posted by elatllat View PostA glass 1/100th empty (99/100 full);
https://forge.rust-lang.org/release/...m-support.html- It's fully-supported by multiple compilers.
- It's standardized.
Comment
-
Originally posted by pal666 View Postnot via this unique_ptr
Example 1:
Code:std::unique_ptr< int > p( new int( 42 ) ); p.release(); std::cout << "p = " << (*p) << "\n";
Segmentation fault (core dumped)
Example 2:
Code: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";
q = 42
Segmentation fault (core dumped)
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.
Originally posted by pal666 View Postonly if you are using obsolete standard. c++17 brings https://en.cppreference.com/w/cpp/la...ment_deduction so you can writeCode:[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]
Point taken, however AsuMagic not only beat you to it, but also made a reasonable counter-point (for compound types).
Comment
-
Originally posted by pal666 View Posti'd start with https://en.cppreference.com/w/cpp/ex...ector/erase_if
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.
Comment
-
Originally posted by pal666 View Postis microsoft big enough company for you?
Originally posted by pal666 View Postmost of c++17 works across all compilers that matter
- Likes 1
Comment
-
Originally posted by tildearrow View PostWhat if I really have to pass a pointer to some C function?
(you can't do that with std::array (?))
Just take a couple minutes and read through the class: https://en.cppreference.com/w/cpp/container/array
Comment
-
Originally posted by tildearrow View Post...us? Do many people write under your account?
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.
Originally posted by tildearrow View PostI know but I would prefer not to do so.
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?
Comment
-
Originally posted by cynical View PostLisp has been around since like the 40s lol.
Comment
-
Originally posted by carewolf View Postin 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
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.
Comment
Comment