.NET or VC++
-
Simply go to Monster, Dice or other employment listings and search out jobs. Majority are Java and .NET for Windows while you still find a few C/C++ for Linux projects. Search Monster for MFC you have 550 listings, Win32 only 332, C#, VB.NET, ASP.NET or just .NET are all over 1000 (they only list 1000). Also compare salaries. C/C++ was the way to go for decades, but the shift started years ago and it seems to continue. Not only on Windows platform, but there are more and more projects on Linux now using .NET (mono), but the numbers on Linux are much smaller. For most business applications, .NET is a clear winner as develop time is drastically less and bugs are fewer require far less debugging time. Shorter development cycles mean less cost which is a winner with business. On the other hand, if your target profession will be in the CAD world or some other CPU/Graphic intense applications, then C++ is at the moment still a winner, for at least the time being. It can also matter a little bit on where you happen to live as technology can vary.
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Blog changed to Subtext!
MS is pushing for dotnet, but they will keep on releasing SDKs like Win32, Win64 (or even Win128). Depends on where you want to be in the herd...
-
There was a time when C++ was the only way to write reall applications for Windows. Now that this is no longer the case, I reckon more and more work will be in C# ( and VB.NET, I admit it ). But, that doesn't mean there aren't C++ projects that need maintenance, teams that stick to c++ because they know it, or because of tools and libraries they have in it, etc. Personally, I'd say if you can learn *anything*, do it. Don't abandon .NET, but certainly take the chance to learn C++. Which in essence means learning MFC, in Windows.
Christian Graus - C++ MVP
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
This is a pointless question. Can't you think for yourself?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
This is a pointless question. Can't you think for yourself?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Not everyone has your wisdom. Would you mind elaborating? Why is it pointless?
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
-
Not everyone has your wisdom. Would you mind elaborating? Why is it pointless?
Anyone that's been programming for any length of time knows damn well that technologies change on an all-too-frequent basis and that the more you know, the more marketable you make yourself for employment. If you are tasked with using a certain technology, then you have to learn the technology at least well enough to complete the task. For instance, I've been doing C++/MFC since 1991 or so. In June, I started working on a .Net project. Guess what - I absolutely hate .Net, but I'm learning it anyway because if I don't, I'll lose my job. You don't need to be a freakin' rocket scientist to put 2 and 2 together here. The original question is therefore pointless.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;
- Games (for speed & cross platform) - Cross platform apps (for Windows / OS X / Linux) - Any application where performance is an issue but those millions of VB apps have definately moved to .NET
Todd Smith
-
- Games (for speed & cross platform) - Cross platform apps (for Windows / OS X / Linux) - Any application where performance is an issue but those millions of VB apps have definately moved to .NET
Todd Smith
Todd Smith wrote:
- Any application where performance is an issue
Supposedly that's no longer the case. I've seen a number of articles where managed code is faster than the equivalent native code. The rationale is that the just-in-time compiler and loader can perform whole-program and load environment optimizations that yield greater performance than is possible with a 'static' compiler and linker. I'm willing to believe it on a case-by-case basis, but I have my doubts under general circumstances.
Software Zen:
delete this;
-
Anyone that's been programming for any length of time knows damn well that technologies change on an all-too-frequent basis and that the more you know, the more marketable you make yourself for employment. If you are tasked with using a certain technology, then you have to learn the technology at least well enough to complete the task. For instance, I've been doing C++/MFC since 1991 or so. In June, I started working on a .Net project. Guess what - I absolutely hate .Net, but I'm learning it anyway because if I don't, I'll lose my job. You don't need to be a freakin' rocket scientist to put 2 and 2 together here. The original question is therefore pointless.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001If you've been programming for a long time you know new things come along a lot, but also some have a tendency to stick around even beyond expectations. Remember how many companies where freaking out at the end of the 90s because they still had systems built in the 60's, when no one was even thinking they'd last up to 2000?
John Simmons / outlaw programmer wrote:
For instance, I've been doing C++/MFC since 1991 or so
Me too!! How nice to meet someone alike. In fact, back in 2002, I rushed in a store to buy Visual Studio.net 2002. And following the "new things always come along", I learned .net. At that time .net jobs were scarce. And even though I have coded in C# for several years, I am now back to C++. So never say never.
John Simmons / outlaw programmer wrote:
You don't need to be a freakin' rocket scientist to put 2 and 2 together here. The original question is therefore pointless.
Well not everyone has many years of experience like you. So don't be so harsh. I have read that long long thread where you seem to be fighting the whole lounge. I have even voted you 5 several times. But damn, I am starting to understand why some wrote you were a little "tough". :)
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++. They will be around for decades to come (eg COBOL programmers are still required). A company which has invested $millions in C++ software development is not going to chuck it all away just because something new has come along. I reckon it's easier to go from C++/MFC to c# than vice versa.
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;
Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
-
Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
While services can be implemented using C# and the .NET framework, they're not generally practical. They're very slow to start and have a huge memory footprint compared to an equivalent C++ service.
Software Zen:
delete this;
-
MS is pushing for dotnet, but they will keep on releasing SDKs like Win32, Win64 (or even Win128). Depends on where you want to be in the herd...
That does not mean there will be a sizable market though..
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Blog changed to Subtext!
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;
- Windows services Many VB programmers were writing true Windows services in VB6. I wrote my first Windows service in VB6 back in 1998. It isn't easy, but it works quite well and is fast. It is much easier to write them in VB.NET and C#.
-
- Windows services Many VB programmers were writing true Windows services in VB6. I wrote my first Windows service in VB6 back in 1998. It isn't easy, but it works quite well and is fast. It is much easier to write them in VB.NET and C#.
I'm going to go against the flow here. While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps. Large categories of apps are going to be on C++ for a long long time. And yes, I know of new apps being written in unmanaged C++. I've been looking at some time critical apps. While I'm skeptical about claims of .NET going faster then well written unmanaged C++ using a good optimizing compiler I'll pass on that because it's not my main concern about .NET My main concerns are these: 1. The garbage collector. If you're doing a little database app (retrieve stuff from the database, display it, let the user edit it, put it back in the database) or something like that it's no big deal. If you're doing a time critical app which CANNOT EVER halt to do GC I'm skeptical. I know there's things you can do with the GC to keep some of it's problems in check, but they seem to me to be overly involved compared to just being able to do delete when need be. You don't need to be an expert on heap management to use delete, you do need to know a lot about the garbage collector to keep it from shooting you in the foot sometimes. Yes I know the C++ heap can become fragmented and the GC can relieve that issue, but it's been my experience that fragmentation is hardly ever a problem, and on those RARE occasions when it is there are ways to relieve it without chucking the whole thing and using a garbage collected language. 2. I have to give up control in the memory representation in .NET which often makes it hard to write good code. C++ lets me specify exactly how an object is handled in memory -- whether on the heap or stack, passed by value or reference, const reference, whatever. With C# several times I have found myself fighting the language just to get it to produce something halfway reasonable. 3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET even if you're writing managed C++, whereas if you stick to ANSI unmanaged C++, portability is often very manageable. Until MS can convince other OSes to use .NET this is going to be a serious problem in some environments. 4. It's been my observation that the problems .NET always trumpets as having solved aren't nearly as bad as they make them out to be and the problems it introduces are, in some situations far more serious. I am quite capable of using delete for example but the loss of control is sometimes nasty. Yes there's many
-
Todd Smith wrote:
- Any application where performance is an issue
Supposedly that's no longer the case. I've seen a number of articles where managed code is faster than the equivalent native code. The rationale is that the just-in-time compiler and loader can perform whole-program and load environment optimizations that yield greater performance than is possible with a 'static' compiler and linker. I'm willing to believe it on a case-by-case basis, but I have my doubts under general circumstances.
Software Zen:
delete this;
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
sorry when i said the algorithm written in vb.net was slower than the built in one i meant it was slower than c++
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;
Windows services can be written using .NET, so you can take those off the list!
'Howard
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
hi Do you have an sample main ? I want to optimize this function. just for fun ... I would like to speed up this code. Long life to C/C++ Fred
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
Hey I think that the C++ will surely exist for couple of years in future as a kind of native language to do some low level development where the run-time efficiency is more important than developing efficiency. But MFC might not be pretty a perfect thing, and I don't think that it is one of the best GUI developing helper amoung varieous kinds of programming language. Cheers one to two, two to three, three to everything