8 ms·

I think not. The language is too big [it's always odd to see some people say things like "the language is still too big", as if some recent effort has succeede

by marris 14y ago

I think not. The language is too big [it's always odd to see some people say things like "the language is still too big", as if some recent effort has succeeded in making the language somewhat smaller, but not small enough... every recent effort has actually made the language bigger] There are too many ways to write bad code and too few ways to navigate bad code. It's hard enough to pick up a big C# program and figure out what it does ... C++ is not easier. I'm not sure why there's all this excitement over bit twiddling... every language lets you twiddle bits. I can only assume the cool feature here is mislabeled, and the authors are really excited about memory twiddling. Fair enough. It's fun to write code that touches data structures at a byte level. But it's not fun to read/fix someone's buggy byte manipulation code. If you're not writing a device driver, or your own compression library, then you should not do this. Now, I am a big fan of people learning low-level system details, provided they do it with some small C program, or by doing a project for their OS or compilers class, or by maybe working on some open source project. But anyone who chooses C++ when he doesn't need it reminds me of the kid who, rather than painting on paper, decides to paint on the carpet. You could do it. It's also probably a lot of fun. There's even the remote possibility that you'll improve the carpet. But you probably won't. You'll probably just make a mess. And it won't be fun to clean it up.

furyofantares 14y ago
> If you're not writing a device driver, or your own compression library, then you should not do this Or a cutting edge game, or a high frequency trading system, or a high performance server, or an operating system, or implementing a language, or a database, or a numerical library, or a crypto library, or a VM...
- xyzzy123 14y ago
  Or a web browser....
- 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.
dmcg 14y ago
We've added 3 rounds of features to the language and it's still too complex.
jandrewrogers 14y ago
In practice, C++ is considerably smaller than the theoretical extent of the language. Every C++ code base I ever worked on restricted itself to a subset of the possible feature space. With C++11, you can have a restricted subset of C++ that is actually pretty decent as a programming language and relatively easy to maintain. With respect to bit-twiddling, the advantages of C/C++ are not intrinsic; many other languages have broken implementations for this purpose. For example, a glaring deficiency in Java is the lack of large unsigned integers which are useful for many types of algorithms. You can always implement these algorithms with signed integers but they may be much slower as a consequence. For most people though, memory control and optimization is the primary reason to use C/C++. While I can see why it is difficult code for people uncomfortable with it, I think you overestimate the complexity for people that have done it for years. Like LISP, you have to become used to it. It is similar to the reason why, despite some arguments, there are many huge C/C++ code bases that rarely leak memory despite very active development. Proper idioms and use are a discipline like anything else. C++ is never coming back for front-end applications. It is unnecessary and inefficient for that purpose. However, on the server side (where I do development), C/C++ is expanding very rapidly. Five years ago almost all of the server engines I worked on were written in Java. These days, all new development is in C++. The reasoning is pragmatic: C++ offers much better performance and latency characteristics for server engines, primarily due to its excellent memory behavior and efficiency. The latency and throughput differences are often integer factor relative to other languages for server workloads, so it is not a small difference and people are very sensitive to operational costs and footprint these days. I pretty much hated C++ for years but with C++11 it is not great but it is adequate. Too much junk glued onto the language too many times. But until something remotely as capable becomes widely used, C++ will be with us for a long time, particularly as power efficiency becomes more important.
- oelewapperke 14y ago
  There's also, when it comes to hirability, the other end of the equation. When you know Java, PHP or even Ruby and Python, you've got craploads of competition. There's loads and loads of acceptably capable programmers in those languages. I think the amount of good enough C/C++ programmers is relatively tiny. Certainly compared to the amount of code in these languages.

by marris 14y ago

furyofantares 14y ago

> If you're not writing a device driver, or your own compression library, then you should not do this Or a cutting edge game, or a high frequency trading system, or a high performance server, or an operating system, or implementing a language, or a database, or a numerical library, or a crypto library, or a VM...

xyzzy123 14y ago
Or a web browser....
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.

dmcg 14y ago

We've added 3 rounds of features to the language and it's still too complex.

jandrewrogers 14y ago

In practice, C++ is considerably smaller than the theoretical extent of the language. Every C++ code base I ever worked on restricted itself to a subset of the possible feature space. With C++11, you can have a restricted subset of C++ that is actually pretty decent as a programming language and relatively easy to maintain. With respect to bit-twiddling, the advantages of C/C++ are not intrinsic; many other languages have broken implementations for this purpose. For example, a glaring deficiency in Java is the lack of large unsigned integers which are useful for many types of algorithms. You can always implement these algorithms with signed integers but they may be much slower as a consequence. For most people though, memory control and optimization is the primary reason to use C/C++. While I can see why it is difficult code for people uncomfortable with it, I think you overestimate the complexity for people that have done it for years. Like LISP, you have to become used to it. It is similar to the reason why, despite some arguments, there are many huge C/C++ code bases that rarely leak memory despite very active development. Proper idioms and use are a discipline like anything else. C++ is never coming back for front-end applications. It is unnecessary and inefficient for that purpose. However, on the server side (where I do development), C/C++ is expanding very rapidly. Five years ago almost all of the server engines I worked on were written in Java. These days, all new development is in C++. The reasoning is pragmatic: C++ offers much better performance and latency characteristics for server engines, primarily due to its excellent memory behavior and efficiency. The latency and throughput differences are often integer factor relative to other languages for server workloads, so it is not a small difference and people are very sensitive to operational costs and footprint these days. I pretty much hated C++ for years but with C++11 it is not great but it is adequate. Too much junk glued onto the language too many times. But until something remotely as capable becomes widely used, C++ will be with us for a long time, particularly as power efficiency becomes more important.

oelewapperke 14y ago
There's also, when it comes to hirability, the other end of the equation. When you know Java, PHP or even Ruby and Python, you've got craploads of competition. There's loads and loads of acceptably capable programmers in those languages. I think the amount of good enough C/C++ programmers is relatively tiny. Certainly compared to the amount of code in these languages.