3

Manifesting unending hatred for GCC on this Wednesday afternoon

Comments
  • 3
  • 2
    @happygimp0 I passed std=c++20 to it
    It didn't complain

    A reasonable person would think "oh neat, it supports c++20!"

    But in reality it only supports most of it, not all.
    So I went on coding with C++20 features up until it just hit in the face with an include error.
    Cause GCC 12 doesn't yet support <format>.

    But instead of making that clear to you it just does its thing until it hits a wall. You gotta figure it out.
  • 6
    @LotsOfCaffeine So what should it do? Refuse C++20 support completely until all of it is implemented? That's not how it works. No compiler does that.

    You are expected to check the compiler documentation or some cheat sheet like https://en.cppreference.com/w/cpp/....
  • 2
    @LotsOfCaffeine What would be a better way? GCC needs a way to enable the C++20 features it already supports, so it makes sense to have a -std=c++20 flag.
  • 1
    @Fast-Nop well that expectation is fucking stupid

    I mean its not like GCC is known for having any coherent or useful error message, but none at all is another step

    @happygimp0 I'd suggest either making it an experimental flag or giving the user a warning stating that the support is incomplete.

    But then again, I feel like user experience is very far down the list of priorities for the C++ folk. They just wanna feel smart for using such a complicated and hard to use tool.
  • 1
    @LotsOfCaffeine so are we supposed to junk up the warnings with garbage because someone doesn't know their tools? C++ isn't for casuals.
  • 1
    @Demolishun Well, technically, it could give a useful error message like "that feature is not supported in this GCC version". But that would require already implementing the detection of unimplemented features - which doesn't make sense, especially in this case, because format isn't even part of the compiler itself, but of the libraries.
  • 2
    @Fast-Nop I am still waiting for the Rust plug to come. Or Rust does this.
  • 1
    -std=c++20 is actually the experimental flag.

    At least until they announce full support.

    I side with the multiple people who already said that not knowing your compiler support is your fault only.

    Compilers could do a better job at that? Yes. Guess what? Feature macros are excellent for that. Guess what? They are part of the still not universally implemented changes 😂
  • 0
    @Fast-Nop gcc also provides their libstdc++, which that cppreference site you sent even mentions. So yes, it would absolutely possible for them to have a format header that just has an

    #error "This header isn't yet supported"

    inside of it.

    But that would honestly be a bad solution. The compiler should make it clear that its support of the spec is incomplete. I mean for gods sake the modules feature is only partially supported and that was one of the things the C++ comittee hyped up.

    Passing std=c++20 behaves the exact same as passing std=c++17, despite it not adhering to that spec. It should force me to pass some experimental flag or give me some sort of notification, everything else is just bad ux.
  • 1
    @Demolishun you say this like gcc's warnings aren't already useless most of the time. But yes, we absolutely should give out warnings that inform the user instead of just letting things happen.

    And just so you know, I'm not a "casual". I do this shit full time. But this sorta attitude is exactly why C++ is such a cancerous language. On the one hand there's a small gem of a well designed language and stdlib in there, but it's tainted by complete morons like you who keep giving themselves facials when they think about how amazingly complex and difficult to use their tooling is and how godlike their programming powers are.

    Say what you will about Rust (you brought it up), it ain't a perfect ecosystem. But at least the people that make it actually give a shit about their users. Their compiler is actually meant to be a useful tool.
  • 1
    @CoreFusionX idk I feel like the "experimental" flag and the stable one shouldn't have the exact same format, but maybe I'm just expecting too much.

    Well it's nice to hear that they are giving us feature macros at some point, still waiting on them to announce some way to convert enums to strings in a standard fasion, maybe in c++32...
  • 1
    @LotsOfCaffeine

    While I'm not gonna argue against the c++ committee bring able to do a better job, I dare question you doing this full time for a very long time. Otherwise you'd know that it's 2023 and it's only now that c++11 is starting to be enforced for granted...
  • 1
    @CoreFusionX couple of years now. Thing is, before that I did a bit of C# (after dotnet core) and now some Rust at home.

    So I'm very much used to, let's say more "modern" toolchains.

    When I started working with C++ and cmake I felt like I was being forced to build a house with nothing but a shiv from the stone ages. The compiler errors specifically seem to be designed in a way to make it harder.

    Though I got lucky in that the project was fairly recent so we had C++17 going (or at least most of its features I guess).

    There are projects in the company where I'm not even sure C++11 is used.

    And a disturbing amount of developers who don't know what RAII is. I'm talking try-catch with a mutex::unlock in the finally block...
  • 0
    @LotsOfCaffeine I have never found it complex. Just the new user base seems less inclined to figure things out. The cppreference didn't exist when I learned this. The internet was barely existing. So we had to figure everything out. Competent people expect others to do the same. Being offended by someone describing the ecosystem is bizarre.
  • 0
    @Demolishun It's not about less inclined to figure things out, it's about the ecosystem not throwing rocks at the new users.

    I'm sure it was a lot harder to learn during the age of paper books, but that doesn't mean it should continue to be hard. Granted, C++ holds a lot of historical baggage and they generally want to preserve compatibility, which is commendable.

    But an ecosystem that is hostile to users, especially new ones, isn't something I would be proud of.
  • 1
    I don't see what is hostile about the ecosystem. It was a false expectation to treat a standards implementation as monolithic. You found out pretty quickly that is not the case. Finding out that some features take longer than others for any particular standard is just information. Some things have taken years to implement.

    Compiler vendors are not required to implement features in a particular time frame. I don't think we would want that. It would lead to bad implementations we have to live with. Spend some time on r/cpp to get an idea of what I am referring to. There are libraries in the standard that they cannot change or it would break things. Some of these implementations are just plain bad. I think the standard regex library is an example of this.

    There might be a way to test for features in your code during compile.

    I don't write compilers. That seems like tedious work. I am grateful someone else did and gave it away.
  • 0
    @LotsOfCaffeine when stuff gets into the standard that is implemented badly. It is often not changed because of the ABI. A lot of header only stuff is this way. There is a lot of effort spent on maintaining the ABI between compiler versions. So taking time to not inject garbage into the ecosystem is why some things take longer. I may be confusing standard and implementation here.
  • 1
    @Demolishun

    The biggest roadblocks, at least on the later standards really had to do with dealing with windows and other non POSIX stuff in the stdlib implementations.

    It's down to only three major players anyway.

    Usually GCC was first, clang arrived a bit later, and msvc was abysmal.

    Lately Microsoft has picked up the pace rather pleasantly, so they usually reach compliance by the time the next standard releases.

    And in fact, compiler support for c++ 20 is actually almost complete.
    https://en.cppreference.com/w/cpp/...
  • 0
    @CoreFusionX I ran into a bug in a version of gcc and to get work done I switched to msvc. Microsoft is doing much better these days.
  • 1
    @CoreFusionX only modules and the calendar+timezone lib are missing.

    Ironically, I played around with the partial module support that's already there, but you have to pass an extra argument alongside std=c++20...

    @Demolishun some implementations are plain bad? Probably. I have yet to use the regex lib myself for more than one check.

    Though sometimes the specification is just plain bad, looking at you vector<bool>
  • 2
    @Demolishun wait, if C++ isn't for casuals, then why do most people that use it yell that people shouldn't ever use higher level languages, because C/C++/Rust are superior in every way, and everyone should always learn those first?
  • 1
    @Parzi I think people should learn C at some point. Because it teaches you how the computer actually operates. C++ brings a ton of complications. I like C++, but I am used to its bullshit. Python is more fun.
  • 1
    @Parzi also, I mostly use Qt library to avoid a lot of the standard bullshit. I would say Qt is a much nicer experience.
  • 1
    @Demolishun sure learn C, maybe together with assembler

    But I think we shouldn't teach C in C++ courses
Add Comment