16 ms·

What Modern C++ practices specifically have you found that Google discourages? I'm curious. I'm reading through Scott Meyers' Effective Modern C++ and am findin

What Modern C++ practices specifically have you found that Google discourages? I'm curious. I'm reading through Scott Meyers' Effective Modern C++ and am finding so much easy and fantastic advice, I wonder if Google is at odds with some it?

otabdeveloper1 11y ago
> I wonder if Google is at odds with some it? It's at odds with almost all of it. Google's standards are C-with-classes based on compiler bugs circa 1999. Despite their (misleading) marketing, Google is still just another enterprisey megacorp employing 30000 blub programmers. Expect the usual 'enterprise' failures.
- hellofunk 11y ago
  >based on compiler bugs circa 1999 What do you mean by this?
- _yosefk 11y ago
  > Google is still just another enterprisey megacorp employing 30000 blub programmers. Expect the usual 'enterprise' failures. Ouch! That must have hurt 'em. Of course the original meaning of "Blub" is "anything which isn't Lisp", especially C++ (as well as say Java.) But what the heck, it has a good sound to it. Anyway, I think their C++ style guide isn't bad. As to "modern C++ style", let's wait for a few years, shall we? When the STL came out, auto_ptr and for_each(v.begin(), v.end(), FunctorFromHell()) were marketed as the way to go for a long while; then the usual suspects became a bit more silent. Now again, despite their being a smart for loop, for_each with a lambda (with its crazy capture lists and all) is supposedly considered at least as good as a for loop, and typically better. And you're supposed to use unique_ptr and what-not. Maybe a few years down the road things will look different again. C++11/14 has a ton of weird shit you ought to keep in your mind on top of the weird shit in C++98/03 and many "enterprisey megacorps" seem to apply a restricted subset of C++ rather successfully.
  - hellofunk 11y ago
    It's hard to deny that there are some really useful new features in modern c++, though. Standardized multithreading primitives is a big one. Smaller ones like scoped enums are useful too. I'm a big fan of lambdas and the ability to use them for things that used to be very awkward to do without them, like std::bind and functors. In all, I think the modern additions are a net positive for sure.
    - to3m 11y ago
      If you're of this opinion, you should be glad when people don't use them. This can be your competitive advantage.
    - 72deluxe 11y ago
      I would agree with this. I am writing C++03 at work due to lame compilers I am forced to use on Windows, and I really miss little things like std::atomic. Lambdas would mean I could bin all those structs with bool operator()() for find_if that I have to litter my code with.
      - scott_s 11y ago
        I know a lot of people say "Boost is awful", but Boost provides the same atomic interfaces: http://www.boost.org/doc/libs/1_60_0/doc/html/atomic.html http://www.boost.org/doc/libs/1_60_0/doc/html/atomic.html. Quoting from the introduction: "Boost.Atomic is a library that provides atomic data types and operations on these data types, as well as memory ordering constraints required for coordinating multiple threads through atomic variables. It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature."
        72deluxe 11y ago
        Thanks for the suggestion, much appreciated.
    - _yosefk 11y ago
- petke 11y ago
  When I read the Google coding standard I realized I never want to work there. Microsoft on the other hand seems to get cpp. Maybe because herb Sutter has managed to change the culture from the inside. Anyone remember how awful vc6 was back in the day? MS has come a long way. Edit: It seems the standards have changed. It doesn't seem so bad now. They cant use exceptions but they can use some of boost cpp11 and templates. So maybe working at google ain't that bad.
pjmlp 11y ago
- use of pointers instead of references - C style error codes - minimal use of STL - use of templates is frowned upon - C style enums This just of the top of my head, I would need to read it again to see if they changed anything.
- hellofunk 11y ago
  >minimal use of STL I was recently reading the docs for a physics engine in c++ and they said that its initial implementation used std::vector in many places, but they instead implemented their own in later versions to accommodate maximum "portability and compatibility." I wonder what that means? Since the STL is included in C++ compilers and vector is always going to be there, why would they need to roll their own to make the engine either more portable or more compatible? >use of templates is frowned upon I wonder if this means the writing of templates, or using existing templates. If the latter, maybe like the STL their primary concern is compile times?
  - plq 11y ago
    std::vector spec leaves quite a bit of performance-critical details unspecified. I imagine the allocator behaviour differs enough between implementations that they implemented their own to keep performance in different platforms more predictable. The performance requirements for a physics engine can be quite different from the general case that the std::vector spec is aiming for. I imagine templates are frowned upon for the same reason -- too many moving parts. Otherwise they're perfectly fine to use in projects that have goals other than portably predictable performance.
    - hellofunk 11y ago
      Good points, I hadn't considered that the implementation of a vector could widely vary. That makes sense.
      - vvanders 11y ago
        Yup, the spec is also really vague on if clear() actually releases memory. AFAIK the only "correct" way to actually clear a vector is "vec = std::vector<T>()" with the STL.
