5 ms·

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto in

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default. Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some memory allocations under the hood). I like that I can breakpoint my C++ code and look at the disassembly if I am concerned that the compiler did something other than expected.

William_BB 2y ago
E.g. `std::ranges::for_each`, where lambda captures a bunch of variables by reference. Like I would hope the compiler optimizes this to be the same as a regular loop. But can I be certain, when compared to a good old for loop?
- jpc0 2y ago
  To be fair std::ranges seems like the biggest mistake the committee allowed into the language recently. Effectively other than for rewriting older iterators based algorithms to using new ranges iterators I just don't use std::ranges... Likely the compiler cannot optimise it as well (yet) and all the edge cases are not workes out yet. I also find it to be quite difficult to reason about vs older iterator based algorithm's. for each would take a lambda and call the lambda for each iterator pair, if the compiler can optimise it it becomes a loop, if it can't it becomes a function call in a loop which probably isn't much worse... If for some reason the lambda needs to allocate per iteration it's going to be a performance nightmare. Would it really be much harder to take that lambda, move it to a templated function that takes an iterator and call it the old fashioned way?
  - jandrewrogers 2y ago
    Yeah, the std::ranges implementation is a bit of a mess. The inability to start clean without regard for backward compatibility reasons limits what is possible. I think most people see how you could implement comparable functionality with nicer properties from a clean sheet of paper. It is the curse of being an old language.
    - imron 2y ago
      There are sane approaches to dealing with this - e.g. epochs. This wasn’t proven by the time c++11 was ready, but for c++20 and beyond it’s a shame they didn’t go with this.
- throwaway2037 2y ago
  Did you try the two version in Godbolt?
- TinkersW 2y ago
  Just ban ranges lib, it is hot garbage anyway. The compilers are able to optimize lambdas fairly well nowadays(when inlined), I wouldn't be that concerned.
musicale 2y ago
I just wish they hadn't repurposed the old "auto" keyword from C and had used a new keyword like "var" or "let". #define var auto #define let auto
- deleted 2y ago
  [deleted]
- galkk 2y ago
  If we're going that route, how about #define var auto #define let const auto ?
  - musicale 2y ago
    I was thinking of having one or the other, but let as the const form is appealing. ;-)
- maleldil 2y ago
  Given how important backwards compatibility is for C++, it's either take over a basically unused keyword or come up with something so weird that would never appear in existing code. Java solved this by making var a reserved type, not a keyword, but I don't know if that's feasible for C++.
deleted 2y ago
[deleted]

William_BB 2y ago

E.g. `std::ranges::for_each`, where lambda captures a bunch of variables by reference. Like I would hope the compiler optimizes this to be the same as a regular loop. But can I be certain, when compared to a good old for loop?

jpc0 2y ago
To be fair std::ranges seems like the biggest mistake the committee allowed into the language recently. Effectively other than for rewriting older iterators based algorithms to using new ranges iterators I just don't use std::ranges... Likely the compiler cannot optimise it as well (yet) and all the edge cases are not workes out yet. I also find it to be quite difficult to reason about vs older iterator based algorithm's. for each would take a lambda and call the lambda for each iterator pair, if the compiler can optimise it it becomes a loop, if it can't it becomes a function call in a loop which probably isn't much worse... If for some reason the lambda needs to allocate per iteration it's going to be a performance nightmare. Would it really be much harder to take that lambda, move it to a templated function that takes an iterator and call it the old fashioned way?
- jandrewrogers 2y ago
  Yeah, the std::ranges implementation is a bit of a mess. The inability to start clean without regard for backward compatibility reasons limits what is possible. I think most people see how you could implement comparable functionality with nicer properties from a clean sheet of paper. It is the curse of being an old language.
  - imron 2y ago
    There are sane approaches to dealing with this - e.g. epochs. This wasn’t proven by the time c++11 was ready, but for c++20 and beyond it’s a shame they didn’t go with this.
throwaway2037 2y ago
Did you try the two version in Godbolt?
TinkersW 2y ago
Just ban ranges lib, it is hot garbage anyway. The compilers are able to optimize lambdas fairly well nowadays(when inlined), I wouldn't be that concerned.

musicale 2y ago

I just wish they hadn't repurposed the old "auto" keyword from C and had used a new keyword like "var" or "let". #define var auto #define let auto

deleted 2y ago
[deleted]
galkk 2y ago
If we're going that route, how about #define var auto #define let const auto ?
- musicale 2y ago
  I was thinking of having one or the other, but let as the const form is appealing. ;-)
maleldil 2y ago
Given how important backwards compatibility is for C++, it's either take over a basically unused keyword or come up with something so weird that would never appear in existing code. Java solved this by making var a reserved type, not a keyword, but I don't know if that's feasible for C++.

deleted 2y ago

[deleted]