What is the general feeling about reflection extensions in std::type_info?
Posted
by Evan Teran
on Stack Overflow
See other posts from Stack Overflow
or by Evan Teran
Published on 2010-03-18T18:11:41Z
Indexed on
2010/03/18
18:31 UTC
Read the original article
Hit count: 366
I've noticed that reflection is one feature that developers from other languages find very lacking in c++. For certain applications I can really see why! It is so much easier to write things like an IDE's auto-complete if you had reflection. And certainly serialization APIs would be a world easier if we had it.
On the other side, one of the main tenets of c++ is don't pay for what you don't use. Which makes complete sense. That's something I love about c++.
But it occurred to me there could be a compromise. Why don't compilers add extensions to the std::type_info
structure? There would be no runtime overhead. The binary could end up being larger, but this could be a simple compiler switch to enable/disable and to be honest, if you are really concerned about the space savings, you'll likely disable exceptions and RTTI anyway.
Some people cite issues with templates, but the compiler happily generates std::type_info
structures for template types already.
I can imagine a g++ switch like -fenable-typeinfo-reflection
which could become very popular (and mainstream libs like boost/Qt/etc could easily have a check to generate code which uses it if there, in which case the end user would benefit with no more cost than flipping a switch). I don't find this unreasonable since large portable libraries like this already depend on compiler extensions.
So why isn't this more common? I imagine that I'm missing something, what are the technical issues with this?
© Stack Overflow or respective owner