> A struct nested in a class does not have a hidden "outer" pointer as a > nested class does. It's because a struct is generally more bare-bones than > a class (which has loads of hidden pieces: vtable, interfaces, classinfo, > etc.). Also, instantiating such a struct does not tie it to a class > instance. >
Thanks Steve As far as I am concerned, this is a very limiting behavior wrt structs nested inside classes. I have also observed that if you define a constant (using enum for example) inside the enclosing class, the constant remains visible in the nested struct too. So I believe the language is making the hidden "outer" scope visible to the nested struct (or maybe there is some other mechanism for enums that I am not aware of). > You need to implement this behavior on your own: > Actually I am trying to define a DSEL and the end users are not typically programmers. I am in a situation where the end-user decides the unit in an enclosing class (unit of length as an inch for example) and later whenever he instantiates a line or a shape, the particular unit is automatically considered at the time of instantiation. For my application, I need value semantics and therefor using nested classes in place of structs can not be considered. Making the end-users pass the unit or its context (in form of this pointer) everytime they instantiate a shape would be atrocious. It would defeat the very purpose of letting the end-user define a unit. I know I am not on the right mailing group, but I want to ask for this particular language enhancement. I believe this would make the behavior of the language more straight wrt nested structs inside classes (are not these beasts expected to serve like nested classes or even structs nested inside function scopes?). I hope my requirement is generic enough and fits the bill for an enhancement request. Regards - Cherry