Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And you can make your code slower by changing it! Oh the horror. C++ is, imo, a good language for a lot of domains. What goes wrong is when people try to use all of the features that C++ offers instead of just using the ones applicable to their domain, eg. I don't think you would really want to use exceptions in embedded programming. If you are on a platform where performance is the key, then you should be careful of what you are doing.

I think people are mostly blaming C++ instead of bad programmers.



The point is not that I can make the code slower by changing it. The point is that it can get slower by changes to the API, without any changes to functionality.Made by somebody else, unintentionally impacting me.

Let me ask you this: Have you ever worked on a large scale C++ project that didn't have performance issues? Or memory issues?


None of what you've said is in any way specific to C++

APIs can easily lose performance when refactored for correctness or code clarity. Large projects have large project issues!


The difference is that the API can change without visible API changes. If you add a virtual destructor to your class, I won't notice that by looking at the call site. I've just been burdened with additional overhead, without knowing about it.

And yes, large projects have large project issues. It is kind of telling that C++ needs an entire tome on large project issues, though... (Lakos, Large Scale C++ Software Design)


The difference is that the API can change without visible API changes.

I don't understand this at all. The performance of a C function can change without any change to the function signature. Even the destructor scenario can happen invisibly in C code for any type that already has a cleanup function. No matter whether the cleanup function is defined as "int myproj_FooCleanup(struct Foo* foo) {...}" or "myproj::Foo::~Foo() {...}", you won't notice implementation changes until runtime.


I'm not talking about the performance of the function itself, I'm talking about the overhead incurred. That can't change in C.

Also, just adding a virtual destructor (without any functionality) adds cost. And unfortunately, you need to if your class happens to become a base class.


Well if you are working on an embedded platform, then its just poor discipline to add a virtual destructor and it boils down to bad programmers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: