8 ms·

I've been programming professionally for over 20 years, most of it in C++. I really like developing fast code, and C++ used to be my favorite tool for the job.

• johan_larson 10y ago
  Any sense of where the C++ refugees are heading? Rust? Go?
  • bnastic 10y ago
    "C with classes". (I'm not joking)
    • Roboprog 10y ago
      And yet, I'm laughing. As you know, that was what we called the C preprocessor thing back in the mid 80s (as discussed in Uni - I never used it until about 1990)
    • bitL 10y ago
      The most reasonable choice, restricting yourself to a subset. I knew C++ lost it when people started writing library code resembling monads.
      • johan_larson 10y ago
        "When your template system turns out to be Turing-complete, you may have gone too far."
    • isaacremuant 10y ago
      Using a subset of c++ in a c fashion seems much saner than raw c without objects and having to use macros so much.
  • pklausler 10y ago
    Haskell, at least in my case.
    • marcosdumay 10y ago
      Haskell has syntax that is as problematic as this one, and a huge number of extension combinations that nobody can be sure not to be problematic. I'm running into it as much as I can too, but it does look like a language we should replace with something simpler once we get an specification that works.
      • pklausler 10y ago
        > Haskell has syntax that is as problematic as this one... Examples, please.
        • marcosdumay 10y ago
          I've just looked at this line in darcs documentation: (Patchy p, (~) ((* -> *) -> *) (ApplyState p) Tree) => Patchy (PatchInfoAnd rt p)
          • pklausler 10y ago
            The C++ usage (T x{{}}) is problematic because its interpretation is so obscure as to flirt with ambiguity and lead to program-breaking changes in compilers as their semantic analyzers improved. The Haskell line you cite isn't ambiguous at all.
            • marcosdumay 10y ago
              Ambiguity, yes it has none. About obscurity, how many GHC extensions were required to make it accept this code? (Is GADT enough?) And by the way, this is in the interface, while the C++ example is in the implementation. Besides, that's Haskell code that happens in practice. This is one I've just looked at, if I did some research I would certainly come up with more egregious code (maybe even mine). This one probably isn't even problematic (it's hard to say from the interface), but in general, mixing those extensions does lead to some very interesting problems from time to time. Haskell has the same excessive complexity problem that C++ suffers. I do think this is the right thing to do right now. But I can't imagine it not looking as dated in 4 decades as C++ is now.
  • petters 10y ago
    Go is nice, but not a substitute for C++. https://github.com/nieksand/sortgenerics/blob/master/README.md https://github.com/nieksand/sortgenerics/blob/master/README....
  • pjmlp 10y ago
    I went to Java/.NET lands and respective languages. Since 2006, I only had one project where using C++ really mattered. A mix of Assembly and C++ was used for image codecs, which were just 5% of the whole application done in WPF. On personal projects, I went back to it for portable code across Android and Windows Store, but now with Xamarin being part of Microsoft, I am using it for newer projects.
  • rb808 10y ago
    Java/C#, though the complexity is now matching C++, especially with all the new fashionable functional "features" most large code bases are a huge mishmash of styles and complexity that is making me wish for sensible C++ developers again.
    • johan_larson 10y ago
      The problem with Java isn't so much the language. It's the ecosystem and the community. The ecosystem is very rich, so there are many ways of doing pretty much anything, which means it's easy to get lost in the complexity. And the community is fad-prone. Patterns! Injection! Annotations! Something else (for now)! A certain skepticism is crucial for staying sane.
  • hota_mazi 10y ago
    Most of them moved to Java twenty years ago. People who are still programming in C++ today do so either because they like it or because they have no choice.
    • FT_intern 10y ago
      Many of the bigger, well paying companies like FB, GOOG, LNKD, etc. have C++ backends
      • pjmlp 10y ago
        Those worshipped companies at Silicon Valley are a tiny spot in the ocean of companies that most of us, common developers, get to work on.
        • gpderetta 10y ago
          They do hire a lot of C++ programmers to work on cool projects tough. They also pay well. Also banks.
          • pjmlp 10y ago
            Assuming you live close to one of their sites and are willing to put yourself through their crazy hiring process. As for the banks, the ones around where I live only care for Cobol, RPG, JEE and .NET.
  • PeCaN 10y ago
    Honestly for me… C++. C++ but with restricted and consistent feature usage at every level of the stack. This means no stdlib, no stl, no boost. Writing your own pared-down standard library is actually not that hard if you make sure none of the calling code hits edge cases. 90% of boost just makes sure it's robust in the face of anything (classes that are movable but not assignable, initializer list constructors that behave differently, classes that overload unary &, etc… just weird stuff). Honestly the only reason I do this is simply because I like writing fast code and C++ is a good tool to do that. It would take me longer to become equally proficient in Rust, D, etc, than to just write 100% dependency-free C++. I mostly work on programming language implementation though, so libraries are less of an issue than in other possible situations. D has been catching my attention a lot though. I just wish it had something kind of like C++'s move semantics, to make implementing owned pointers (C++ unique_ptr, Rust Box, etc) possible. Maybe it does and I just haven't seen it used yet. The other problem I have with D is that most libraries seem to rely on the GC.
    • gmfawcett 10y ago
      Re: move semantics and unique_ptr in D, take a quick peek at std.typecons (unique, refCounted) and std.algorithm.mutation.move. I haven't used them, and they are library code (and so not as well specified as C++'s counterparts), but you might find them useful. There's been good progress on the @nogc front in the standard library, too, hoping to see continuing improvements there. - http://dlang.org/phobos/std_typecons.html http://dlang.org/phobos/std_typecons.html - http://dlang.org/phobos/std_algorithm_mutation.html#.move http://dlang.org/phobos/std_algorithm_mutation.html#.move My personal worry with D is that the language changes a bit faster than, say, C++ or Rust. I don't know how whether the code I write today will still compile in five years. I wouldn't mind a feature freeze on the language design and the existing stdlib APIs.
    • emmelaich 10y ago
      No STL at all? That's the best part of C++! OK, don't use iostreams, or stringstreams perhaps, and use boost very sparingly. But not at all?
      • 10y ago
  • agersant 10y ago
    I'm a game developer using C++ every day at work. It's the standard in our industry (at least for AAA games) and probably will be for at least another decade. I used to choose C for pet projects (when I cared about performance) but I've been learning Rust for ~3 months now. I think I'll replace my usage of C by Rust from here on as much as I can. I also had a brief affair writing Go but it didn't resonate nearly as well with my background as Rust does.
