4 ms·

It's been the go-to syntax for 15 years now

by on_the_train 9mo ago

Night_Thastus 9mo ago
Go-to? I've never seen a project use it, I've only ever seen examples online.
- whobre 9mo ago
  Same here
- on_the_train 9mo ago
  It's still been the standard since c++11 and I've been using it every since in all teams I've worked in.
cpburns2009 9mo ago
Now I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?
- yunnpp 9mo ago
  No. The auto there is doing some lifting so that you can declare the type afterwards. The return type is only defined once. There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas. https://en.cppreference.com/w/cpp/language/auto.html https://en.cppreference.com/w/cpp/language/auto.html auto f() -> int; // OK: f returns int auto g() { return 0.0; } // OK since C++14: g returns double auto h(); // OK since C++14: h’s return type will be deduced when it is defined
  - maccard 9mo ago
    What about auto g() -> auto { return 0.0; }
    - yunnpp 9mo ago
      0.0 is a double, so I would assume the return type of g is deduced to be double, if that is what you're asking.
      - maccard 9mo ago
        I was more pointing out that the syntax was dumb for that particular example!
- maccard 9mo ago
  I really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature
  - zabzonk 9mo ago
    the standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.
    - maccard 9mo ago
      Indeed. I am a frequent critic of the c++ committee’s direction and decisions. There’s no direction other than “new stuff” and that new stuff pretty much has to be in the library otherwise it will require changes that may break existing code. That’s fine. But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier. St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently. There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?

It's been the go-to syntax for 15 years now

Night_Thastus 9mo ago

Go-to? I've never seen a project use it, I've only ever seen examples online.

whobre 9mo ago
Same here
on_the_train 9mo ago
It's still been the standard since c++11 and I've been using it every since in all teams I've worked in.

cpburns2009 9mo ago

Now I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?

yunnpp 9mo ago
No. The auto there is doing some lifting so that you can declare the type afterwards. The return type is only defined once. There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas. https://en.cppreference.com/w/cpp/language/auto.html https://en.cppreference.com/w/cpp/language/auto.html auto f() -> int; // OK: f returns int auto g() { return 0.0; } // OK since C++14: g returns double auto h(); // OK since C++14: h’s return type will be deduced when it is defined
- maccard 9mo ago
  What about auto g() -> auto { return 0.0; }
  - yunnpp 9mo ago
    0.0 is a double, so I would assume the return type of g is deduced to be double, if that is what you're asking.
    - maccard 9mo ago
      I was more pointing out that the syntax was dumb for that particular example!
maccard 9mo ago
I really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature
- zabzonk 9mo ago
  the standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.
  - maccard 9mo ago
    Indeed. I am a frequent critic of the c++ committee’s direction and decisions. There’s no direction other than “new stuff” and that new stuff pretty much has to be in the library otherwise it will require changes that may break existing code. That’s fine. But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier. St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently. There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?