I don't see a link incompatibility, since we're not changing signatures, or the layout of the class members or the vtable of DOMString. As long as we're careful not to put any inline calls to the implementation in the DOMString header, we should be O.K.
But, I'd be just as happy with the fall-back, since I do most of my debugging in debug mode. -Rob Dean Roddey wrote: >It might not be quite that simple. A major reason for the DOM having opaque >implementation classes is so that the implementations can be changed >without breaking binary compabitility. I'm not sure if that will remain the >case on all compilers once you move the class definition out to the header. > >If it doesn't cause this problem, then I got no problem with it. But, if it >does, we might need to consider some other way to achieve this result. > >One posibility would be to put those two little classes in a separate >header. In debug mode, include it into the DOMString header. In release >mode, include it back into the DOMString Cpp file in order to insure that >binary compatability issues are not compromised.
