[Development] Suggested addition to wiki.qt.io/Coding_Conventions
thiago.macieira at intel.com
Wed May 13 22:57:54 CEST 2015
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
More information about the Development