DSPRelated.com
Forums

OT: Is C++ doomed?

Started by HardySpicer December 10, 2007
I have been reading that the .Net languages are taking over and that
c# will be the future if youcurrently program in c or c++. The reason?
Development time is too long in c++. What is to be gained by a
language that few can program effectively in? The nice thing of course
is that all the visual .Net  languages are compatable with one another
and they is easy to translate.



Hardy
HardySpicer wrote:
> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++. What is to be gained by a > language that few can program effectively in? The nice thing of course > is that all the visual .Net languages are compatable with one another > and they is easy to translate. > > > > Hardy
C# isn't that much different from C++ Or at least, the features I commonly use in C++ are mostly still there. Fortunately horrible things like multiple inheritance aren't. But then again, I'm still getting to grips with Visual C# so I may well find some problems. -- Dirk http://www.transcendence.me.uk/ - Transcendence UK Remote Viewing classes in London
HardySpicer <gyansorova@gmail.com> writes:

> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++.
There's nothing wrong with C++. There's a lot wrong with most software developers' design methodologies (i.e., there is none, or what there is is pitiful) and that in turn gets blamed on C++.
> What is to be gained by a > language that few can program effectively in? The nice thing of course > is that all the visual .Net languages are compatable with one another > and they is easy to translate.
I sure hope C++ stays around indefinitely, at least until something better, and not least importantly, platform-independent (C# and .net are obviously Microsnot-centric) comes along. -- % Randy Yates % "She tells me that she likes me very much, %% Fuquay-Varina, NC % but when I try to touch, she makes it %%% 919-577-9882 % all too clear." %%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO http://www.digitalsignallabs.com
Hi

HardySpicer schrieb:
> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason?
well, many things are written. Some authors write their opinion, others their wishes and others that what they are told.
> Development time is too long in c++. What is to be gained by a > language that few can program effectively in?
Most important is that there are enough people around that roughly caught the idea of the language and the environment. The older a language gets the more complexity it offers. And once in a while there comes a new guy that only understands half of the complex language. He tells us that his new language is only as half as complex and makes everything easier. And then the cycle starts anew. Of course, the new languages do not share all the dark sides of the older ones, and so there is still some development with time. Look at Java and .NET. They introduced generics some time ago. And the complexity came. Still they are far behind the todays features of C++. In my oppinion C++ is still one of the best languages around. It enables you to write abstract solutions with data separated from the generic algorithms. You can choose your memory management. You can program close to your hardware while still having the type safety of the high level language in most parts of your code. If you know what you are doing you can write programs with very low runtime overhead without to pass on modern OOP features. Here we are in a dsp group. Garbage collecting languages like Java/.NET are completely out of place there, if you ask me.
> The nice thing of course > is that all the visual .Net languages are compatable with one another > and they is easy to translate.
That is no practical advantage from my point of view. Its only nice for presentation sessions. Learning a new language takes an experienced programmer about one or two weeks at most. But learning a new environment or new programming techniques will take moths or even years. Furthermore automatic transcoding is available for much more than only .NET languages. Unfortunately that ends if threads are taken into account. As far as I know the required theory is not yet completely understood for multithreaded applications. But this may have changed in the last years. Marcel
Hi Hardy,

> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++.
There is some truth in it. C# development time is shorter for sure, No c++ programmer should argue againt that unless he had his share of C# coding. It's a language where it's much easier/faster to get things done and you have way much ways to shoot yourself into the foot. Besides that, all managed languages have one thing built in that touches my main research interest: Dynamic Code Generation. The java-guys tell us for years that code written in a bytecode language could - with proper support of a jit-compiler - adapt to the parameters, ranges, datatypes, use-cases ect and compile specialized routines for our worhorse functions. This is true in principle, but unfortunately the practice has not happend yet. There is *lots* of potential out there, The managed programming language guys just haven't had the time or dediation to explore it. I do dynamic code generation on the C64+ DSP. Not to satisfy my low-level asm-coder soul but just for performance reasons. I've written a graphics library for the DaVinci Platform, and 95% of the time is spent in a single function where 99% of all if-calls are constant across the call and won't ever change. I cannot make any assumptions which branches are affected and which not. Dymamic code genration is - as far as I know - the only way to get out of my dilemma. I could precompile all possile variants of routines, but that would take nearly half a year with the code composer studio on a compiler farm. And even then: Where should I store all of that compiled code? A DVD will be way to small. Having a JIT built into the language would be a *great* help. I would have much more time to spend on high level things than to worry and optimize my humble SSA to machine-code compiler. Otoh writing JIT-engines and getting as low level as a human can get is exactly my thing. The uglier the guts of a platform is, and the more arcane the CPU and DMA and DSP work together, the more I feel at home. I like to push things to their limits, Back to the topic: The .NET languages aren't that non-portable as it seems. You only have to write a virtual machine to execute them and it will *just* work on your machine. It's work for sure to migrate the stuff to a new platform, but it's doable, and there aren't that many platforms out there. Do it for ARM, MIPS and maybe SH, and you would cover 95% of what's out there. Regards, Nils Pipenbrinck <-- who should write an official introduction of myself for this group one day.
Nils <n.pipenbrinck@cubic.org> writes:
> [...] > C# development time is shorter for sure,
Why? Be specific, and avoid terminology that was invented only in the last 5 years. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://www.digitalsignallabs.com
Randy Yates wrote:
> Nils <n.pipenbrinck@cubic.org> writes: >> [...] >> C# development time is shorter for sure, > > Why? Be specific, and avoid terminology that was invented only in the > last 5 years.
Or by the marketing department. jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
On Mon, 10 Dec 2007 10:25:20 -0800, HardySpicer wrote:

> I have been reading that the .Net languages are taking over and that c# > will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++. What is to be gained by a language > that few can program effectively in? The nice thing of course is that > all the visual .Net languages are compatable with one another and they > is easy to translate. > > > > Hardy
Happiness means being able to buy all the column space in as many trade rags as you want. Microsoft is happy. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
On. Dec 10, 12:25 pm, HardySpicer <gyansor...@gmail.com> wrote:
> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++. What is to be gained by a > language that few can program effectively in? The nice thing of course > is that all the visual .Net languages are compatable with one another > and they is easy to translate. > > Hardy
C didn't displace assembly. C++ didn't displace C. Java or C# will not displace the lower level languages. Each language has its place. Many DSPers are still producing hand-crafted, tight assembly code and will continue to do so. I think faster processors will result in greater use of the higher level languages but the lower level ones will still be used. See the following link for a popularity ranking of the languages. I can't vouch for it's accuracy, but it squares with my experience. http://www.tiobe.com/tpci.htm Darol Klawetter
On 10 Des, 19:25, HardySpicer <gyansor...@gmail.com> wrote:
> I have been reading that the .Net languages are taking over and that > c# will be the future if youcurrently program in c or c++. The reason? > Development time is too long in c++.
Where I work processing time is the second most important success measure (the first being acceptable results). Last week I found that a processing bottleneck could be eliminated by switching file formats. That alone would shave 4 hours of the processing pipeline per 24 hr survey. Four months ago I did something similar, shaving 4 hrs off the final data checking procedure; now final checks take 1 hr, not 5. Per 6 hr survey. In short, your poor programming could put me out of business. I don't care how long you take to get there, but I want programs which actually help me as a user do my job. If you as a programmer rush your delivery, chances are that your program is of no help, maybe even a liability.
> What is to be gained by a > language that few can program effectively in? The nice thing of course > is that all the visual .Net languages are compatable with one another > and they is easy to translate.
Ever tried to translate one of those to a 1000+ node linux cluster? Well, me neither. But some of the people I've worked for use thise sorts of beasts routinely. If you want to play with those guys, make sure your program is both efficient and portable between platforms. Rune