4 ms·

Game... maybe HFT... maybe High performance server... sure OS... most are not (C++ != C, C++ != assembly) Implementing a language... maybe Database... sure Nume

by marris 14y ago

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.

furyofantares 14y ago
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.
AnthonyMouse 14y ago
>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?
pjmlp 14y ago
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.

by marris 14y ago

furyofantares 14y ago

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.

AnthonyMouse 14y ago

>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?

pjmlp 14y ago

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.