2 ms·
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 la
by blasdel 17y ago
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!
- groby_b 17y agoThe 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)
- aceofspades19 17y agoWell 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.
- dkarl 17y agoThe 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.
- groby_b 17y agoI'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.