On Fri, May 29, 2020 at 9:52 AM Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:
> On Fri, May 29, 2020 at 06:30:07AM -0700, Adam Light wrote:
> >I will note, however, that #including the moc output from the .cpp
> >file (the "moc_myclass.cpp" form) is not compatible with my mocinclude
>
On Fri, May 29, 2020 at 06:30:07AM -0700, Adam Light wrote:
I will note, however, that #including the moc output from the .cpp
file (the "moc_myclass.cpp" form) is not compatible with my mocinclude
trick posted at https://bugreports.qt.io/browse/QTBUG-81348.
the report doesn't mention
[Resending to the entire list this time]
On Thu, May 28, 2020 at 3:12 PM Thiago Macieira
wrote:
> On Thursday, 28 May 2020 10:19:58 PDT Adam Light wrote:
> > I'm including generating moc files in "build time". I'm not saying that
> > compiling the .cpp files will take significantly longer, but
On Thursday, 28 May 2020 10:19:58 PDT Adam Light wrote:
> I'm including generating moc files in "build time". I'm not saying that
> compiling the .cpp files will take significantly longer, but if a .cpp file
> has a #include "myclass.moc" type statement, that .cpp file has to be
> processed by moc
On 5/28/20 8:21 PM, Matthew Woehlke wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh?*Why*?
A direct use case of this is to support having Q_OBJECT classes defined
in a .cpp file. That requires moc to parse foo.cpp file and
On 28/05/2020 13.19, Adam Light wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh? *Why*?
AFAIK that's just... wrong.
MOC needs to process files that do metaobject things (e.g. use
Q_OBJECT). Including a .moc in a .cpp does not
On Thu, May 28, 2020 at 9:55 AM Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:
> On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
> >> [include mocs]
> >>
> >Changing Qt in a way that would require #including the moc output from
> >the .cpp file might cause noticeable increase
On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
[include mocs]
Changing Qt in a way that would require #including the moc output from
the .cpp file might cause noticeable increase in build times unless moc
is also changed.
care to explain how _exactly_ that would be the case?
On Wed, May 27, 2020 at 8:51 AM Thiago Macieira
wrote:
> On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> > > this is not something we can subject our users to.
> >
> > orly? kde had been doing that for quite a while.
>
> And I fixed QtCore to do the same.
>
> The only reason
On Thursday, 28 May 2020 02:06:01 PDT Shawn Rutledge wrote:
> > On 2020 May 27, at 17:50, Thiago Macieira
> > wrote:>
> > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> >>> this is not something we can subject our users to.
> >>
> >> orly? kde had been doing that for quite a
this is not something we can subject our users to.
On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
>>> orly? kde had been doing that for quite a while.
On 2020 May 27, at 17:50, Thiago Macieira wrote:
>> And I fixed QtCore to do the same.
>>
>> The only reason not to
> On 2020 May 27, at 17:50, Thiago Macieira wrote:
>
> On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
>>> this is not something we can subject our users to.
>>
>> orly? kde had been doing that for quite a while.
>
> And I fixed QtCore to do the same.
>
> The only reason not
On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> > this is not something we can subject our users to.
>
> orly? kde had been doing that for quite a while.
And I fixed QtCore to do the same.
The only reason not to include the moc output in your .cpp is if you don't
have one (a
On Wed, May 27, 2020 at 08:21:48AM +, Fabian Kosmale wrote:
the only way to get this to work is to include the moc file in the
same cpp file. While doing this inside of Qt is possible,
this is not something we can subject our users to.
orly? kde had been doing that for quite a while.
The task:
Currently, when using QMetaMethod::parameterType, we end up doing a costly
string comparison.
In order to get rid of the property cache in QML, we need faster way to obtain
the metatype of
method parameters and return types. This also has some benefits outside of QML,
as it should
15 matches
Mail list logo
