On Friday 22 May 2015 22:45:41 Marc Mutz wrote:
> On Friday 22 May 2015 18:32:21 Thiago Macieira wrote:
> > On Friday 22 May 2015 11:12:01 Marc Mutz wrote:
> > > On Thursday 21 May 2015 18:38:52 Thiago Macieira wrote:
> > > > Those are very good examples of not exporting the whole class, at the
> >
On Friday 22 May 2015 18:32:21 Thiago Macieira wrote:
> On Friday 22 May 2015 11:12:01 Marc Mutz wrote:
> > On Thursday 21 May 2015 18:38:52 Thiago Macieira wrote:
> > > Those are very good examples of not exporting the whole class, at the
> > > expense of making very ugly headers.
> >
> > Sorry,
On Friday 22 May 2015 11:12:01 Marc Mutz wrote:
> On Thursday 21 May 2015 18:38:52 Thiago Macieira wrote:
> > Those are very good examples of not exporting the whole class, at the
> > expense of making very ugly headers.
>
> Sorry, which class and which headers are you referring to?
The QVector
On Thursday 21 May 2015 18:38:52 Thiago Macieira wrote:
> Those are very good examples of not exporting the whole class, at the
> expense of making very ugly headers.
Sorry, which class and which headers are you referring to?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschl
On Thursday 21 May 2015 15:36:46 Marc Mutz wrote:
> FTR: Attempt at a workaround (existed for QVector already):
>https://codereview.qt-project.org/112761
> Now, _that_ is one ugly hack. And only necessary because non-polymorphic
> classes were exported. Open (perceived) beauty in one header th
On Thursday 21 May 2015 14:54:24 Marc Mutz wrote:
> > How?
>
> Compile a QtCore debug version with an MSVC version that doesn't support
> rvalue refs, try to link against an application compiled with an MSVC
> version that does?
>
> > > By Sergio's problem, an application built in C++11 debug mod
On Saturday 16 May 2015 22:01:36 Marc Mutz wrote:
> But the root problem isn't inheriting from templates, it's exporting
> the whole subclass.
>
> Convinced now?
FTR: Attempt at a workaround (existed for QVector already):
https://codereview.qt-project.org/112761
Now, _that_ is one ugly hack. A
On 21-May-15 14:54, Marc Mutz wrote:
> Compile a QtCore debug version with an MSVC version that doesn't support
> rvalue refs, try to link against an application compiled with an MSVC version
> that does?
You (usually) cannot build your application with MSVC X and link against
a Qt that was buil
On Wednesday 20 May 2015 20:23:01 Thiago Macieira wrote:
> On Tuesday 19 May 2015 11:47:47 Marc Mutz wrote:
> > Taking this train of thought one stop further: this is also makes QString
> >
> > BiC:
> >
> > class Q_CORE_EXPORT QString
> > {
> > public:
> > // ...
> >
> > #ifdef Q_COMPILE
On Tuesday 19 May 2015 11:47:47 Marc Mutz wrote:
> Taking this train of thought one stop further: this is also makes QString
> BiC:
>
> class Q_CORE_EXPORT QString
> {
> public:
> // ...
> #ifdef Q_COMPILER_RVALUE_REFS
> inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
>
On Tuesday 19. May 2015 11:47:47 Marc Mutz wrote:
> Taking this train of thought one stop further: this is also makes QString
> BiC:
>
> class Q_CORE_EXPORT QString
> {
> public:
> // ...
> #ifdef Q_COMPILER_RVALUE_REFS
> inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
On Saturday 16 May 2015 22:01:36 Marc Mutz wrote:
> On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > The drawbacks only appear in debug builds, so is this worth the
> > uglification?
>
> Yet another example of things that go wrong when blindly exporting
> classes wholesale:
>
> http:
On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> The drawbacks only appear in debug builds, so is this worth the
> uglification?
Yet another example of things that go wrong when blindly exporting
classes wholesale:
http://testresults.qt.io/logs/qt/qtdeclarative/472c6e2acc170082356db37
On Friday 15 May 2015 07:59:19 Marc Mutz wrote:
> Interesting. I didn't know that. Please document it on
> https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
>
> I guess that means we should revert
> ab8366b5923ec0feb730df98040885669f7bbe38, too?
Whoa! Yes, we have to
void f(
On Friday 15. May 2015 07:59:19 Marc Mutz wrote:
> On Thursday 14 May 2015 02:04:44 Thiago Macieira wrote:
> > On Thursday 14 May 2015 02:13:59 Marc Mutz wrote:
> > > On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > > > The drawbacks only appear in debug builds, so is this worth the
> >
On Thursday 14 May 2015 02:04:44 Thiago Macieira wrote:
> On Thursday 14 May 2015 02:13:59 Marc Mutz wrote:
> > On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > > The drawbacks only appear in debug builds, so is this worth the
> > > uglification?
> >
> > No, the drawbacks are *due to*
On Thursday 14 May 2015 09:33:59 Olivier Goffart wrote:
> On Thursday 14. May 2015 08:48:36 Thiago Macieira wrote:
> > On Thursday 14 May 2015 02:15:54 Marc Mutz wrote:
[...]
> > > The standard doesn't talk about DLLs and SOs. Semantics of those
> > > constructs is supplied by the platform ABI, not
On Thursday 14 May 2015 09:33:59 Olivier Goffart wrote:
> The standard C++ defines all the semantics of the code unless it defines it
> as implementation-defined or undefined behaviour.
> The ABI is just an implementation detail and cannot overwrite the C++
> standards.
>
> For example, the C++ st
On Thursday 14. May 2015 08:48:36 Thiago Macieira wrote:
> On Thursday 14 May 2015 02:15:54 Marc Mutz wrote:
> > On Wednesday 13 May 2015 23:36:29 Olivier Goffart wrote:
> > > On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote:
> > > > You cannot compare the addresses [of inline methods]
> > >
On Thursday 14 May 2015 02:13:59 Marc Mutz wrote:
> On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > The drawbacks only appear in debug builds, so is this worth the
> > uglification?
>
> No, the drawbacks are *due to* MSVC debug builds. They *appear* in release
> builds and all platfor
On Thursday 14 May 2015 02:15:54 Marc Mutz wrote:
> On Wednesday 13 May 2015 23:36:29 Olivier Goffart wrote:
> > On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote:
> > > You cannot compare the addresses [of inline methods]
> > > This is intentional and if you rely on that, your code is flawed
On Wednesday 13 May 2015 23:36:29 Olivier Goffart wrote:
> On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote:
> > You cannot compare the addresses [of inline methods]
> > This is intentional and if you rely on that, your code is flawed by
> > design.
>
> Why not?
> The C++ standards does not
On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> The drawbacks only appear in debug builds, so is this worth the
> uglification?
No, the drawbacks are *due to* MSVC debug builds. They *appear* in release
builds and all platforms, too. Exporting the whole class restricts what kind
of ch
On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote:
> You cannot compare the addresses [of inline methods]
> This is intentional and if you rely on that, your code is flawed by design.
Why not?
The C++ standards does not forbid it. It defines that it works. I see no
exceptions for inline f
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
>
> M
I guess this came from QSslEllipticCurve.
+1 for not doing that until it really affects release build [with
non-broken compilers].
Regards,
Konstantin
2015-05-13 17:45 GMT+04:00 Matthew Woehlke :
> On 2015-05-13 04:25, Marc Mutz wrote:
> > Hi,
> >
> > I'd like to suggest the following addition t
On 2015-05-13 04:25, Marc Mutz wrote:
> Hi,
>
> I'd like to suggest the following addition to the Qt Coding Conventions:
>
> === Exporting Classes ===
>
> Export polymorphic classes as a whole:
>
>
> class Q_LIB_EXPORT QMyWidget : public QWidget
> { ...
>
>
> But don't export non-polymor
On Wednesday 13 May 2015 10:25:57 Marc Mutz wrote:
> * it exports symbols that don't need exporting:
> ** private methods never called from user code
> ** methods of private nested structs and classes
> ** inline methods
> * exporting inline methods makes MSVC call the library implementation in
> d
Hi,
I'd like to suggest the following addition to the Qt Coding Conventions:
=== Exporting Classes ===
Export polymorphic classes as a whole:
class Q_LIB_EXPORT QMyWidget : public QWidget
{ ...
But don't export non-polymorphic classes that way. Instead, only export the
following non-inl
29 matches
Mail list logo
