Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Monday 29 of February 2016 08:38:30 Thiago Macieira wrote:
> On segunda-feira, 29 de fevereiro de 2016 10:09:51 PST Jędrzej Nowacki 
wrote:
> > On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote:
> > > > I.e. what problems would we get from having to install the
> > > > moc files?
> > > 
> > > Lots.
> > 
> > And probably all go away if instead of installing anything we use
> > QMetaObjectBuilder (assuming it's api stabilization). Yes it would have
> > performance impact, but only on the templated version and only during
> > initialization, qml is paying that price constantly without bigger
> > complains. It would not require any build system changes. The only
> > limitation I can think of right now is that in QObject, Foo needs to
> > be know to QMetaType system, which is not a big deal.
> 
> What source data do you propose for QMOB?

So for QObject moc should generate something like that:
{
QMetaObjectBuilder builder; // Side note: add overloads that takes type 
id
builder.addProperty("property", "int")
builder.addMethod("void Invokable(int)"); 
builder.setClassName("QObject<" + 
QMetaType::typeName(qMetaTypeId()) 
+ ">")
return builder.toMetaObject();
}

Yes, it is super inefficient, but in the same time I think it is quite safe to 
support. 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Thursday, March 3, 2016 2:05:18 PM CET Dominik Haumann wrote:
> Hi Milian,
> 
> On Thu, Feb 25, 2016 at 7:22 PM, Milian Wolff  wrote:
> > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> >> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam 
wrote:
> >> > This might be a burden for some of the Qt developers (Windows ones).
> >> > 
> >> > But all the Qt users get a modern / flexible moc, see this thread:
> >> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c
> >> > 90e
> >> 
> >> I don't think we need a more flexible moc. What do we want to do that we
> >> can't do with the current one?
> >> 
> >> Don't say "template QObjects". That has other reasons for being a bad
> >> idea,
> >> currently.
> > 
> > Can you explain what those reasons are? I'd really love to write a generic
> > QAbstractTableModel implementation that operates using concepts. Currently
> > that would require type erasure and thus another set of virtual function
> > calls...
> > [...]
> > If we'd have templates QObjects, the above could easily be written. I bet
> > there are other valid use-cases.
> 
> It's not directly related, but instead of templated QObjects you
> could also find worksarounds like this:
> template 
> class Foo {
> public:
> // ...
> QObject * notificationObject();
> private:
> QObject * m_notificationObject;
> };
> 
> In the constructor, you can create the m_notificationObject
> and even to connects etc.
> 
> I once used this trick (in a non-templated version) to obtain
> value-semantics for a class that can still have signals and
> slots etc (be careful with assignment operator, though).
> Of course, you still might not have the metadata moc
> typically creates for you. So I'm not claiming this is a
> totally cool solution, but sometimes this workaround
> comes in very handy.

Note that this won't work for the use-case I have in mind, namely templated 
QAIM implementations for efficient, and correct, list and table models on 
QVector.

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Dominik Haumann]

Hi Milian,
On Thu, Feb 25, 2016 at 7:22 PM, Milian Wolff  wrote:
> On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
>> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote:
>> > This might be a burden for some of the Qt developers (Windows ones).
>> >
>> > But all the Qt users get a modern / flexible moc, see this thread:
>> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e
>>
>> I don't think we need a more flexible moc. What do we want to do that we
>> can't do with the current one?
>>
>> Don't say "template QObjects". That has other reasons for being a bad idea,
>> currently.
>
> Can you explain what those reasons are? I'd really love to write a generic
> QAbstractTableModel implementation that operates using concepts. Currently
> that would require type erasure and thus another set of virtual function
> calls...
> [...]
> If we'd have templates QObjects, the above could easily be written. I bet
> there are other valid use-cases.

It's not directly related, but instead of templated QObjects you
could also find worksarounds like this:
template 
class Foo {
public:
// ...
QObject * notificationObject();
private:
QObject * m_notificationObject;
};

In the constructor, you can create the m_notificationObject
and even to connects etc.

I once used this trick (in a non-templated version) to obtain
value-semantics for a class that can still have signals and
slots etc (be careful with assignment operator, though).
Of course, you still might not have the metadata moc
typically creates for you. So I'm not claiming this is a
totally cool solution, but sometimes this workaround
comes in very handy.

Cheers,
Dominik
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quinta-feira, 3 de março de 2016 08:24:23 PST Olivier Goffart wrote:
> > I'm not against the principle. I am against the implementation details, as
> > Olivier's current commit has.
> 
> This commit was a starting point. Of course there are implementation details
> to address.
> However, I took your -2 as a "Don't even bother working on it".

I thought I was clear that the -2 was because we needed to have a mailing list 
discussion. Which we've now had.

> > In the course of this thread, we came up with workable solutions I
> > wouldn't
> > object to. I don't like them, I find that they are limited and will bite
> > people in the back, but they don't have fatal flaws.
> 
> As soon as the limitations are known and documented, it is fine.
> The current approach also has plenty of limitations. We are just removing
> some limitations.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Olivier Goffart]

Am Mittwoch, 2. März 2016, 13:43:39 CET schrieb Thiago Macieira:
> On quarta-feira, 2 de março de 2016 22:34:16 PST Milian Wolff wrote:
> > On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote:
> > > On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote:
> > > > Hey Thiago,
> > > > 
> > > > what is "the runtime merging problem on Windows"?
> > > 
> > > Ever heard of the dynamic_cast problem on Windows? It's the same.
> > 
> > Great, thanks a lot for this insightful write-up!
> > 
> > So, do you -2 a templated QObject then for these reasons?
> 
> I'm not against the principle. I am against the implementation details, as
> Olivier's current commit has.

This commit was a starting point. Of course there are implementation details 
to address.
However, I took your -2 as a "Don't even bother working on it".

> In the course of this thread, we came up with workable solutions I wouldn't
> object to. I don't like them, I find that they are limited and will bite
> people in the back, but they don't have fatal flaws.

As soon as the limitations are known and documented, it is fine.
The current approach also has plenty of limitations. We are just removing some 
limitations.

-- 
Olivier 

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quarta-feira, 2 de março de 2016 22:34:16 PST Milian Wolff wrote:
> On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote:
> > On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote:
> > > Hey Thiago,
> > > 
> > > what is "the runtime merging problem on Windows"?
> > 
> > Ever heard of the dynamic_cast problem on Windows? It's the same.
> 
> Great, thanks a lot for this insightful write-up!
> 
> So, do you -2 a templated QObject then for these reasons? 

I'm not against the principle. I am against the implementation details, as 
Olivier's current commit has.

In the course of this thread, we came up with workable solutions I wouldn't 
object to. I don't like them, I find that they are limited and will bite people 
in the back, but they don't have fatal flaws.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote:
> On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote:
> > Hey Thiago,
> > 
> > what is "the runtime merging problem on Windows"?
> 
> Ever heard of the dynamic_cast problem on Windows? It's the same.

Great, thanks a lot for this insightful write-up!

So, do you -2 a templated QObject then for these reasons? Personally, I still 
think that it would be nice to have. The cases I'm thinking of using this 
feature, i.e. QAIM, would always involve private data types. But of course, 
with Qt being a library, I realize that it has to care for all eventualities, 
like a common Foo being used repeatedly and then breaking ODR.

Thanks

