Home > Archive > VC STL > March 2006 > Re: Visual Studio.NET 2003 building woes .... :S
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Visual Studio.NET 2003 building woes .... :S
|
|
| KevinGPO 2006-03-07, 7:58 am |
| I found out that the "free" Visual Studio/C++ 2003 compiler doesn't come
with MFC/ATL. So I'll be sticking to getting Visual Studio.NET 2003 (full
thing with MFC/ATL) to compile my application.
The current changes are:
(Search & Replace in entire solution)
HFILE (to) HANDLE
#include <ostream.h> (to) #include <ostream>
Value.GetDoubleValue (to) Value.GetDoubleValue()
AFX_OLE_DATETIME_ERROR (to) COleDateTime::error
~~~~~~~~~~~~~~~~~~~~~~~~~
I am wondering whether I should put using namespace std; in all my files...
but I'll need to write a script to know where to put it (eg. after
preprocessor lines, etc.)
I came across this page and found it very useful:
http://msdn.microsoft.com/library/d...esvisualc70.asp
Basically it details all the changes. I can see why am getting these errors
now. I could do a Search & Replace to change class usage into template class
usage.
However am surprised no one wrote a script to convert VC6 MFC/ATL programs
into VC7.1 MFC/ATL programs. Maybe I should? Maybe you can help me?
"KevinGPO" <kevingpo@hotmail.com> wrote in message
news:uQUOuOSQGHA.2628@TK2MSFTNGP15.phx.gbl...
> My application was developed under Visual C++ 6.0, ATL, MFC & PlatformSDK
> Feb2003 (the last VC6 compatible version).
>
> I am wondering if PlatformSDK Feb2003 is compatible with Visual Studio.NET
> 2003? I am having major problems trying to port/build my application under
> Visual Studio.NET 2003 using the unmanaged/native C++ compiler.
>
> I was told that Visual Studio.NET 2003 had native C++ compiler support. I
> am aware about the new C++ 1999 changes (eg. #include <iostream>, using
> namespace std; etc). However my errors seem to be related to the
> PlatformSDK Feb2003. eg:
>
> error C2039: 'Delete' : is not a member of 'CCommandEx<TAccessor>' with
> [TAccessor=ATL::CManualAccessor]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
> error C2065: 'AFX_OLE_DATETIME_ERROR' : undeclared identifier
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
> error C2143: syntax error : missing ',' before '<'
>
> NOTE: what is this issue about templates??? my templates are like:
>
> <code snip>
> template <class TAccessor = CNoAccessor, template <typename T> class
> TRowset = CRowset>
> class CAccessorRowset :
> public TAccessor,
> public TRowset<TAccessor> // error C2143
> {
> <code snip>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
> error C2440: 'type cast' : cannot convert from 'CFile' to 'HFILE'
>
> <code snip>
> if ((HFILE)File==CFile::hFileNull)
> <code snip>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
> error C2475: 'CDouble::GetDoubleValue' : forming a pointer-to-member
> requires explicit use of the address-of operator ('&') and a qualified
> name
>
> <code snip>
> if(Value.GetDoubleValue != 0)
> <code snip>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
> error C2516: 'TRowset' : is not a legal base class
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
>
>
> and there's more. What was wrong with Visual C++ 6.0? and why is there so
> many errors when trying to compile under Visual Studio.NET 2003? Does
> anyone know a quick conversion script?
>
| |
| Stephen Howe 2006-03-07, 7:19 pm |
|
"KevinGPO" <kevingpo@hotmail.com> wrote in message
news:%23QN6hSeQGHA.1204@TK2MSFTNGP12.phx.gbl...
> I found out that the "free" Visual Studio/C++ 2003 compiler doesn't come
> with MFC/ATL.
That is noted in the FAQ about the free compiler.
> #include <ostream.h> (to) #include <ostream>
That was noted in version 6.
Version 6 comes with 2 C++ libraries : a legacy C++ library and a more
standard one.
You should not mix-and-match the old and new C++ libraries.
Use the newer C++ header files & libraries unless you have large amounts of
legacy code to support.
> However am surprised no one wrote a script to convert VC6 MFC/ATL programs
> into VC7.1 MFC/ATL programs.
Sorry why do they need "converting"? I had no problem.
Stephen Howe
| |
| KevinGPO 2006-03-07, 7:19 pm |
|
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:OQP%23sAfQGHA.720@TK2MSFTNGP14.phx.gbl...
>
> "KevinGPO" <kevingpo@hotmail.com> wrote in message
> news:%23QN6hSeQGHA.1204@TK2MSFTNGP12.phx.gbl...
>
> That is noted in the FAQ about the free compiler.
>
>
> That was noted in version 6.
Version 6 of Visual Studio.NET 2003?
> Version 6 comes with 2 C++ libraries : a legacy C++ library and a more
> standard one.
> You should not mix-and-match the old and new C++ libraries.
> Use the newer C++ header files & libraries unless you have large amounts
> of
> legacy code to support.
>
I have a huge amount of MFC/ATL VC6 code. As I said I would need to convert
the syntax for calling the MFC/ATL classes with the template class syntax.
>
> Sorry why do they need "converting"? I had no problem.
>
> Stephen Howe
>
>
| |
| Stephen Howe 2006-03-07, 7:19 pm |
| > Version 6 of Visual Studio.NET 2003?
No. Visual Studio 6.00.
> I have a huge amount of MFC/ATL VC6 code. As I said I would need to
convert
> the syntax for calling the MFC/ATL classes with the template class syntax.
The writing was on the wall with the C++ compiler that comes with Visual
Studio 6.0.
It was not the most compliant of C++ compilers and that looked likely to
change.
In writing code, your object should _NOT_ be, "lets see what we can get past
the compiler" but instead be "how can we write the most compliant C++ code
given the compiler we have?". The latter will be such that each newer
compiler will require few code changes, the former will be many.
An example is the old and new style C++ libraries that come with Visual
Studio 6.0.
Why didn't you switch to the newer libraries some time ago?
Stephen Howe
| |
| KevinGPO 2006-03-07, 7:19 pm |
| > No. Visual Studio 6.00.
Hmm, I don't remember seeing this in Visual C++ 6.0 (knowing that you said
Visual Studio 6.0). I don't even think VC6 accepts #include <iostream>.
Actually, unless you are talking about Service packs too. In which case,
there has been 5 service packs.
>
> convert
>
> The writing was on the wall with the C++ compiler that comes with Visual
> Studio 6.0.
> It was not the most compliant of C++ compilers and that looked likely to
> change.
>
> In writing code, your object should _NOT_ be, "lets see what we can get
> past
> the compiler" but instead be "how can we write the most compliant C++ code
> given the compiler we have?". The latter will be such that each newer
> compiler will require few code changes, the former will be many.
>
I totally agree
> An example is the old and new style C++ libraries that come with Visual
> Studio 6.0.
> Why didn't you switch to the newer libraries some time ago?
>
It's my new job/employment. Current applications are all like this. So am
doing some own time to try to get it to compile under VS.NET2003 unmanaged
C++.
| |
| P.J. Plauger 2006-03-07, 7:19 pm |
| "KevinGPO" <kevingpo@hotmail.com> wrote in message
news:uuw6GkfQGHA.648@TK2MSFTNGP14.phx.gbl...
>
> Hmm, I don't remember seeing this in Visual C++ 6.0 (knowing that you said
> Visual Studio 6.0). I don't even think VC6 accepts #include <iostream>.
It does, and always has. <iostream> was introduced with V4.2 in 1996.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
| |
| Stephen Howe 2006-03-07, 7:19 pm |
| > Hmm, I don't remember seeing this in Visual C++ 6.0 (knowing that you said
> Visual Studio 6.0). I don't even think VC6 accepts #include <iostream>.
Nonsense.
We used Visual Studio 6.0 for 4 years before upgrading, the new style
headers and libraires come with this which we used at work - very happily.
Furthermore, you could download patches to the header files from Dinkumwares
site for Visual Studio 5.0/6.0 which fixed some discovered problems. They
were not included in any of the SP's by Microsoft for Visual Studio 6.0
because Dinkumware had an ongoing lawsuit which has now been resolved. They
are still on Dinkumware's site I believe.
> Actually, unless you are talking about Service packs too. In which case,
> there has been 5 service packs.
Right.
> It's my new job/employment. Current applications are all like this. So am
> doing some own time to try to get it to compile under VS.NET2003 unmanaged
> C++.
I sympathise. Perhaps you should nudge your employee to have a code standard
meeting and point out the value (to the business) in writing code that is as
near ISO standard compliant as possible. Get fellow programmers educated.
Stephen Howe
| |
| KevinGPO 2006-03-09, 3:59 am |
|
>
> I sympathise. Perhaps you should nudge your employee to have a code
> standard
> meeting and point out the value (to the business) in writing code that is
> as
> near ISO standard compliant as possible. Get fellow programmers educated.
I totally agree and opt for ISO standard compliant code. However my
companies clients/customers still use old windows (Windows95/98/ME/2000). If
we did compile our VC6 ATL/MFC apps under VS2003 then VS2003 PSDK only
supports 2000 upwards.
| |
| Stephen Howe 2006-03-09, 7:02 pm |
| > I totally agree and opt for ISO standard compliant code. However my
> companies clients/customers still use old windows (Windows95/98/ME/2000).
If
> we did compile our VC6 ATL/MFC apps under VS2003 then VS2003 PSDK only
> supports 2000 upwards.
We run VS2003 (7.1) developed apps (MFC) no problem under Windows NT 4.0,
SP6a.
We have not tested them under Windows 95/98 but I have no reason to believe
it will not run.
However we have found that VS2005 (8.0) developed apps (MFC) will not work
if dynamically linked to MFC DLLs, it complaining of missing API
"GetLongPathNameW". If you link statically with MFC LIBs, it will get
further but die on "stack failure". I have not had time to see if I can
experiment with linker options.
Stephen Howe
| |
| KevinGPO 2006-03-10, 3:58 am |
| > We run VS2003 (7.1) developed apps (MFC) no problem under Windows NT 4.0,
> SP6a.
> We have not tested them under Windows 95/98 but I have no reason to
> believe
> it will not run.
So you can guarantee me that VS2003 (7.1) MFC/ATL apps should run under
Win95/98/ME/NT.
>
> However we have found that VS2005 (8.0) developed apps (MFC) will not work
> if dynamically linked to MFC DLLs, it complaining of missing API
> "GetLongPathNameW". If you link statically with MFC LIBs, it will get
> further but die on "stack failure". I have not had time to see if I can
> experiment with linker options.
>
And it's definite that VS2005 (8.0) MFC/ATL apps will not run on
Win95/98/ME/NT.
| |
| Stephen Howe 2006-03-10, 7:01 pm |
| > So you can guarantee me that VS2003 (7.1) MFC/ATL apps should run under
> Win95/98/ME/NT.
No. Just NT 4.0.
Since Windows 95/98/ME is another Windows product line that lacks Unicode
support, it may well be the executables do not run on these. I have never
checked and I do not know what the official MS line on this is. It maybe
that NT 4.0 is not officially supported either for apps developed using
VS2003. I do know that MFC apps _DO_ run on it (whether officially or
unofficially) as we are running a 7.1 MFC app.
> And it's definite that VS2005 (8.0) MFC/ATL apps will not run on
> Win95/98/ME/NT.
Note: If an executable does not run on NT 4.0 for API reasons, it is even
more unlikely to run on Windows 95/98/ME. It is also possible for the
converse to be true. You can get badly behaved DOS apps that Windows
95/98/ME will tolerate that Windows NT/2000/XP will not.
It may be possible, for limited cases to get VS2005 MFC/ATL apps to run on
NT 4.0.
You might even manage Windows 95/98/ME but I doubt it.
I don't like the way this conversation is going.
Reading between the lines, it sounds to me like you & fellow programmers at
your company need training. Hanging around the Visual C++ newsgoups also
comp.lang.c++ in your lunchtimes would be a good move. Read the responses
from the MVPs in Microsoft newsgroups, they know their stuff.
comp.lang.c++ is very useful for picking up on details on ISO C++.
Your company should also invest in some books. The 3 Scott Meyers books,
Nicolas Josuttis's book on the C++ library, Bjarne Stroustrup Special
Edition and Accelerated C++ by Koenig & Moo would be good investment. Also
Steve Dewhurst's 100 Gotcha's. Progammers should be encouraged to read.
For the more advanced, Herb Sutters 3 books and the book co-written with
Alexandrescu are very useful. You might want to browse the UK's ACCU site on
book reviews:
www.accu.org
On newsgroups: They are the school of hard knocks. You might be flamed,
rubbished. But your C++ will improve and you (and your fellow progarmmers)
should be more finacially valuable to your company. It is worth hanging in
there, answering questions when you can, learning from those who regularly
answer questions.
I get my information from
Good Books
Online articles
MSDN documentation
ISO standards
Newsgroup posts
Google searches
Stephen Howe
|
|
|
|
|