5 ms·

I'd be interested to see which subset of C++ each company picked. Google's coding guidelines are always cited, but I can't find many others. MySQL's seem lackin

I'd be interested to see which subset of C++ each company picked. Google's coding guidelines are always cited, but I can't find many others. MySQL's seem lacking in details. C++ is such a broad spectrum, I bet some of these companies only used simple classes and virtual functions, whereas some used boost.spirit and functors. https://dev.mysql.com/doc/internals/en/general-development-guidelines.html#coding-guidelines-c https://dev.mysql.com/doc/internals/en/general-development-g...

meaty 14y ago
Good point. Most c++ coding standards I've seen are lists of stuff not to use.
- ksec 14y ago
  They are more like C+ with C++ minus a set of features. And there are those who write C style in C++ for various of reason. And everyone knew the huge amount of software in C++. Why the list?
  - mpyne 14y ago
    > And everyone knew the huge amount of software in C++. Why the list? Perhaps the submitter just likes watching HN'ers fall all over themselves to reflexively point out all the reasons why C++ is, like, the worst language ever? (Someone even mentioned coding Windows in ML-derived languages, I can only imagine Raymond Chen's reaction to that)
johngunderman 14y ago
MySQL, though written in C++, reads more like C with classes. Even then, a large portion of the code is procedural instead of OO. They are slowly moving towards an OO style, but it will take a while before a reasonable percentage of the code base has been re-written.
apaprocki 14y ago
At Bloomberg, we just published our lowest-level C++ standard library (and plan to add more layers on top).[1] Everything we do is based upon this library and all the higher level layers which are not OSS yet. (i.e., No external 3rd party libs in any of these lowest layers) We CC-BY-SA'd our code standards as well if you're interested.[2] [1]: https://github.com/bloomberg/bsl https://github.com/bloomberg/bsl [2]: https://github.com/bloomberg/bsl/wiki/bdestds.pdf https://github.com/bloomberg/bsl/wiki/bdestds.pdf
- halostatue 14y ago
  Can I ask why the `gyp` build tool?
  - drucken 14y ago
    I'd be interested to know what they used before gyp, which is relatively new compared to Bloomberg.
    - matthavener 14y ago
      Me too. QMake can generate from visual studio, I think it also integrates with XCode.
  - apaprocki 14y ago
    We went with gyp because we wanted to natively support MSVC and XCode projects as well as standard GNU make environments. Our production build system actually has simple text metadata files that live along-side the code and it generates all the required files as well. We felt that it easier to provide a gyp based system instead of also open-sourcing the entire Perl-based build system which was tied to our custom data format and not generally useful to anyone else. We generate the gyp input files from the metadata on our end and then anyone using the open-source project can use gyp to do whatever they need. If we get to the point where OS distros want to package the libs, we may opt to generate autotools files, but that was too much work to be a roadblock from open-sourcing the lib.
fafner 14y ago
I hope nobody uses boost.spirit. It's nearly impossible to debug, increases compile time dramatically, and increases binary size dramatically as well. It's a nice idea showing what can be done in C++ but it's really nothing you should practically use. I think Boost is simply going overboard with stuff like this. Another interesting C++ coding guideline are the JSF coding guidelines. Stroustrup was actually involved in creating them. It's mostly focused in embedded and critical systems. But unlike what most people expect they highly recommend stuff like Templates http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf
- phaedrus 14y ago
  Actually boost.spirit is an excellent library. The fact that it can both parse and generate made it a great basis for the Io debugger I wrote that wraps gdb; since gdb uses a text based interface I had to both parse and generate in order to spoof gdb responses for Io script debugging. Spirit allows me to do that quite ncely. Like anything boost spirit has a leaning curve. You could just as easily say no one should use emacs because it is hard to learn. In fact I personally don't use emacs because I found it too hard to get going with, but I don't from there extrapolate that no one else should use it. The compile time and binary size problems of boost spirit can be addressed by factoring your grammar into smaller subgrammars in separate compilation units. The subgrammars can still be combined the same as rules can be. The obscure error messages can be improved by using typeful programming so that you get an error like "no conversion from MyRuleADatatype to MyRuleBDatatype". Yes these things are still problematic, but how do we get from "X is hard" to "no one should use X"? See the Clojure author's talk on Simple vs Easy: he lambasts programmer culture for being obsessed with 'easy' to the detriment of creating useful stuff. He asks, what if the Foo Fighters said guitars are hard to play, let's play kazoos because they are easy. Would you listen to the Kazoo Fighters, he asks.
  - ryanmolden 14y ago
    For simple lexing/parsing it likely is overkill, that said for more complex things it can be nice. I have a lexer for Erlang written with Boost.Spirit on my Github. I found debugging no worse than the general Chutulu-horror that are C++ template errors, something you get used to, looking at the root of the spew is generally your best bet. Also they have built in debug nodes you can trivially add to your grammar that will spew every step of the lexing/parsing process so you can easily see where things are going off the rails if your grammar is wrong. Compile times are definitely increased in my experience, don't recall the binary bloat though it has been awhile since I played around with it, a good compiler should be able to fairly aggressively trim it down. Will it be as optimal as a hand written system (assuming you know what you are doing)? Unlikely, but it will be much quicker to get up and running if you know Boost.Spirit.
