Hacker News new | past | comments | ask | show | jobs | submit login

“Wizard” is the right way to put it. There’s a certain kind of “experienced” developer who enjoys being the local guru way too much. Even regardless of technology, their projects are invariably set up in such a way that no one can do anything without them.

C++ seems perfect for these people because there are so many little traps and arbitrary rules to remember. “Ha ha, you wrote for (const auto x: y) instead of for (const auto& x: y)? Stupid fool!”

(Or is it auto&& now? decltype(auto)? I honestly don’t remember and don’t really care.)

I’m not remotely suggesting all or even most C++ experts are like this, but anecdotally, their share is higher than among, say, Python programmers.

It’s not like Rust is particularly easy to learn. On a conceptual level, it’s probably harder than C++ (traits, generics, lifetimes). It’s just so much less arcane.




Both are wrong, east-const is the one true way!


I sympathise with East Const, but immediately I am just reminded of another problem with C++

The defaults are wrong. Const should have been the default. Whereupon "East Const" doesn't matter, all the variables which are mutated get labelled. Similarly "explicit" should be the default (nobody wants your random single parameter constructor to be implicitly called, stop that) and "override" shouldn't be (If I name my method foo why is it my responsibility to first check whether some other bozo named a method foo so that I don't "override" it ? The compiler can and should tell me this won't end well†)

† Rust brought me around to the idea that some other bozo's quack() method has no business sharing a namespace with mine just because we're both Ducks, if I wanted to override the shared method I'd have re-implemented Duck::quack() not added my own quack() method. But in the C++ world I'll stick to just saying override shouldn't silently be the default.


> The defaults are wrong. Const should have been the default.

yeah no.

    struct foo { 
      int x;
    };
would not be compatible with C because the int would be const, that would have made the language particularly useless.


Right, C++ has CV-qualified member variables†, because of course it does.

I'm not talking about those. I think they plain shouldn't exist, but it's a separate discussion from the discussion about the defaults.

But yes, this means you can't cut-and-paste C code. I appreciate that this is disappointing for the "Actually we already have lots of C++, it's just that it's mostly .c files and doesn't realise it's C++ yet" people. Set your sights higher.

† Yes, this insanity is also available in volatile flavour.


Not having that would mean no access to the Windows SDK, no access to a libc, the macOS frameworks, etc. It's far from negligible. It takes other languages years to wrap the OS APIs correctly, if they even do it.

Why would CV members be insane ? Having const members has been very useful for me when refactoring codebases, to make sure that I knew every place modifying such a member. It has never been a hindrance, just plain positive, and not having it would mean one more rule to remember (and having to explain students why you can write "const int foo;" here and not there)


Uninitialized constant foo

They actually can't (well, shouldn't) write "const int foo;" as a local variable because the compiler needs to know its value. And that gives the game away.

These are already different cases, yes both the structure member and the local variable are names with types, but they already need to be explained separately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: