|
OK -- First I read all this stuff thats negative.
Now a few days later I read a bunch of positives.
And toss is questions about a 2005. And you
recommend 2003. CONFUSION!
I posted earlier I would just stick with V6 and
save my 100 bucks. (I don't know what 200x the
version a CompUSA I saw is.)
Should I just wait for 2005? What about the "better
compiler"? Is it really all that much better than
V6? (I was under the impression that V6 was a
very good compiler.)
The interface I can adjust to. (I moved from
UNIX and emacs and plain C to VC6 and their IDE --
I can move to any new interface  .) But I do have
a lot of MFC code (and some COM) that I will have
to port.
COM is another question... Is 2003 (or 2005) better
(easier) with COM? (I know I don't want to
learn C#!!!)
WedgeSoft
|
|
|
|
|
By saying that VS2003 has a better compiler I mean standard conforming with improved error and warning messages. Performance-wise VC6 is pretty good - it produces executables that are, generally, relatively quick and small. And, in that regard, comparable to executables produced by VS2003.
But if you want to use modern C++ techniques (particularly those involving templates) it's quite difficult, if not impossible in VC6. And if you want to use modern C++ libraries (boost and loki are two that spring to mind) you simply can't use VC6.
VS2005 will not give you any noticable advantages (over VS2003) to developing in C++ unless you're using C++/CLI (ie .NET stuff). If you are considering using C++/CLI in the future then definitely wait as the syntax has changed between version 2003 and 2005 and the latters is far superior.
I believe COM support is much of a muchness between all the versions.
I guess it depends what you want. If your developers (is it just you?) are happy using older-style C++ techniques & libraries then stick with VC6. (If you need to ask "what are modern techniques/libraries" then you can safely assume that you can stick with VC6)
If your developers are the type that would like to progress and take advantage of new coding techniques so they can take their C++ skills to the next level then I'd suggest VS2003.
If you're seriously considering moving to C++/CLI and .NET I'd wait for VS2005.
Personally, I tend to develop more generically these days with a relatively high usage of templated code. I'd hate to have to use VC6 again.
Hope that helps more than hinders!! 
Cheers,
Matt
|
|
|
|
|
Thank you! Very helpful.
Just me. Stuck in my old ways
I know what templates are, I don't need them.
I assume CLI is Command Line Interpreter. I
don't need that either. I can't afford to buy
"modern libraries". Guess -- when I am forced
to upgrade, then I will. Your email
re-enforced that it is best I stay at V6
(for now).
WedgeSoft
|
|
|
|
|
OK, sounds like the right decision for you.
However, I've got to admit that I didn't think that I 'needed' templates all that long ago. Now I look to solve problems generically and I often use templates. Try not to dismiss their use as they are an extremely powerful tool.
And the boost (and loki) libraries are free, check them out!
Cheers,
Matt
|
|
|
|
|
may be the vim is exported product from India to SA
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
I am stuck at vc6 (I do have the latest .net) because vc.net is not backward compatible with vc6. It would take me way too long to port my 500K+ lines of source code that I am currently working on. I actually began a port but after 2, 60 hour weeks and I did not even dent the problem I gave up...
John
|
|
|
|
|
Ha! Anyone stuck doing driver development is likely stuck on VC 1.5, as it was the last compiler that can produce 16-bit code, and all 95/98/Me drivers are 16-bit.
So count your lucky stars. 
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
That's interesting, I was responsible for porting our code (similar number of loc) and had very few issues - it only took a couple of days.
What kind of problems did you have?
Cheers,
Matt
|
|
|
|
|
Most of the problems were due to changes in templates or changes in MFC. I admit that of the 500K lines 20 to 30% is from codeproject and that part was the hardest to port (and also the part with the most problems) because its difficult to port code unless you understand exactly what it is trying to accompish. When I tried to do the port (probably two years ago) most of the users did not update their articles to make them VC.NET compatible but this would not be of total help to me as I rarly get any free code that I do not need to make some modifications either to fix a bug or to add a new feature.
|
|
|
|
|
Sorry about the annonymous post, I wish I could have deleted it but...
Most of the problems were due to changes in templates or changes in MFC. I admit that of the 500K lines 20 to 30% is from codeproject and that part was the hardest to port (and also the part with the most problems) because its difficult to port code unless you understand exactly what it is trying to accompish. When I tried to do the port (probably two years ago) most of the users did not update their articles to make them VC.NET compatible but this would not be of total help to me as I rarly get any free code that I do not need to make some modifications either to fix a bug or to add a new feature.
John
|
|
|
|
|
A bit OT but you got to love that versioning. 97, 6, .NET 2002, .NET 2003 and now just 2005. What happened to 2004? And was 6 == 98/99/00/01?
Marketing definitely had a hand in all that. I'll bet the developers of Visual Studio would have just stuck with linear numbering and us users, developers too, would have preferred it.
Any idea why they dropped .NET from 2005? Not so new (i.e. marketable) anymore?
regards,
Paul Watson
Bluegrass
South Africa
Michael Dunn wrote:
"except the sod who voted this a 1, NO SOUP FOR YOU"
Crikey! ain't life grand?
|
|
|
|
|
Paul Watson wrote:
A bit OT but you got to love that versioning. 97, 6, .NET 2002, .NET 2003 and now just 2005. What happened to 2004? And was 6 == 98/99/00/01?
I lot can be gleaned just by looking at directories under studio. For instance, everyting under Studio 6 is labeled V*98.
Then, oddly enough, the subdirs under Studio.NET 2002 are V*7. (Adding confusion, the subdirs of Studio.NET 2003 are also V*7).
Back in the day - the first C++ compiler from Microsoft was labeled "Microsoft C/C++ 7.0" (Borland had several adds making fun of that). The next compiler they came out with was Visual C++ 1.0 - go figure!
Dale Thompson
|
|
|
|
|
Dale Thompson wrote:
Then, oddly enough, the subdirs under Studio.NET 2002 are V*7. (Adding confusion, the subdirs of Studio.NET 2003 are also V*7).
This is not that big of a deal. VS.Net2003 was not a major release. It wasn't version 8. It was merely an upgrade of VS.Net2002. The correct directory naming would've been V7.1 as opposed to V7 for 2003. Visual Studio 2005 is going to be version 8. That's the reasoning behind that (as per my understanding of about boxes).
Manuet Systems
http://www.manuet.com
|
|
|
|
|
I have been with Vb since 1.0 and in my opinion the even versions were always better than the odd ones, so hopefully V8 will be ace.
I think it will be because if I understand it correctly V8 will have the ability to debug code and make changes to it whilst in run mode. That is something I really miss from VB6.
Siv
Graham Sivill
Martley, Near Worcester. UK.
|
|
|
|
|
|
Dale Thompson wrote:
Back in the day - the first C++ compiler from Microsoft was labeled "Microsoft C/C++ 7.0" (Borland had several adds making fun of that). The next compiler they came out with was Visual C++ 1.0 - go figure!
If you used Microsoft C 5.0 and 6.0 as I did in 19XX, you will know why it be called version 7.0. At that time, MSC5 was a good compiler but Borland have a better visual IDE.
---
Herbert Yu
Are you sure the speed of computer industry is proper? Are you sure the software you released is a bug free one?
|
|
|
|
|
And TurboDebugger was a lot nicer to use than CodeView. MSC 6 was the version that introduced two things: Bugs and OS2 support. MSC7 introduced C++ and MFC 1.0
onwards and upwards...
|
|
|
|
|
Well, Microsoft has to be consistent. Their naming scheme for compilers makes every bit as much sense as their naming scheme for operating systems. 
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
|
At some MSDN event I recently attended, it was said that the '.Net' was removed because now everything is going to be .Net hence it was not needed anymore.
Yves Tkaczyk
|
|
|
|
|
The developers of the compiler HAVE kept the original linear version scheme!
Check out the value of _MSC_VER, or enable the banner when compiling. Eg, VC6 prints this:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
See that? Version 12.0! There's no mention of "VC6" anywhere in the compiler itself, just in the IDE.
Versions 1-6 were C compilers.
After C/C++ 7 came VC1.0 which had _MSC_VER=8000
VC1.5 was 9000 I think.
(there was no VC2 or 3 - you missed that piece of stupidity in your list. VC4 was the first Windows 95 one, it was probably given that title to match Windows 4.0, which of course was never marketed in that way, though I note that XP Pro calls itself Windows Ver 5.1 on the command line).
VC 4 is 10000, VC5 is 11000
(I never heard of 97. Was it VC 5.0? I jumped from VC4 to VC6. Also I never used VC1.0).
VC6 is 12000.
VC7 is 13000
VC7.1 is 14000.
I haven't checked, but I expect that VC8 is actually Microsoft C/C++ v 15.0!
It's all pretty hilarious really.
I just wish they'd put the _MSC_VER value on the box, and completely abandon the ridiculous marketing version numbers.
Call it "MS VC Whidbey" and have 15.0 in small print somewhere.
|
|
|
|
|
You are wrong as for VC2; I have the box here in my office... At that time MS even tried the "subscription model", where they would ship an update every 3 months...
After 9 month, with VC 2.12, they gave up!
Alberto
|
|
|
|
|
Thats correct, as well as the often *forgotton* VC for Macintosh Cross-Compiler which is on my shelf...
onwards and upwards...
|
|
|
|
|
>You are wrong as for VC2; I have the box here in my office... At that time MS even tried the "subscription model", where they would ship an update every 3 months...
After 9 month, with VC 2.12, they gave up!
That's really interesting. I never heard of VC2. But there never was a VC3, right?
(Unless VC3 was one of the MIPS/Alpha compilers?)
The numbering system is a complete pig's breakfast!
|
|
|
|
|
Right, there was no VC3. This because they wanted to align all the numbers...
Microsoft C/C++ 7.0 shipped with MFC 1.0
Visual C++ 1.x (16 bit) shipped with MFC 2.0
Visual C++ 2.x (32 bit) shipped with MFC 3.0 (in the same box there was VC 1.15 for 16 bit development)
So, they skipped VC 3.0 to finally have
Visual C++ 4.0 shipped with MFC 4.0
But they soon broke this nice alignment by having
Visual C++ 5.0 with MFC 4.1
Visual C++ 6.0 with MFC 4.2
and finally
Visual C++ 7.0 (aka .NET 2002) with MFC 7.0
Visual C++ 7.1 (aka .NET 2003) with MFC 7.1
Alberto
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
