On: Why C++ is back

[marris]

Game... maybe HFT... maybe High performance server... sure OS... most are not (C++ != C, C++ != assembly) Implementing a language... maybe Database... sure Numerical library... most are not Crypto library... most are not VM... maybe Browser... maybe the rendering engine

Again, you need to wrap your mind around:

(1) Some things will be written in C++

(2) C++ is not a synonym for "low-level." Many of your examples are really referring to C and assembly. Why would you prefer a C++ implementation of a crypto library to a C one?

(3) The vast majority of computer code written today is not for any of these systems. Lots of code uses these systems, but most people are happy with language bindings for a crypto API. Or to a numerical processing library. Or running on a VM running on an OS.

Does anyone have empirical data that the C++ fraction of software written today is increasing? If so, then you have a case. I'm going to guess that that fraction has been falling for quite some time, and will continue to fall.

[AnthonyMouse → marris]

>Why would you prefer a C++ implementation of a crypto library to a C one?

Here's an example from the EVP_Digest* man page from OpenSSL, with some comments added:

EVP_MD_CTX *mdctx;

// forget this part and get undefined behavior (but maybe it seems to work, sometimes)

mdctx = EVP_MD_CTX_create();

// forget this part? more and different runtime errors

EVP_DigestInit_ex(mdctx, md, NULL);

EVP_DigestUpdate(mdctx, mess1, strlen(mess1));

EVP_DigestUpdate(mdctx, mess2, strlen(mess2));

// md_value allocated with malloc()? don't forget to free()

EVP_DigestFinal_ex(mdctx, md_value, &md_len);

// forget this part, or remember it but miss an "if(err) return -1" statement somewhere? memory leak

EVP_MD_CTX_destroy(mdctx);

Comparable C++ implementation:

// RAII, compile error if you don't provide constructor argument instead of runtime error if you don't call init function

EVP_Digest_CTX ctx(md);

ctx.update(msg1, msg1_size);

ctx.update(msg2, msg2_size);

// return simple object: typed dynamic byte array + size with its own destructor, both digest and ctx destructors get called when function returns from anywhere

EVP_Digest digest = ctx.final_result();

And it's 4 lines of code instead of 7.

Can you explain why I would want the C version?

[furyofantares → marris]

I was responding to your statement that you shouldn't be doing byte-level manipulation unless you're writing a device driver or compression library. The fact that C and assembly are used for some of my examples does not take away from them.

I agree that there is a ton of code being written where byte-level manipulation is not needed and is not appropriate. But there is still a ton of code where it is needed or appropriate, and you misrepresent that when you say you shouldn't be doing it unless you're writing a device driver or compression library.

[pjmlp → marris]

Symbian, BeOS(Haiku), z/OS, MacOS X device drivers, Windows COM infrastructure and user space drivers are all written in C++.

Additionally Microsoft is now replacing parts of the Windows C codebase to C++, as mentioned at the latest Build 2012 conference.