|
I was actually doing 16-bit MFC. This was part of a contract assignment. At the same site I also used VC++ 6 and 7.0, plus ASP and VB .NET/ASP.NET. So, quite a bit of variety!
I actually used the VC6 IDE to edit my VC 1.5 code, so I could get all the IntelliSense and other features of the IDE. Then I'd switch to VC 1.5 for the compile.
Kevin
|
|
|
|
|
You would be wrong. I still use VC6 every day. A large portion of what I do is building back-end systems to produce web-enabled presentations for reports, analysis, raw data, etc. I am still building new applications with VC6. I have a huge investment in C++ libraries (written by me and others) and some will not compile under VC.NET. I am slowly moving to VC.NET, but I will still be using C++ for the bulk of my work. I can't even imagine using C# or VB.NET for some of the stuff I have to build. I love ASP.NET for web front-ends, but for back end systems, C++ still is the best IMHO. As far as I know, for programming win32, non-mfc, non-gui C++, there are relatively few benefits to VC.NET.
However, I am not building shrink-wrapped applications which may be what you mean.
|
|
|
|
|
I wasn't talking there about C++ and VC6, but about building new apps with COBOL, Fortran, etc.. I write all my code in C++ using the beta of VC2005 and I can't imagine me moving to C# or whatever .NET language anytime soon...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Same here... I use VS .NET to develop C++ applications using frameworks other then those developed by Microsoft. The truth is I am not taking full advantage of the .NET capibilities in any way.
|
|
|
|
|
If I'm not mistaken, VC++ 6 is a compiler not a language... So technically if you wrote something in C and compiled it with VC++ 6, what are the chances that it will compile with VC++ 18? As long as you don't have some #pragma in the code specific to VC++ 6 and perhaps unless the command line options change, you probably don't even have to change a makefile to get it to work!
Of course, there may be some incompatibilities which need to be ported here and there (especially when using a poorly portable langauge, I won't mention any names) but in general it should just work... So I don't see how you would judge legacy by the compiler used to build a binary but rather the coding methods, algorithms and implementation of the design (what APIs are being used, etc.).
As an example, using a single threaded implementation to get around an issue that a specific OS that doesn't support threading; however the OS does now support threading in the latest releases.
The other definition would simply be "code that was written before the current project" even if it was last month. Last month was a seperate project and it's already been released. Since it pre-exists your current code, it could technically be referred to as legacy.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Despite my pleas, we still end up creating solutions using legacy code. Why we start a new project in ASP 3 is beyond me, but it still happens from time to time. It's partly because not everyone on the team is C# and ASP.NET ready. I was a fairly early adopter and I'm cringing as I see them begin to dabble in ASP.NET for the first time right as Whidbey is about to be released. 
|
|
|
|
|
I'm in the same boat but I actually prefer projects in the legacy code to the new stuff. It was better thought out, planned and written. Some of the code hasn't been changed since 1995 and it still works. It has been structured in a way that is easy to modify and easy to maintain.
State machines - they're really simple compared to the complex algorithms that needn't be complex. The 'kids' nowadays aren't taught state machines so the coding is unduly complex. One of them couldn't believe how simple the coding became when I showed him how to do it with a state machine. Legacy methods are great if someone bothers teaching them to the youngsters.
A lot of the C# stuff is coded on screen with very little planning. It is a nightmare to maintain even though it is less than 2 years old. There are no programming standards and you spend a quarter of the time battling with Visual Studio.
Legacy stuff loads up in 15 seconds. Non legacy stuff takes almost 5 minutes! For minor mods, it takes 30s to rebuild legacy stuff and almost 10-15 minutes to rebuild non-legacy. I'm sticking to legacy for now.
|
|
|
|
|
I have to admit that I'm one of those 'kids' you speak of. I'm working hard to more about the design principles that will help me write more maintainable code.
For us youngsters, have you got any favorite URLs that will help us with, for instance, state machines?
|
|
|
|
|
cup wrote:
Some of the code hasn't been changed since 1995 and it still works
Maybe that could be rewritten as "Some of the code hasn't been changed since 1995 and that's why it still works"
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I have written legacy (forth and C) code as well as new software using .NET. My experiance has been that language and age of code (or the programmer  ) don't matter. Design, quality control, and coding style (i.e. readability) are the important factors.
As far as coding style is concerned, people must realize that code was meant to be read by people. If we wanted code to be dense and efficient, we would write in hex. So don't do something like this...
if((c=getchar())!='\n')
...and if you do, COMMENT COMMENT COMMENT!!!!!!!!! 
-SHaroz
|
|
|
|
|
Recently I was involved in a new project launch with legacy developers in charge The lead "architect" insisted the only dependable tool is ....  .... VC++6. He informed the project sponsor "it is quicker than learning new technolgies". I feel your pain and distress....
|
|
|
|
|
I selected "more than 80%", but it is very close to 100%. I maintain:
- A 15 years old machine translation library: old-style C++
- Applications that go with above-mentioned library: MFC
- A couple of years old terminology extraction library: modern C++ with lots of Boost and STL (I love this one )
- An overdesigned and bloated CAT application (C#)
- A machine translation web farm, or what's left of it (mostly C++)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Anyone who selected less than 80% isn't a real programmer. 
|
|
|
|
|
NO, most likely they are doing new work in .net. My answer would have been 90% before .net came along, now we are re-writing every app in .net, down the road my answer will flip to supporting legacy code again. It's the cycle of things, any "real programmer" who spends 80% of their time supporting legacy code forever isn't really a programmer, more of a caretaker.
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
|
|
|
|
|
CP Visitor wrote:
Anyone who selected less than 80% isn't a real programmer.
I suggest the opposite! Everyone who selected more than 80% has bad luck or isn't a good enough programmer to do new code.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Isn't there a point in the lifecycle where you should say: "Ok, it's bugfree or i'ts dead...". You can't support your old creations forever. This would stop you from beginning something new and better.
WM.
What about weapons of mass-construction?
|
|
|
|
|
True, but some companies have one or more main products that they keep upgrading. These companies would have to maintain the code for every major change they make.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I selected "I don't touch legacy code" because, in my current job, I am the first developer they've had. There was no legacy code. I guess if I go back and update any of my projects, I'm working on legacy code.
|
|
|
|
|
That's a retarded comment. How do you think all the legacy code came to be?
--
An eye for an eye will only make the world blind.
|
|
|
|
|
It varies, but I would likely tend to agree. If you aren't working with 80% legacy code, even if you are working with new features, then most likely you're a start up or this is a completely bran new project and has a long way to go. Even those who don't "support" legacy code still "work" with legacy code, so I would definately agree.
I wouldn't say that those people "aren't real programmers" but I would say that "they definately haven't worked or aren't working on a large project".
So, even if you start a new project, that means that there is very little code. Then it's "how long does code sit around before you deem it as 'legacy'"? In 2-3 years your project will be pretty big. If you add a new feature, that code that you plug into could technically be considered "legacy".
You also have to wonder about those who re-write their entire code base. Perhaps it wasn't that big to begin with, wasn't that complex or they're going to be working on it for many years until it's finished!
I work on a very large code base which contains everything from video drivers to NT Services It wouldn't be a simple task to re-write everything from scratch!
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
CP Visitor wrote:
Anyone who selected less than 80% isn't a real programmer
I think it's called moving on and keeping your skills upto date, anyway .net is far more interesting than skimming thru MFC/ATL.
Blogless
My Blog ^
|
|
|
|
|
I much prefer this:
Nemanja Trifunovic wrote:
modern C++ with lots of Boost and STL
to this:
Nemanja Trifunovic wrote:
old-style C++
Trouble is that there's too much, even recent, C++ that's written in the old style.
Kevin
|
|
|
|
|
If something works - don't touch!!!
|
|
|
|
|
If you don't touch it you don't have to see you dumb mistakes or inefficient ways of doing things. One of the reasons I don't touch old code it because I have learnt better ways of doing things. Once you know better you can never go back
http://doubin.forwardslash.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