> Here's the problem:
> 
> QMetaObjects are identified by their pointer addresses: two meta objects are
> the same if their pointer addresses are the same (remember: QMetaObject has
> no operator==). qobject_cast uses that feature to conclude whether a given
> object derives from a given class.
> 
> The way it's currently designed in Qt, the meta object is exported
> (Q_DECL_EXPORT) from the DLL in which the class is defined. Obviously, that
> can only happen for concrete types, not for templates. As I explained, we
> could add a feature to allow the class author to export all possible
> instantiations of a template. Each and every instantiation would be
> exported from the DLL. That's, in fact, why a full listing is required: to
> determine which instantiations to export in the first place.
> 
> The other suggestion done here is that the user of a template create the
> meta object. That's how typeinfo works for types without virtual tables:
> each place where typeid() is called, the typeinfo is generated, then merged
> at runtime by the dynamic linker. On ELF systems without any special
> compiler flags, this works because symbols are global by default ("default"
> visibility) and all references to any symbol name are accessed via the GOT,
> which ensures that only one copy is active and all accesses get the same
> pointer address.
> 
> Where this breaks down:
> 
> 1) Windows: the PE-COFF file format does not work like ELF. Symbols are by
> local (the default), __declspec(dllexport), or __declspec(dllimport). If the
> symbol is local or exported, then the compiler generates access assuming
> that the copy in the current DLL is the active one; if it's imported, then
> the compiler generates code assuming it exists in another DLL and will not
> emit a copy.
> 
> This means that if a DLL has a copy, it assumes its copy is active. If it
> has no copy, some other DLL must have it. What's more, imports are
> associated with a particular DLL, so the compile-time linker needs to know
> which DLL contains the symbol.
> 
> I don't know how or even if throwing template types or dynamic_cast'ing them
> works on Windows. It's possible it doesn't work and will never work. I
> don't care to find out.
> 
> 2) "hidden" visibility: modern libraries on Unix today compile with
> -fvisibility=hidden -fvisibility-inlines-hidden, like Qt does. Many of them,
> like Qt, heavily pollute the global namespace if you don't use those flags,
> and that's assuming they work at all. Every type with hidden visibility is,
> as the name says, not exported to the ELF dynamic symbol table, which means
> the dynamic linker doesn't see them and will not merge with other copies.
> 
> 3) -Bsymbolic / "protected" visibility: this instructs the compiler and
> linker that the exported symbols are not subject to preemption and that,
> like Windows's __declspec(dllexport), the copy in this ELF module is always
> the active one and local accesses need not go through the GOT (that's why
> we use it). If this assumption fails, crazy things happen, as we've seen
> with platforms other than x86 for our -Bsymbolic usage.
> 
> Summary: this is where the theory of the C++ Standard and reality do not
> agree. When you take the ABIs into consideration, the C++ Standard's
> definition of ODR is just wishful thinking.
> 
> In time: C++17 Modules do not solve this issue. Modules replace some use of
> headers and #include; they have nothing to do with DLLs and symbol
> exporting/ importing.
> 
> Glossary:
>  * ELF: Executable and Linkable Format, the file format for all object
> files, libraries, executables and core dumps on modern Unix systems, first
> deployed by Sun on Solaris.
>  * PE-COFF: Portable Executable COFF, Microsoft's variant of the COFF object
> file format, used for DLLs and executables (not for .obj files, that's
> OMF). * GOT: Global Offset Table, a technique used to achieve position-
> independence. Whenever a symbol "foo" is referenced, instead of writing its
> address into the code, the compiler generates an indirect load of the
> symbol's address from a fixed location in the GOT, which the dynamic linker
> will write to once it has finished loading all modules and can resolve all
> symbols. This can be used to make the code read-only and share

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote:
> Hey Thiago,
> 
> what is "the runtime merging problem on Windows"?

Ever heard of the dynamic_cast problem on Windows? It's the same.

Here's the problem:

QMetaObjects are identified by their pointer addresses: two meta objects are 
the same if their pointer addresses are the same (remember: QMetaObject has no 
operator==). qobject_cast uses that feature to conclude whether a given object 
derives from a given class.

The way it's currently designed in Qt, the meta object is exported 
(Q_DECL_EXPORT) from the DLL in which the class is defined. Obviously, that can 
only happen for concrete types, not for templates. As I explained, we could 
add a feature to allow the class author to export all possible instantiations 
of a template. Each and every instantiation would be exported from the DLL. 
That's, in fact, why a full listing is required: to determine which 
instantiations to export in the first place.

The other suggestion done here is that the user of a template create the meta 
object. That's how typeinfo works for types without virtual tables: each place 
where typeid() is called, the typeinfo is generated, then merged at runtime by 
the dynamic linker. On ELF systems without any special compiler flags, this 
works because symbols are global by default ("default" visibility) and all 
references to any symbol name are accessed via the GOT, which ensures that 
only one copy is active and all accesses get the same pointer address.

Where this breaks down:

1) Windows: the PE-COFF file format does not work like ELF. Symbols are by 
local (the default), __declspec(dllexport), or __declspec(dllimport). If the 
symbol is local or exported, then the compiler generates access assuming that 
the copy in the current DLL is the active one; if it's imported, then the 
compiler generates code assuming it exists in another DLL and will not emit a 
copy.

This means that if a DLL has a copy, it assumes its copy is active. If it has 
no copy, some other DLL must have it. What's more, imports are associated with 
a particular DLL, so the compile-time linker needs to know which DLL contains 
the symbol.

I don't know how or even if throwing template types or dynamic_cast'ing them 
works on Windows. It's possible it doesn't work and will never work. I don't 
care to find out.

2) "hidden" visibility: modern libraries on Unix today compile with 
-fvisibility=hidden -fvisibility-inlines-hidden, like Qt does. Many of them, 
like Qt, heavily pollute the global namespace if you don't use those flags, and 
that's assuming they work at all. Every type with hidden visibility is, as the 
name says, not exported to the ELF dynamic symbol table, which means the 
dynamic linker doesn't see them and will not merge with other copies.

3) -Bsymbolic / "protected" visibility: this instructs the compiler and linker 
that the exported symbols are not subject to preemption and that, like 
Windows's __declspec(dllexport), the copy in this ELF module is always the 
active one and local accesses need not go through the GOT (that's why we use 
it). If this assumption fails, crazy things happen, as we've seen with 
platforms other than x86 for our -Bsymbolic usage.

Summary: this is where the theory of the C++ Standard and reality do not 
agree. When you take the ABIs into consideration, the C++ Standard's definition 
of ODR is just wishful thinking.

In time: C++17 Modules do not solve this issue. Modules replace some use of 
headers and #include; they have nothing to do with DLLs and symbol exporting/
importing.

Glossary:
 * ELF: Executable and Linkable Format, the file format for all object files, 
libraries, executables and core dumps on modern Unix systems, first deployed by 
Sun on Solaris.
 * PE-COFF: Portable Executable COFF, Microsoft's variant of the COFF object 
