|
We need something really unmanaged (.NETless) and better MSDN.
VS.NET offers bad explanation on Win32 API, MFC and other older technologies in the attached MSDN.
I just so hope MS will release a Visual C++ 7 and not Visual C++.NET.
Not everyone interested on .NET.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
There are no improvements to MFC in VS.NET. In fact MS announced that it has discontinued MFC development (only bug fixes).
If you are only doing c++ and/or MFC development, the few extra improvements (mainly the compilor) may not make it worth the effort. If you convert your project, you will have to retest everything. At least I have found many subtle bugs introduced into my code by the new libraries.
VC6 was a mature and stable product. If it works why fix it?
|
|
|
|
|
If the rumours I hear are true you may have no option but to upgrade for the new vesion of windows (as usual). If anyone knows if this lot is true, please post back 
1. All subclassing(VB) and hooking code will not run due to the API being deprecated.
2. The GUI will be (stolen from the) XML forms specification. Who MS?
3. The GUI is script/markup based so web-form will finally be seamless.
4. To use un-managed code you will need to go through an virtual application?
If any of this is true and you know why, please tell me 
Bulletin boards are the root of all evil and myths.
|
|
|
|
|
One may find that a big proportion of the people who ticked VC++ 6 also ticked one of the VS.NET options.
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
Einstein says...
|
|
|
|
|
I would say that not everyone is having the same problems when it comes right down to it because not everyone uses a product in the same fashion so some will see bugs that others might never see... 
I for one have had Visual Studio .NET 2002 crash on me several times and have seen quite a few strange things while Visual C++ 6.0 has NEVER crashed on me a single time (as far as I can remember), and I can also admit that the VS.NET 2002 and 2003 products are more sluggish that the VS 6.0 products.
For me at least, VS.NET 2003 (which I use VC++.NET, VC#.NET, and VB.NET) seems to be a bit more stable than 2002, but hopefully I haven't spoke too soon. 
BNEACETP
|
|
|
|
|
We have older versions of our products, developed on VC6, that we still need to support. We still need to use VC6 to recompile changes for these older products. We use VS.net 2003 for new development.
I'm sure there are lots of other companies in the same boat.
Ian J Prest
|
|
|
|
|
Ian Prest wrote:
I'm sure there are lots of other companies in the same boat.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
