[Development] Suggested addition to wiki.qt.io/Coding_Conventions

[Thiago Macieira]

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