C++/CLI Speed Discussion
Author
I read an article that is a couple months old on MSDN.
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/vs05cplus.asp
The guys discusses how C++ will remain a hardcore language in that you will be able to fine tune code, and that the C++ compiler will produce more optimized MSIL code. Also, he details how IJW(It just works) interop technology will help introduce more coders to .NET. Are you guys buying this? I think this whole C++/CLI is leading towards a new kind of language, with it's own specification.
I also think that most new languages will be attached to their own library. It seems like in C++, when porting between Windows, and Linux, and Mac, their is a lot more hassle than in java or something with it's own library.
Quote:Original post by Sagar_Indurkhya
I think this whole C++/CLI is leading towards a new kind of language, with it's own specification.
It already has.
The C++ standard committee is ISO/IEC JTC1/SC22/WG21, the C++/CLI standard committee is ECMA TC39/TG5. While there is a bit of interaction between the two (just as between WG21 and WG14), they are essentially independent entities, dealing with more-or-less independent languages.
Author
Quote:Original post by FrunyQuote:Original post by Sagar_Indurkhya
I think this whole C++/CLI is leading towards a new kind of language, with it's own specification.
It already has.
The C++ standard committee is ISO/IEC JTC1/SC22/WG21, the C++/CLI standard committee is ECMA TC39/TG5. While there is a bit of interaction between the two (just as between WG21 and WG14), they are essentially independent entities, dealing with more-or-less independent languages.
Please don't tell me that we are falling into times with various implementations of different languages. Why couldn't Microsoft just rename C++/CLI into some other name? I was hoping that we would come out with a very solid platform for C++. Sometimes it seems that unless we really need performance, we won't use C++.
Quote:Original post by Sagar_Indurkhya
Sometimes it seems that unless we really need performance, we won't use C++.
It's already true. I, personally, mostly program in Python with some C++ extension routines for performance.
Precisely, I don't like the direction that software development is taking nowadays. Ambiguous standards, new frameworks, automatization...everything appears to be handy, but at what cost?
Heaven forbid we lose the ability to control every memory allocation!
Get over it. I'm sure the programmers of yesteryear were sure that letting compilers allocate registers was the end of the world as well.
Get over it. I'm sure the programmers of yesteryear were sure that letting compilers allocate registers was the end of the world as well.
Quote:Original post by Pse
Precisely, I don't like the direction that software development is taking nowadays. Ambiguous standards, new frameworks, automatization...everything appears to be handy, but at what cost?
Nothing has really changes, the direction of software was always bound by software theory and limited by hardware. Software theory suggests that making analogies with real life (as in Object Oriented Design), and using very high level 'programmable programming languages' allows us to produce high quality code, quickly. On one side of the fence we have languages that allow us to overcome the limitations of hardware, on the other we have languages that allow 100% good code, produced quickly (see C++ vs Common Lisp).
Of course there is also language popularity and interopability but this is just one piece of theory that was too new when Lisp was originally being developed, and as a language hasn't evolved to include it much (although commercial impl. will usually contain some form of forriegn function utility). This is what the modern languages seem to be about, interopability vs inovativeness/power/friendliness. C#/Java/... vs Python/Lisps/Haskel/...
At the end of the day, Lisps and C style languages will completely merge and will most likely include high levels of interopability will evolve. This is where languages are heading, of course things won't get any simpler, it just won't be languages that are the issue of the day (as much anyway). Most likely focus will shift on what utility libraries you use, what platform optimized code you use, intermediate languages and compilation theory...
It's possible, but I disagree. I think there will be a diversification of languages as the understanding of language design concepts becomes more formalised. Then we won't require turing completeness for every language we use if it makes the specific job we are doing easier. Incidentally, Lisps makes this easy. Apart from Bison and Spirit tools, C++ practices aren't really moving into a language-fabrication environment.
This is already the case with most UNIX programmers who use Make to write makefiles, shell scripting languages for shell scripts, sed for making batch changes to files, some other systems language for systems programming, etc. Heck, most people have already learned 'google-fu' whether they realise it or not (or consider it a language).
This is already the case with most UNIX programmers who use Make to write makefiles, shell scripting languages for shell scripts, sed for making batch changes to files, some other systems language for systems programming, etc. Heck, most people have already learned 'google-fu' whether they realise it or not (or consider it a language).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement