7 ms·

Are you saying there's no way to make it optional and, when it's not being used, maintain the same runtime speeds? Virtual functions are "costly" too, but C++ h

by Jach 15y ago

Are you saying there's no way to make it optional and, when it's not being used, maintain the same runtime speeds? Virtual functions are "costly" too, but C++ has them and it's considered poor form to not declare your destructor virtual.

pmarin 15y ago
sincerely I don't know if is comparable the virtual function's overhead with the reflexion's overhead. Stroustrup answered a question about reflexion in this interview[1]: Have you ever considered adding reflection to C++? BS: Often. However, I have not seen an approach to full reflection directly supported by a language that didn't cause serious overheads. Also, reflection seems to encourage styles of programming that make it hard to determine what's going on from the source text and discourage static checking. I see that as a problem. Consequently, the C++ RTTI provides only the minimal information to determine the types of objects at run time. Where necessary, this can be used as a handle for more information about types (classes), but any such information is beyond what the standard guarantees[2]. [1] http://www2.research.att.com/~bs/omo_interview.html http://www2.research.att.com/~bs/omo_interview.html [2] I think he was talking about "type_info"
- malkia 15y ago
  MSVC Runtime already keeps names of the classes in the executable (browse the EXE and you would see it). Really the only loss there would be memory usage. And this can be all optional - where you can waste some memory, for more information about the code currently running - the better. There's already been such scarifies in C++ - exceptions, RTTI cannot be used everywhere - a xbox console would not handle C++ exceptions for example, yet you can still write in C++ (someone might argue that it's not C++ if it does not have exceptions)
tomjen3 15y ago
Well the issue is that virtual functions are only costly when they are used an it can (trivially) be determined at compile whether they are in use or not. On the other hand, you cannot determine if reflection will be used (not, at least without solving the halting problem) and so you have to generate the reflection code for everything.
- Game_Ender 15y ago
  And what is costly about the reflection code exactly? It is just some static structures with type information and function/data pointers. I fail to see how it can impact performance in anyway. The only side effect will be an increase in binary size.
copper 15y ago
> Virtual functions are "costly" too, but C++ has them and it's considered poor form to not declare your destructor virtual. It's a bit more subtle than that: a virtual destructor is only required when the class, or its base classes, already have another virtual function (and it's only really needed if another class inherits from it. hmm.) At that point, a virtual destructor doesn't add any more cost over and above the virtual function that's already defined.
- malkia 15y ago
  But not putting one, using foreign code base might get you in trouble (resource leaking, not de-initializing certain piece of the parent, threads not closing, etc.). This would've been prevented if destructors were always virtual. My take is that if the compiler cannot make the decision, but it's left to you, in this case it's better to always have the virtual destructors ON. The problem is more visual than analytical - you would have to dig through the whole hierarchy in several files to understand whether you need to put a virtual destructor or not. Compiler/Linker/some post-proc tool should be better at that job. It already has all that information.
  - copper 15y ago
    Hm, I'd rather pay the cost of having to add a virtual keyword in a few places (easily found using the equivalent of g++ -Wnon-virtual-dtor, and you do ship C++ code that is warning-free, right? :) rather than have to deal with up to eight bytes extra per instance in all my classes.
    - malkia 15y ago
      Thanks for the hint! Actually I did not know about this option. I've just fixed such bug in one of our tools, written using wxWidgets for Windows. Have to check MSVC on this option. At the same time a coworker was able to get the Xbox360 analyze thing and it worked finding suspicious stuff in the runtime code. But we have only the professional version for PC :(
      - 15y ago

by Jach 15y ago

pmarin 15y ago

sincerely I don't know if is comparable the virtual function's overhead with the reflexion's overhead. Stroustrup answered a question about reflexion in this interview[1]: Have you ever considered adding reflection to C++? BS: Often. However, I have not seen an approach to full reflection directly supported by a language that didn't cause serious overheads. Also, reflection seems to encourage styles of programming that make it hard to determine what's going on from the source text and discourage static checking. I see that as a problem. Consequently, the C++ RTTI provides only the minimal information to determine the types of objects at run time. Where necessary, this can be used as a handle for more information about types (classes), but any such information is beyond what the standard guarantees[2]. [1] http://www2.research.att.com/~bs/omo_interview.html http://www2.research.att.com/~bs/omo_interview.html [2] I think he was talking about "type_info"

malkia 15y ago
MSVC Runtime already keeps names of the classes in the executable (browse the EXE and you would see it). Really the only loss there would be memory usage. And this can be all optional - where you can waste some memory, for more information about the code currently running - the better. There's already been such scarifies in C++ - exceptions, RTTI cannot be used everywhere - a xbox console would not handle C++ exceptions for example, yet you can still write in C++ (someone might argue that it's not C++ if it does not have exceptions)

tomjen3 15y ago

Well the issue is that virtual functions are only costly when they are used an it can (trivially) be determined at compile whether they are in use or not. On the other hand, you cannot determine if reflection will be used (not, at least without solving the halting problem) and so you have to generate the reflection code for everything.

Game_Ender 15y ago
And what is costly about the reflection code exactly? It is just some static structures with type information and function/data pointers. I fail to see how it can impact performance in anyway. The only side effect will be an increase in binary size.

copper 15y ago

> Virtual functions are "costly" too, but C++ has them and it's considered poor form to not declare your destructor virtual. It's a bit more subtle than that: a virtual destructor is only required when the class, or its base classes, already have another virtual function (and it's only really needed if another class inherits from it. hmm.) At that point, a virtual destructor doesn't add any more cost over and above the virtual function that's already defined.

malkia 15y ago
But not putting one, using foreign code base might get you in trouble (resource leaking, not de-initializing certain piece of the parent, threads not closing, etc.). This would've been prevented if destructors were always virtual. My take is that if the compiler cannot make the decision, but it's left to you, in this case it's better to always have the virtual destructors ON. The problem is more visual than analytical - you would have to dig through the whole hierarchy in several files to understand whether you need to put a virtual destructor or not. Compiler/Linker/some post-proc tool should be better at that job. It already has all that information.
- copper 15y ago
  Hm, I'd rather pay the cost of having to add a virtual keyword in a few places (easily found using the equivalent of g++ -Wnon-virtual-dtor, and you do ship C++ code that is warning-free, right? :) rather than have to deal with up to eight bytes extra per instance in all my classes.
  - malkia 15y ago
    Thanks for the hint! Actually I did not know about this option. I've just fixed such bug in one of our tools, written using wxWidgets for Windows. Have to check MSVC on this option. At the same time a coworker was able to get the Xbox360 analyze thing and it worked finding suspicious stuff in the runtime code. But we have only the professional version for PC :(
    - 15y ago