| David Brown <david.brown@hesbynett.no>: May 04 06:34PM +0200 On 03/05/2021 18:13, Paavo Helde wrote: > the proposal for getting auto working here would not get much traction > in the committee, it looks more like a great feature for obfuscated C++ > contests. I would go further and say that you definitely /want/ auto to give the proxy object, not the conversion, in a case like this. When initialising from "mydb[y]", sometimes you would want the converted value, and sometimes the proxy object - and when you want the converted value you can, as you say, write "X x = mydb[y];". If you want the proxy itself then it would be a good use of "auto" - the type is likely to be verbose and its details would be a clutter in the code. |
| Juha Nieminen <nospam@thanks.invalid>: May 04 10:32AM > applications that has the most runtime on a specific system - perhaps > using several CPU-hours per day. Not trying to get everything else down > from 5 to 4 microseconds. Or, conversely, it may be worth for the developer to spend an extra 10 hours of development time if the end result is a program that runs twice as fast, saving potentially thousands of CPU hours in the long run. Those microseconds add up when they are run many, many times. |
| Juha Nieminen <nospam@thanks.invalid>: May 04 10:43AM > Performance starts to matter only after correctness has been > reached from end to end and then only to minor subpart of > whole program. When Knuth wrote "premature optimization is the root of all evil" in 1974, I doubt he was thinking about std::string::substr() vs. std::string::compare() in a language standardized in 1998. In fact, I personally consider the (in)famous adage to have caused more harm than good overall because way, way, way too many programmers have interpreted it to mean "deliberately and purposefully make your program as inefficient as you possibly can, because optimization, any kind of optimization, is one of the worst things you could possibly do". I'm not even kidding. I have encountered that sort of attitude in the real world out there many times. People deliberately choosing a less efficient algorithm or data container even when a significantly more efficient one is available, because "premature optimization is the root of all evil", and there's literally zero reason not to use the more efficient version. I don't think many people even understand what he meant by it. Does anybody understand what he meant by it? By "premature optimization" didn't he merely mean ugly hacks that supposedly make the program a few clock cycles faster at the cost of making it almost unreadable (something that was especially common in the 70's and 80's, when compilers were extraordinarily basic and bad at optimization). Such as explicitly using bitshifting instead of multiplication, manually inlining code, and other such hacks. The more such hacks are used, the less readable and maintainable the code belongs, and it becomes. "Premature optimization" does not mean using quicksort instead of bubble sort. Or using a balanced binary tree instead of an array (and linear searches). Or using std::string::compare() instead of std::string::substr(). |
| Juha Nieminen <nospam@thanks.invalid>: May 04 10:53AM > Also, the first version expresses nearly directly the desired operation, > while the rewrite is just that: a rewrite to fit more arbitrary > requirements, in the direction of expressing C++ code in assembly. The two lines are about equal in length and complexity, are arguably equally clear to read and understand, and as someone measured, the second version is about 10 times faster than the first version. Just because you personally are not acquainted too well with std::string::compare() doesn't make it somehow the inferior option. There really is no good reason to deliberately make the comparison 10 times slower just so that it can have "substr" instead of "compare". It would be different if the faster version would be like 10 lines of complicated code while the slower version is just a one-liner. Then there may be an argument to be made. In this case, however, just no. |
| David Brown <david.brown@hesbynett.no>: May 04 03:20PM +0200 On 04/05/2021 12:43, Juha Nieminen wrote: > more efficient one is available, because "premature optimization > is the root of all evil", and there's literally zero reason not to > use the more efficient version. I have certainly seen code written without any thought given to efficiency (like "x * 0.5" instead of "x / 2" on an 8-bit embedded system). But I don't believe I have seen anyone deliberately choosing a less efficient algorithm when the efficiency was the only difference. > bubble sort. Or using a balanced binary tree instead of an array (and > linear searches). Or using std::string::compare() instead of > std::string::substr(). For most code, efficiency does not particularly matter (pick your own favourite statistic - 95.32% of run time is spent inside 2.12% of the code). It might begin to matter if the bulk of the code uses really bad algorithms, but you don't need to put special effort into it. In particular, you should not optimise for efficiency at the expense of making code less clear, or increasing the risk of making it incorrect. I can't remember if it was Knuth or someone else who said that optimising for speed is easy if you don't worry about correctness. There are good reasons why most code these days is not written in compiled languages - developer time, ease of maintenance, flexibility, etc., are often more important than absolute speed. But premature pessimisation follows close behind premature optimisation as the root of all evil. So it might be better to write a piece of code in Python rather than C++, but you still want to make sure you use lists or dicts as appropriate and avoid needlessly inefficient algorithms. |
| Manfred <noname@add.invalid>: May 04 04:41PM +0200 On 5/4/2021 3:20 PM, David Brown wrote: > as the root of all evil. So it might be better to write a piece of code > in Python rather than C++, but you still want to make sure you use lists > or dicts as appropriate and avoid needlessly inefficient algorithms. You are bringing on an important aspect here. I have experienced too the fact that performance really matters in a small fraction of code, however I am seeing the opposite attitude growing up to a point that the performance hit becomes actually relevant even for ordinary applications. The most relevant issue is not really about writing one piece of C or C++ code in one way or the other - what is becoming (has become) relevant IMO is pervasive use of managed languages because of their appeal to make programming "easy" at the cost of some performance hit that is supposed to be not that relevant after all with nowadays' hardware. This marketing narrative may be appealing to some management that has some financially biased perspective on sw development - be as it may, the fact is that it is quite common to run into some trivial application that for the sole purpose of keeping running needs to load dozens of DLLs. The issue even stops being a matter of preventing "premature optimization", i.e. favor simplicity over sophistication for the purpose of ensuring correctness. When you build something that needs a ton of subsystems for the the sake of its own language infrastructure you are still introducing extra and brittle sophistication even if it is hidden by the curtain of apparently compact source code. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: May 03 10:01PM -0700 On 5/3/2021 9:33 AM, Andrey Tarasevich wrote: > But it is not the case in GCC. Who's right here? GCC? Or MSVC++ and Clang? OK, I see that the standard is rather straightforward about it "The set of default template-arguments available for use is obtained by merging the default arguments from all prior declarations of the template in the same way default function arguments are ([dcl.fct.default]). [Example 6: template<class T1, class T2 = int> class A; template<class T1 = int, class T2> class A; is equivalent to template<class T1 = int, class T2 = int> class A; — end example]" http://eel.is/c++draft/temp.param#13 So, this is indeed a bug in GCC. -- Best regards, Andrey Tarasevich |
| David Brown <david.brown@hesbynett.no>: May 04 09:04AM +0200 On 04/05/2021 07:01, Andrey Tarasevich wrote: > — end example]" > http://eel.is/c++draft/temp.param#13 > So, this is indeed a bug in GCC. Don't forget to register it in the gcc bugzilla. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment