| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 5 | |
Justin: The problems with VC++.NET, explained previously in this mailing list. Basically, my understanding is that VC++.NET has some significant problems with C++. ---------- Forwarded Message ---------- Subject: Re: Visual C++ 7.0 Date: Tue, 12 Feb 2002 11:07:11 +0100 From: "Volker Hilsheimer" <vohi@trolltech.com> To: <qt-interest@trolltech.com> Cc: <kfisk@linkpoint.com>, <christ@axionspatial.com>, <vv@iware.com>, "Paul Curtis" <plc@rowley.co.uk> Ah, after all it looks like there is something like a community on Windows, too ;-) Attached are two zipped C++-only projects, each building a small DLL, and an executable linking against that DLL: - inlinetemplate.zip demonstrates the compiler bug. There is a #define COMPILERBUG in the reftemplate.h header; if you remove the line it will actually be the workaround I applied against Qt to at least be able to compile. This workaround will be in Qt 3.0.2, but I would rather like to remove it again. - reftemplate.zip demonstrates the linker bug (which is probably a compiler bug). This is more or less identical to inlinetemplate, just the line causing the compiler bug has been removed. Now you end up with the linker bug, but unfortunately no #define LINKBUG, so I've not found a workaround for that one. Both archives come with a build.bat file that you can run from the command line (e.g. the Visual Studio .Net Command Prompt, which is an item in the start menu after installing that beast). This will build first the DLL and then the executable, redirecting the output of cl and link into a build.log file. Natrually, both projects compile and link and run without problems when using Visual C++ 6.0. The DLL itself resembles what we do in Qt's reference based collection template classes (implementing generic algorithms in non-template baseclasses working on void*, with the templates providing a typed interface to the algorithms). The VS.NET I tried was the one made public to MSDN subscriptors a couple of weeks ago. I have not checked whether there are any later versions, but this should be checked by Visual Studio.NET on it's own, after all. Thanks to everybody participating! -- [ signature omitted ]
Attachment:
inlinetemplate.zip
Description: Zip compressed data
Attachment:
reftemplate.zip
Description: Zip compressed data
Hi Justin and Soeren,
Soeren and I have been having a discussion about the cure. Attached is my
cure. Removing any of the changes will show you a problem when you compile
under either VS6 or VS7.
We were able to compile Volker's project (and confirm that the dll was being
used) on both
VS6 and VS7 by making three changes: two to the reftemplate.h file, and
adding another cpp file to the project.. All three are necessary. The
changes are marked in the two files with // Change #" 1, 2, and 3 comments.
The main.cpp has been changed to show another difficulty you can get into if
all three changes are not done.
(1) In reftemplate.h remove the import statement for the template.
// Change # 1
template<class type>class /*RTEXPORT*/ RefTemplate : public GRefTemplate
(2) in the same file, add "extern" to force main to use the dll
instantation.
// Change # 2
#if !defined(REFDLL)
extern
#endif
template class RTEXPORT RefTemplate<double>;
(3) To force the compiler to "see" this definition, add an empty cpp file
that contains only the statement:
// Change #3
#include "reftemplate.h"
----- Original Message -----
From: "Christopher Thompson" <christ@axionspatial.com>
To: "Justin Georgeson" <jgeorgeson@unboundtech.com>
Cc: <qt-interest@trolltech.com>
Sent: Tuesday, March 12, 2002 1:18 PM
Subject: Fwd: Re: Visual C++ 7.0
> Justin:
>
> The problems with VC++.NET, explained previously in this mailing list.
Basically, my understanding is
> that VC++.NET has some significant problems with C++.
>
> ---------- Forwarded Message ----------
>
> Subject: Re: Visual C++ 7.0
> Date: Tue, 12 Feb 2002 11:07:11 +0100
> From: "Volker Hilsheimer" <vohi@trolltech.com>
> To: <qt-interest@trolltech.com>
> Cc: <kfisk@linkpoint.com>, <christ@axionspatial.com>, <vv@iware.com>,
"Paul Curtis" <plc@rowley.co.uk>
>
> Ah, after all it looks like there is something like a community on
> Windows, too ;-)
>
> Attached are two zipped C++-only projects, each building a small DLL,
> and an executable linking against that DLL:
>
> - inlinetemplate.zip demonstrates the compiler bug. There is a #define
> COMPILERBUG in the reftemplate.h header; if you remove the line it will
> actually be the workaround I applied against Qt to at least be able to
> compile. This workaround will be in Qt 3.0.2, but I would rather like to
> remove it again.
>
> - reftemplate.zip demonstrates the linker bug (which is probably a
> compiler bug). This is more or less identical to inlinetemplate, just
> the line causing the compiler bug has been removed. Now you end up with
> the linker bug, but unfortunately no #define LINKBUG, so I've not found
> a workaround for that one.
>
> Both archives come with a build.bat file that you can run from the
> command line (e.g. the Visual Studio .Net Command Prompt, which is an
> item in the start menu after installing that beast). This will build
> first the DLL and then the executable, redirecting the output of cl and
> link into a build.log file.
>
> Natrually, both projects compile and link and run without problems when
> using Visual C++ 6.0. The DLL itself resembles what we do in Qt's
> reference based collection template classes (implementing generic
> algorithms in non-template baseclasses working on void*, with the
> templates providing a typed interface to the algorithms).
>
> The VS.NET I tried was the one made public to MSDN subscriptors a couple
> of weeks ago. I have not checked whether there are any later versions,
> but this should be checked by Visual Studio.NET on it's own, after all.
>
> Thanks to everybody participating!
>
> --
> Volker Hilsheimer, Trolltech AS, Oslo
>
> -------------------------------------------------------
>
>
>
Soory, did not attach the files!
Hi Justin and Soeren,
Soeren and I have been having a discussion about the cure. Attached is my
cure. Removing any of the changes will show you a problem when you compile
under either VS6 or VS7.
We were able to compile Volker's project (and confirm that the dll was being
used) on both
VS6 and VS7 by making three changes: two to the reftemplate.h file, and
adding another cpp file to the project.. All three are necessary. The
changes are marked in the two files with // Change #" 1, 2, and 3 comments.
The main.cpp has been changed to show another difficulty you can get into if
all three changes are not done.
(1) In reftemplate.h remove the import statement for the template.
// Change # 1
template<class type>class /*RTEXPORT*/ RefTemplate : public GRefTemplate
(2) in the same file, add "extern" to force main to use the dll
instantation.
// Change # 2
#if !defined(REFDLL)
extern
#endif
template class RTEXPORT RefTemplate<double>;
(3) To force the compiler to "see" this definition, add an empty cpp file
that contains only the statement:
// Change #3
#include "reftemplate.h"
----- Original Message -----
From: "Christopher Thompson" <christ@axionspatial.com>
To: "Justin Georgeson" <jgeorgeson@unboundtech.com>
Cc: <qt-interest@trolltech.com>
Sent: Tuesday, March 12, 2002 1:18 PM
Subject: Fwd: Re: Visual C++ 7.0
> Justin:
>
> The problems with VC++.NET, explained previously in this mailing list.
Basically, my understanding is
> that VC++.NET has some significant problems with C++.
>
> ---------- Forwarded Message ----------
>
> Subject: Re: Visual C++ 7.0
> Date: Tue, 12 Feb 2002 11:07:11 +0100
> From: "Volker Hilsheimer" <vohi@trolltech.com>
> To: <qt-interest@trolltech.com>
> Cc: <kfisk@linkpoint.com>, <christ@axionspatial.com>, <vv@iware.com>,
"Paul Curtis" <plc@rowley.co.uk>
>
> Ah, after all it looks like there is something like a community on
> Windows, too ;-)
>
> Attached are two zipped C++-only projects, each building a small DLL,
> and an executable linking against that DLL:
>
> - inlinetemplate.zip demonstrates the compiler bug. There is a #define
> COMPILERBUG in the reftemplate.h header; if you remove the line it will
> actually be the workaround I applied against Qt to at least be able to
> compile. This workaround will be in Qt 3.0.2, but I would rather like to
> remove it again.
>
> - reftemplate.zip demonstrates the linker bug (which is probably a
> compiler bug). This is more or less identical to inlinetemplate, just
> the line causing the compiler bug has been removed. Now you end up with
> the linker bug, but unfortunately no #define LINKBUG, so I've not found
> a workaround for that one.
>
> Both archives come with a build.bat file that you can run from the
> command line (e.g. the Visual Studio .Net Command Prompt, which is an
> item in the start menu after installing that beast). This will build
> first the DLL and then the executable, redirecting the output of cl and
> link into a build.log file.
>
> Natrually, both projects compile and link and run without problems when
> using Visual C++ 6.0. The DLL itself resembles what we do in Qt's
> reference based collection template classes (implementing generic
> algorithms in non-template baseclasses working on void*, with the
> templates providing a typed interface to the algorithms).
>
> The VS.NET I tried was the one made public to MSDN subscriptors a couple
> of weeks ago. I have not checked whether there are any later versions,
> but this should be checked by Visual Studio.NET on it's own, after all.
>
> Thanks to everybody participating!
>
> --
> Volker Hilsheimer, Trolltech AS, Oslo
>
> -------------------------------------------------------
>
>
>
Attachment:
repairedtemplate.ZIP
Description: Zip compressed data
> We were able to compile Volker's project (and confirm that the dll was being > used) on both > VS6 and VS7 by making three changes: two to the reftemplate.h file, and > adding another cpp file to the project.. All three are necessary. The > changes are marked in the two files with // Change #" 1, 2, and 3 comments. And while we both agree on step 1, so far I fail to see why steps 2 and 3 are necessary. Works perfectly without. What am I missing? Is this really relevant for Qt? Sure, "extern" tells the compiler to avoid inlining of code, but why would I want to suppress optimization? (Unless I don't trust the compiler's heuristics to determine when inlining is appropiate and when it is not -- but I do have that trust). Besides, is it really standard C++? I have only seen it in the context of standard extensions in gcc and msvc. > > The main.cpp has been changed to show another difficulty you can get into if > all three changes are not done. Which difficulty exactly? Really puzzled, Soeren
> > The main.cpp has been changed to show another difficulty you can get into if > > all three changes are not done. > > Which difficulty exactly? Try removing any of the changes I made. Watch the errors that appear in main for the ri<double>. I think that will make clearer why, on Visual C++, the extern is needed. You already know the template import/export statement is wrong, so do't worry about my change # 1. Remove either or both of the other two changes and do a complete rebuild each time. Have fun, Mark