file format, used for DLLs and executables (not for .obj files, that's OMF).
 * GOT: Global Offset Table, a technique used to achieve position-
independence. Whenever a symbol "foo" is referenced, instead of writing its 
address into the code, the compiler generates an indirect load of the symbol's 
address from a fixed location in the GOT, which the dynamic linker will write 
to once it has finished loading all modules and can resolve all symbols. This 
can be used to make the code read-only and shareable. See also PLT and the GOT 
pointer (which is the value that the PIC register carries).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Mittwoch, 2. März 2016 11:28:07 CET Thiago Macieira wrote:
> On quarta-feira, 2 de março de 2016 19:24:15 PST Milian Wolff wrote:
> > On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote:
> > > On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote:
> > > > A simple solution would then be a macro for an explicit instantiation,
> > > > similar  to what we already do with
> > > > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would
> > > > moc
> > > > generate the static meta object. That should work, no?
> > > 
> > > That is the case I mentioned before: the template class's author needs
> > > to
> > > know each and every possible instantiation ahead of time and instantiate
> > > them. Unlikely to be acceptable use-case.
> > 
> > For the use-case I have in mind, i.e. templated models, it would just
> > fine.
> > Note that I did not propose to have the macro for the instantiation where
> > the template gets defined. Rather, I imagine users of the template to do
> > that on demand.
> 
> That's not the case above. I was talking about pre-populating every possible
> instantiation.
> 
> If the users do it on demand, then we have the runtime merging problem on
> Windows.
> 
> Pick your poison.

Hey Thiago,

what is "the runtime merging problem on Windows"?

Thanks
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quarta-feira, 2 de março de 2016 19:24:15 PST Milian Wolff wrote:
> On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote:
> > On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote:
> > > A simple solution would then be a macro for an explicit instantiation,
> > > similar  to what we already do with
> > > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc
> > > generate the static meta object. That should work, no?
> > 
> > That is the case I mentioned before: the template class's author needs to
> > know each and every possible instantiation ahead of time and instantiate
> > them. Unlikely to be acceptable use-case.
> 
> For the use-case I have in mind, i.e. templated models, it would just fine.
> Note that I did not propose to have the macro for the instantiation where
> the template gets defined. Rather, I imagine users of the template to do
> that on demand.

That's not the case above. I was talking about pre-populating every possible 
instantiation.

If the users do it on demand, then we have the runtime merging problem on 
Windows.

Pick your poison.

> It's like QMetaType, no? We can, optionally, supply a set of instantiations
> for common types in the library. All others will be done by the user on-
> demand. If he then triggers an ODR violation, he can solve it by sharing the
> common code.

No, it isn't. QMetaType doesn't compare pointers. QMetaType assumes that ODR 
wasn't violated.

The meta objects will violate ODR.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote:
> On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote:
> > A simple solution would then be a macro for an explicit instantiation,
> > similar  to what we already do with
> > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc
> > generate the static meta object. That should work, no?
> 
> That is the case I mentioned before: the template class's author needs to
> know each and every possible instantiation ahead of time and instantiate
> them. Unlikely to be acceptable use-case.

For the use-case I have in mind, i.e. templated models, it would just fine. 
Note that I did not propose to have the macro for the instantiation where the 
template gets defined. Rather, I imagine users of the template to do that on 
demand.

It's like QMetaType, no? We can, optionally, supply a set of instantiations 
for common types in the library. All others will be done by the user on-
demand. If he then triggers an ODR violation, he can solve it by sharing the 
common code.

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote:
> A simple solution would then be a macro for an explicit instantiation,
> similar  to what we already do with
> Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc
> generate the static meta object. That should work, no?

That is the case I mentioned before: the template class's author needs to know 
each and every possible instantiation ahead of time and instantiate them. 
Unlikely to be acceptable use-case.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On quarta-feira, 2 de março de 2016 10:14:18 PST Ziller Eike wrote:
> That would break if any other code in the application (possibly in a
> different library linked to it) has e.g. using Blah = Foo;
> right?
> That sounds pretty fragile. Especially if an application loads plugins.

Correct.

You cannot compare the template instantiations' meta objects across libraries. 
They will compare as if they were different classes (with the same name).

That's an ODR violation, but it's allowed because we're talking about DLLs.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Mittwoch, 2. März 2016 13:48:49 CET Ziller Eike wrote:
> > On Mar 2, 2016, at 11:23 AM, Milian Wolff  wrote:
> > 
> > On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote:
> > 
> >>> On Feb 29, 2016, at 1:21 PM, Milian Wolff 
> >>> wrote:
> >>> 
> >>> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
> >>> 
> >>> 
>  On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff
>  wrote:
>  
>  
> >> The main problems of templated QObject are captured more or less in
> >> this
> >> 
> >> thread:
> >> http://lists.qt-project.org/pipermail/development/2013-March/010288.h
> >> tm
> >> l
> >> 
> >> Personally I still think it would be a fancy feature, a bit
> >> dangerous
> >> to
> >> 
> >> implement maybe even dangerous to use, but really cool :-D
> > 
> > 
> > 
> > Thanks for the link. How often is the MOC layout changed in an ABI
> > incompatible way?
>  
>  
>  
>  There's no historical pattern. There was a major break from Qt 3 to 4
>  and
>  smaller one from 4 to 5. Qt 4 did have updates that didn't break the
>  ABI;
>  the Qt 5.0 update removed the ability to read meta objects created
>  with
>  Qt
>  4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3
>  still
>  used register-on-load meta objects).
>  
>  But since the meta object itself has a version number and the only
>  code
>  that
> > 
> > ever reads the internal data is inside QtCore, so we could make
> > 
>  changes that change the layout.  We haven't done that: all changes
>  between major releases have added things without changing the layout.
>  
>  That's the structure layout though. The file itself compares the
>  Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
> >>> 
> >>> 
> >>> 
> >>> OK, but changing the layout between major versions is fine as we break
> >>> ABI
> >>> 
> > 
> > anyways then, no?
> > 
> >>> 
> >>> 
> >>> 
> > I.e. what problems would we get from having to install the
> > moc files?
>  
>  
>  
>  Lots.
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
>  Have I convinced you? I'm only getting warmed up. I'm sure I can find
>  more
>  issues.
> >>> 
> >>> 
> >>> 
> >>> Thanks for the exhaustive, and educative list! I think this should be
> >>> put
> >>> on 
> > 
> > the Wiki somewhere for future reference.
> > 
> >>> 
> >>> 
> >>> 
> > Alternatively: couldn't moc re-create the required data from included
> > files
> > when they contain templated objects? That would solve the problem as
> > well,
> > no?
>  
>  
>  
>  I have no idea what you meant here.
>  
>  Or, well, I do have one, but I don't think that I understood correctly
>  what
> > 
> > you're suggesting. I understood that we keep a copy of the header
> > 
>  file's source in the target application and run moc at runtime to
>  dynamically create the meta object, on the fly.
>  
>  Since I don't think that's what you're suggesting and since the above
>  has
>  so
> > 
> > many problems (starting with the fact that it doesn't resolve the
> > 
>  problem), I'm not even going to analyse it.
>  
>  Can you clarify what you meant?
> >>> 
> >>> 
> >>> 
> >>> Yes, what I had in mind from my outsiders POV was the following, and I
> >>> have no 
> > 
> > clue whether it is feasible at all:
> > 
> >>> 
> >>> We have the following structure:
> >>> 
> >>> $path1/lib/foo.h
> >>> template Foo : QObject { ...};
> >>> 
> >>> moc is not doing anything here as the templated QObject is not fully 
> >>> specialized.
> >>> 
> >>> $path2/app/bar.h:
> >>> #include 
> >>> using Bar = Foo;
> >> 
> >> 
> >> 
> >> That would break if any other code in the application (possibly in a
> >> different library linked to it) has e.g.
> > 
> > using Blah = Foo;
> > 
> >> right?
> >> That sounds pretty fragile. Especially if an application loads plugins.
> > 
> > 
> > Can you clarify what would break here? Isn't it exactly the same as doing
> > 
> > QVector in multiple TUs?
> 
> 
> As I understood it, moc would generate the MetaObject for Foo when it
> sees “using SomeAlias = Foo” (or some macro).
 So if lib A does it and
> lib B does it, and they both get linked into the same application, there
> would be two implementations of the static meta object, which Thiago said
> would not work? But maybe I missed something from the discussion.

Ah, indeed - QMetaObject::cast e.g. does a pointer comparison on the static 
meta object. So if we end up with two instances of that in different TUs, 
we'll encounter issues.

A simple solution would then be a macro for an explicit instantiation, similar 
to what we already do with Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only 
there then would moc generate the static meta object. That should work, no?

Bye
-- 
Mil

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Ziller Eike]

> On Mar 2, 2016, at 11:23 AM, Milian Wolff  wrote:
> 
> On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote:
>>> On Feb 29, 2016, at 1:21 PM, Milian Wolff  wrote:
>>> 
>>> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
>>> 
 On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
 
>> The main problems of templated QObject are captured more or less in
>> this
>> 
>> thread:
>> http://lists.qt-project.org/pipermail/development/2013-March/010288.htm
>> l
>> 
>> Personally I still think it would be a fancy feature, a bit dangerous
>> to
>> 
>> implement maybe even dangerous to use, but really cool :-D
> 
> 
> Thanks for the link. How often is the MOC layout changed in an ABI
> incompatible way?
 
 
 There's no historical pattern. There was a major break from Qt 3 to 4
 and
 smaller one from 4 to 5. Qt 4 did have updates that didn't break the
 ABI;
 the Qt 5.0 update removed the ability to read meta objects created with
 Qt
 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
 used register-on-load meta objects).
 
 But since the meta object itself has a version number and the only code
 that
> ever reads the internal data is inside QtCore, so we could make
 changes that change the layout.  We haven't done that: all changes
 between major releases have added things without changing the layout.
 
 That's the structure layout though. The file itself compares the
 Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
>>> 
>>> 
>>> OK, but changing the layout between major versions is fine as we break ABI
>>> 
> anyways then, no?
>>> 
>>> 
> I.e. what problems would we get from having to install the
> moc files?
 
 
 Lots.
>>> 
>>> 
>>> 
>>> 
>>> 
 Have I convinced you? I'm only getting warmed up. I'm sure I can find
 more
 issues.
>>> 
>>> 
>>> Thanks for the exhaustive, and educative list! I think this should be put
>>> on 
> the Wiki somewhere for future reference.
>>> 
>>> 
> Alternatively: couldn't moc re-create the required data from included
> files
> when they contain templated objects? That would solve the problem as
> well,
> no?
 
 
 I have no idea what you meant here.
 
 Or, well, I do have one, but I don't think that I understood correctly
 what
> you're suggesting. I understood that we keep a copy of the header
 file's source in the target application and run moc at runtime to
 dynamically create the meta object, on the fly.
 
 Since I don't think that's what you're suggesting and since the above has
 so
> many problems (starting with the fact that it doesn't resolve the
 problem), I'm not even going to analyse it.
 
 Can you clarify what you meant?
>>> 
>>> 
>>> Yes, what I had in mind from my outsiders POV was the following, and I
>>> have no 
> clue whether it is feasible at all:
>>> 
>>> We have the following structure:
>>> 
>>> $path1/lib/foo.h
>>> template Foo : QObject { ...};
>>> 
>>> moc is not doing anything here as the templated QObject is not fully 
>>> specialized.
>>> 
>>> $path2/app/bar.h:
>>> #include 
>>> using Bar = Foo;
>> 
>> 
>> That would break if any other code in the application (possibly in a
>> different library linked to it) has e.g.
> using Blah = Foo;
>> right?
>> That sounds pretty fragile. Especially if an application loads plugins.
> 
> Can you clarify what would break here? Isn't it exactly the same as doing 
> QVector in multiple TUs?

As I understood it, moc would generate the MetaObject for Foo when it sees 
“using SomeAlias = Foo” (or some macro).
So if lib A does it and lib B does it, and they both get linked into the same 
application, there would be two implementations of the static meta object, 
which Thiago said would not work?
But maybe I missed something from the discussion.

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote:
> > On Feb 29, 2016, at 1:21 PM, Milian Wolff  wrote:
> > 
> > On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
> > 
> >> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
> >> 
>  The main problems of templated QObject are captured more or less in
>  this
>  
>  thread:
>  http://lists.qt-project.org/pipermail/development/2013-March/010288.htm
>  l
>  
>  Personally I still think it would be a fancy feature, a bit dangerous
>  to
>  
>  implement maybe even dangerous to use, but really cool :-D
> >>> 
> >>> 
> >>> Thanks for the link. How often is the MOC layout changed in an ABI
> >>> incompatible way?
> >> 
> >> 
> >> There's no historical pattern. There was a major break from Qt 3 to 4
> >> and
> >> smaller one from 4 to 5. Qt 4 did have updates that didn't break the
> >> ABI;
> >> the Qt 5.0 update removed the ability to read meta objects created with
> >> Qt
> >> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
> >> used register-on-load meta objects).
> >> 
> >> But since the meta object itself has a version number and the only code
> >> that
 ever reads the internal data is inside QtCore, so we could make
> >> changes that change the layout.  We haven't done that: all changes
> >> between major releases have added things without changing the layout.
> >> 
> >> That's the structure layout though. The file itself compares the
> >> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
> > 
> > 
> > OK, but changing the layout between major versions is fine as we break ABI
> > 
 anyways then, no?
> > 
> > 
> >>> I.e. what problems would we get from having to install the
> >>> moc files?
> >> 
> >> 
> >> Lots.
> > 
> > 
> > 
> > 
> > 
> >> Have I convinced you? I'm only getting warmed up. I'm sure I can find
> >> more
> >> issues.
> > 
> > 
> > Thanks for the exhaustive, and educative list! I think this should be put
> > on 
 the Wiki somewhere for future reference.
> > 
> > 
> >>> Alternatively: couldn't moc re-create the required data from included
> >>> files
> >>> when they contain templated objects? That would solve the problem as
> >>> well,
> >>> no?
> >> 
> >> 
> >> I have no idea what you meant here.
> >> 
> >> Or, well, I do have one, but I don't think that I understood correctly
> >> what
 you're suggesting. I understood that we keep a copy of the header
> >> file's source in the target application and run moc at runtime to
> >> dynamically create the meta object, on the fly.
> >> 
> >> Since I don't think that's what you're suggesting and since the above has
> >> so
 many problems (starting with the fact that it doesn't resolve the
> >> problem), I'm not even going to analyse it.
> >> 
> >> Can you clarify what you meant?
> > 
> > 
> > Yes, what I had in mind from my outsiders POV was the following, and I
> > have no 
 clue whether it is feasible at all:
> > 
> > We have the following structure:
> > 
> > $path1/lib/foo.h
> > template Foo : QObject { ...};
> > 
> > moc is not doing anything here as the templated QObject is not fully 
> > specialized.
> > 
> > $path2/app/bar.h:
> > #include 
> > using Bar = Foo;
> 
> 
> That would break if any other code in the application (possibly in a
> different library linked to it) has e.g.
 using Blah = Foo;
> right?
> That sounds pretty fragile. Especially if an application loads plugins.

Can you clarify what would break here? Isn't it exactly the same as doing 
QVector in multiple TUs?

Thanks
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Ziller Eike]

> On Feb 29, 2016, at 1:21 PM, Milian Wolff  wrote:
> 
> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
>> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
 The main problems of templated QObject are captured more or less in
 this
 
 thread:
 http://lists.qt-project.org/pipermail/development/2013-March/010288.html
 
 Personally I still think it would be a fancy feature, a bit dangerous
 to
 
 implement maybe even dangerous to use, but really cool :-D
>>> 
>>> Thanks for the link. How often is the MOC layout changed in an ABI
>>> incompatible way?
>> 
>> There's no historical pattern. There was a major break from Qt 3 to 4 and
>> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI;
>> the Qt 5.0 update removed the ability to read meta objects created with Qt
>> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
>> used register-on-load meta objects).
>> 
>> But since the meta object itself has a version number and the only code that
>> ever reads the internal data is inside QtCore, so we could make changes
>> that change the layout.  We haven't done that: all changes between major
>> releases have added things without changing the layout.
>> 
>> That's the structure layout though. The file itself compares the
>> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
> 
> OK, but changing the layout between major versions is fine as we break ABI 
> anyways then, no?
> 
>>> I.e. what problems would we get from having to install the
>>> moc files?
>> 
>> Lots.
> 
> 
> 
>> Have I convinced you? I'm only getting warmed up. I'm sure I can find more
>> issues.
> 
> Thanks for the exhaustive, and educative list! I think this should be put on 
> the Wiki somewhere for future reference.
> 
>>> Alternatively: couldn't moc re-create the required data from included
>>> files
>>> when they contain templated objects? That would solve the problem as well,
>>> no?
>> 
>> I have no idea what you meant here.
>> 
>> Or, well, I do have one, but I don't think that I understood correctly what
>> you're suggesting. I understood that we keep a copy of the header file's
>> source in the target application and run moc at runtime to dynamically
>> create the meta object, on the fly.
>> 
>> Since I don't think that's what you're suggesting and since the above has so
>> many problems (starting with the fact that it doesn't resolve the problem),
>> I'm not even going to analyse it.
>> 
>> Can you clarify what you meant?
> 
> Yes, what I had in mind from my outsiders POV was the following, and I have 
> no 
> clue whether it is feasible at all:
> 
> We have the following structure:
> 
> $path1/lib/foo.h
> template Foo : QObject { ...};
> 
> moc is not doing anything here as the templated QObject is not fully 
> specialized.
> 
> $path2/app/bar.h:
> #include 
> using Bar = Foo;

That would break if any other code in the application (possibly in a different 
library linked to it) has e.g.
using Blah = Foo;
right?
That sounds pretty fragile. Especially if an application loads plugins.

Br, Eike

> Now when we compile app, moc runs over the fully specialized templated 
> QObject 
> and can instantiate it as needed and put all the required code into the 
> moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to 
> install the templated QObject's moc file. This also is close to how an 
> ordinary template is handled by a C++ compiler as far as I know.
> 
> Maybe I'm missing something, but this sounds like an elegant solution? The 
> only downside is increased complexity in moc to find such instantiations. 
> Until clang can be used for moc, we could add a macro, lets say 
> Q_INSTANTIATE(Foo), or similar.
> 
> What do you say? What am I missing that would break my assumptions?
> -- 
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On terça-feira, 1 de março de 2016 17:39:28 PST Mathias Hasselmann wrote:
> Am 29.02.2016 um 17:40 schrieb Thiago Macieira:
> > On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote:
> >> What do you say? What am I missing that would break my assumptions?
> > 
> > This is what Olivier proposed too.
> > 
> > Like I said, I don't like it, but it works.
> 
> Well, and it's proposed as temporary solution until we got a clang based
> moc. Such solutions don't have to be perfect. Well yes, and I know what
> they say about temporary solutions (and how they become a permanent
> solution).

If Olivier is willing to modify current moc (non-ng) to support explicit 
template instantiation, go for it.

Another possibility is to provide a separate moc-ng that accomplishes that 
goal and writes meta objects.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Mathias Hasselmann]

Am 29.02.2016 um 17:40 schrieb Thiago Macieira:

On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote:

What do you say? What am I missing that would break my assumptions?


This is what Olivier proposed too.

Like I said, I don't like it, but it works.

Well, and it's proposed as temporary solution until we got a clang based 
moc. Such solutions don't have to be perfect. Well yes, and I know what 
they say about temporary solutions (and how they become a permanent 
solution).


Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Mathias Hasselmann]

Am 25.02.2016 um 19:22 schrieb Milian Wolff:


Can you explain what those reasons are? I'd really love to write a generic
QAbstractTableModel implementation that operates using concepts. Currently
that would require type erasure and thus another set of virtual function
calls...

I.e. in many projects I end up writing the same boiler plate code to display a
QVector in a view. As far as I can see most of that could be
abstracted away easily, leaving only slim concepts to the struct:

struct MyRowType {
QString foo;
int bar;
QVariant data(int column, int role) const
{
 if (!role == Qt::DisplayRole) return {}
 switch (column) {
   case 1: return foo;
   case 2: return bar;
 }
 return {};
}
};


Yes, please! Writing the almost same list model over and over again is 
boring. Although MyRowType::data() should not be a member, but a 
free-standing function to allow any type to be used as row data type.



If we'd have templates QObjects, the above could easily be written. I bet
there are other valid use-cases.


QFutureWatcher comes to mind. Regularly using its pattern in projects 
and would prefer I could avoid this boilerplate.


Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote:
> What do you say? What am I missing that would break my assumptions?

This is what Olivier proposed too.

Like I said, I don't like it, but it works.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On segunda-feira, 29 de fevereiro de 2016 10:09:51 PST Jędrzej Nowacki wrote:
> On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote:
> > > I.e. what problems would we get from having to install the
> > > moc files?
> > 
> > Lots.
> 
> And probably all go away if instead of installing anything we use
> QMetaObjectBuilder (assuming it's api stabilization). Yes it would have
> performance impact, but only on the templated version and only during
> initialization, qml is paying that price constantly without bigger
> complains. It would not require any build system changes. The only
> limitation I can think of right now is that in QObject, Foo needs to
> be know to QMetaType system, which is not a big deal.

What source data do you propose for QMOB?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
> > >  The main problems of templated QObject are captured more or less in
> > >  this
> > > 
> > > thread:
> > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html
> > > 
> > >  Personally I still think it would be a fancy feature, a bit dangerous
> > >  to
> > > 
> > > implement maybe even dangerous to use, but really cool :-D
> > 
> > Thanks for the link. How often is the MOC layout changed in an ABI
> > incompatible way?
> 
> There's no historical pattern. There was a major break from Qt 3 to 4 and
> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI;
> the Qt 5.0 update removed the ability to read meta objects created with Qt
> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
> used register-on-load meta objects).
>
> But since the meta object itself has a version number and the only code that
> ever reads the internal data is inside QtCore, so we could make changes
> that change the layout.  We haven't done that: all changes between major
> releases have added things without changing the layout.
> 
> That's the structure layout though. The file itself compares the
> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).

OK, but changing the layout between major versions is fine as we break ABI 
anyways then, no?
 
> > I.e. what problems would we get from having to install the
> > moc files?
> 
> Lots.



> Have I convinced you? I'm only getting warmed up. I'm sure I can find more
> issues.

Thanks for the exhaustive, and educative list! I think this should be put on 
the Wiki somewhere for future reference.
 
