Just think about the virtual destructor.. why isn't it automatically virtual?
Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members. The merits of what should be the default are debatable, but as with anything in C++, the reason is probably historical. For example, it would break all C code that used structs. One of the C++ design principles is to not impose features upon you that you don't need, so that might be why they decided not to e.g. make classes have virtual functions by default, but not structs, a bit like classes have private members and bases by default.
In any case, these are straw man arguments. The point I was trying to make is that you suggested turning down people because they know the low-level details of the platform and their implications. I counter that this is a phenomenally bad idea; knowing what lies beneath the abstraction is always a good idea, especially if that reveals dragons.
You haven't said anything to counter that, instead pointing out aspects of C++ you don't like. If you dislike C++ enough not to use it, why are you interviewing people for C++ programming positions anyway?
You are right that knowning low-level detail of a language is great and I have badly explained what I meant to say in my first post (Mostly because I'm a terribly bad english speaker). Here is what I meant to say: C++ is archaic for a lot of reasons; just read effective C++ of any book and you'll find subtile bugs that you need to avoid.
My point is: I don't say whether C++ is bad or not but when you compare it to scheme or python, for instance, you clearly see that there're some archaic parts. Some programmers only know C++ and have closed mind on everything else. If they start arguing about the glory of those "c++ design error", it's a huge hint that it's a C++-only programmer.
OK, I'll quite happily agree with that. I'm generally wary of people who won't venture outside one language (one-trick ponies). I personally try to avoid using C++ except where it's clearly the best choice, mostly because I used it as my main language for the best part of a decade (high performance computing and game development). The thing is, C++ is still possibly the best choice in that narrow segment where C alone is too tedious but a high-level language won't work for some reason.
Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members.
I also see classes used as members in Smalltalk. I wonder if a language can make the use of these sorts of objects explicit? Seems like there should be a good opportunity for better optimization.
A a;
A* p = new A;
assert(sizeof(*p) == sizeof(a));
This wouldn't be true and cause all sorts of trouble (arrays, etc.) if a had no pointer to a vtable, but *p did. Moreover, you can take the address of a stack/member object, so how would you distinguish the two types? You'd literally need to modify the type system, and that would cause trouble with templates, etc.
Comments
Thanks for saying I'm not competent.
This isn't what I said, but you know that anyway.
Just think about the virtual destructor.. why isn't it automatically virtual?
Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members. The merits of what should be the default are debatable, but as with anything in C++, the reason is probably historical. For example, it would break all C code that used structs. One of the C++ design principles is to not impose features upon you that you don't need, so that might be why they decided not to e.g. make classes have virtual functions by default, but not structs, a bit like classes have private members and bases by default.
In any case, these are straw man arguments. The point I was trying to make is that you suggested turning down people because they know the low-level details of the platform and their implications. I counter that this is a phenomenally bad idea; knowing what lies beneath the abstraction is always a good idea, especially if that reveals dragons.
You haven't said anything to counter that, instead pointing out aspects of C++ you don't like. If you dislike C++ enough not to use it, why are you interviewing people for C++ programming positions anyway?
You are right that knowning low-level detail of a language is great and I have badly explained what I meant to say in my first post (Mostly because I'm a terribly bad english speaker). Here is what I meant to say: C++ is archaic for a lot of reasons; just read effective C++ of any book and you'll find subtile bugs that you need to avoid.
My point is: I don't say whether C++ is bad or not but when you compare it to scheme or python, for instance, you clearly see that there're some archaic parts. Some programmers only know C++ and have closed mind on everything else. If they start arguing about the glory of those "c++ design error", it's a huge hint that it's a C++-only programmer.
OK, I'll quite happily agree with that. I'm generally wary of people who won't venture outside one language (one-trick ponies). I personally try to avoid using C++ except where it's clearly the best choice, mostly because I used it as my main language for the best part of a decade (high performance computing and game development). The thing is, C++ is still possibly the best choice in that narrow segment where C alone is too tedious but a high-level language won't work for some reason.
Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members.
I also see classes used as members in Smalltalk. I wonder if a language can make the use of these sorts of objects explicit? Seems like there should be a good opportunity for better optimization.
The problem with that (in C++) would be that
This wouldn't be true and cause all sorts of trouble (arrays, etc.) if a had no pointer to a vtable, but *p did. Moreover, you can take the address of a stack/member object, so how would you distinguish the two types? You'd literally need to modify the type system, and that would cause trouble with templates, etc.I'm not thinking of this in C++ or Smalltalk. I'm thinking of a feature in another language.