|
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
|
|
|
|
|
Thanks for that info.
>
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
----
Also from memory VC4 shipped with ATL 1.0, VC5 with ATL 2.0, VC6 with ATL 3.0, and VC7 with ATL 7.0.
So there's an extraordinary range of numbers on offer at any given time
So you think my guess about VC 4.0 matching Windows 4.0 is wrong, and that the numbers were driven by MFC instead?
Also, is VS 97 the same as VC 5 ?
Then C/C++ 11.0 = Visual Studio 97 = Visual C++ 5.0 = MFC 4.1 = ATL 2.0
would be the most absurd point in the history.
-Don.
|
|
|
|
|
Don Clugston wrote:
So you think my guess about VC 4.0 matching Windows 4.0 is wrong, and that the numbers were driven by MFC instead?
Also, is VS 97 the same as VC 5 ?
Yes to both questions; this is the proof that marketing people cannot keep a steady course for more than a couple of years...
Alberto
|
|
|
|
|
Most of the versioning chaos started when Gates decided to call Windows 4 Windows 95. Since then we've had a mixture of years and version numbers.
Of course they used to skip version numbers occasionally but ta least they were increasing.
Though, as pointed out below, there was MS C/C++ 7 -> Visual C++1.0. But you could argue that VC++ was a new product.
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