> > Alternatively: couldn't moc re-create the required data from included
> > files
> > when they contain templated objects? That would solve the problem as well,
> > no?
> 
> I have no idea what you meant here.
> 
> Or, well, I do have one, but I don't think that I understood correctly what
> you're suggesting. I understood that we keep a copy of the header file's
> source in the target application and run moc at runtime to dynamically
> create the meta object, on the fly.
> 
> Since I don't think that's what you're suggesting and since the above has so
> many problems (starting with the fact that it doesn't resolve the problem),
> I'm not even going to analyse it.
> 
> Can you clarify what you meant?

Yes, what I had in mind from my outsiders POV was the following, and I have no 
clue whether it is feasible at all:

We have the following structure:

$path1/lib/foo.h
template Foo : QObject { ...};

moc is not doing anything here as the templated QObject is not fully 
specialized.

$path2/app/bar.h:
#include 
using Bar = Foo;

Now when we compile app, moc runs over the fully specialized templated QObject 
and can instantiate it as needed and put all the required code into the 
moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to 
install the templated QObject's moc file. This also is close to how an 
ordinary template is handled by a C++ compiler as far as I know.

Maybe I'm missing something, but this sounds like an elegant solution? The 
only downside is increased complexity in moc to find such instantiations. 
Until clang can be used for moc, we could add a macro, lets say 
Q_INSTANTIATE(Foo), or similar.

What do you say? What am I missing that would break my assumptions?
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Monday 29 of February 2016 11:11:28 Иван Комиссаров wrote:
> 2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki  > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > 
> > The thought evolved over last months and now I think that QAIM should not
> > be
> > QObject at all, it is just an unnecessary cost.
> 
> Hm... Really? http://doc.qt.io/qt-5/qabstractitemmodel.html#signals AFAIK,
> Q_GADGET doesn't support signals

I was not explicit enough, I do not think QAIM, in the current state, is a 
very good API. I was thinking about new API with a similar functionality.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote:
> > I.e. what problems would we get from having to install the
> > moc files?
> 
> Lots.

And probably all go away if instead of installing anything we use 
QMetaObjectBuilder (assuming it's api stabilization). Yes it would have 
performance impact, but only on the templated version and only during 
initialization, qml is paying that price constantly without bigger complains. 
It would not require any build system changes. The only limitation I can think 
of right now is that in QObject, Foo needs to be know to QMetaType 
system, which is not a big deal.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Bo Thorsen]

Den 27-02-2016 kl. 20:07 skrev Thiago Macieira:

On sábado, 27 de fevereiro de 2016 12:56:11 PST Olivier Goffart wrote:

First of all, note that you're asking that

  a) installing generated code
  b) including such generated code from your public headers


Not necessarily installed:
  - The feature might be used only for application code or implementation
without having the need of installing them.
  - The build system can be adapted such that moc is run on headers
containing  object template from a library, and put these generated code in
the build directory.


Ok, this is an interesting solution. I don't like it, but it's workable.

If you want to use template QObjects, you need to tell your buildsystem where
the header files declaring such a QObject are (/usr/include/...) and which
template expansion of it you want. Each one. Then moc gets run for creating
the meta object for those classes, which will need to be Q_DECL_EXPORT'ed from
your module.


Well, you could give the include path to moc and let it search? If the 
compiler can find the proper file, moc can too.


In qmake it would be possible to add something like

EXTERNAL_TEMPLATE_HEADERS += foobar.h

And magic stuff happens...

It sounds like this is something that would require qmake, moc and qdoc 
support, not just moc-ng.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Иван Комиссаров]

2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki :

> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
>
> The thought evolved over last months and now I think that QAIM should not
> be
> QObject at all, it is just an unnecessary cost.
>
>
Hm... Really? http://doc.qt.io/qt-5/qabstractitemmodel.html#signals AFAIK,
Q_GADGET doesn't support signals
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On sábado, 27 de fevereiro de 2016 12:56:11 PST Olivier Goffart wrote:
> > First of all, note that you're asking that
> >
> >  a) installing generated code
> >  b) including such generated code from your public headers
> 
> Not necessarily installed:
>  - The feature might be used only for application code or implementation 
> without having the need of installing them.
>  - The build system can be adapted such that moc is run on headers
> containing  object template from a library, and put these generated code in
> the build directory.

Ok, this is an interesting solution. I don't like it, but it's workable.

If you want to use template QObjects, you need to tell your buildsystem where 
the header files declaring such a QObject are (/usr/include/...) and which 
template expansion of it you want. Each one. Then moc gets run for creating 
the meta object for those classes, which will need to be Q_DECL_EXPORT'ed from 
your module.

If we do this, I recommend moc-ng, so that it can actually understand the 
templates and calculate the proper expansions for the reflection.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Olivier Goffart]

Am Freitag, 26. Februar 2016, 15:56:08 CET schrieb Thiago Macieira:
> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
> > >  The main problems of templated QObject are captured more or less in
> > >  this
> > > 
> > > thread:
> > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html
> > > 
> > >  Personally I still think it would be a fancy feature, a bit dangerous
> > >  to
> > > 
> > > implement maybe even dangerous to use, but really cool :-D
> > 
> > Thanks for the link. How often is the MOC layout changed in an ABI
> > incompatible way?
> 
> There's no historical pattern. There was a major break from Qt 3 to 4 and
> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI;
> the Qt 5.0 update removed the ability to read meta objects created with Qt
> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
> used register-on-load meta objects).
> 
> But since the meta object itself has a version number and the only code that
> ever reads the internal data is inside QtCore, so we could make changes
> that change the layout.  We haven't done that: all changes between major
> releases have added things without changing the layout.
> 
> That's the structure layout though. The file itself compares the
> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).

Indeed, the Q_MOC_OUTPUT_REVISION could not change without breaking the 
installed moc files, if they get installed.

> > I.e. what problems would we get from having to install the
> > moc files?
> 
> Lots.
> 
> First of all, note that you're asking that
>  a) installing generated code
>  b) including such generated code from your public headers

Not necessarily installed:
 - The feature might be used only for application code or implementation 
without having the need of installing them.
 - The build system can be adapted such that moc is run on headers containing 
object template from a library, and put these generated code in the build 
directory.

> That means the headers do not compile until moc has generated its output.
> Moc is currently able to ignore missing includes and we need that when
> parsing .cpp files that contain Q_OBJECT. But doing that in headers is
> just... ick.

I don't see why this is an issue at all.
As you said we already sometimes include the moc code from the .cpp in some 
cases.

 > There's also the fact that now the generated code becomes part of your
> public ABI and will be compiled by your users. That means the code from moc
> needs to compile with their compiler settings, whichever that may be. And
> we would need to be very careful in how we change moc, because we need to
> keep users' compatibility requirements when they upgrade Qt. Their
> requirements could be stricter than Qt's (to a point).

No changes from now.
The generated code is already stricter than Qt headers themself. (we guard 
against more warnings). And since they include Qt header they already would 
have the problem with Qt headers. Also they would already have the problem 
with the moc generated files in their own application too.

> If we talk simply about non-templated QObjects, there are only drawbacks.
> The first is that the current output produces functions and data which
> would end up in *each* and *every* translation unit that included the
> output. You'd get linker errors. We could fix this by marking all the
> functions as inline, but we can't fix the data.
>
> This includes the most important data member of all: const QMetaObject *
> ClassName::staticMetaObject. It's a class-level static, so it needs to be
> defined in a single .cpp and nowhere else. Period, no fix possible.

Why would we even have to install the moc generated files for non templated 
QObject?

We can split the moc generated files in two: one with the data that is not 
installed, and one with the functions that is included by every user of the 
templated object.  =>  fix possible

> So the discussion ends here for non-template classes, at least without
> breaking Qt API.
> 
> If we were willing to break Qt API, we could remove the staticMetaObject
> class member and make it static inside a member static inline function.
> Static data inside inline functions need to be merged by the linker and the
> dynamic linker.

[This would be good step to allow unnamed class or local classes to be 
Q_OBJECT/Q_GADGET since such class cannot have static data member. But this is 
incompatible with moc anyway.  And has nothing to do with the discussion at 
hand]
This is not relevant for templated QObject so i'll skip the next paragraphes.

> [...]

 
> And then there are templates.
> 
> If we talk about template classes, then we have more problems. First, note
> the bloating and runtime-deduplication problem I mentioned above. They'd
> apply here. Though note that you can declare static data of template
> classes in headers, so we wouldn't need to break the Qt API just for this.

This bloat is a classig probl

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On sábado, 27 de fevereiro de 2016 09:48:36 PST Marc Mutz wrote:
> On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote:
> > Have I convinced you? I'm only getting warmed up. I'm sure I can find more
> > issues.
> 
> That's all correct. But can't we create a subset of features that the
> QObject template may use in order to make that subset work? 

