|
When a new compiler comes out, as a developer or development manager you have to ask yourself two questions.
1. Do I have the time and manpower to make sure that the product still works after we've compiled it in the new compiler.
2. Do the new features in the compiler, justify the risk of upgrading.
When you have a codebase that has been developed over several years and is the main source of company income - you have to make sure that the upgrade is worth it.
You'd be surprised about the number of little things that have changed that can break legacy apps - I know, I've been there.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
And don't forget number 3:
3. Am I in the middle or near the end of the development cycle for a product?
If the answer to that is yes, then you probably want to wait a while before upgrading... 
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Dale Thompson wrote:
Visual C++ 6 is 5 and a half years old. Its last service pack was three years ago.
Isn't there supposed to be a new service pack for VC++6 released this year?
"Insanity runs in my family... It practically gallops." - Mortimer Brewster, in Arsenic and Old Lace
My 20 favorite films:
http://www.ymdb.com/user_top20_view.asp?usersid=8912
|
|
|
|
|
Don't know, but there was a service pack last year
|
|
|
|
|
|
Dale Thompson wrote:
This looks pretty bad
I take it you are a Microsoft salesperson then? I mean, the only one it's "bad" for is Microsoft, that don't get to peddle more wares that are once again unsupported and artificially obsoleted in a year or three.
But more than 50% of the responders are using VC++ 6, which can easily be upgraded to VC++ .NET 2002 or 2003 (versions 7 and 7.1, if you would rather).
Easily? Well, as a sales person I think you might not see the difficulties involved in such a change.
Let's paint a not too fantastic scenario:
2002:
- Upgrade to 7.0. ~50 licenses. A nice sum of Redmond Tax.
- Requires ~4-6 times as much memory, ~5 times as much disk, and 4-6 times the CPU, why obviously new developer machines would be required [1]. Another $70-$100K (current exchange rate).
- Standstills due to OS and software installations, say just one lost workday/developer (too low to be realistic). At $100 each that's another $40K.
- Oh, it's incompatible with all our other tools (profilers and such)? OK, another $10K-$20K.
- Incompatible with VC6, and incompatible with the standard. Requires code rewrites incompatible with both. This is wasted time, and money, that "nicely" spills over to the next upgrade (2003). Estimate impossible.
- Hope (and pray) all developers becomes reasonably comfortable with it, to let them be at least as productive as with VC6. Fat chance.
That would set us back a quite noticable amount, with no immediate benefits in sight.
[1] Due to these machines, they might like Microsoft start writing sloppy code, consuming way more resources (e.g. memory and CPU) without even noticing the slowdowns - only the customers running older machines will experience this (I think that might be a reason VC7 even was released - if you compare its speed on a top-of-the-line machine at the time it was release, it actually might run the same speed as VC6 on a top-of-the-line machine at its time - but I wouldn't bet on it).
Now fast forward just one year to 2003.
2003:
- Yet *another* version, even that it's internal numbering clearly displays it as a just revision (7.1). More Microsoft Tax.
- This time perhaps the machines are "fat" enough to handle it. "Only" 4 hrs/dev. $20K.
- Oh, it broke 50% of the developers OSes? Tough luck. Complete reinstallation of OS and tools takes care of that. 25 developers * 1 day. Another $20K.
- More conforming compiler. Great, finally we may change the code to be C++, but it costs money. Money we wasted on the interim 7.0 code. Estimate impossible.
For both versions, the API documentation has only become worse and worse. If this continues, there will no longer be a Win32 API - just a 10GB of "soup" called "MS Runtime Slosh", or something like that.
<sarcasm>Yeah, I can see how this could have been of benefit...</sarcasm>
The improved MFC and ATL support in version 7 alone should make the upgrade mandatory.
Improved?! They have for crissake put it on death row! OK, that might be an "improvment" for something as MFC from a C++ POV, but for the ones using it it's a knife in the back!
Visual C++ 6 is 5 and a half years old.
So you judge software by age? The older the worse? Then, surely, you must think antiquities as vi, ls, more, grep and uncountable other tools or built-in commands to be so useless they should be banned?
I'd love to see you even try getting on the net if that ever happened...
But if this is your view, that you actually think customers are happy being put in an endless-upgrade treadmill, perhaps you should start trying to sell your software with a big red best-before date on the box, making it clear that "after this date, we won't care about neither this software nor you"?
Another viewpoint is that the older the software the more it displays it's utility. If it's used after half a decade, that's good in MS-terms. If it's used after a decade, it's good. Many use software that's over 20 years old. Not because they are "cheap", but because it still does the job! Sometimes, it's even the best there still is!
It's time to upgrade to at least get product support!
Like we have ever gotten any "support". VC6 was released the same year the C++ standard was ratified. Did they do anything to increase the level of standards conformance to the compiler? Anything at all? No. You call that support? I call it "pissing customers in the face".
Forcing a sh*tty VB-ish IDE down developers throats when MS instead/also could have upgraded the compiler for MSVC6, and charged for it as 6.1, 6.2... I don't like it, and apart from the few here that are forced to use 7.x, I've got a feeling VC6 was the last full MS C++ development product we rolled out.
|
|
|
|
|
Maintenance old son, maintenance.
Software Zen: delete this;
|
|
|
|
|
I am not surprised at all that the use of VC6 and VC7.1 both end up ~50%. In our company we use both, VC7.1 and VC6, for C++, MFC and COM work. Most 'unmanaged' code. I think I can make a reasonable good comparison between the two development environments as regards this work.
In our company we have upgraded the final compilation to VC7.1. We had to re-write some of our code because VC7 is less forgiving in how you use C++. Not a big problem.
It is still a relief however for me to go back to the sleek, uncluttered VC6. ClassView in VC7.1 is way too cluttered with useless information. ClassWizard was good and we did not get back the same helpful functionality. I added Visual Assist to VC7.1 and that helped. Still, VC6 together with WndTabs is preferred. I also like to open a few projects at the time so I have say 4 times Visual Studio running. No problem, but impossible to do with resource-hungry VC7.1.
VC6 had reasonable good support of COM: putting an ActiveX control on a form went smoothly, classwizard enabled you to add parameters to control, handle events, add message handlers. I searched for this in VC7.1 but it was gone. The "properties" table looks like VB but not nearly as useful. We use ActiveX components a lot. These can have Methods, Events or Properties. In VC6 adding an ActiveX to a project is easy, two stub files are created with "Get/Set" functions for the properties. In VC7.1 adding an ActiveX control can be done in two ways which is confusing, and the ActiveX properties are simply ignored in the newly created stub files.  It's a bug and it surprises me that it is still in VC7.1. I concluded that ActiveX controls are better added in VC6.
I disagree that support for MFC has improved. Some classes may have been extended and a few added but nothing groundbraking.
In conclusion I would say that VC7.1 is not really "better" for use with MFC/COM. If money is an issue as well then I'd say: stick with VC6. Our company moved to VC7.1 in the vian hope that the teething problems would have been sorted out, and in the fear that we would suffer from "lagging behind" in technology. We went with the perpetual M$ adagium "upgrade or perish" so now we have to buy faster PCs as well 
Hidde Wallaart
software engineer
www.leo-em.co.uk
|
|
|
|
|
I have a really strong impression that the whole VS.NET IDE is just a Visual Interdev 6.0 with some eye-candy sliding and docking panes added.
It may be good for VB users as VB IDE is similiarly (dis)organized but from the VC++ 6.0 user point of view it's a major setback and loss of productivity both in time due to the slowness of the UI and lack of features. Only Visual Assist saves the day and if it wasn't for that it would be impossible to get any serious work done using just plain VS.NET environment.
One-size-fits all simply doesn't work well when it comes to IDEs
And then there are bugs and annoyances...
Trying to edit HTML pages in VS.NET may leave you with files truncated in half or re-formatted as IDE sees fit.
Using the integrated source control will trash the project level changes history by filling it with lots of entries like "Added ~sak5a3bbbd501c3d918.tmp" followed closely by "Deleted ~sak5a3bbbd501c3d918.tmp". If you will carelesly start a build and then try to checkin your files or diff at the same time then you may get a hung IDE at the build end. You can't close the IDE any more as it claim that you ought to close some imaginary popup window.
Using the wizard to add message hanlers and virtual overrides will switch the files after each addition so if you want to add more than one it get's a bit tiresome. And on top of that it will inject redundant include line with header name in lover case preceded by "./". That micro-management doesn't seem to serve any real purpose.
I guess we have to have wait two or three more versions to get a functional product...
<center> </center>
|
|
|
|
|
... you forgot to mention the buggy resource editor... a real pain...
|
|
|
|
|
George wrote:
One-size-fits all simply doesn't work well when it comes to IDEs
After working with it for a good six months now, I've found the IDE to be not as bad as I first thought. (Although, I tend to be writing code by hand rather than using the wizards)
George wrote:
Using the integrated source control will trash the project level changes history by filling it with lots of entries like "Added ~sak5a3bbbd501c3d918.tmp" followed closely by "Deleted ~sak5a3bbbd501c3d918.tmp". If you will carelesly start a build and then try to checkin your files or diff at the same time then you may get a hung IDE at the build end. You can't close the IDE any more as it claim that you ought to close some imaginary popup window.
Not seen that happen. Is this with Visual Sourcesafe integration?
George wrote:
Using the wizard to add message hanlers and virtual overrides will switch the files after each addition so if you want to add more than one it get's a bit tiresome. And on top of that it will inject redundant include line with header name in lover case preceded by "./". That micro-management doesn't seem to serve any real purpose.
Oh yes, one of my biggest problems with the new IDE, that's why I started handcoding a lot of the stuff.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
We recently moved from VC6 to VS.NET 2003 and I think this was a mistake. We only do c++ and MFC development. Although there are some improvements, there are a lot more things that are worse. VS.NET is more crashy, slower and buggy. The UI is sluggish and badly designed - the resouce editor is really awful.
|
|
|
|
|
Anonymous wrote:
VS.NET is more crashy, slower and buggy.
I've not had any major problems with VS.NET 2003. 2002 was a bitch, but the current version works a lot better.
Anonymous wrote:
The UI is sluggish and badly designed
After you've used it for a while, you find it grows on you. I certainly feel more productive using it.
Anonymous wrote:
the resouce editor is really awful.
I don't use it much. Most of my legacy code I maintain, doesn't need much in the way of UI changes. For my C# work, my apps build their ui from an XML file (which I currently handcode). The resource editor is probably easier to grips with, if you've done any VB6 programming 
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
>the resouce editor is really awful.
Well said. The resource editor in VS6 is much better - copying resources from other .RC files for example. Plus, the only crashes I have had in VS.2003 have been when resource editing. There is also a highly annoying bug which means some resource elements end up as numeric IDs instead of the #define - e.g.:
"&Open", 31234
instead of:
"&Open", ID_FILE_OPEN
The real problem with this is when you try to use the new ClassWizard to add a WM_COMMAND handler, you see a list of bloody numbers instead of readable commands! Aaaarrrggghhh!
The Rob Blog
|
|
|
|
|
Robert Edward Caldecott wrote:
There is also a highly annoying bug which means some resource elements end up as numeric IDs instead of the #define - e.g.:
"&Open", 31234
instead of:
"&Open", ID_FILE_OPEN
That is one of the most annoying bugs that I have found in the program. I end up changing the IDs back to the #define name and VC++.NET ends up sooner or later, changing it back to the number. Weird stuff.
Talk about something that needs to be fixed! 
BNEACETP
|
|
|
|
|
I have another one.
Try
String *strNet = S"llll";<br />
CString strATL;<br />
strATL = strNet;
<br />
String *strNet = S"llll";<br />
CString strATL = strNet;
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
String *strNet = S"llll";
CString strATL;
strATL = strNet; //This will give compile error on my VS.NET 2002
String *strNet = S"llll";
CString strATL = strNet; //this works, weird
That is some weird stuff... 
BNEACETP
|
|
|
|
|
Anonymous wrote:
We only do c++ and MFC development
C++ projects that do not use MFC benefit greatly from VS.NET 2003 IMO. This is mainly down to the compiler rather than the UI. Everything is better from standards support right down to error messages.
Anonymous wrote:
VS.NET is more crashy, slower and buggy. The UI is sluggish and badly designed
I am another person who finds it better. The main improvement UI wise is the text editor and the debugger. However, this is only because my comp can run it at a decent speed. It must be horrible on an older comp.
I can honestly say I have not seen crashes. But I have seen the odd 100% cpu use (only working on asp.net projects). I would guess I don't see many problems because I do not use the resource editor.
|
|
|
|
|
Mazy
No sig. available now.
|
|
|
|
|
Sorry to disagree. VC6 is not a stable version. I used to use bookmarks and brief-emulation, which resulted in daily crashes. Intellisense surprisingly popups, sometimes. The class-tree frequently gets corrupted. The resource editor, well it was not so bad if you haven’t seen the resource handling in Visual Studio.Net. Although, a nice feature I miss is debug – apply code changes.
|
|
|
|
|
Leifen wrote:
The class-tree frequently gets corrupted
Yep. It was unusable with namespaces and folders in VC6. It would just forget them  In VS2003 I have not found a single problem after I set that option that prevents it from jumping around. It took em a while, but I have to say, at last, MS got it right. For what I do anyway 
|
|
|
|
|
I have mixed feelings about new IDE (it is too slow and unresponsive sometimes), but the fact that we have a decent Standard Library would be enough for me to switch, not to mention compiler improvements (VC 7.1 is 98% ISO compliant) and ATL Server.
|
|
|
|
|
And I really hate the attached MSDN.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Anonymous wrote:
the resouce editor is really awful.
Resources are so '90's. Most (if not all) of our new apps now use XML based resources and generate the UI on the fly. Sure, it was a big hit to code that all up the first time, but it's working quite well now. 
As for VS.NET - we are still on VS.NET 2002, and it's been a mixed bag. I think I do like the UI better, although it took a while. The compiler is mostly better. There are some annoying... how shall we say, issues, in the new MFC, but we hardly ever use MFC anymore these days. Unicode support is much better in VS.NET than in VC6. VC6 seemed to be more stable, though, as there are often little annoying things that come up from time to time that can drive me crazy.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
We have mixed sites with both frameworks and classic therefore I still manage and edit my files in VS6 because I can. On the other hand I use VS 7(2002) for desktop applications. VS7 is too napoleonic to use for web site development. I prefer to create my classes and code behind in a different folder and I don't er won't use the designer so it is a waste of my energy and money.
Pam
Some days the Dragon wins!!
Pamela Reinskou
VersusLaw Inc.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
