8 ms·

> Google is still just another enterprisey megacorp employing 30000 blub programmers. Expect the usual 'enterprise' failures. Ouch! That must have hurt 'em. Of

by _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
  I don't deny that there are useful features in C++11/14 (though I find "modern C++" an irksome marketing trick by people peddling a disgusting programming language; it was called "modern" since at least the early 2000s and it was disgusting then.) Of course I'd rather iterate over std::map with a range for loop than use the C++98 way, and as to lambdas - while I find them way too awkward and limited compared to closures without the sharp edges (and with garbage collection), and a ton of "modern C++ code" went batshit insane in its extent of unnecessary reliance on lambdas, lambdas remain much more practical than the alternatives when doing things like some sort of a parallel_for. But then it's hard to find a language whose version X+1 adds nothing useful to version X. Is C++14 a better language than C++98? It's hard to tell (I think it is - I think C++ is worse than C, but having gotten to C++98, perhaps it helps more than hurts to add all that other shit), but it's not an interesting question anyway because the upgrade is easy enough and it's worth it for most people for their specific reasons, so C++98 will die out. But then it's not like Google aren't upgrading to the latest C++ standard, they're just doing it slowly AFAIK.
  - hellofunk 11y ago
    It's interesting to consistently find that people who hate C++ just really really hate it a lot, to the point of using profanity a lot of the time. I don't see what the big deal is. C++ is probably the most gigantic and complex language I am likely to ever use... but you don't have to use the vast majority of it if you don't want to. If you want to stick with C-style coding, you pretty much can, if you don't want OO or STL or ++11/14 features -- nothing is forcing you to write those features into your code. But when you want access to them, there they are; and if suddenly you find yourself needing a particular library that only exists in C++ (as so many graphics and physics engines do), you can get access to that as well. As soon as you need multithreading, or sorting of hash maps, or even basic string operations, knowing you can reach for them in pinch rather than find the C alternatives or build your own, seems like a big bonus to me (assuming a comparison to C).
    - 72deluxe 11y ago
      True, but I think a lot of the encouragement is to move away from writing C++ like it is C because we really don't want to encourage people to write with dangerous approaches anymore (like you can if you write C++ like it is C). I work with a few who write their C++ like it is C (pointers thrown around, no const-correctness, memcpy instead of copy constructors etc. etc.) and it is horrible to read. There is no indication of lifetimes of objects, nor any indication of ownership. No RAII, no exceptions, nothing. It is dangerous. You are rewarded for writing C++ safely because you won't have to fix any bugs and you can offload all the work onto the compiler for checking types and safety for you. Like you, though, I don't understand people who get red in the face about C++ and go into a profane rage. It is just a language after all.
otabdeveloper1 11y ago
> many "enterprisey megacorps" seem to apply a restricted subset of C++ rather successfully Your definition of 'successfully' is vastly different from the Megacorp definition of 'successfully'. I interview C++ programmers _all the time_, and let me tell you: practically the only reason those restricted subsets of C++ exist is to allow bad programmers to work at Megacorp. There are a lot of really unqualified C++ programmers in the world, and by far the biggest problem faced by Megacorp is employee churn, not code quality and not product deadlines. The use of 'C++ subsets' solves the employee churn problem at the cost of code quality.
- p0nce 11y ago
  Agreed. If you are using C++ but no exceptions, no RAII, and no std::unique_ptr, you are avoiding the best part of C++.
  - vvanders 11y ago
    I'm with you on RAII and unique_ptr but I've yet to find exceptions to be compelling enough. I find Rust's approach(Result<T,E>) much nicer.
    - lmm 11y ago
      The functional approach is great in a language with typeclasses or modules. But it's not a good fit for RAII - how would a C++ constructor report an error using Result?
      - vvanders 11y ago
        By not doing any work in the constructor. IMO constructors should be setting sane defaults and nothing more. If you need to do work that could fail put that into an "init()" function with a return type that can signal an error. I worked for quite a while on platforms that didn't have exceptions and this was the standard pattern for keeping RAII without needing them. If you wrap the return value correctly(like with Result<T,E>) you can also guarantee that your clients need to deal with the error case(or fail to handle it with unwrap()) as opposed to getting caught by an exception that wasn't declared or documented.

