Hacker News Reader

> you find a simple line of C++ that says "y=f(x);", and it can do anything

In practice you know what it does because of the context. Devs don't usually override operator to mean the opposite of their meaning. And in case there are doubts, editors have become pretty good at pointing out at the right location.

It is the same in C. is `y` or `f` or `x` a macro that could potentially have `return` or `goto` statements, that can potentially use a `__LINE__` meaning you can't use two occurrence on the same line or within another macro. if `f` is a function, what are its side effects? Do conversion happen depending on the type of x? Or is it like a va_arg function that need the exact right type?

What i mean is that if you want to obfuscate things, you can do it in C just like in C++. But in normal code it's all pretty obvious.

It's not that anybody wants to obfuscate things. But with clever mechanisms, people start to notice that they did only when it's too late.

C macros can be useful, I would enjoy programming in this language much less if they weren't there. And if I build a reasonable abstraction with them, it's as little as a grep or go-to declaration to find out the definition. There are no implicit complicated resolution mechanims, no complicated internal data structures that keep what should be application data isolated in the compiler (so it has to be duplicated in other parts of the code). With macros, I just search for the name, and will usually quickly find the definition with very little additional indirection.

> The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand.

> For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one.

I have yet to see any of this be an actual problem in real-world projects.

I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects.

> I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects.

Well, I for one had the opposite experience. I started programming in C++, and writing, reading and debugging lots of C++ code. It was not "modern" C++, since I stopped doing so around 2006. I embraced C out of personal despair with C++, especially the C++ of other people. For my personal projects, I can still enjoy using "my" favorite subset of C++ (basically, without objects nor pointers, and building the data structures by composing stl containers). Yet, anytime I have to deal with an unknown piece of C++ it is a nightmare. Especially since it is very easy to hide the behavior of the code.

>I have yet to see any of this be an actual problem in real-world projects

Just on Monday, I was bitten by a bug caused by operator overloading. I'm building a static analysis tool in C++. There's a method `getType()` that returns the qualified type of an expression. I had a call to `getType()` nested in some other calls, e.g. `expr->asAssignmentExpr()->getRHS()->getType()->getSomeQualifiedTypeProperty()`.

The creators of the `QualifiedType` type that's returned by `getType()` had overridden the class member access operator to return an UnqualifiedType. This problem took me an embarrassingly long amount of time to diagnose. The compiler error messages told me that `UnqualifiedType` doesn't have a property `getSomeQualifiedTypeProperty`, but I couldn't see why I was getting an unqualified type from a method that is supposed to return a qualified type. I searched the documentation online, searched the header files, tried reinstalling the library, nothing made sense.

Then, I learned this operator had been overloaded. So, I just needed to write `expr->asAssignmentExpr()->getRHS()->getType().getSomeQualifiedTypeProperty()`.

Ouch.

> So, I just needed to write `expr->asAssignmentExpr()->getRHS()->getType().getSomeQualifiedTypeProperty()`.

with any decent IDE you'd type something like

    expr.as<enter>.get<enter>.get<enter>.get<enter>

and you'd see the following:

https://streamable.com/xib4s0

so I fail to see how this can be an issue if you don't use prehistoric tooling

Well... What's the difference compared to C? f(x) can also do anything, including side-effects, changing mutable state, etc. Worse if it's a macro.

In C, n=f(x) plainly means the variable n is assigned the value returned from f(x). While you don't know what f(x) does, you can tell it is a function.

In c++, the = could be a function too, that does unexpected things. Critically, if you are unaware of the side effects of that = operator, you may be doing things you don't want to do. The most likely issue would be performance if you are repeatedly using the = operator thinking it is a simple operation. Like if someone is being clever and uses the Active Record model and you are unexpectedly doing database writes with what you thought was a local object with no side effects.

To not have this happen, of course, you could read the entire object definition, but then you need everyone working on the project to have 100% of the code committed to memory. This is why you will likely find rules in the coding style guide of whatever company banning such practice after someone is bitten by it.

I have indeed seen horrible things done with overloading andnto a much lesser extent copy consteuctors. But don't forget inheritance or partial template specialization. There are so very many ways to make subtle problems. In C you basically have evil macros and bad casts, which are bad enough.

Are there any languages since C you think have gotten it right?

> Are there any languages since C you think have gotten it right?

Basically any language except C++ ? ;)

There's lots of languages that I use and enjoy: lua, julia, octave (just for numerical computation), python (except for numerical computation), the unix shell I find particularly beautiful and elegant (even with its obvious warts). Hell, even javascript the language is mostly OK, if it wasn't for its toxic development ecosystem.

Do you mean npm and its ability to both facilitate and encourage gigantic dependency trees? I'm worried julia and rust will get lesser versions of that problem.

Yes. That's what kills the language for me.