I don't think so. The thing with currently no solution is the ability to add 
mix templates and signals (signals in template class or template signals). 
Without signals, it all breaks down.

> As for the staticMetaObject, moc could  write its output not as C++ code,
> but as a macro containing the C++ code, for QObject templates, to be called
> with those QObject template instantiations that the user creates (similar
> to the old method of template instantiation where the user needs to list
> the explicit template instantiation in a separately-compiled TU). Only one
> TU would contain the macro call for any given instantiation, solving the
> multiple-definition problem you mentioned.

This would be severely limited, but doable. It would only work for a small, 
hand-crafted list of template parameters and only if the template parameters 
were used in very trivial uses, like these:

>   template 
>   class ListModel : QAbstractListModel {
>   Q_OBJECT_TEMPLATE(T)
>   public:
>   // ...

adding:
Q_PROPERTY(T value READ value WRITE setValue)
signals:
void changed(const T &);
public slots:
void change(const T &t);
>   };
> 
>   // in some other TU

But you can't do anything non-trivial with T, like use it in remove_cv.

If we were to do this, I'd also require the list of explicit instantiations to 
be in the header file. This serves two purposes:

 a) it makes it clear to the user that only those instantiations are 
permitted, and to the compiler that it should not instantiate on its own

 b) it allows moc to know which instantiations to create a meta object for, 
dispensing with the need for a macro. By doing this, moc-ng could even 
deal with complex uses of the template parameters. 

There's no solution for template members, though.

Is it worth it? How often are templates used with only a very small list of 
explicit instantiations?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Marc Mutz]

On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote:
> Have I convinced you? I'm only getting warmed up. I'm sure I can find more 
> issues.

That's all correct. But can't we create a subset of features that the QObject 
template may use in order to make that subset work? After all, function 
templates as slots don't work in classical QObject, either, so we don't lose 
anything by banning them in QObject templates, either.

As for the staticMetaObject, moc could  write its output not as C++ code, but 
as a macro containing the C++ code, for QObject templates, to be called with 
those QObject template instantiations that the user creates (similar to the 
old method of template instantiation where the user needs to list the explicit 
template instantiation in a separately-compiled TU). Only one TU would contain 
the macro call for any given instantiation, solving the multiple-definition 
problem you mentioned.

  template 
  class ListModel : QAbstractListModel {
  Q_OBJECT_TEMPLATE(T)
  public:
  // ...
  };

  // in some other TU

  #include "listmodel.moc"
  Q_MOC_INSTANTIATE(ListModel, MyStruct)
 // resolves to something like
 // Q_MOC_INSTANTIATE_ListModel(MyStruct, #MyStruct)

  void Foo::Bar() {
  auto *model = new ListModel(this);
  // use 'model'
  }
  ... other code ...

Partly, this can already be emulated by just not including the Q_OBJECT macro 
in the QObject template and then deriving non-template QObjects from it that 
do contain the Q_OBJECT macro, hiding the actual subclass from moc with 
Q_MOC_RUN. This would just move the boilerplate code into moc's hands, where 
it belongs.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Thiago Macieira]

On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
> >  The main problems of templated QObject are captured more or less in this
> > 
> > thread:
> > http://lists.qt-project.org/pipermail/development/2013-March/010288.html
> > 
> >  Personally I still think it would be a fancy feature, a bit dangerous to
> > 
> > implement maybe even dangerous to use, but really cool :-D
> 
> Thanks for the link. How often is the MOC layout changed in an ABI
> incompatible way?

There's no historical pattern. There was a major break from Qt 3 to 4 and 
smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI; the 
Qt 5.0 update removed the ability to read meta objects created with Qt 4 moc. 
I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still used 
register-on-load meta objects).

But since the meta object itself has a version number and the only code that 
ever reads the internal data is inside QtCore, so we could make changes that 
change the layout.  We haven't done that: all changes between major releases 
have added things without changing the layout.

That's the structure layout though. The file itself compares the 
Q_MOC_OUTPUT_REVISION macro for equality (not ordering).

> I.e. what problems would we get from having to install the
> moc files?

Lots.

First of all, note that you're asking that
 a) installing generated code
 b) including such generated code from your public headers

That means the headers do not compile until moc has generated its output. Moc 
is currently able to ignore missing includes and we need that when parsing 
.cpp files that contain Q_OBJECT. But doing that in headers is just... ick.

There's also the fact that now the generated code becomes part of your public 
ABI and will be compiled by your users. That means the code from moc needs to 
compile with their compiler settings, whichever that may be. And we would need 
to be very careful in how we change moc, because we need to keep users' 
compatibility requirements when they upgrade Qt. Their requirements could be 
stricter than Qt's (to a point).

If we talk simply about non-templated QObjects, there are only drawbacks. The 
first is that the current output produces functions and data which would end up 
in *each* and *every* translation unit that included the output. You'd get 
linker errors. We could fix this by marking all the functions as inline, but we 
can't fix the data.

This includes the most important data member of all: const QMetaObject * 
ClassName::staticMetaObject. It's a class-level static, so it needs to be 
defined in a single .cpp and nowhere else. Period, no fix possible.

So the discussion ends here for non-template classes, at least without 
breaking Qt API.

If we were willing to break Qt API, we could remove the staticMetaObject class 
member and make it static inside a member static inline function. Static data 
inside inline functions need to be merged by the linker and the dynamic 
linker.

This however produces data bloat and reduces performance. For one thing, 
instead of getting the address of the meta object directly, you need to call a 
function that will return the address. For another, since we created work for 
the dynamic linker, now it needs to resolve a named relocation in places it 
didn't before. And there's still the fact that the meta object is present in 
every shared object / DLL that it got used from, even if at runtime only one 
copy is ever used.

And then there are the problems of dynamic linkers actually merging static 
data inside inline functions at runtime. This is an area where several ABIs 
fall short and that's assuming that they even try. I have one word for you 
here: dynamic_cast.

And then there are templates.

If we talk about template classes, then we have more problems. First, note the 
bloating and runtime-deduplication problem I mentioned above. They'd apply 
here. Though note that you can declare static data of template classes in 
headers, so we wouldn't need to break the Qt API just for this.

