Originally posted by Vistaus
View Post
Announcement
Collapse
No announcement yet.
GCC Developers Look At Transitioning Their Codebase To C++11
Collapse
X
-
Originally posted by AsuMagic View Post[insert "modern code" here
It also didn't compile on the clang provided with our version of UE4 (4.9 I believe). We use an older version because the project started quite a while ago. It finishes in another year .
I don't believe it compiles on our codeplay compiler either. The focus on this compiler is not for latest standards but for parallelization.
Its basically not practical (for another 5 years).
Edit: It did work on Emscripten. Horray!
As for the actual code... Honestly the first one actually is easier to read. Breaking the logic up into sections is something I like to actively pursue. The 3rd one was OK. Middle one was horrid.Last edited by kpedersen; 30 September 2019, 01:14 PM.
Comment
-
Originally posted by Vistaus View PostWith so many people disliking using the latest and greatest (in this case C++20) for coding, instead using older versions for a while longer, I wonder if anybody even uses the latest and greatest?
But if IBM complained about trigraphs removal for C++17, I suppose they care at least a bit.
Comment
-
Originally posted by cl333r View Post
Something's wrong with the like system, I hit like a few hours ago but currently it shows zero likes and the "unlike" option. Can't post a screenshot because phoronix doesn't accept uploading images to it and too lazy to use an uploading service.
Comment
-
Originally posted by kpedersen View Post
This didn't compile on my RHEL 6 compiler (-std only goes up to 11). This is still our main server target unfortunately.
It also didn't compile on the clang provided with our version of UE4 (4.9 I believe). We use an older version because the project started quite a while ago. It finishes in another year .
I don't believe it compiles on our codeplay compiler either. The focus on this compiler is not for latest standards but for parallelization.
Its basically not practical (for another 5 years).
Edit: It did work on Emscripten. Horray!
As for the actual code... Honestly the first one actually is easier to read. Breaking the logic up into sections is something I like to actively pursue. The 3rd one was OK. Middle one was horrid.
I disagree about the 1st one being better. 2nd one might lead to a long line but you can always store the lambda in a const auto variable before the sort call if it bothers you that much. I know it does not bother me. Having to scroll up to find how the sort is actually performed contributes to spaghetti code IMO.
Either way, this is still much better than the standalone function because that comparison function literally only has a single statement.
Another (artificial) example, which might be a more striking usecase of lambdas to me:
Code:struct StudentFilterComparator { int score_threshold; bool operator()(const Student& student) const { return student.score < score_threshold; } }; void foo(int thresh) { // Some more code around here... StudentFilterComparator comp; comp.score_threshold = thresh; const std::vector<Student>::const_iterator it = std::remove_if(students.begin(), students.end(), comp); students.erase(it, students.end()); }
Compare to C++20:
Code:void foo(int thresh) { // ... Stuff ... std::erase_if(students, [thresh](const Student& student) { return student.score <= thresh; }); }
This is just much much easier to think about IMHO.Last edited by AsuMagic; 30 September 2019, 01:58 PM.
Comment
-
Originally posted by AsuMagic View PostManual memory allocations are essentially always a terrible idea.
Most of the time you can do the job with unique_ptr and it will neatly manage the lifetime of the held object.
Seriously, if it's anything, it's not laziness. There are so much use-after-free bugs and memory leaks in the real world that could have been avoided with smart pointers.
Originally posted by AsuMagic View PostThreading is a pain in the ass without C++11. Most people used Boost threading or just directly used pthread or win32 threading.
The former is a massive dependency, the latter is a portability issue, and it's not any nice to work with.
Originally posted by AsuMagic View PostEven on the simplest stuff C++03 is annoying: No initializer lists, the stupid > > syntax rule, being unable to call a parent constructor or inherit from them...
Originally posted by AsuMagic View PostFor-range loops are a godsent. Seriously. How can you not prefer this
Code:for (const auto& [key, value] : my_container) { // use key and value }
Code:for (std::map<MyKey, MyValue>::const_iterator it = my_container.begin(); it != m_container.end(); ++it) { // use it->first and it->second }
Although I never knew you could initialize several variables in the for loop, Python style?
Also, is it possible to access the associated iterator using the for (type i: var) {} syntax? Will come in handy when having to erase stuff in arrays.
Originally posted by AsuMagic View PostI don't want to have to pull a separate library to deal with something as basic as time. Say what you want about <chrono>, but it does what I want to and does that pretty well.
Originally posted by AsuMagic View PostMove semantics are great. It actually makes RAII bearable in many instances where it wasn't.
I don't want to free up resources manually much like I don't want to have to deal with memory allocations manually.
Originally posted by AsuMagic View PostLambdas, again, are a godsent. Why do you prefer, sayCode:void my_comparison_function(const Something& a, const Something& b) const { return a.foo < b.foo; } void some_function() { // Possibly lots of code that makes my_comparison_function much further separated std::sort(some_container.begin(), some_container.end(), my_comparison_function); }
Code:std::sort(some_container.begin(), some_container.end(), [](const Something& a, const Something& b) { return a.foo < b.foo });
Code:std::ranges::sort(some_container, [](const Something& a, const Something& b) { return a.foo < b.foo });
Originally posted by AsuMagic View Postauto is not only useful for "laziness". It is very convenient for metaprogramming, and allows avoiding needless verbosity or workarounds. With if constexpr too, you can make so much code more maintainable and readable without having to parse dozens of lines of SFINAE bullshit.
Originally posted by AsuMagic View Postconstexpr is just really convenient. Unfortunately IMO it does not go as extensive as I want it to be, but it is going to improve a fair bit in C++20 and probably in other future standards. I find it comparable to Haskell's purity concept in a very good way.
There are many C++ features I have never used...
Originally posted by AsuMagic View PostI take std::array so much for granted that I forgot that it was not a thing in C++03. Seriously, if you still are willingly using C-style arrays in 2019, I just don't ever want to have to deal with your code. I never ever found any reason not to use that other than pure masochism.
Originally posted by AsuMagic View PostMoving forward, modules are going to be one hell of an upgrade. I don't know about you but I'm not exactly a fan of having to micro-optimize declarations and definitions between .cpp and .hpp files by fear of bumping up compile time. And there is so much more that makes includes a PITA.
Yes, compile time had been an increasing problem in newer standards because the standard library grew and allowed constructs that were a bit heavier on the compiler, but this is absolutely going to be a thing of the past.Last edited by tildearrow; 30 September 2019, 03:05 PM.
- Likes 1
Comment
-
Originally posted by Vistaus View Post
Companies must not like you very much lol
Comment
-
Originally posted by tildearrow View Post"> >"? What is that? Pipes? The operator you use with cout or cin?
Originally posted by tildearrow View PostThis. I use it a lot and makes my code much more readable than ::iterator.
Although I never knew you could initialize several variables in the for loop, Python style?
Originally posted by tildearrow View PostAlso, is it possible to access the associated iterator using the for (type i: var) {} syntax? Will come in handy when having to erase stuff in arrays.
This would not work anyway in the usecase you provide, because of iterator invalidation (assuming you would get a read-only view to the iterator, which IMO would be the safest).
Originally posted by tildearrow View PostWhat?
RAII is about, in a way, associating the lifetime of an object to the resource it holds.
This is what happens for instance:- for std::vector, std::list, std::unique_ptr etc.: The managed resource is the underlying dynamically allocated memory. You never actually have to care about deallocation because the lifetime of the object defines the lifetime of the resource.
- for std::fstream: The underlying file handle is closed when the object is destroyed. Forgetting to close a handle can have annoying consequences as you would expect.
Move semantics is the std::move and rvalue reference stuff (&&). It allows indicating the transfer of a resource from someplace to another.
For instance:
Code:std::vector a{1, 2, 3}; std::vector b{std::move(a)};
It is part of why std::unique_ptr works so well: You can safely move the dynamically allocated data it handles through move semantics. So you have to try very very hard with std::unique_ptr to cause a memory leak.
It's not as simple as that so you might want to look it up, but it is pretty useful.
Originally posted by tildearrow View PostI never understood how to use λ's...
A lambda function is sort of the instantiation of an anonymous class you can use as a functor.
I think Jason Turner on YouTube has made a few videos to introduce people to them and explain how they work, so you could be interested. I know for sure he has talked a lot about them.
C++ weekly is great in general.
Originally posted by tildearrow View Postconstexpr? I never knew about that.
constexpr functions have a lot of (unnecessary) restrictions, but they are progressively getting lifted away.
It is quite worthwhile to know about them. At their simplest level, they allow you to define compile time constants so you don't have to deal with macros.
Originally posted by tildearrow View PostI only use C arrays for fixed-size ones or when I really desire speed. Otherwise I use std::vector
Its size is determined by a template parameter. Unlike C arrays, you can pass them and return them from functions safely.
Originally posted by tildearrow View Post...modules? Is this a replacement to libraries, or something like Java packages?
They promise some advantages you can look up too. Performance is actually a side effect of module design, but it's not 100% sure whether it will make an improvement in the real world once the implementations have matured. Wait & see.
- Likes 3
Comment
Comment