[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-windows
Subject: Re: Template Macros in VS2003
From: Simon Hausmann <hausmann () kde ! org>
Date: 2007-01-21 20:41:06
Message-ID: 200701212141.11100.hausmann () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
On Sunday 21 January 2007 21:26, Jarosław Staniek wrote:
> On Sunday 21 January 2007 20:30, Stromek wrote:
> > On Thu, Jan 18, 2007 at 05:10:54PM -0800, Ryan Loebs wrote:
> > > Hello again!
> > >
> > > I decided to start fresh and did a clean SVN grab to make sure there
> > > weren't any parts I missed. One error that I got before and am still
> > > getting is with the plastik and keramik packages. The macro
> > > K_EXPORT_STYLE(name, type) produces this error in VS2003:
> > >
> > > plastik.cpp(60) : error C2947: expecting '>' to terminate
> > > template-argument-list, found '>>'
> > >
> > > Which, when I googled it, is fixed with a simple space in between a
> > > few arguments in most cases. It didn't work here though.... I can
> > > bypass the error by commenting out the line but then I assume the
> > > themes are never registered which probably causes some issues. If
> > > there's a way to fix this without having to upgrade to VS2005 I'd love
> > > to know how.
> >
> > Yep, there is a way. As you wrote, inserting a simple space :) However
> > it has to be inserted on the right place.
> >
> > First things first, it looks like this is a known compiler error which
> > according the following microsoft page won't be fixed in msvc7.
> >
> > http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feed
> >ba ckID=98665
> >
> > The real error is caused by expanding Q_EXPORT_PLUGIN with argument which
> > is of template type as defined in K_EXPORT_STYLE. One way is to make
> > typedef something like
> >
> > typedef KStyleFactory< KeramikStyle > KStyleFactory_KeramikStyle;
> > Q_EXPORT_PLUGIN( KStyleFactory_KeramikStyle )
> >
> > However, I don't know whether this can be automated by symbol definition
> > because something like #define foo( type ) typedef foo_type doesn't
> > expand type.
> >
> > The second way is to modify qplugin.h
> > (QTDIR\src\corelib\plugin\qplugin.h)
>
> Question to TT guys: could we have it fixed in Qt, and thus avoid patching?
>
> > --- qplugin.h 2007-01-21 19:47:19.000000000 +0100
> > +++ qplugin.orig.h 2007-01-21 20:09:31.000000000 +0100
> > @@ -54,7 +54,7 @@
> >
> > #define Q_PLUGIN_INSTANCE(IMPLEMENTATION) \
> > { \
> > - static QPointer< IMPLEMENTATION > _instance; \
> > + static QPointer<IMPLEMENTATION> _instance; \
> > if (!_instance) \
> > _instance = new IMPLEMENTATION; \
> > return _instance; \
Fortunately this is fixed already for Qt 4.3 where a QPointer<QObject> is used
instead, which makes it possible to use a full constructor expression for
IMPLEMENTATION. But of course that should also fix the problem you ran
into :)
Now I don't think we're going to backport that change to Qt 4.2.3, but I think
your suggestion of adding a space in front and after IMPLEMENTATION is safe
and a very nice solution to your problem. I'll see about getting that one
into the next patch release (4.2.3).
Simon
[Attachment #5 (application/pgp-signature)]
_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic