[Xupicor]

It may be old news for some, but I've decided to put it here anyway. I've just come across this post:
http://www.cplusplus...reflection.html

I'm not going to comment much about it before I read the n3410 in full... But we're all used to reflection in other languages, what do you think about it being a part of C++? />

This post has been edited by ishkabible: 24 November 2012 - 03:57 PM

[ishkabible]

This would allow a lot more flexibility in the language. I think it would also provide a means by which accurate garbage collection could take place! It would deferentially open up a lot of possibilities. Multiplier dispatch could also be completely taken care of in the language sense the inheritance hierarchy would be known. So many features could be added as a library that so frequently require explicit language support.

This would be very cool!

This post has been edited by ishkabible: 24 November 2012 - 03:58 PM

[MathiasVP]

I could see static reflection as being part of the language. But I can't see how a feature such as dynamic introspection can be implemented in combination with C++'s aggressive optimizations. My fear is that it will become a very limited feature such as RTTI's typeid operator.

[ishkabible]

its just extra metadata that would be available both statically and dynamically. It wont interfere with optimization in anyway other than it will make binaries larger which *might* cause minnor cache performance issues but I doubt it. The only reason typeid is limited is because it lacks more metadata, not because of language limits.

[MathiasVP]

I was thinking of something along the lines of

struct S {
	int i;
};

int main(int argc, char* argv[])
{
	S s = {42};
	//... Something using s
	return 0;
}

Obviously the compiler will optimize away the struct and just replace it with an int. What should a dynamic introspection feature report about the members of S since they're compiled away?

[ishkabible]

well first off no, it doesn't optimize any structure away becuase there is no structure to optimize away. regardless of how that would be compiled it, it would be indistinguishable from just 1 integer.

second, the metadata would only be attached to a rich pointer in the dynamic case. that metadata would only be attached to the actual data after casting it to a rich pointer. hence the expression "only pay for what you use" still applies to C++ even with this. the metadata need not even be in the binary if you don't preform any casts to rich pointers.

last, unless there is an inheritance hierarchy or a void pointer is used(it looked like in the paper that casting any pointer to a rich_ptr<void> maintained proper type info unlike with other casts where the vtable and RTTI are not maintained) then type information can actually be determined statically. this is just the same kind of information as RTTI and vtables only it gives you even more information.

This post has been edited by ishkabible: 25 November 2012 - 06:10 PM

[vividexstance]

I'm not saying that reflection/introspection is not needed, but if you properly design your code, for the most part, you shouldn't have to rely on type information that frequently. And if you do, you might want to think about your design and any issues there might be.

[ishkabible]

You don't have to rely on it but it makes the language so much more flexible; you could construct much more sophisticated libraries with it.