Opinions on C++ .NET
-
thanks for the reply it was informative, but i meant more than just the furture of MFC and C++ as a vialble tool. I know that microsoft isnt building longhorn with VB.NET. I mean more of the popularity and use of the language as a whole. Will VC++ become like Win32, one of those nasty areas only Coding Gods frolic in. Will the release of whidbey and longhorn result in a resurecting of VC++. I mean i know we all use it now, but i think VB.net and C# are gaining ground quick. It just seem to me programming is going towards ease of use and not opening up in turns of functionality. The more easier things try to get, the harder it will be to keep C++ around. What a harsh mistress that C++ can be. ;P Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
C++ won't die but, over time, it will get more specialised. It will be confined to tasks such as writing operating systems, games, high-performance computing and so on. But typical business-oriented apps. will be written in more productive languages. C++ will be confined to tasks where nothing else will do - to tasks where, if you can't do it in anything else, you can do it in C++. I think C++ currently has too wide a usage. It is used for tasks where simpler languages suffice. Kevin
-
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
First two paragraphs spot on. Third paragraph is interesting. Kevin
-
thanks for the reply it was informative, but i meant more than just the furture of MFC and C++ as a vialble tool. I know that microsoft isnt building longhorn with VB.NET. I mean more of the popularity and use of the language as a whole. Will VC++ become like Win32, one of those nasty areas only Coding Gods frolic in. Will the release of whidbey and longhorn result in a resurecting of VC++. I mean i know we all use it now, but i think VB.net and C# are gaining ground quick. It just seem to me programming is going towards ease of use and not opening up in turns of functionality. The more easier things try to get, the harder it will be to keep C++ around. What a harsh mistress that C++ can be. ;P Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
JimRivera wrote: I mean more of the popularity and use of the language as a whole. It will become less popular but won't die. JimRivera wrote: It just seem to me programming is going towards ease of use and not opening up in turns of functionality. I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. Kevin
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
looks like lots of good feedback thus far. I guess my only comment is to use the right tool for the right job. As computing grows ever more advanced, so too must the languages grow to higher and higher levels. Like many mentioned, why write a bunch of low-lvl code for win-based gui stuff when you can use newer paradigms. Contrary to that, how on earth would one go about writing an XAML embedded device driver for fiber-optic communications in the saftey-critical flight control software that powers our aircraft industry? ~Nitron.
ññòòïðïðB A
start -
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
Judah Himango wrote: Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? I would challenge this statement all day. Managed languages ( read - those languages that hold the programmer hand so he CAN'T deviate from the approved path ) have no real constructs to handle complex data structures on an easily accessable level. I can use CGI code to process data from a web page(s) written in C or C++ that will be on a level with anything in C# or VB.NET and I can also do things that would be ( Almost )impossible for you to do in those languages. Having said that I do my net programming using C# and Java because the RAD tools are there. However if there is anything complex to do I usually end up writing a unmanaged C++ DLL and pass the info to it ( another bad rap on managed languages is how difficult this can be if using any kind of complex data structures ). I think that the real future will be in light weight smart client style applications and these can be written in C++ easier than with C# or Java. Richard "The man that hath not music in himself and is not moved with concord of sweet sounds is fit for treasons, stratagems and spoils; Let no man trust him." Shakespeare
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
First I would like to thank everybody for there feedback, i get up for a few and then my email gets swapmed lol. I do agree that its easier to produce in .NET (C#, VB.NET) but the way that everything is going is out of wack. Productivity maybe higher in these languages, but try to deviate from there purpose and you will be assimilated. IMHO these languages are not becoming more complex, they are just following the trend. I mean alot of functionality has been added to C# and VB.NET, but i feel mostly just additions to its libraries. MS developers open up more Windows API to these high level languages, the languages themselves are pretty much the same. Besides the tools for RAD, these languages in the end can really hurt the developer and user. To get to this point we are in, it took alot of ingenuity, and .NET takes alot of ingenuity away from programming. I'm just sayiing if it gets too easy, won't we start to get lazy. I think it shows now, as hardware is now moving faster than software. Computers these days are more powerful than the software it runs. I dont mean networks or DB anything Enterprise. I just mean regular applications, even games. Programers used to complain abut the poor hardware and the need for speed. Now we have the speed, and no use for it. I dont know just me rambling thanks for the great opinions everybody has shared. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
JimRivera wrote: I mean more of the popularity and use of the language as a whole. It will become less popular but won't die. JimRivera wrote: It just seem to me programming is going towards ease of use and not opening up in turns of functionality. I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. Kevin
Kevin McFarlane wrote: I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart.
-
Judah Himango wrote: Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? I would challenge this statement all day. Managed languages ( read - those languages that hold the programmer hand so he CAN'T deviate from the approved path ) have no real constructs to handle complex data structures on an easily accessable level. I can use CGI code to process data from a web page(s) written in C or C++ that will be on a level with anything in C# or VB.NET and I can also do things that would be ( Almost )impossible for you to do in those languages. Having said that I do my net programming using C# and Java because the RAD tools are there. However if there is anything complex to do I usually end up writing a unmanaged C++ DLL and pass the info to it ( another bad rap on managed languages is how difficult this can be if using any kind of complex data structures ). I think that the real future will be in light weight smart client style applications and these can be written in C++ easier than with C# or Java. Richard "The man that hath not music in himself and is not moved with concord of sweet sounds is fit for treasons, stratagems and spoils; Let no man trust him." Shakespeare
Richard Stringer wrote: I would challenge this statement all day. Managed languages ( read - those languages that hold the programmer hand so he CAN'T deviate from the approved path ) have no real constructs to handle complex data structures on an easily accessable level. We can deviate from the so-called approved path, it's just not recommened; we can use pointers and direct memory manipulation in C#, use platform invoke, write non-CLS compliant code, and so on. So I don't see C# as a restrictive language...more like a "hey, here's the correct, safe way to do it. It's a bitch to do it another way." :) I guess the point I was making about writing large chunks of MFC, ATL, et al code in C++ applies only to applications on a non-system level. I find C# about 98% sufficient for such tasks (certain tasks like hooking require a dip into P/Invoke or unmanaged code), but for the great majority of the time, the .NET BCL suffices my needs. It is this area in which C++ will no longer be the de facto standard, applications development. The sheer number of lines of code for a typical MFC C++ app compared against that of a typical C# WinForms app, for example, is visible proof of the RAD superiority of managed languages for application development. And again, I'm stressing here that C++ is not going away: low level systems programming, a few performance-intensive applications, and of course maintaining the vast library of billions of lines of existing C/C++ code out there will all require the C and C++ languages. By no means is C++ dying, it's just not the right tool for RAD anymore, and with Longhorn we'll see this come to pass. #include "witty_sig.h"
-
Kevin McFarlane wrote: I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart.
Nemanja Trifunovic wrote: I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
Judah Himango wrote: As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. Thats really interesting. If you have a few links to share I'd to read on that. I think what you're saying is true, but what does this mean to the future of computing. LongHorn looks cool, but it doesnt really sway much from windows does it. If we're just throwing together quick code, who gets to make the "next big thing". Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
C++ won't die but, over time, it will get more specialised. It will be confined to tasks such as writing operating systems, games, high-performance computing and so on. But typical business-oriented apps. will be written in more productive languages. C++ will be confined to tasks where nothing else will do - to tasks where, if you can't do it in anything else, you can do it in C++. I think C++ currently has too wide a usage. It is used for tasks where simpler languages suffice. Kevin
I agree with parts of this statement. At my company we have done an app or two with the .nyet methodology and we have learned enough that we will do everything possible to avoid it in the future. We did not find it to be more productive in the slightest and our quotes in the future will reflect that. __________________________________________ a two cent stamp short of going postal.
-
Kevin McFarlane wrote: I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart.
Nemanja Trifunovic wrote: C++ is more complex and harder to learn than C#/Java/VB, You can say that again! Nemanja Trifunovic wrote: but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. What do you mean by productivity? I mean factors such as speed of development and robustness of application. I am primarily a C++ developer myself. I don't yet have heaps of experience of C#. However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. You also say that "a skilled C++ programmer is often more productive than his C#/Java/VB counterpart." It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. Kevin
-
Nemanja Trifunovic wrote: C++ is more complex and harder to learn than C#/Java/VB, You can say that again! Nemanja Trifunovic wrote: but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. What do you mean by productivity? I mean factors such as speed of development and robustness of application. I am primarily a C++ developer myself. I don't yet have heaps of experience of C#. However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. You also say that "a skilled C++ programmer is often more productive than his C#/Java/VB counterpart." It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. Kevin
Kevin McFarlane wrote: What do you mean by productivity? I mean factors such as speed of development and robustness of application. Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. Kevin McFarlane wrote: However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Anyway, the single most influential factor when it comes to productivity is the process used in an organization, not programming language or tools, or even the skill level of developers. Kevin McFarlane wrote: It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. It is fairly easy to avoid "obscure runtime crashes", memory leaks etc. if you stick to some good development practices. By using well known idioms, such as smart pointers, RAII, Standard containers and algorithms, it is often easier to quickly develop robust applications and libraries with C++ than with some "RAD languages". There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl X| ).
-
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
Where I see the actual growth in C++ use is on the CE platform where speed still matters and in real time programming.
-
Judah Himango wrote: As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. Thats really interesting. If you have a few links to share I'd to read on that. I think what you're saying is true, but what does this mean to the future of computing. LongHorn looks cool, but it doesnt really sway much from windows does it. If we're just throwing together quick code, who gets to make the "next big thing". Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
Check out the PDC slides/video that is available on MSDN. Also, check for websites like www.longhornblogs.com[^], look for articles in MSDN on longhorn, particularly the longhorn development center, which's been around for the past six months or so. Here are some links, http://msdn.microsoft.com/Longhorn/[^]
-
I agree with parts of this statement. At my company we have done an app or two with the .nyet methodology and we have learned enough that we will do everything possible to avoid it in the future. We did not find it to be more productive in the slightest and our quotes in the future will reflect that. __________________________________________ a two cent stamp short of going postal.
Are you guys trying to do some driver development in .net or what, first time I'm hearing someone saying .net is not productive :) I'm sure there are certain set of apps. which are better developed with some low level languages, but for business app development I would certainly think .net is the way to go.
-
Kevin McFarlane wrote: What do you mean by productivity? I mean factors such as speed of development and robustness of application. Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. Kevin McFarlane wrote: However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Anyway, the single most influential factor when it comes to productivity is the process used in an organization, not programming language or tools, or even the skill level of developers. Kevin McFarlane wrote: It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. It is fairly easy to avoid "obscure runtime crashes", memory leaks etc. if you stick to some good development practices. By using well known idioms, such as smart pointers, RAII, Standard containers and algorithms, it is often easier to quickly develop robust applications and libraries with C++ than with some "RAD languages". There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl X| ).
Nemanja Trifunovic wrote: Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. That's surprising. It's not obvious to me what features of C++ would make it easier to maintain than the other languages. Nemanja Trifunovic wrote: Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? One of them doesn't use a Java IDE. Nemanja Trifunovic wrote: IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Yes, you have a point there. But then the languages arn't much use without the libraries. However, I think the complexity of C++ just makes it harder to do things. And it means that the average developer tends to create more havoc than they do in the other languages. That's my experience anyway. C++ can be clear and well-written but it requires a lot of effort. Nemanja Trifunovic wrote: You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. Yes, and the problem is that the average programmer is not disciplined enough. You can get away with this in the other languages but not with C++. One of the major problems with C++ is that too many C++ programmers don't seem to have heard of modern C++. Though this is really a problem with programmers than with C++. However, some of the newer features do appear quite difficult to master. Nemanja Trifunovic wrote: There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl ). Yes, at the end of the day we should use the most appropriate tool for the task in hand, rather than thinking C++ (or .NET, or Java) is the best tool for all situations. I see you hate Perl!:) We have something in common then. I've used to some extent the following languages: C, C++, VB (all variants), Java, JavaScript, C#, Pascal, Fortran, Eiffel, Python and Perl. Perl is the only one I truly hate! Kevin
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
First, if you are talking C#/VB.NET, you are talking .NET frameworks. You will not run C# without .NET, so that isolates the question to .NET programming. Currently in .NET, it is a pain to write code in C++. MS is helping to make life easier in thier next Visual Studio and .NET V2.0 for those that do not wish to move to another language and still use C++. After being a C/C++ programmer for about two decades, it was nice to hear there is still hope for C++ in the .NET world. That said though, I do not expect a large number of developers to be writing .NET applications using C++. The code is more steamline and easier to maintain in the other langauges (read as C# for me ;) ) and spending the extra time to build C++ application on .NET is not worth it for the types of applications you would build with .NET. As for jobs, on Windows based systems, C++ offers will be few and far between. Mainly drivers or games but usually not dealing with .NET. Some will argue, but so far the employment outlook of upper salary positions is the greatest with C#. The main concern is that you know the .NET frameworks, the langauge can be picked up in a few weeks, but the framework is huge! As for productivity, even after about 20 years of C/C++, I can build more robust stable applications in .NET/C# than I would have built in C++/MFC/Win32 and do that in a fraction of the time. Maintaining code is better and debugging is reduced to practically nothing. Anyway, the main question is your target. If you are looking into the crystal ball for C++, it will probably be Linux/Unix, or device drivers, games and CAD for Windows. If I were a new programmer coming into the field and desired a MS platform, I would be C#/.NET in a heart beat and never look back! Rocky <>< www.HintsAndTips.com www.GotTheAnswerToSpam.com