On Wednesday 13 May 2015 09:45:03 Matthew Woehlke wrote: > > But exporting the whole class, while convenient, has several drawback: > > > > * it exports symbols that don't need exporting: > > ** private methods never called from user code > > ** methods of private nested structs and classes > > Many Qt classes have corresponding Private (PIMPL) classes. Private > methods would hopefully be few and far between. > > Is it possible to override the export decoration for things like this > that should *not* be exported?
Yes, but not on Windows, which was the point of the proposal. > > ** inline methods > > * exporting inline methods makes MSVC call the library implementation in > > debug builds > > That's a feature. There are reasons why debug builds don't inline > (mostly because it makes stack traces unreliable). This is not about inlining. This is about calling the library implementation instead of emitting a local copy and calling that. > > ** a copy of the function is placed in the library even though the library > > itself may never use it > > What if I need to take the address of an inline method (e.g. to use it > as a functor argument)? See above: the compiler should be smart enough to emit a local copy and pass the address to that. You cannot compare the addresses. This is intentional and if you rely on that, your code is flawed by design. > > ** exported inline functions can no longer be removed > > They can't anyway, as this would be both an API and ABI break; see > previous point. Only if you accept the MSVC ABI behaviour. Private inline methods could be removed if it weren't for that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
