The Redmond, Wash.-based software giant said it is working through ECMA International, the Geneva-based standards organization, to push the development of a standard set of language extensions that will create a binding between the International Standards Organization (ISO) standard C++ programming language and Microsoft’s Common Language Infrastructure (CLI).
Microsoft, ECMA Seek C++ and CLI Binding
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Herb Sutter is on the Standard C++ committee so he is aware of modern C++. If he has his way than it might turn out to be a good product, still though, it’s Microsoft, so nothing matters. SUN should do this with Java though, so that we can use it on Linux.
Ok, so who does this benefit besides Borland and maybe a couple other vendors? It’s one thing to write a c or c# compiler, and a whole other thing writing a c++ compiler. Mono won’t be writing one and either will Pnet. The standard is scheduled to come out late ’04, so even if someone decided to write a back-end to the GNU c++ compiler to produce CIL we might see something in the unix space in around 2007 or so. Does anybody really care enough so that you can have managed c++ on some other platform besides Windows?
Don’t get me wrong. I like .NET, mono, pnet and have sharpdevelop open as I type this, but I just don’t see how this really matters to anyone except maybe Borland.
SUN should do this with Java though, so that we can use it on Linux.
What does that supposed to mean? You can already run java on linux. Geez, some people have nothing better to do with their time except get their panties in a bundle if everything isn’t submitted to a standards body or open sourced.
I think the various pogramming platforms simply cant ignore that the most software currently is written in C++. The possibility to hook C++ and Java is not really satisfactory (for political reasons) and I think thats whats holding it back in many projects.
Same is true for the “free platforms” like python or perl.
“Standards are great. I think everyone should have their own.”
Now Microsoft, submit the remaining parts of the .NET Framework, and really impress me and sign a legally binding pledge that any future .NET Framework enhancements will be submitted to the ECMA standards body.
Why include this in ISO C++?
Why do I need these bindings in *nix? Noone in their right minds would use a microsoft language if offered a choice.
ISO C++ is about compatibility.. not breaking things.
How exactely is this vendor neutral as they claim? Or platform neutral?
Why not just release a library, and leave ISO C++ as it is. Protability from Windows to Linux is bad anyway with all the windows commands people use just because they don’t know there is a standard C++ version.
It sounds like this *won’t* be included in ISO C++.
Instead, consider it to be a new language, “Managed C++”, based on ISO C++ but standardized by ECMA.
Why do we need a “new” language? As the article states, a lot of existing code is written in C++, and one of the design points of ECMA CLI is to permit easy integration/interopation with existing code. Existing C code is easiest to integrate with right now, but there’s no real reason that C++ can’t be used instead. In fact, that’s what Microsofts Managed Extensions to C++ allow.
But why a language, instead of a library? Complexity. (Read the Microsoft Managed Extensions to C++ some time.) The CLI has some language features that C++ doesn’t have, such as properties, events, and explicit interface implementation (which allows separate implementation of interface methods with the same name; C++ has a workaround, but the workaround requires multiple inheritance, and thus won’t permit easy integration with other CLI languages).
Plus, you need ways to specify that some types are value-types, while others are class-types, and the various managed pointer types, and boxing, and…
A library would not be a good fit. A language, with well-defined semantics as to how all of this should be done, and how the features mix with each other, is a better fit.
As for why does *nix need the bindings? Arguably, it doesn’t. How much C++ software have *you* seen on *nix? However, for the people who have existing C++ code, and want to use it without resorting to C wrapper libraries, such as those generated by SWIG or Qtc (the C wrapper for the C++ Qt, which is used by lots of language bindings), a fully-standardized Managed C++ compiler will be a god-send.
Especially with Borland making compilers for *nix. (Or have they stopped that effort? Come to think of it, I haven’t heard about Borlands C++ compiler efforts on Linux in a while…)
How is this vendor neutral? Well, with multiple vendors participating, isn’t it vendor-neutral by definition? (Unless Microsoft strong-arms the others into standardizing it, but I don’t think that’s likely. They want a non-sucky Managed C++ definition; the current one sucks.)
Platform neutrality will require platform support, which may be slow coming (as others have pointed out). But an existing standard is *always* a better starting point than proprietary extensions, which is the only other alternative right now.
It sounds like this *won’t* be included in ISO C++.
Instead, consider it to be a new language, “Managed C++”, based on ISO C++ but standardized by ECMA.
Why do we need a “new” language? As the article states, a lot of existing code is written in C++, and one of the design points of ECMA CLI is to permit easy integration/interopation with existing code. Existing C code is easiest to integrate with right now, but there’s no real reason that C++ can’t be used instead. In fact, that’s what Microsofts Managed Extensions to C++ allow.
But why a language, instead of a library? Complexity. (Read the Microsoft Managed Extensions to C++ some time.) The CLI has some language features that C++ doesn’t have, such as properties, events, and explicit interface implementation (which allows separate implementation of interface methods with the same name; C++ has a workaround, but the workaround requires multiple inheritance, and thus won’t permit easy integration with other CLI languages).
Also, there are lots of cool features that are bought to the table such as garbage collection etc.
There is also myth that circulates that C++ is the “red headed step child” of the .NET family where as Microsoft is trying to say that there is *NOTHING WRONG* with using managed C++ and infact encourages its use over taking the re-write approach some people assume they need to do.
What I would like to see is a greater enthusiasm to embrace the .NET Framework by the ISV community. Realise that if they embrace it NOW they’re going to future proof themselves so that when longhorn does roll around they can say to their customers, “no problems, continue running, it is compatible” rather than having peeved off customers spitting tacks because these companies waited till the last minute.
But of course, I’ll promise you that in 2 years time, when a new .NET based Office (using Managed C++) and Longhorn is released, Microsoft will release a whole new bunch of software, and we’ll see third party developers whinge and whine about the fact that they’re losing marketshare and losing money.
Office took over the market place because it took the various wordprocessor/database/spreadsheet/presentation vendors so bloody long for their Windows versions to come online. When they did come on line, it took them so long to then get their 32bit versions working. Heck, it took Lotus 6 years to get their Lotus Smart Suite 100% win32 compliant. 6 YEARS!
Managed C++ could compile to bye code and be run by a Java interpreter, why not.
Yet standard C++ is too broad of a core language to use with a business framework where the code is managed and the framework itself is only object oriented and not multi-paradigm.
However lets see what they come up with, it doesn’t really matter though, it’s not important.
I think that they are probably targeting Microsoft Win32 developers who don’t want to use .Net. That’s the type of thing that Microsoft should be doing but it really isn’t important in the context of quality software.
Most Win32 developers probably used Win32 because Microsoft didn’t change it every two or three years. That’s not what is going to happen with .Net, they are now changing everything every six months.
No, I have no clue kid, just taking a break.
Most Win32 developers probably used Win32 because it *is the primary API for 32 bit Windows Systems*. It changed and extended at a rapid rate of knots for the 10 years or so of its life, to the point where it is now a bloated and disorganized mass of tens of thousands of APIs, many of which are depracated.
(That’s not to say that most Windows developers are Win32 developers of course. *Most* write to a completely different API – the VB runtime and libraries)
.NET, on the other hand, is extending and advancing in a much more managed fashion. 1.0->1.1 saw several modifications, fixes, and a relatively small number of breaking changes that were pretty much essential for security or future directions. 1.1->Whidbey sees a number of additional changes, and the depracation of some existing APIs. I would say that it was changing at about the same rate as Win32, but with the experience of both Win32 and the 1.0->1.1 changes to build upon. The biggest change will come with the transition to Longhorn, where we see managed APIs become the norm, and the Win32 API greatly rationalized (a transition as significant as Win16->Win32 in the mid 1990s). This sets the platform for the next ten years.
All in all, we saw DOS rule from the late 80s to the early 90s, Win16 transition in until it was superceded about 5 years later by Win32 (with Win32s as the transition technology), which, 7 or 8 years later, is now transitioning to a Longhorn Managed API (with .NET 1.0 / 1.1 as the transition technology).
ISO is supposed to be vendor neutral. That’s what “open” standards are all about. .NET is not vendor neutral, it’s a Microsoft entity and it’s not a global industry standard despite the perception that it is in the United States. Luckily this really affects no one else in the application development industry. C++ developers to a large degree aren’t affected as there is no change in the “real” ISO standard, if you can call it that…
Java, C, PERL, Python, Ruby, Ada, etc etc aren’t affected. There are soooo many choices out there already than cumbersome C++ and more portable than .NET.