Qt for example uses the pimpl idiom for achieving ABI compatibility between releases. The problem is additional heap allocations, additional indirection and you pay for it, whether needed or not. (For example even derived classes in the same library pay for it.) I wondered whether this would still be necessary in D and I think not. In D, as interface files are automatically generated, it could be possible to have ones created with let's say a special "@private_impl" property or something. For these classes the object size would have to be stored as hidden static member in the library. The new operator could then simply read the size and allocate the needed space. Derived class methods can also use the size to calculate the offset of the derived class data members.
So you would lose some optimizations, e.g. initializing of base members can't be inlined and stuff. But this is not possible with pimpl either and you gain the following: - You only pay for it if you want it. You can also use the standard .di file and lose the ABI compatiblity between versions if you so want and derived classes in the same library do not need to pay any additional overhead either. - It is completely transparent: If you later on decide you need ABI compatibility between releases, it's just a matter of a compiler switch and differend .di files. - I think it will also be more efficient than pimpl in all regards. I think this would be a real neat and very important feature, when it comes to shared libraries. Is there any plan to implement something like that in the future? Do I miss something? Best regards, Robert -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
