6 ms·

Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not s

by mpu 11y ago

Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not seem to apply his guidelines into any practical project of his. As a programmer, I'm suspicious when people have opinions and give advice but never showed me more than snippets of code. Like a master tailor that wouldn't sew. How come he gets that much recognition and respect? I would be much more inclined into accepting advice from someone like, say, Carmack, that has successful projects in C++ under his belt. (Many people consider Doom 3's code beautiful C++, yet, the choices made there are very controversial, and far from "modern".) I also put Bjarne Stroustrup in the same category. What do you think?

solipsism 11y ago
Are you putting Stroutrup in the I'm suspicious of his advice category or the He teaches from experience category?
- rshaban 11y ago
  It would seem from the context of his statement the latter, especially given that he built C++
  - lfowles 11y ago
    It could also go the "ivory tower" direction
  - solipsism 11y ago
    Creating C++ means you're likely to know the ins and outs of the language. That's a necessary condition to being a good C++ programmer, but it's not sufficient. It's not at all obvious to me that Stroustrup would be a good C++ programmer or even a good C programmer.
    - innguest 11y ago
      Macho man! If you need to know the intricacies of an abstraction in order to use an abstraction, then it's not a very good abstraction. Do engineers know the ins and outs of concrete and rebar? Or do they offload that knowledge onto manufacturers? But programmers can't offload anything onto the language creator or they aren't real programmers. I'm glad for all the work the SBCL and GHC teams put onto their languages so I can use their abstractions without needing to know the ins and outs of performance optimization. Maybe one day you'll find a language you like that allows you to focus more on your problem domain and less on its traps, idiossyncrasies and inadequacies.
      - solipsism 11y ago
        What? You're reading way too much into my use of the term ins and outs. I didn't say good C++ programmers must know how to implement a C++ compiler. By ins and outs I meant: the syntax, the evaluation strategy, the features and facilities provided by the language and toolsets, etc. You need to know those kinds of things to be a good programmer, and every language creator is likely to know those things about the language she created. My point was that knowing those things is necessary but not sufficient to be a good programmer. Macho man! ... Maybe one day you'll find a language ... Your tone is really shitty, and it's made worse by the fact that you're being shitty toward some imaginary strawman you've put in my place. For what it's worth: I greatly value good abstractions, I think appropriate high-level languages should be used whenever there's not a good reason to use low-level languages, I think leakier abstractions are shittier abstractions, I think C++ is full of the leakiest of abstractions, and I think Haskell and lisps are great. I know you're really eager to shit on others because you think you've achieved some kind of higher level consciousness, but you should probably work on your knee-jerk reactions.
- ksherlock 11y ago
  I'm suspicious of his advice because the c++ he wants isn't the c++ I want.
lfowles 11y ago
I think some of the most solid and forward thinking advice I've seen and used in my C++ have come from his books. As for Carmack: I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set. http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ
mikekchar 11y ago
His webpage: http://www.aristeia.com/ http://www.aristeia.com/ indicates that he has been a programmer since 1972. Even if he has been doing training/consulting for a couple of decades, that leaves a lot of time to get the basics down. I've never met him, though I have browsed one of his books once. My own personal feeling is that books like these can be invaluable for people starting out in the industry. It gives you a reference point to relate to. If he can explain things well and people can understand his writing, then it can be useful even if the person isn't the best living coder on earth. At some point in your development, you need to branch out from what people are saying in books and start to form your own opinions. You have to start questioning what the "experts" are saying and try to experiment with other techniques. It is frustrating when people hang on to certain ideas just because a famous author said it. Sometimes it holds us back. It doesn't make their contribution any less valuable, though, because at least newbies are getting to a certain level due to the well written books.
- lfowles 11y ago
  > It is frustrating when people hang on to certain ideas just because a famous author said it. Sometimes it holds us back. What I appreciate is that most of what he says (via GotW or the books) comes with the rationale and a code snippet instead of a blind assertion that this is The True Way.
- sbov 11y ago
  You should still read them though. But instead of reading them like an instruction manual, you should read them for an eye towards when you would disagree with them, when you wouldn't, and why.
- jlarocco 11y ago
  I largely agree with you, BUT, this version of Effective C++ was less opinion and style oriented and more a guide to avoiding easy to make mistakes with some of the new C++11 and C++14 features. Not following many of the guidelines will result in incorrect and broken code. My recollection of the older books is that they covered "best practices," and ignoring them may have been bad style, but the code would still be technically correct. Quite a few are still style issues, but it's important to recognize the difference before deciding to ignore them :-)
coliveira 11y ago
His books are well-researched, that is for sure. However, you cannot use his ideas as gospel. He will try to teach the most conservative way of using C++, not the best for your purposes. I particularly think that there are several areas of C++, such as exceptions and constness that should better be avoided if possible. But each one has a different way to use the language.
- netheril96 11y ago
  I could understand why some people like to avoid exceptions. But constness? Really?
  - coliveira 11y ago
    Constness when used on classes introduces a way to create objects that behave differently in different contexts. Are you calling a member function from a const or from a non-const pointer? Depending on that you could be running different code. In my opinion you should make your mind about what the class does: is it mutable? then don't use it with const. Unfortunately, you are still required to use const in many places: copy constructors and operators, for example. However, you can still choose to minimize the use of const, and avoid it whenever possible.
    - Negitivefrags 11y ago
      That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
      - smikims 11y ago
        I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include <iostream> void foo(const int& a, int& b) { std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; ++b; std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; } int main() { int a = 1; foo(a, a); } Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes, const is useful, but if you don't know what it actually does it will bite you in the ass, just like most of C++.
pikma 11y ago
His past C++ projects (or lack thereof) do not tell much about the quality of his books. He teaches people how to master C++, and that's a very precise skill. He doesn't claim to teach how to organize software, or how to manage collaboration between people, or any of the other skills that are necessary for a successful software project. It's the same way that good grammar is only one of the skills involved in writing a great novel. Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.
- millstone 11y ago
  His book is titled "Effective Modern C++," which necessarily contains opinions about what is effective and what is modern. Without practical experience writing software, his opinions won't be grounded, and so his advice won't be sound. That said, I think he does a good job being even-handed. For example, his chapter on auto covers both advantages and pathological cases, and goes on to say: First, take a deep breath and relax. auto is an option, not a mandate. If, in your professional judgment, your code will be clearer or more maintainable or in some other way better by using explicit type declarations, you’re free to continue using them. But bear in mind that C++ breaks no new ground in adopting what is generally known in the programming languages world as type inference. So he is not excessively proscriptive.
- lambda 11y ago
  > Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example. Not sure that Strunk, or the successor Strunk and White, are good examples here; they didn't "really grok grammar", in fact, they were pretty bad at both understanding it and teaching it, and their advice consists of a lot of incorrect information and vague platitudes. E. B. White was actually a good writer, but much of his writing violates the prescriptions in The Elements of Style. Geoff Pullum has a good rant on the subject, if you want more detail: https://chronicle.com/article/50-Years-of-Stupid-Grammar/25497 https://chronicle.com/article/50-Years-of-Stupid-Grammar/254... So, this is exactly why it's an interesting question to test if the suggestions in the "Effective C++" series are actually good suggestions, or are just someone expounding rules that sound good in theory but don't actually help in practice.
IvyMike 11y ago
Anecdotal, but a friend of a friend talked with Meyers, and Meyers said he has not worked on any large scale C++ programs in a while. That being said, I have worked on large scale C++ projects, with a lot of people smarter than me, and the biggest criticism of Meyers' books and advice would be "necessary but not sufficient". I can't, off the top of my head, think of anything he recommends that would have been controversial amongst my peers.
3legcat 11y ago
>Is this guy actually writing C++ programs in the wild? Well, I read one of his articles which you can find here: http://www.artima.com/cppsource/top_cpp_books.html http://www.artima.com/cppsource/top_cpp_books.html In it, he writes about his role with C++: "I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it. It’s not by virtue of any intimate association with the language’s standardization, either, because I’ve never been a member of the C++ standardization committee, I’ve never been on the committee’s mailing lists, and I’ve never attended any standardization meetings. My knowledge of the inner workings of the committee—including the things that have had a significant impact on it—is based on what I’ve read and heard from others. This means that I may be ignorant of important forces that shaped C++ as we know it, because those forces may have been felt only within the committee. Given that I don’t really use C++, nor do I help specify it, you might wonder what I do do. Fundamentally, I study C++ and its application. I gather as much information as I can about the language and its use (from books, magazines, newsgroups, email and face-to-face conversations with developers and members of the standardization committee, experiments with toy programs I write, etc.), organize and analyze what I find, then I package my findings in concentrated form (e.g., books, magazine articles, technical presentations, etc.) for consumption for people like you—people who do use the language. Your job is to employ C++ as a tool to write useful software. My job is to discover and package the information you need to best apply that tool. I like to think of myself as an outside observer, not too deeply steeped in the day-to-day travails of programmers and not too keenly focused on the minutiae of standardization, yet familiar with both. This series of articles, then, summarizes what this self-proclaimed outside observer thinks have been the most important contributions to C++ since its inception...."
berns 11y ago
He gave a talk at DConf 2014. He said "I'm gonna make a confesion which will make many of you instantly stop listening to me which is I don't develop software." Meyers is a teacher, a very good one. http://www.ustream.tv/recorded/47947981 http://www.ustream.tv/recorded/47947981
zerr 11y ago
While Carmack obviously is a great programmer, the fact that C++ compiler eats his `C with classes` code doesn't make him the best C++ programmer out there :)
seesomesense 11y ago
Those who can't do, teach. Those who cannot do or teach, write books. ( And use the fame derived from them to get consulting gigs. )
- warkid 11y ago
  well, "writing books" is "doing"
lordnacho 11y ago
The best coaches are not necessarily the best players. Like in sport, coaches are good at pointing to particular aspects of someone's game, but were not necessarily great at putting it all together on the field. You find there's different coaches for attacking, defending, etc. They all tend to have tried playing at some level, however. Even Mourinho was a senior player for a short while. I suspect programming gurus are no different. They may get very good at shouting RAII or SFINAE at you, without being great at executing it in a large project.
w8rbt 11y ago
Great programmers don't typically write books. They are busy writing programs. 'de Raadt on C' would be a good book, wouldn't it? But he'll never have time to write it.

by mpu 11y ago

solipsism 11y ago

Are you putting Stroutrup in the I'm suspicious of his advice category or the He teaches from experience category?

rshaban 11y ago
It would seem from the context of his statement the latter, especially given that he built C++
- lfowles 11y ago
  It could also go the "ivory tower" direction
- solipsism 11y ago
  Creating C++ means you're likely to know the ins and outs of the language. That's a necessary condition to being a good C++ programmer, but it's not sufficient. It's not at all obvious to me that Stroustrup would be a good C++ programmer or even a good C programmer.
  - innguest 11y ago
    Macho man! If you need to know the intricacies of an abstraction in order to use an abstraction, then it's not a very good abstraction. Do engineers know the ins and outs of concrete and rebar? Or do they offload that knowledge onto manufacturers? But programmers can't offload anything onto the language creator or they aren't real programmers. I'm glad for all the work the SBCL and GHC teams put onto their languages so I can use their abstractions without needing to know the ins and outs of performance optimization. Maybe one day you'll find a language you like that allows you to focus more on your problem domain and less on its traps, idiossyncrasies and inadequacies.
    - solipsism 11y ago
      What? You're reading way too much into my use of the term ins and outs. I didn't say good C++ programmers must know how to implement a C++ compiler. By ins and outs I meant: the syntax, the evaluation strategy, the features and facilities provided by the language and toolsets, etc. You need to know those kinds of things to be a good programmer, and every language creator is likely to know those things about the language she created. My point was that knowing those things is necessary but not sufficient to be a good programmer. Macho man! ... Maybe one day you'll find a language ... Your tone is really shitty, and it's made worse by the fact that you're being shitty toward some imaginary strawman you've put in my place. For what it's worth: I greatly value good abstractions, I think appropriate high-level languages should be used whenever there's not a good reason to use low-level languages, I think leakier abstractions are shittier abstractions, I think C++ is full of the leakiest of abstractions, and I think Haskell and lisps are great. I know you're really eager to shit on others because you think you've achieved some kind of higher level consciousness, but you should probably work on your knee-jerk reactions.
ksherlock 11y ago
I'm suspicious of his advice because the c++ he wants isn't the c++ I want.

lfowles 11y ago

I think some of the most solid and forward thinking advice I've seen and used in my C++ have come from his books. As for Carmack: I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set. http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ

mikekchar 11y ago

His webpage: http://www.aristeia.com/ http://www.aristeia.com/ indicates that he has been a programmer since 1972. Even if he has been doing training/consulting for a couple of decades, that leaves a lot of time to get the basics down. I've never met him, though I have browsed one of his books once. My own personal feeling is that books like these can be invaluable for people starting out in the industry. It gives you a reference point to relate to. If he can explain things well and people can understand his writing, then it can be useful even if the person isn't the best living coder on earth. At some point in your development, you need to branch out from what people are saying in books and start to form your own opinions. You have to start questioning what the "experts" are saying and try to experiment with other techniques. It is frustrating when people hang on to certain ideas just because a famous author said it. Sometimes it holds us back. It doesn't make their contribution any less valuable, though, because at least newbies are getting to a certain level due to the well written books.

lfowles 11y ago
> It is frustrating when people hang on to certain ideas just because a famous author said it. Sometimes it holds us back. What I appreciate is that most of what he says (via GotW or the books) comes with the rationale and a code snippet instead of a blind assertion that this is The True Way.
sbov 11y ago
You should still read them though. But instead of reading them like an instruction manual, you should read them for an eye towards when you would disagree with them, when you wouldn't, and why.
jlarocco 11y ago
I largely agree with you, BUT, this version of Effective C++ was less opinion and style oriented and more a guide to avoiding easy to make mistakes with some of the new C++11 and C++14 features. Not following many of the guidelines will result in incorrect and broken code. My recollection of the older books is that they covered "best practices," and ignoring them may have been bad style, but the code would still be technically correct. Quite a few are still style issues, but it's important to recognize the difference before deciding to ignore them :-)

coliveira 11y ago

His books are well-researched, that is for sure. However, you cannot use his ideas as gospel. He will try to teach the most conservative way of using C++, not the best for your purposes. I particularly think that there are several areas of C++, such as exceptions and constness that should better be avoided if possible. But each one has a different way to use the language.

netheril96 11y ago
I could understand why some people like to avoid exceptions. But constness? Really?
- coliveira 11y ago
  Constness when used on classes introduces a way to create objects that behave differently in different contexts. Are you calling a member function from a const or from a non-const pointer? Depending on that you could be running different code. In my opinion you should make your mind about what the class does: is it mutable? then don't use it with const. Unfortunately, you are still required to use const in many places: copy constructors and operators, for example. However, you can still choose to minimize the use of const, and avoid it whenever possible.
  - Negitivefrags 11y ago
    That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
    - smikims 11y ago
      I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include <iostream> void foo(const int& a, int& b) { std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; ++b; std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; } int main() { int a = 1; foo(a, a); } Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes, const is useful, but if you don't know what it actually does it will bite you in the ass, just like most of C++.

pikma 11y ago

His past C++ projects (or lack thereof) do not tell much about the quality of his books. He teaches people how to master C++, and that's a very precise skill. He doesn't claim to teach how to organize software, or how to manage collaboration between people, or any of the other skills that are necessary for a successful software project. It's the same way that good grammar is only one of the skills involved in writing a great novel. Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.

millstone 11y ago
His book is titled "Effective Modern C++," which necessarily contains opinions about what is effective and what is modern. Without practical experience writing software, his opinions won't be grounded, and so his advice won't be sound. That said, I think he does a good job being even-handed. For example, his chapter on auto covers both advantages and pathological cases, and goes on to say: First, take a deep breath and relax. auto is an option, not a mandate. If, in your professional judgment, your code will be clearer or more maintainable or in some other way better by using explicit type declarations, you’re free to continue using them. But bear in mind that C++ breaks no new ground in adopting what is generally known in the programming languages world as type inference. So he is not excessively proscriptive.
lambda 11y ago
> Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example. Not sure that Strunk, or the successor Strunk and White, are good examples here; they didn't "really grok grammar", in fact, they were pretty bad at both understanding it and teaching it, and their advice consists of a lot of incorrect information and vague platitudes. E. B. White was actually a good writer, but much of his writing violates the prescriptions in The Elements of Style. Geoff Pullum has a good rant on the subject, if you want more detail: https://chronicle.com/article/50-Years-of-Stupid-Grammar/25497 https://chronicle.com/article/50-Years-of-Stupid-Grammar/254... So, this is exactly why it's an interesting question to test if the suggestions in the "Effective C++" series are actually good suggestions, or are just someone expounding rules that sound good in theory but don't actually help in practice.

IvyMike 11y ago

Anecdotal, but a friend of a friend talked with Meyers, and Meyers said he has not worked on any large scale C++ programs in a while. That being said, I have worked on large scale C++ projects, with a lot of people smarter than me, and the biggest criticism of Meyers' books and advice would be "necessary but not sufficient". I can't, off the top of my head, think of anything he recommends that would have been controversial amongst my peers.

3legcat 11y ago

>Is this guy actually writing C++ programs in the wild? Well, I read one of his articles which you can find here: http://www.artima.com/cppsource/top_cpp_books.html http://www.artima.com/cppsource/top_cpp_books.html In it, he writes about his role with C++: "I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it. It’s not by virtue of any intimate association with the language’s standardization, either, because I’ve never been a member of the C++ standardization committee, I’ve never been on the committee’s mailing lists, and I’ve never attended any standardization meetings. My knowledge of the inner workings of the committee—including the things that have had a significant impact on it—is based on what I’ve read and heard from others. This means that I may be ignorant of important forces that shaped C++ as we know it, because those forces may have been felt only within the committee. Given that I don’t really use C++, nor do I help specify it, you might wonder what I do do. Fundamentally, I study C++ and its application. I gather as much information as I can about the language and its use (from books, magazines, newsgroups, email and face-to-face conversations with developers and members of the standardization committee, experiments with toy programs I write, etc.), organize and analyze what I find, then I package my findings in concentrated form (e.g., books, magazine articles, technical presentations, etc.) for consumption for people like you—people who do use the language. Your job is to employ C++ as a tool to write useful software. My job is to discover and package the information you need to best apply that tool. I like to think of myself as an outside observer, not too deeply steeped in the day-to-day travails of programmers and not too keenly focused on the minutiae of standardization, yet familiar with both. This series of articles, then, summarizes what this self-proclaimed outside observer thinks have been the most important contributions to C++ since its inception...."

berns 11y ago

He gave a talk at DConf 2014. He said "I'm gonna make a confesion which will make many of you instantly stop listening to me which is I don't develop software." Meyers is a teacher, a very good one. http://www.ustream.tv/recorded/47947981 http://www.ustream.tv/recorded/47947981

zerr 11y ago

While Carmack obviously is a great programmer, the fact that C++ compiler eats his `C with classes` code doesn't make him the best C++ programmer out there :)

seesomesense 11y ago

Those who can't do, teach. Those who cannot do or teach, write books. ( And use the fame derived from them to get consulting gigs. )

warkid 11y ago
well, "writing books" is "doing"

lordnacho 11y ago

The best coaches are not necessarily the best players. Like in sport, coaches are good at pointing to particular aspects of someone's game, but were not necessarily great at putting it all together on the field. You find there's different coaches for attacking, defending, etc. They all tend to have tried playing at some level, however. Even Mourinho was a senior player for a short while. I suspect programming gurus are no different. They may get very good at shouting RAII or SFINAE at you, without being great at executing it in a large project.

w8rbt 11y ago

Great programmers don't typically write books. They are busy writing programs. 'de Raadt on C' would be a good book, wouldn't it? But he'll never have time to write it.