On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote:
> On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote:
> >> Like you maybe have learned there are C++ Core Guidelines. They are
> >> already very comprehensive. What about basing the Qt Creator Code
> >> Style on it?
> >>
> >> I see advantages like new developer can easier grasp out rules
> >> because they are already familiar with it.
> >>
> >> We may have to exclude some rules too because they don't fit to us.
>
> Thiago Macieira replied:
> > "very comprehensive" is an understatement. Can you point out examples
> > of rules you're more interested in? Maybe we should start with a
> > whitelist of rules we do want and progressively expand from there.
>
> The guidelines' introduction does, after all, countenance gradual
> adoption - especially for existing code-bases - and a general opt-in
> approach. Presumably QtC's style is also used for new projects; it may
> be worth using a larger subset of the guidelines for new projects as
> compared to old; and it probably makes sense to make it easy for users
> to configure which of the guidelines they opt in to, for each project.
If we do nothing else, we should at least use owner<T> whereever possible. We
can add it to QtGlobal, since we require now enough C++11 to support it:
namespace gsl {
template <typename T> using owner<T> = T;
}
There, done. It doesn't even interfere with client code including a more
comprehensive GSL library, because they will define it the same way, and it's
just a type alias.
One problem is that in Qt, who is the owner is often not clear. But that
should not prevent us from using it everywhere else.
Than again, no compiler actually checks for this atm, not even MSVC, afaik, so
if we get it wrong, there's no-one but reviewers to call the mistake...
The bigger problem is that while owner<T> does not affect the ABI, all other
GSL types do, and we're back to our §$%&!§ rule that we can't accept other
libs' types in our ABI, preventing anything other than owner<T> from being
added to Qt.
My personal opinion is that we're way, WAY, past the tipping point where this
policy started to hurt Qt more than the convenience of interchanging libc++
and libstdc++ on OS X gives to the 5 people in the world that use this
feature. And I'm not at all happy that QtCS chickened out on a decision this
year. I don't think we can afford to wait for next year's QtCS to maybe-maybe-
not get rid of that nonsensical rule.
Thanks,
Marc
--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
