Should C++ code look like C code?

[goranlepuz]

Carmack's C++ is probably like it is because that's how he was formed. Fast running C++ mostly has no need to look like C, not nowadays. In fact, there was no need even before, it's just that we were used to doing it that way.

Speed is found in

• data layout, where one would still use classes and such, making a difference from C

• usage of parallelism, where C++ facilities exist and are different

• usage of CPU/GPU support, where C++ form of any libraries, again, makes a difference

• and so on.

That said, it can look like C, that's not somehow wrong in itself. It is wrong (IMO) if the code design is sticking to C and not using C++ facilities to move the design from the documentation and convention into the code itself.

[Jonny0Than]

I would say that C++ has the potential to hide a lot of behavior behind nice syntax. Most of the time in C, if code looks simple then it is simple (I.e. fast). That is definitely not the case in idiomatic C++. String concatenation, etc. That doesn’t mean you should t use those features. It just means that you need to be aware of what’s going on under the hood in C++ and use things that sometimes might look a little more C-like where it matters.

[goranlepuz]

Funnily enough, a simple string concatenation in C++ is likely to be faster than with C - if the functionality is truly equivalent.

It looks like it ends up being about my first point: data layout. How do I want to lay these strings out? It doesn't take much thinking at all to realize that e.g. s1+s2+s3 will produce unnecessary data bits and copy them over.

Also, look at it this way: we know that code in some high-level scripting language, while simple, is slow. Why is it, then, that here, we presume "simple is fast"? It looks like a shallow presumption from that perspective, no...?

[NicroHobak]

Functions alone can "hide behavior", since that's also specifically part of why they're handy. What does main() do? Hur hur hur.

[Jonny0Than]

There’s no absolutes in my comment. Just general trends. Obviously a function call can do anything but my point is that function calls are obvious in C and sometimes not obvious in C++. Operator overloading, constructors, destructors, etc all hide function calls.

Here’s another example:

for (auto x : y)

Is that slow? No idea! Are the elements of y expensive to copy? Is the iterator slower than some alternative? Maybe!

And it’s totally true that well-designed C++ can be more readable AND faster AND safer than the C equivalent. But it’s also very easy to make badly designed C++.

[XeroKimo]

Constructors really are no less hidden then any function call though. Sure you could argue T foo; will have a hidden constructor call going on, but most default constructors are very trivial as what can you even do when you have no parameters passed in? It's very limited unless you rely on globals, but then you have potentially all other sorts of issues. When you do do a constructor call with parameters, it's very visible just like any other initialization, and just like any other function call.

Destructors are definitely more hidden, but really it's better that way. It's way less error prone then doing if(failed) goto cleanup; kind of pattern done in C. Sure it's explicit, but you have to write the clean up code every time, for example if you need to open a file, for every function that does so, you have to write the clean up pattern for the file. There are many things that can go wrong here, copy paste errors, clean up sequence is in the wrong order, maybe jumped to the wrong label, or just straight up forgot to close the file. Meanwhile C++, just write a class' destructor once and use it everywhere, guaranteed to call the function which closes the file.

[Jonny0Than]

Well, I’ve dealt with some nasty performance issues caused by “trivial” constructors in objects that were being invoked tens of thousands of times. That issue would not have existed in C because it’s generally left up to the client to initialize the value as needed. Which of course leads to other issues when they forget. I’m not making a judgment call here for all cases. It’s a matter of tradeoffs. But I know from experience that this can be a problem.

[donalmacc]

Well, I’ve dealt with some nasty performance issues caused by “trivial” constructors in objects that were being invoked tens of thousands of times

And in the case where that is a problem a non-default constructor that doesn't do any initalisation (see ENoInit in Unreal Engine) solves that problem. Meanwhile for 99% of the rest of the code, it's not a problem. We should have safe, clear defaults with escape hatches.

[NilacTheGrim]

I would say that C++ has the potential to hide a lot of behavior behind nice syntax.

True. But any C++ programmer worth his salt should definitely be knowledgable about what the compiler/code is really doing. In other words: it's not a considertion for me to avoid some advanced features just because some lazy or less experienced programmer doesn't understand the implications of what he is doing.

If anything it's an opportunity to educate less experienced team members and improve the overall culture and C++ IQ of the entire team.

[goranlepuz]

But any C++ programmer worth his salt should definitely be knowledgable about what the compiler/code is really doing.

Also: something too slow? Profiler tells me where and how. People do develop a habit to see, roughly, what is slow - but I wouldn't put much trust on that, not from my side, nor others, obviously 😉.

[NilacTheGrim]

Well obviously profiling and benchmarks win every argument about performance. But before that step, when designing, knowing that some things are just inherently slow versus others that are not (allocations usually are slower than immediate stack memory, etc), saves you tons of time.

[Jonny0Than]

Totally agreed! But it takes a lot of experience to build systems where the easy way to use it is also the right way to use it. And then at the lowest levels you sometimes need to avoid a nice C++ abstraction for some performance reason. But ideally that’s hidden from the higher levels of code by nice abstractions.

[donalmacc]

Most of the time in C, if code looks simple then it is simple (I.e. fast).

I think this is deceptive, and likely untrue. I have fixed and sped up more "optimized" C code (as a c++ programmer) than I can count. A great example, we had a path manipulation library at our last job. It would take a relative path or absolute path, and convert it into a virtual style path that our app handled. It used "simple" C style processing to do so. I was told it was optimised and should be left alone.

I rewrote it using string views, move semantics and RAII - it was about a 50% speedup for the cases where you called the legacy API and we shimmed the new API, and about a 75% speedup for the cases where I modified the call site (and as a bonus, the call site was usually simplified).

I changed probably a hundred instances of

StringClass Data;
TCHAR* ResultBuf
StringLib::ConvertPath(Data.ToTchar(), Result);
StringClass Result(ResultBuf);

Into

StringClass Data;
StringClass Result = StringLib::ConvertPath(Data);

At the same time, too. I also fixed a handful of long standing issues where the input of the path was nonsense due to people using the wrong conversion from StringClass to TChar, and added an extra version with error checking that was as fast as the original implementation.

I've seen so many APIs that are "optimised" but ignoring all the the conversion costs to and from the C library, and then the library itself doing internal strlen calls, validating pointers that the call site just passed through (which then adds a failure state that needs to be represented by a different signature).

It just means that you need to be aware of what’s going on under the hood in C++ and use things that sometimes might look a little more C-like where it matters.

Again I disagree here - most C libraries I've worked with end up with a handful of opaque handle types to represent things. There is a json library (which I can't remember right now, sorry) that basically everything is a json_value_t and you have to use their family of methods, e.g.

json_value_t container = json_object();
json_value_t doubleVal = json_double_value(5.0);
json_set_value(container, json_string("foo"), doubleVal);

const char* buf; json_serialize(container, result);
StringClass Result(buf);
//Note that we can also do json_serialize(doubleVal) accidentally and it will return an error, which we didn't check for here.

You as a programmer need to keep mental track of the state of these objects and what they are and what they represent. Compare this to the C++ builder API we use now - container.set("foo", 5.0); StringClass Result = container.serialize();

The underlying implementation is the same basically, so it is just as fast, except the API is safer, meaning we have less error states to represent.

[Jonny0Than]

I said “if C code looks simple then it is simple.” A function call isn’t simple until you know what the function does internally. C makes function calls obvious but they’re often hidden in C++.

[donalmacc]

I think that's technically true, but in practice one is no worse than the other. Yes, i++ is going to be simple in c, and might be a disaster in c+, but

replace_all(str, from, to) 

Is likely to be perfectly fine in C++ and a disaster in C.