7 ms·

I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!"

• angersock 12y ago
  Everything else isn't too slow, though, especially if you hit any meaningful IO.
  • unstabilo 12y ago
    Or if you use clever algorithms. I don't have benchmarks at hand, but I suspect that an FFT in Python is faster than a naive Fourier transform in C.
    • nadam 12y ago
      Theoretically this is true, but in practice, those who need to write very efficient code competitively, rarely use naive algorithms. (Pure C/C++ also isn't enough nowadays though, the processor isn't competitive with the GPU in a lot of algorithms, so CUDA/OpenCL needs to be also used in most cases.)
    • stinos 12y ago
      Not sure if this way of comparing programming languages (i.e. do A in language X and do B in language Y => Y is not slower than X) makes enough sense to draw conclusions. If you can use clever algorithms, in the majority of cases you'd do so in any language and in the majority of cases C would lead to more performant code than Python. Then again, wheteher this matters in the scope of the actual application is something else.
      • verbin217 12y ago
        I suspect his comment meant to imply that a level of skill exists for which a programmer could build an FFT in python, a plain DFT in C, but not a proper FFT in C. That programmer would benefit from using python.
    • easytiger 12y ago
      Err, why?
      • chris_b 12y ago
        Because the FFT in python is almost certainly implemented in C, and probably more cleverly done than a naive FFT that I/you/someone would whip up as part of a C program.
        • easytiger 12y ago
          Is this a joke? Something written with the same algorithm in c will be faster than python. Why not use someone elses non naive FFT impl in c then as well?
          • andrepd 12y ago
            Yeah, I really don't see the GP's point.
          • rprospero 12y ago
            I think the argument isn't that Python code out performs C code, it's that code written by mediocre Python programmers often outperforms code written by mediocre C programmers. C code is fast enough the mediocre programmers get used to letting the language bail them out. Python programmers know that their language is slow and that they have to work around it. I've encountered this several times in my own career. A co-worker who writes in C will be implementing a process in parallel with my Python implementation. A week later, my O(N) Python code is outperforming my colleagues O(N^3) C code, since I chose a more complex algorithm which is trickier to get right. The C programmer then re-implements my method in C, which would completely trounce my own code, except I've spent that time leaning on BLAS and LAPACK, speeding up my operations again. The C programmer then starts using fast libraries instead of her own code, again beating my old source, only to find that I've now pushed a good chunk of the processing onto the GPU. Eventually, I will run out of tricks. The final draft of the C code will trounce the final draft of my Python code. However, during most of the creation process, my Python usually out performs their C. Also, a truly talented C programmer would write my colleague's final draft as her first draft, negating every advantage that I had in the process. However, that's not a situation that I'm likely to run into, because places hiring truly talented programmers aren't likely to be hiring me.
    • GFK_of_xmaspast 12y ago
      I think the replies to this post are getting confused between the FFT/DFT, which is O(n log n), and the "naive Fourier transform", O(n2). My experience with numerics in regular python is that they're generally 50-500x slower than the equivalent in C/C++, this just pushes back the point at which the asymptotics take over.
    • blt 12y ago
      C has libraries too, you know :)
  • kbart 12y ago
    Yeah, tell that to embedders and kernel/driver programmers.
    • CHY872 12y ago
      and there the additional complexity of C++ is a barrier to entry but no more, so no biggie in this context.
    • AlexandrB 12y ago
      The irony is that at least one class of kernel developers (Linux) refuse to touch C++.
      • GFK_of_xmaspast 12y ago
        Yeah, but how much of that is because Torvalds has opinions and how much of it is actual fact and preference.
  • MrScruff 12y ago
    There are many applications that either aren't typically IO bound, or where the IO (eg. gpu<->memory) is fast enough that you'll likely need C++ to maximise performance. Writing software that pushes bleeding edge hardware is fun, which is why many people still want to learn C++.
    • angersock 12y ago
      Oh, sure, but the vast vast vast majority of applications--especially that people are hiring for--aren't what you're referring to.
      • MrScruff 12y ago
        Statistically I've no doubt you're right. However there are still a bunch of jobs where performance matters. If I left my job and industry, I'm fairly certain I could find another employer that found value in having a specific piece of code run as fast as possible.
  • blt 12y ago
    I work on programs that are CPU and memory access bound.