InclinedPlane 14y ago
C++ isn't just about subsets, it can easily be about building your own language, even without templates. I've seen enough C++ in "really big projects" to know that the amount of complexity it spans and the extreme differences in every aspect of usage is every bit as significant as comparing completely different languages.

meaty 14y ago

Good point. Most c++ coding standards I've seen are lists of stuff not to use.

ksec 14y ago
They are more like C+ with C++ minus a set of features. And there are those who write C style in C++ for various of reason. And everyone knew the huge amount of software in C++. Why the list?
- mpyne 14y ago
  > And everyone knew the huge amount of software in C++. Why the list? Perhaps the submitter just likes watching HN'ers fall all over themselves to reflexively point out all the reasons why C++ is, like, the worst language ever? (Someone even mentioned coding Windows in ML-derived languages, I can only imagine Raymond Chen's reaction to that)

johngunderman 14y ago

MySQL, though written in C++, reads more like C with classes. Even then, a large portion of the code is procedural instead of OO. They are slowly moving towards an OO style, but it will take a while before a reasonable percentage of the code base has been re-written.

apaprocki 14y ago

At Bloomberg, we just published our lowest-level C++ standard library (and plan to add more layers on top).[1] Everything we do is based upon this library and all the higher level layers which are not OSS yet. (i.e., No external 3rd party libs in any of these lowest layers) We CC-BY-SA'd our code standards as well if you're interested.[2] [1]: https://github.com/bloomberg/bsl https://github.com/bloomberg/bsl [2]: https://github.com/bloomberg/bsl/wiki/bdestds.pdf https://github.com/bloomberg/bsl/wiki/bdestds.pdf

halostatue 14y ago
Can I ask why the `gyp` build tool?
- drucken 14y ago
  I'd be interested to know what they used before gyp, which is relatively new compared to Bloomberg.
  - matthavener 14y ago
    Me too. QMake can generate from visual studio, I think it also integrates with XCode.
- apaprocki 14y ago
  We went with gyp because we wanted to natively support MSVC and XCode projects as well as standard GNU make environments. Our production build system actually has simple text metadata files that live along-side the code and it generates all the required files as well. We felt that it easier to provide a gyp based system instead of also open-sourcing the entire Perl-based build system which was tied to our custom data format and not generally useful to anyone else. We generate the gyp input files from the metadata on our end and then anyone using the open-source project can use gyp to do whatever they need. If we get to the point where OS distros want to package the libs, we may opt to generate autotools files, but that was too much work to be a roadblock from open-sourcing the lib.

fafner 14y ago

I hope nobody uses boost.spirit. It's nearly impossible to debug, increases compile time dramatically, and increases binary size dramatically as well. It's a nice idea showing what can be done in C++ but it's really nothing you should practically use. I think Boost is simply going overboard with stuff like this. Another interesting C++ coding guideline are the JSF coding guidelines. Stroustrup was actually involved in creating them. It's mostly focused in embedded and critical systems. But unlike what most people expect they highly recommend stuff like Templates http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf

phaedrus 14y ago
Actually boost.spirit is an excellent library. The fact that it can both parse and generate made it a great basis for the Io debugger I wrote that wraps gdb; since gdb uses a text based interface I had to both parse and generate in order to spoof gdb responses for Io script debugging. Spirit allows me to do that quite ncely. Like anything boost spirit has a leaning curve. You could just as easily say no one should use emacs because it is hard to learn. In fact I personally don't use emacs because I found it too hard to get going with, but I don't from there extrapolate that no one else should use it. The compile time and binary size problems of boost spirit can be addressed by factoring your grammar into smaller subgrammars in separate compilation units. The subgrammars can still be combined the same as rules can be. The obscure error messages can be improved by using typeful programming so that you get an error like "no conversion from MyRuleADatatype to MyRuleBDatatype". Yes these things are still problematic, but how do we get from "X is hard" to "no one should use X"? See the Clojure author's talk on Simple vs Easy: he lambasts programmer culture for being obsessed with 'easy' to the detriment of creating useful stuff. He asks, what if the Foo Fighters said guitars are hard to play, let's play kazoos because they are easy. Would you listen to the Kazoo Fighters, he asks.
- ryanmolden 14y ago
  For simple lexing/parsing it likely is overkill, that said for more complex things it can be nice. I have a lexer for Erlang written with Boost.Spirit on my Github. I found debugging no worse than the general Chutulu-horror that are C++ template errors, something you get used to, looking at the root of the spew is generally your best bet. Also they have built in debug nodes you can trivially add to your grammar that will spew every step of the lexing/parsing process so you can easily see where things are going off the rails if your grammar is wrong. Compile times are definitely increased in my experience, don't recall the binary bloat though it has been awhile since I played around with it, a good compiler should be able to fairly aggressively trim it down. Will it be as optimal as a hand written system (assuming you know what you are doing)? Unlikely, but it will be much quicker to get up and running if you know Boost.Spirit.

InclinedPlane 14y ago

C++ isn't just about subsets, it can easily be about building your own language, even without templates. I've seen enough C++ in "really big projects" to know that the amount of complexity it spans and the extreme differences in every aspect of usage is every bit as significant as comparing completely different languages.