by _yosefk 11y ago

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
I don't deny that there are useful features in C++11/14 (though I find "modern C++" an irksome marketing trick by people peddling a disgusting programming language; it was called "modern" since at least the early 2000s and it was disgusting then.) Of course I'd rather iterate over std::map with a range for loop than use the C++98 way, and as to lambdas - while I find them way too awkward and limited compared to closures without the sharp edges (and with garbage collection), and a ton of "modern C++ code" went batshit insane in its extent of unnecessary reliance on lambdas, lambdas remain much more practical than the alternatives when doing things like some sort of a parallel_for. But then it's hard to find a language whose version X+1 adds nothing useful to version X. Is C++14 a better language than C++98? It's hard to tell (I think it is - I think C++ is worse than C, but having gotten to C++98, perhaps it helps more than hurts to add all that other shit), but it's not an interesting question anyway because the upgrade is easy enough and it's worth it for most people for their specific reasons, so C++98 will die out. But then it's not like Google aren't upgrading to the latest C++ standard, they're just doing it slowly AFAIK.
- hellofunk 11y ago
  It's interesting to consistently find that people who hate C++ just really really hate it a lot, to the point of using profanity a lot of the time. I don't see what the big deal is. C++ is probably the most gigantic and complex language I am likely to ever use... but you don't have to use the vast majority of it if you don't want to. If you want to stick with C-style coding, you pretty much can, if you don't want OO or STL or ++11/14 features -- nothing is forcing you to write those features into your code. But when you want access to them, there they are; and if suddenly you find yourself needing a particular library that only exists in C++ (as so many graphics and physics engines do), you can get access to that as well. As soon as you need multithreading, or sorting of hash maps, or even basic string operations, knowing you can reach for them in pinch rather than find the C alternatives or build your own, seems like a big bonus to me (assuming a comparison to C).
  - 72deluxe 11y ago
    True, but I think a lot of the encouragement is to move away from writing C++ like it is C because we really don't want to encourage people to write with dangerous approaches anymore (like you can if you write C++ like it is C). I work with a few who write their C++ like it is C (pointers thrown around, no const-correctness, memcpy instead of copy constructors etc. etc.) and it is horrible to read. There is no indication of lifetimes of objects, nor any indication of ownership. No RAII, no exceptions, nothing. It is dangerous. You are rewarded for writing C++ safely because you won't have to fix any bugs and you can offload all the work onto the compiler for checking types and safety for you. Like you, though, I don't understand people who get red in the face about C++ and go into a profane rage. It is just a language after all.

otabdeveloper1 11y ago

> many "enterprisey megacorps" seem to apply a restricted subset of C++ rather successfully Your definition of 'successfully' is vastly different from the Megacorp definition of 'successfully'. I interview C++ programmers _all the time_, and let me tell you: practically the only reason those restricted subsets of C++ exist is to allow bad programmers to work at Megacorp. There are a lot of really unqualified C++ programmers in the world, and by far the biggest problem faced by Megacorp is employee churn, not code quality and not product deadlines. The use of 'C++ subsets' solves the employee churn problem at the cost of code quality.

p0nce 11y ago
Agreed. If you are using C++ but no exceptions, no RAII, and no std::unique_ptr, you are avoiding the best part of C++.
- vvanders 11y ago
  I'm with you on RAII and unique_ptr but I've yet to find exceptions to be compelling enough. I find Rust's approach(Result<T,E>) much nicer.
  - lmm 11y ago
    The functional approach is great in a language with typeclasses or modules. But it's not a good fit for RAII - how would a C++ constructor report an error using Result?
    - vvanders 11y ago
      By not doing any work in the constructor. IMO constructors should be setting sane defaults and nothing more. If you need to do work that could fail put that into an "init()" function with a return type that can signal an error. I worked for quite a while on platforms that didn't have exceptions and this was the standard pattern for keeping RAII without needing them. If you wrap the return value correctly(like with Result<T,E>) you can also guarantee that your clients need to deal with the error case(or fail to handle it with unwrap()) as opposed to getting caught by an exception that wasn't declared or documented.