• jokoon 12y ago
  > but the complexity of C++ is troubling. It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected. I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it. 1) There are many other alternatives than C++ that will cover a lot of use-cases. You don't always "need" to use C++, unless you have precise needs all the time, or don't want to have another language interact with your code. 2) You can still use C++ and avoid complex features, or just use C. 3) The language keeps evolving, and I think it's great that companies are working towards an ISO standard. Few languages have that. Maybe the language will be a little easier to use in the future.
  • stinos 12y ago
    Maybe the language will be a little easier to use in the future. this is always double with C++. At one point, it most definitely is easier to use now already than pre-C++14 or 11. Lots of those additions really make me enjoy using it (even more:) and often lead to less code which does the same while still not being harder to understand (often even better to understand) and having the same performance. However, because of the backwards compatibility there still is cruft around which does make it harder to use because you basically need to know how to use it or in most cases that you shouldn't use it at all. Ideally one just wouldn't need to spend time / 'brain resources' on that kind of stuff. Simple example: I can still use std::auto_ptr. I won't because there are much better alternatives. I can still use std::tr1::shared_ptr. I don't, and I know what it is when I see it. But for a newcomer or slow learners this is just utter nonsense: need to figure out wtf tr1 is, why it exists, what to do with it, and so on.
    • amatheus 12y ago
      Couldn't these things just be deprecated? As in, never removed because of compatibility, but when compiling you would get warnings about using features no longer 'best practices', and maybe there could be a switch for 'modern c++' that would turn use of these features in errors?
• andrepd 12y ago
  The price for zero-cost abstractions and expressiveness is a monstrous complexity. If you want clean, expressive and easy-to-write code, you have a ton of languages where you can do just that. If you want performance and expressiveness, you will have to do with C++'s complexity.
  • moomin 12y ago
    I think Rust is making the case that you don't. In particular, I think one of the largest sources of complexity is C++'s backwards compatibility.
    • GFK_of_xmaspast 12y ago
      One advantage of c++ is it is kind of nice to know that code you wrote six weeks ago is going to still work.
      • dbaupp 12y ago
        Yeah, instability is definitely a good reason for people to not use Rust, although that's quickly being resolved, both in theory, with the stable 1.0 release in just over 3 weeks, and in practice, with the recent 1.0-beta release.
    • unfamiliar 12y ago
      I think Rust is going a pretty good job of adding a similar level of complexity. I see most of this due to the new abstractions they have added like lifetimes and borrowing. With the old abstractions we have kind of figured out the least confusing way to implement them.
      • dbaupp 12y ago
        I think initial impressions of Rust may make it seem a lot more complicated than it is. That's not saying it's simple, but it doesn't have the same kind of dark corners and 'surprising' interactions that has C++ (often due to backward compatibility requirements); most features in Rust are pretty orthogonal and minimal. Having the compiler on your back about lifetimes/borrowing is definitely unfamiliar, but, fwiw, a programmer usually has to be keeping track of that in C/C++ anyway (if it's complex when the computer checks it, it's complex when a human checks it).
• restalis 12y ago
  "the complexity of C++ is troubling" This comes out of the fact that C++ is being developed more as an engineering tool than as a programming toy. When you're into real engineering, you don't have free lunch.
  • seabee 12y ago
    You can see this with Rust which tries to satisfy the same niche. It's possible to avoid the gotchas in C++ while preserving the advantages, you just pay a different price by working harder to satisfy the compiler.
    • kbart 12y ago
      A lot of people working with C/C++ I know are looking forward to Rust, but the problem is that currently it's nowhere near as mature and widespread as former languages. I hope that will change in the near future as it looks like promising system language.
      • RBO2 12y ago
        Why wait for Rust when D is already there?
        • kbart 12y ago
          Honestly, I haven't tried D, but if it hadn't got traction in 14 years, I'd say it was a miss. It's not enough to be a good language -- documentation, tools, libraries, community, adoption in open source projects is, arguably, even more important.
  • unfamiliar 12y ago
    I disagree. I see most of the complexity of C++ as being due to design mistakes which have to be maintained for backwards compatibility. I would personally like to see a breaking change where a lot of the inconsistencies and design mistakes that have been identified are rectified.
  • 12y ago
• jlebrech 12y ago
  couldn't D, go, nim or rust fill that need?