• Roboprog 10y ago
  I would like to thank Mr Meyers for his Effective C++ book, back in the 90s. Said book for me was the tipping point with C++. Having used Borland Pascal-with-Objects, and read about Eiffel, that book confirmed for me, at least, that C++ was a tool of last resort for trying to build on top of existing C code. C++ devs are a hardy breed :-)
  • revelation 10y ago
    I was skimming his most recent book and I got the impression that a large part of it was on pretty much the same esoteric nonsense of various && constructs as this blog post. The blog post has an excuse, I'm not sure the book does.
  • Roboprog 10y ago
    In fairness, it was a good book. But it's like combat training. You don't want to be in a combat zone. BUT, if you are, you had better know what you are doing. Most apps don't need this heartache.
• walkingolof 10y ago
  Same here, I will look at Scala Native, like Scala, but instead of JVM as the target platform, its using LLVM
  • bitL 10y ago
    You'll go from bad to worse; Scala is to Java what C++ is to C; barely anyone understands all constructs in either language. You either know everything or nothing (i.e. you can't understand somebody else's code unless you enforce rules or know the complete language in detail).
    • premium-concern 10y ago
      I'd say this is blatant non-sense usually coming from people who lack any kind of experience in C++, Scala or both.
      • bitL 10y ago
        OK. Enjoy your ignorance then.
        • premium-concern 10y ago
          I'm not the one being ignorant. See your other comment where you have been flat-out misinformed.
    • edblarney 10y ago
      I think this comment is fair, but could be misinterpreted. Scala allows you to do the same thing in many different ways, and with operator overloading ... the approach you chose to coding defines almost a 'custom syntax' for a project. Which makes it very hard to read sometimes - you have to infer the 'style' before you can get too far. To be fair - that's a different kind of 'inconvenience' than C++ from C - but the comparison is pragmatically valid.
      • 10y ago
• pjmlp 10y ago
  > I'm now actively looking for gigs in which I can develop high-performance code in a language _other than_ C++, just because it's such a minefield. C++ was my next loved language after Turbo Pascal and I still like it. Nowadays I use mostly JVM and .NET languages and after reading Meyers's latest book, and still following the standardization process, I have to agree with you. On private projects I can control what gets used, but at company wide level, it is almost impossible to do so. So one ends up with a gigantic C++ code base, many times just C with C++ compiler, with different meanings depending which ANSI version, compiler extensions and version are being used. Considering most common companies don't follow code reviews or use static analysis tools, this just leads to quite some buggy code.
• bmm6o 10y ago
  Amen. I was just thinking the other day about how I used to really like C++ but how glad I was to not have to use it anymore. I haven't worried about "the most vexing parse" for years! There was this last week, and yes it's contrived but it suggests something has gone horribly wrong: http://stackoverflow.com/questions/40462612/moving-a-member-function-from-base-class-to-derived-class-breaks-the-program-for http://stackoverflow.com/questions/40462612/moving-a-member-... .