lmm 11y ago
They avoid using exceptions, which means avoiding doing work in constructors, which compromises your ability to use RAII, which in turn makes template-style programming much less effective.

otabdeveloper1 11y ago

> I wonder if Google is at odds with some it? It's at odds with almost all of it. Google's standards are C-with-classes based on compiler bugs circa 1999. Despite their (misleading) marketing, Google is still just another enterprisey megacorp employing 30000 blub programmers. Expect the usual 'enterprise' failures.

hellofunk 11y ago
>based on compiler bugs circa 1999 What do you mean by this?
_yosefk 11y ago
> Google is still just another enterprisey megacorp employing 30000 blub programmers. Expect the usual 'enterprise' failures. Ouch! That must have hurt 'em. Of course the original meaning of "Blub" is "anything which isn't Lisp", especially C++ (as well as say Java.) But what the heck, it has a good sound to it. Anyway, I think their C++ style guide isn't bad. As to "modern C++ style", let's wait for a few years, shall we? When the STL came out, auto_ptr and for_each(v.begin(), v.end(), FunctorFromHell()) were marketed as the way to go for a long while; then the usual suspects became a bit more silent. Now again, despite their being a smart for loop, for_each with a lambda (with its crazy capture lists and all) is supposedly considered at least as good as a for loop, and typically better. And you're supposed to use unique_ptr and what-not. Maybe a few years down the road things will look different again. C++11/14 has a ton of weird shit you ought to keep in your mind on top of the weird shit in C++98/03 and many "enterprisey megacorps" seem to apply a restricted subset of C++ rather successfully.
- hellofunk 11y ago
  It's hard to deny that there are some really useful new features in modern c++, though. Standardized multithreading primitives is a big one. Smaller ones like scoped enums are useful too. I'm a big fan of lambdas and the ability to use them for things that used to be very awkward to do without them, like std::bind and functors. In all, I think the modern additions are a net positive for sure.
  - to3m 11y ago
    If you're of this opinion, you should be glad when people don't use them. This can be your competitive advantage.
  - 72deluxe 11y ago
    I would agree with this. I am writing C++03 at work due to lame compilers I am forced to use on Windows, and I really miss little things like std::atomic. Lambdas would mean I could bin all those structs with bool operator()() for find_if that I have to litter my code with.
    - scott_s 11y ago
      I know a lot of people say "Boost is awful", but Boost provides the same atomic interfaces: http://www.boost.org/doc/libs/1_60_0/doc/html/atomic.html http://www.boost.org/doc/libs/1_60_0/doc/html/atomic.html. Quoting from the introduction: "Boost.Atomic is a library that provides atomic data types and operations on these data types, as well as memory ordering constraints required for coordinating multiple threads through atomic variables. It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature."
      - 72deluxe 11y ago
        Thanks for the suggestion, much appreciated.
  - _yosefk 11y ago
petke 11y ago
When I read the Google coding standard I realized I never want to work there. Microsoft on the other hand seems to get cpp. Maybe because herb Sutter has managed to change the culture from the inside. Anyone remember how awful vc6 was back in the day? MS has come a long way. Edit: It seems the standards have changed. It doesn't seem so bad now. They cant use exceptions but they can use some of boost cpp11 and templates. So maybe working at google ain't that bad.

pjmlp 11y ago

- use of pointers instead of references - C style error codes - minimal use of STL - use of templates is frowned upon - C style enums This just of the top of my head, I would need to read it again to see if they changed anything.

hellofunk 11y ago
>minimal use of STL I was recently reading the docs for a physics engine in c++ and they said that its initial implementation used std::vector in many places, but they instead implemented their own in later versions to accommodate maximum "portability and compatibility." I wonder what that means? Since the STL is included in C++ compilers and vector is always going to be there, why would they need to roll their own to make the engine either more portable or more compatible? >use of templates is frowned upon I wonder if this means the writing of templates, or using existing templates. If the latter, maybe like the STL their primary concern is compile times?
- plq 11y ago
  std::vector spec leaves quite a bit of performance-critical details unspecified. I imagine the allocator behaviour differs enough between implementations that they implemented their own to keep performance in different platforms more predictable. The performance requirements for a physics engine can be quite different from the general case that the std::vector spec is aiming for. I imagine templates are frowned upon for the same reason -- too many moving parts. Otherwise they're perfectly fine to use in projects that have goals other than portably predictable performance.
  - hellofunk 11y ago
    Good points, I hadn't considered that the implementation of a vector could widely vary. That makes sense.
    - vvanders 11y ago
      Yup, the spec is also really vague on if clear() actually releases memory. AFAIK the only "correct" way to actually clear a vector is "vec = std::vector<T>()" with the STL.

lmm 11y ago

They avoid using exceptions, which means avoiding doing work in constructors, which compromises your ability to use RAII, which in turn makes template-style programming much less effective.