The next problem is the meta object layout. Currently, it's optimised to 
contain static strings (an array of QByteArrayLiteral data in Qt 5, one long 
const char array in Qt 4, which I'll bring back for Qt 6). Obviously, the name 
of the instantiated class isn't constant, so the data can't be constant 
either. It stands to reason that the use of a templated class in the first 
place is the ability to use the template parameters in reflected members 
(signals, slots, invocables, properties, enums, classinfo), so the types and 
signatures for those members would need to change.

Then we go back to whether we can keep the current Qt API: if the data isn't 
constant, can we even return const char* from the QMetaObject member functions 
like we do? If we're going to calculate the strings at runtime, are we even 
able to? What happens for:

signal:
void somethingHappened(
typename 
std::ena

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Freitag, 26. Februar 2016 09:43:40 CET Jędrzej Nowacki wrote:
> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam 
wrote:
> > > > This might be a burden for some of the Qt developers (Windows ones).
> > > > 
> > > > But all the Qt users get a modern / flexible moc, see this thread:
> > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09
> > > > c9
> > > > 0e
> > > 
> > > I don't think we need a more flexible moc. What do we want to do that we
> > > can't do with the current one?
> > > 
> > > Don't say "template QObjects". That has other reasons for being a bad
> > > idea,
> > > currently.
> > 
> > Can you explain what those reasons are? I'd really love to write a generic
> > QAbstractTableModel implementation that operates using concepts. Currently
> > that would require type erasure and thus another set of virtual function
> > calls...
> > 
> > I.e. in many projects I end up writing the same boiler plate code to
> > display a QVector in a view. As far as I can see most of that
> > could be abstracted away easily, leaving only slim concepts to the
> > struct:
> > 
> > struct MyRowType {
> > QString foo;
> > int bar;
> > QVariant data(int column, int role) const
> > {
> > 
> > if (!role == Qt::DisplayRole) return {}
> > switch (column) {
> > 
> >   case 1: return foo;
> >   case 2: return bar;
> > 
> > }
> > return {};
> > 
> > }
> > };
> > 
> > this could easily be extended to other methods, such as setData,
> > headerData, etc. pp. In the end, one would only need to implement a
> > trivial minimal API at the place where the data is actually stored. And
> > no, I do _not_ consider the current QAIM interface trivial to implement,
> > not even for "simple" lists!
> > 
> > If we'd have templates QObjects, the above could easily be written. I bet
> > there are other valid use-cases.
> > 
> > Cheers
> 
> Hi,
> 
>  When first time I heard about templated QObject, QAIM was my first thought
> :-) The thought evolved over last months and now I think that QAIM should
> not be QObject at all, it is just an unnecessary cost.

Can you explain how you imagine the code to look like for the model to notify 
the view about changes? Curtis' note on QML requiring introspection for models 
is also very valid.

>  The main problems of templated QObject are captured more or less in this
> thread:
> http://lists.qt-project.org/pipermail/development/2013-March/010288.html
> 
>  Personally I still think it would be a fancy feature, a bit dangerous to
> implement maybe even dangerous to use, but really cool :-D

Thanks for the link. How often is the MOC layout changed in an ABI 
incompatible way? I.e. what problems would we get from having to install the 
moc files?

Alternatively: couldn't moc re-create the required data from included files 
when they contain templated objects? That would solve the problem as well, no?

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Curtis Mitch]

> -Original Message-
> From: Development [mailto:development-
> bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Jedrzej
> Nowacki
> Sent: Friday, 26 February 2016 9:44 AM
> To: development@qt-project.org
> Cc: Thiago Macieira ; Milian Wolff
> 
> Subject: Re: [Development] templated QObjects [was: Re: We are planning to
> upgrade qdoc to use clang for parsing C++]
> 
> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam
> wrote:
> > > > This might be a burden for some of the Qt developers (Windows ones).
> > > >
> > > > But all the Qt users get a modern / flexible moc, see this thread:
> > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked
> > > > /d09c9
> > > > 0e
> > >
> > > I don't think we need a more flexible moc. What do we want to do
> > > that we can't do with the current one?
> > >
> > > Don't say "template QObjects". That has other reasons for being a
> > > bad idea, currently.
> >
> > Can you explain what those reasons are? I'd really love to write a
> > generic QAbstractTableModel implementation that operates using
> > concepts. Currently that would require type erasure and thus another
> > set of virtual function calls...
> >
> > I.e. in many projects I end up writing the same boiler plate code to
> > display a QVector in a view. As far as I can see most of
> > that could be abstracted away easily, leaving only slim concepts to the
> struct:
> >
> > struct MyRowType {
> > QString foo;
> > int bar;
> > QVariant data(int column, int role) const {
> > if (!role == Qt::DisplayRole) return {}
> > switch (column) {
> >   case 1: return foo;
> >   case 2: return bar;
> > }
> > return {};
> > }
> > };
> >
> > this could easily be extended to other methods, such as setData,
> > headerData, etc. pp. In the end, one would only need to implement a
> > trivial minimal API at the place where the data is actually stored.
> > And no, I do _not_ consider the current QAIM interface trivial to
> implement, not even for "simple"
> > lists!
> >
> > If we'd have templates QObjects, the above could easily be written. I
> > bet there are other valid use-cases.
> >
> > Cheers
> 
> Hi,
> 
>  When first time I heard about templated QObject, QAIM was my first
> thought :-) The thought evolved over last months and now I think that QAIM
> should not be QObject at all, it is just an unnecessary cost.

What about using C++ models in QML? QAbstractItemModel has to be a QObject for 
that reason alone. Often you also want to control the contents of the model by 
some UI-driven property in QML (e.g. a filter for a list of contacts based on a 
text input field).

>  The main problems of templated QObject are captured more or less in this
> thread: http://lists.qt-project.org/pipermail/development/2013-
> March/010288.html
> 
>  Personally I still think it would be a fancy feature, a bit dangerous to
> implement maybe even dangerous to use, but really cool :-D
> 
> Cheers,
>  Jędrek
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote:
> > > This might be a burden for some of the Qt developers (Windows ones).
> > > 
> > > But all the Qt users get a modern / flexible moc, see this thread:
> > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c9
> > > 0e
> > 
> > I don't think we need a more flexible moc. What do we want to do that we
> > can't do with the current one?
> > 
> > Don't say "template QObjects". That has other reasons for being a bad
> > idea,
> > currently.
> 
> Can you explain what those reasons are? I'd really love to write a generic
> QAbstractTableModel implementation that operates using concepts. Currently
> that would require type erasure and thus another set of virtual function
> calls...
> 
> I.e. in many projects I end up writing the same boiler plate code to display
> a QVector in a view. As far as I can see most of that could be
> abstracted away easily, leaving only slim concepts to the struct:
> 
> struct MyRowType {
> QString foo;
> int bar;
> QVariant data(int column, int role) const
> {
> if (!role == Qt::DisplayRole) return {}
> switch (column) {
>   case 1: return foo;
>   case 2: return bar;
> }
> return {};
> }
> };
> 
> this could easily be extended to other methods, such as setData, headerData,
> etc. pp. In the end, one would only need to implement a trivial minimal API
> at the place where the data is actually stored. And no, I do _not_ consider
> the current QAIM interface trivial to implement, not even for "simple"
> lists!
> 
> If we'd have templates QObjects, the above could easily be written. I bet
> there are other valid use-cases.
> 
> Cheers

Hi,

 When first time I heard about templated QObject, QAIM was my first thought :-) 
The thought evolved over last months and now I think that QAIM should not be 
QObject at all, it is just an unnecessary cost. 

 The main problems of templated QObject are captured more or less in this 
thread: http://lists.qt-project.org/pipermail/development/2013-March/010288.html

 Personally I still think it would be a fancy feature, a bit dangerous to 
implement maybe even dangerous to use, but really cool :-D

Cheers,
 Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote:
> > This might be a burden for some of the Qt developers (Windows ones).
> > 
> > But all the Qt users get a modern / flexible moc, see this thread:
> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e
> 
> I don't think we need a more flexible moc. What do we want to do that we
> can't do with the current one?
> 
> Don't say "template QObjects". That has other reasons for being a bad idea,
> currently.

Can you explain what those reasons are? I'd really love to write a generic 
QAbstractTableModel implementation that operates using concepts. Currently 
that would require type erasure and thus another set of virtual function 
calls...

I.e. in many projects I end up writing the same boiler plate code to display a 
QVector in a view. As far as I can see most of that could be 
abstracted away easily, leaving only slim concepts to the struct:

struct MyRowType {
QString foo;
int bar;
QVariant data(int column, int role) const
{
if (!role == Qt::DisplayRole) return {}
switch (column) {
  case 1: return foo;
  case 2: return bar;
}
return {};
}
};

this could easily be extended to other methods, such as setData, headerData, 
etc. pp. In the end, one would only need to implement a trivial minimal API at 
the place where the data is actually stored. And no, I do _not_ consider the 
current QAIM interface trivial to implement, not even for "simple" lists!

If we'd have templates QObjects, the above could easily be written. I bet 
there are other valid use-cases.

Cheers
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development