Slashdot Mirror
Microsoft's C++/CLI Spec Has an Identity Crisis
Andy Updegrove writes "Microsoft's submission of its XML Reference Schema to Ecma has gotten lots of attention in recent months, because Microsoft offered it to Ecma to try to neutralize Massachusetts' adoption of the OpenDocument Format (ODF) standard. But last week it's earlier submission of C++/CLI to Ecma was in the limelight when the U.K. representatives to ISO cried foul over (of all things) its name, which they said was confusingly, and inappropriately, similar to C++. Some think that there may be more afoot, including the potential for Microsoft to add proprietary extensions after ISO finally adopts the new standard under a different name. Either way, the C++/CLI experience represents an interesting dry run for what to expect as Microsoft pushes the XML Reference Schema throught the same process."
C++ Continues Linux's Invasion
651 (DCLI)
C++ Command Line Interface
The name, as submitted, is a sufficient train-wreck that people savvy enough to know a compile shan't confuse it with something they want. Possibly it will appeal to the PHB audience.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
..as Microsoft pushes the XML Reference Schema throught the same process.
thought + through = throught != a well perused article summary.
This doesn't seem to be anything more than someone who's got his panties in a bunch about Microsoft and is creaming between his thighs about the chance to stick it to the Man.
.Net architecture. It's not a huge departure from the core language by any means, at least not enough of one to require a complete name change.
.Net, etc) and on the other hand you've got a group who is relatively unwilling to give Microsoft the time of day.
C++/CLI seems to be a (standardized) proprietary extension to the C++ language that allows it to interface well with the rest of the
On the one hand, you've got Microsoft who is willing to label various related products under one brand (Windows,
I'm not saying that ISO's wrong, but they could certainly stand to pull that rod out of their collective asses.
I thought C++ programs by default were CLI (as opposed to GUI).
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
BadAnalogyGuy
:)
"This doesn't seem to be anything more than someone who's got his panties in a bunch about Microsoft"
I actually think that's a pretty good analogy
I actually think that's a pretty good analogy
Dammit!
C++/CLI seems to be a (standardized) proprietary extension to the C++ language that allows it to interface well with the rest of the .Net architecture. It's not a huge departure from the core language by any means, at least not enough of one to require a complete name change.
Compilers have no sense of humour. If a language is not ISO C++, it is not C++ and should not have C++ as part of the name. I'm dating myself, but I've worked with "FORTRAN" compilers that didn't support FORTRAN 77 (which was the standard at the time) and to all intents and purposes they were not FORTRAN compilers--they were "some proprietary FORTRAN-like-language compilers" and completely useless if you wanted to compile many perfectly ordinary FORTRAN programmes.
The issue here is that the use of the C++ name is a big marketing issue. But to apply the C++ name in any variant to a language that is not C++ is fundamentally misleading and dishonest. This is because humans are lazy and stupid, and tend to drop the modifier and think of "C++/CLI" as simple "C++"--the article points out that MS documentation has many examples of code samples labelled "C++" with no "CLI" modifier that are not, in fact, C++. They are C++/CLI.
And as I said, compilers have no sense of humour--they don't care that "C++/CLI" is "almost" C++. They see non-standard syntax and barf. So it is very important for those of us who want our code to compile and who want to be able to communicate with others to keep the name "C++" as pure as possible. This isn't being uptight--it is a purely pragmatic concern about keeping marketing droids as far from technology as possible so that software professionals can communicate with each other as clearly and unambigously as possible given the limitations we all have as human beings.
Blasphemy is a human right. Blasphemophobia kills.
Just name it --C/CLI :)
DYWYPI?
The issue here is that the use of the C++ name is a big marketing issue. But to apply the C++ name in any variant to a language that is not C++ is fundamentally misleading and dishonest.
The same argument could have been advanced against the name C++ itself: "The issue here is that the use of the C name is a big marketing issue. But to apply the C name in any variant to a language that is not C is fundamentally misleading and dishonest." Along these lines, I don't see anything wrong with something like "C++ Extensions for CLI" so long as the name makes it clear that it's an extension to C++98 and/or C++0x.
But the problem is that MS has taken to calling it.. C++. We already have a C++. If you look at MSDN they have C++.Net code all over the place, but they never call it that. They always call it C++. They make a C++.Net complier, but they just call it C++. From what I've read, they seem to be almost purposely trying to confuse the difference between C++ and C++.Net.
The worry seems to be that if this standard is ratified, MS will continue this practice. One can argue they have done this in the past, trying to confuse J++ and Java (J++ being their "version" of Java). While this all does seem a bit nit-picky, I think it is important.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
By that logic, C++ should not have C in its name.
C++/CLI is C++ with additional extensions for the Common Language Infrastructure. I believe it's actually a strict superset of C++, unlike C++ vs. C.
The argument for c++ and C is that you can create your own libraries for it if the default ones dont suite your needs.
Does c++.net run ansi c++ code? Then its C++
http://saveie6.com/
ANSI C/C++; If your a .Net developer, don't use Microsoft C++ extensions/managed VM, But of course most c/c++ programmers know that already. Microsoft could/should call thier .Net VS5 hybrids something else besides C++. I'm suprised Bjarne Stroustrup hasn't said anything yet.
Enjoy,
It's just the normal noises in here.
I expect they'll do everything they can to benefit themselves exclusively and screw everyone else subtley. Or blatantly.
Perhaps that's why open-source and community projects will ultimately win (provided Microsoft doesn't succeed in making such software wholly illegal): the community efforts are about making everyone win.
--
Don't like it? Respond with words, not karma.
Congratulations. You just argued that most "English" speakers are not in fact speaking English, but something that sounds very much like English; of course, it's important not to confuse the two, because one is English, and one is not. You just argued that most "Spanish" speakers are not in fact speaking Spanish, but something that sounds very much like Spanish; of course it's important not to confuse the two, because one is Spanish, and one is not. Etc., etc.
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
The prominent C++ expert Herb Sutter is the lead architect of C++/CLI.
He also chair the ISO C++ standards committee.
The Brits are concerned that if MS can't even keep the name straight, what's the chance of everyone else doing so. The end result will be programs that claim to be C++ programs that won't compile without MS.
-- Don't Tase me, bro!
(And some opinions too; I'll leave you to work out which are facts and which are opinions.)
It's the UK's panel that has submitted this paper to ISO; the UK panel is part of BSI, the British Standards Institute, one of the NB's (National Bodies) making up ISO.
The biggest problem is that ISO should not publish two standards which are for such different languages with such similar names, and encourage the confusion. Standards are there to reduce confusion, not to contribute to it.
And make no mistake, C++/CLI is a huge departure from the core language. It introduces a whole new type of pointer, it adds generics to C++ templates, it abandons const-correctness for core using "ref" classes, it has yet another string type (this time somewhat integrated into the language rather than being a pure library entity), it adds mandatory garbage collection (C++ has always permitted, but not required, GC, though with some caveats) in a way not consistent with previous work with GC in C++, and there's more I'm sure.
It's also a concern that C++ may wish to expand into areas overlapping with those that are covered by Microsoft's language "C++/CLI", and may not wish to do so in the same way as C++/CLI, which is mostly just one of a pile of vendor-specific extensions to C++.
ISO is about standardizing existing practice. Some of the biggest problems with existing C++ and C standards has been when they got too inventive, and accepted into the standards things that were implemented in few (or no) compilers. So far as I know, there's still only one compiler that supports C++/CLI (though I've a feeling one other company is working on one).
Microsoft and the ISO C++ groups have been getting along a lot better in the last few years; Microsoft returned to attending committee meetings, and hired some great people, both names that get publicity and some that don't. However, Microsoft is still a large company with a monopoly in certain areas, and some history of anticompetitive practices, and it seems sensible for us to tread carefully.
C++/CLI is, in fact, a strict superset of C++. Any C++ code that compiles without the /clr flag should compile without any complaints with the /clr flag. Linking, however, is another story. Because the result of a /clr linking is different than a native linking, there is no guarentee that C++ code will link correctly.
.NET brand) IS STILL C++
"Managed C++" or "C++ with Managed Extensions" or "C++/CLI" or "C++.net" or whatever you want to call it (Microsoft has done a very poor naming job with the entire
http://brandonbloom.name
Generally, bash is superior to python in those environments where python is not installed.
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
.NET technologies, then C++/CLI is perfect. Any C++ coder worth anything will know that the term "C++" by itself does not fully describe a C++ project's language.
What a load of crap.
C++ was well established on all major platform long before ISO standardized it. I know I've written my share of #ifdef/#define's to make code more portable between IRIX and othe *nix variants in my 15 plus years of C++ coding.
If you want to write a (mostly)cross-platform C++ program then use ISO C++. But if you want to reuse your C++ code and integrate it with newer
Stroustrup's comment. Apparently Microsoft is revising their documentation to clear up the confusion.
All C++ code compiles cleanly in C++/CLI. C++/CLI is a set of (fairly radical) language extensions and modifications that allow interop with managed code.
One can argue they have done this in the past, trying to confuse J++ and Java (J++ being their "version" of Java).
Yes, but:
1) J++ was being pitched as a VB replacement, at a much lower programmer education level
2) Java was relatively new, the standard wasn't widely known.
I guess I'm having trouble believing that C++ programmers would be confused by this.
Whenever I hear the word 'Innovation', I reach for my pistol.
There are in fact different variants of English such as British English and American English. Another example is also European Portuguese and Brazilian Portuguese.
There are special cases of the English language like RFC documents and legal documents where certain words like "must", "should", etc have very specific meanings. That is necessary so that the documents will have the exact same meaning to different people. In contrast poetry has no such regulations. C++ is not poetry though, and it has strict standards so that all compilers (which are written to that standard) will be able to compile it.
Having a dialect of C++ which is not really C++ and cannot be compiled by the standard compilers breaks the standard.
So, I take it you're vehemently against EC++ as well?
You can't be too happy with those Boost guys, either, tampering with the purity of ISO C++ by adding library features.
I'm dating myself
Well at least someone on Slashdot is dating someone.
Bahduh-ching!
"C++/CLI is, in fact, a strict superset of C++."
Have you ever used a microsoft C++ compiler, and compared to a good one?!?! What I mean to say is, C++/CLI is a strict superset of the C++ features which microsofts compilers happen to support. A lot of strict C++ will make MS Compiler poo errors all day.
The problem with your arguement is that the parts where they call C++/CLI C++ is when dealing with .Net code. In those places using ISO C++ isn't an option because it doesn't use the CLI and doesn't support .Net.
So you're trying to claim that MS are like the programming world's equivalent of Noah Webster?
You're dating yourself?
Well, congrats and all, but maybe if you realize that Fortran is such an obstacle to meeting women, take a break once in a while.
I'm dating myself
Yes... most of us call that "single".
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Have you used Visual Studio ever? Since VC7.1, Microsoft has had the most standards compliant compiler. Period. Sorry to burst your bubble.
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
So I guess there weren't any C++ compilers between 1997 when the language was standardised and some time around 2001 when the compiler vendors started catching up with the features that had been included in the spec?
Perhaps my copy of Borland C++ 4.5 from ~1994 isn't a C++ compiler at all, because the language hadn't been standardised when it was written?
Here's a clue for you: in the real world, we call a compiler a C++ compiler if it compiles C++ code. It doesn't have to compile *all* C++ code for this to be true, just a useful subset. If it complies with the spec, so much the better. These we'll call ISO C++ compilers if we're in the mood to distinguish between them.
The same happened with C when it was first standardised. The standard described a language substantially different from what older compilers understood and compiled, but those compilers didn't cease being C compilers just because they couldn't compile all the code that the spec said complying compilers had to. They just weren't ANSI C compilers.
For example, Qt introduces signals and slots as an extension, but the same effect can be achieved with libsigc++ or boost::signals, making intelligent use of the template system. Smart pointers and garbage collection have been demonstrated by boost::shared_ptr and so on.
I understand that in the past weaknesses in implementations of C++ made some of these extensions necessary, but now that we have compliant compilers that actually implement almost all of the language standard, there are less and less reasons to create proprietary extensions to it.
Odds are the overlap is probably on purpose. Here's a sample:
Someone familiar with the special terms MS uses could probably dig up plenty more.
Want to mess with the search results? Simply put links on some of your pages to the non-MS definition.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
to spread confusion and to try and manipulate that confusion to their advantage.
As long as you clicked lots of options to make it behave somewhat sanely. Scoping by default has always been a little loose when I've used VC++ such that:
for (int i...)
for (int i...)
certainly always used to not compile with the default settings, as it claimed that the 'i' variables clashed, and resulted in lots of code being written like:
for (int i=...)
for (i=...)
jh
The difference between the cases you all made is simple:
0. C++ (at one time, at least) EXTENDS C
1. moc/Qt EXTENDS C++
2. C++Builder "properties" and VCL EXTENDS C++
but
2. C++/CLI LIMITS C++ (no multiple inheritance, no metaprogramming, etc etc) -- more than it extends it (.net class libraries)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
ncluding the potential for Microsoft to add proprietary extensions after ISO finally adopts the new standard under a different name.
I fully expect them to "add proprietary extension". Why shouldn't they? Almost every language in existence has had "proprietary extensions" added to it after its standardization. That's a good thing. It's the way languages evolve. Eventually, some of those proprietary extensions themselves become standardized.
Even when Microsoft is the company doing the extending, it doesn't seem to matter; all those proprietary extensions Microsoft has added to C and C++ haven't hurt C or C++ one bit.
The notion that there is a single, enforceable standard that everybody adheres to is some bizarre, self-serving meme created by Sun (made even worse by the fact that Sun's so-called "standard" is actually a proprietary system whose actual behavior is defined by Sun's proprietary implementation).
The only question that hovers over the ECMA CLI-related standards is whether Microsoft can later assert proprietary rights (mostly patents) against implementors of the standards. I think there is still a theoretical possibility, but from my point of view, it's not serious enough to worry about. If someone comes up with a decent alternative to C# that's not linked to either Microsoft or Sun, I'll consider it, though.
5 You try to compile, and it fails horribly.
.so and it fails horribly. Gosh, imagine a C++ lib not being C++ in that case.
6 After some time spent debugging,
And now, back in reality:
5. You try to compile and it fails.
6. You spend seconds looking at the compiler errors and realise this isn't the C++ you know.
You could say the same about any library. eg. I get a linux C++ lib, compile it, link against the
Or, if you have the source code (and not a library), you get a C++ lib, compile it and it fails.. because it contains (say) Linux signal handling code that Windows doesn't understand. Gosh!
You may get really pissed off but I hope you're only being annoyed at your own incompetence.
Maybe they should do the symmetric process to Visual J++ and call it Cava!
Since VC7.1, Microsoft has had the most standards compliant compiler.
So when Herb Sutter posted:
"Microsoft and Gnu have both greatly improved in recent years and are both ship current compilers that are around 98-99%... conformance as measured by the major commercial test suites, which is pretty good -- good enough to build Boost and Loki without workarounds -- but EDG is the only "100% conformance" champ."
he was wrong?
There was precisely one option for that specific behaviour (I think it being not enabled had to do with the fact that many MFC headers relied on it not being there). Furthermore, it is turned on by default in VC++ 2005.
Compilers have no sense of humour. If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
Yea, good luck with that line of reasoning. Have you seen Microsoft's "Visual C++"? Compare and contrast with the real C++, as defined by ISO, and you'll be shocked.
You're missing the point. The fact that standard C++ code can be compiled with the Microsoft compiler isn't contested. The problem is that Microsoft is presenting its version as if it were C++. That means anyone coming to C++/CLI and writing code in the style advocated by Microsoft will not be producing code that can be compiled by any other C++ compiler, though they might not understand this. That is disingenuous, and will damage those who are misled by locking them into the Microsoft platform.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
> Does c++.net run ansi c++ code? Then its C++
Long answer: NO. C++/CLI does not have multiple inheritance; it does have generics, which are templates without the metaprogramming possibilities -- because it does not have templates. Henceforth, the STL does not work under C++/CLI. Nor does Boost.
It does have annotations on classes and methods, reference/value class dichotomy, garbage collection built-in (as opposed to library-based), finalizers (one strange kind of destructor), its generics have type restrictions (like the new templates planned for C++0x -- of which I'm not a big fan)
It's as different from C++ as is C# or Java, really.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
The first C++ compiler I used was a pre-preprocessor. It scanned the C++ code, spat out C, and ran the C compiler on it.
Pavlov wouldn't be so famous if he'd used a can opener instead of a bell.
EDG is the only compiler to support the export keyword on templates, which allows the template definition to be separated from their declarations. It is a feature that is really complicated to implement and that does not seem to worth it.
I think that is what Mr Sutter meant when he said that EDG based compilers were the only 100% compliant compiler. More information is available on http://www.gotw.ca/publications/mill24.htm.
C++/CLI cannot compile ISO C++. You can mix both languages in the same project but the languages are radically different. See my other posts.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I think this naming scheme is bad for the C++ community as a whole because it creates the impression that code created using C++/CLI will be portable to other platforms and compilers. Of course, this is not true because after the initial programmer creates the "innovative' program using generics and managed pointers, the maintance programmer after him will find it impossible to port the code over to another platform without majorly refactoring the code.
.Net on his resume to recieve that 50% pay raise. Everyone else loses.
Of course the initial programmer will love to use C++/CLI because it looks good on his resume and he can get a 50% pay raise when he jumps over to another job. The PHB loves it because he looks like he's using cutting edge technology to solve the company's problems. He too gets to put
Personally, I consider g++ to be the standard and I highly disrepect other compilers which can handle code valid for g++. Of course VC++ will be able to compile g++ code but the reverse is hardly ever true. (3.4.4 has been good, Im hoping 4.0.x will be better...)
Cheers,
Ben
C++/CLI is no more C++ than C# or Java or J++ or D.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
No, it's not quite a strict superset.
Some examples of backward incompatibilities:
C++/CLI introduces some new keywords (therefore no longer available as identifiers), like "nullptr". The comma operator can have a different meaning in some contexts. And there may be other such differences.
If C++/CLI were a subset of C++, even an improper one, that would be good and useful, as you could then feed C++/CLI into a C++ compiler and watch it work.
The example from the article backs this up:
Documentation for Microsoft's Visual C++ product contains many code examples identified as "C++" -- not "C++/CLI" or even "C++.Net" -- which will fail to compile in a Standard C++ environment.
See? That it's not-a-subset is the problem.
Whether C++/CLI is a superset of C++ is totally irrelevant.
Isn't javascript just as guilty or even worse?
There must be tons of PHBs who lump java and javascript together and make many stupid decisions as a result.
I don't think there is a software developer in the entire world that could possibly make that mistake as you describe it.
.NET extensions. It's not like a C++ developer is going to sit down, accidentally type "ref class" and create non-standard C++ code.
.net framework requiring application without being aware of it.
In order to use any of the Microsoft specific functionality of C++/CLI (and hence be locked in to MS playforms), you are going to realize that they are
You are going to have a major deploy problem on your hands reguarding the WINDOWS platform if you write a
If a software engineer doesn't understand this, they are doomed to failure anyway. This is not "missleading" or "disingenuous" action on Microsoft's part. You are worring about DUMB ASS DEVELOPERS. And as many dumb ass developers as there are, I am pretty convinced that there are none dumb enough to look up and learn about managed extensions without realizing they are dependant on Microsoft.NET
http://brandonbloom.name
Actually if you use any of the more powerful aspects of C++ you'll know that no, C++.net is *not* C++. For instance, as far as I know, C++.net only supports single inheritance whereas C++ supports multiple inheritance.
The biggest problem, though, is the inclusion of the garbage collector. Because of this there is the introduced semantic of "finalizing" an object which is very different from the default C++ behavior. Many C++ programmers rely on what is called "guaranteed destruction semantics." What this means is that the moment an object goes out of scope or is deleted with the delete operator, we are guaranteed that the destructor is called and the object is destroyed. In C++.net, the object may or may not be destroyed when you think it is. This seems like a minor thing, but in reality it can be quite major. This introduces subtle changes in a program's behavior. Sure these things can be programmed around in C++.net, but that is just one more evidence that C++.net is *not* C++.
Now it is possible that all of these issues have been addressed. If so, then C++.net is just a C++ compiler that targets the MS virtual machine. But this didn't appear to be the case when I last examined the issue. If this remains unsolved, I can only imagine the chaos that would ensue when clueless end-users (programmers) try to build some hunk of C++ code written by a professional C++ developer and have it compile, but behave incorrectly. Definitely not a desired situation for C++ developers of code that is to be used by others.
It's all very well to get on the standards purity high-horse, but in the entire history of ANSI and ISO language standards, how many translators (compilers, interpreters, or in-between) have been 100% compliant to a standard? That is, they implement every feature of the standard, with no extensions at all?
I don't have any statistics, but I can think of ... well, none. Hm. Whaddya know?
Please don't interpret this as a defense of Microsoft in this instance. I think that something like "CLI extensions to C++" would be a better name, putting the environment (CLI) ahead of the language (C++), because that is obviously consistent with Microsoft's policy.
So, if a translator is not 100% compliant with standard Foo, is it not a Foo translator? At what percentage of compliance should it be called a "some proprietary Foo-like language" translator? And how do you measure that percentage?
What about inconsistencies, irregularities, and vagueness in the standard? What about behaviors that the standard leaves as explicitly implementation-dependent? How do you measure those?
Standards are generally good, but don't confuse them with Scripture. Their purpose is to make it easier to do good work, not to define the One True Way of Programming Holiness.
Oh, PS: I tried dating myself. I found that it is much more fulfilling to date another person. :-)
I had forgotten how much cooler teenagers look when they are smoking. Oh, wait
You're still missing my point. You fundamentally assume that all developers are aware of portability issues, standardisation issues, the technical details of exactly what is and what isn't in ISO C++, the nature of Microsoft's .Net platform and the C++/CLI language, and so on.
Take a look at any C++ newsgroup, preferably one of the unmoderated ones with a lot of newbies asking for help. Observe their level of understanding (or otherwise) of exactly how even standard C++ works. They frequently don't "get" concepts like undefined behaviour, compiler extensions, and standard vs. non-standard libraries. A huge number of the problems posted on such groups come directly from making that sort of mistake; some groups have dozens of examples every week. Some people will even aggressively defend their misconceptions, telling other (correct) posters that they don't know what they're talking about because "it works on my compiler". This has been happening with GCC extensions for years, and it's already happening with Microsoft extensions as well.
So yes, I'm completely convinced that there are huge numbers of new and inexperienced programmers out there who really won't appreciate the significance of tying themselves into Microsoft's platform. Moreover, it is naive to pretend that Microsoft doesn't know this very well. Their whole marketing strategy, which the BSI guys are rightly challenging, seems to be based on creating this ambiguity in people's minds. I've mentioned the "Pure C++" column and random blog post misterminology elsewhere in this thread. There are simpler things too, like highlighting C++/CLI reserved words even when you're editing native C++ code in the IDE, as if they were a part of standard C++, and including C++/CLI and .Net material prominently in help pages even when nothing implying this platform is selected in the filters.
I'm no arbitrary MS-basher -- go ahead and check my previous posts, and you'll find sometimes I support them and others I don't -- but in this case, I think they have a blatant strategy for trying to abuse the system, and it's quite right that those responsible for maintaining that system call them on it. If they had tried this with any well-known language with a major commercial backer, they would have been sued into oblivion by now, probably with a court order not only preventing standardisation under their derivative name but also preventing them from even marketing their own product with it.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
>> Henceforth, the STL does not work under C++/CLI. Nor does Boost.
> That's a different matter, as implementations often need to use compiler-specific tricks.
Nope. Both the STL (as in STLport) and Boost will do fine in any ISO-compliant compiler without resorting to compiler-specific wizardry.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Allow me to rephrase that:
Yes... most of us are "single".
This is Slashdot, after all.
"If a compiler will compile all ANSI C code, is it a C compiler?"
I do not have the ANSI C standard at hand, but I expect that it has at least one paragraph where it proscribes that the language must issue a warning or error when encountering certain non-ANSI C constructs.
A compiler that does not generate those warning or error messages (possibly even accepting it as valid) on that code is not an ANSI C compiler.
By that logic, does the perl-to-C processor mean that perl is C too?
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
I see it as an improvement of Managed C++
PHB may be confused, but that's neither here nor there :)
If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.
.Net code is easier. Honestly, I don't see the problem with that.
Um, is the point of what MS is doing is to add the C++/CLI as PART of the ansi standard? That is, they are trying to extend the standard so that calls to
Doesn't part of ANSI C support extensions that can interact with assembly language?
You download it, figure out the API (i.e. look at documentation, not the code itself, so you don't see the weird syntax), and integrate calls to it into your code.
.Net framework SDK. So I certainly hope that you'd know that you were using a .Net feature.
Um, downloading it would probably be downloading the
Mail? Put "slashdot" in the subject to pass the spam filters.
If someone says "Pascal", I know they can mean any of a dozen vendor-specific dialects. I expect and accept that. Same thing with many other languages from that era.
C++ on the other hand was standardized at some point. All compiler vendors worked in the same direction. C++ programmers have gotten used to the idea that there is one standard. We expect to be able to talk to other people about C++ and agree on what language we mean.
Then Microsoft comes along with a C++-based language which adds an important new object model, new operators and all, and refer to it sometimes as C++/CLI, sometimes vaguely as C++. Of course we are pissed. Of course we see this as a threat to the C++ community.
Or at least do. But my point is, it depends on the language. If I was a Pascal programmer I wouldn't feel as threatened. In the case of C, I believe the competition between C89 and C99 has been harmful to the C programmers out there -- and yet C99 brings useful features for everyone, not just for some people whose target happens to be some specific virtual machine.
For instance, as far as I know, C++.net only supports single inheritance whereas C++ supports multiple inheritance.
I think you're right; however, the reason for that is the the CLR itself only supports single inheritance (except for interface inheritance). Which is a good thing. I've been using C++ for 13 years and I have needed multiple inheritance exactly once (except for, as I said, when implementing interfaces). And it was a problem that could have been worked around in other ways anyway.
In C++.net, the object may or may not be destroyed when you think it is. This seems like a minor thing, but in reality it can be quite major. This introduces subtle changes in a program's behavior.
No it doesn't. new and delete are still there, and they still work the same way. It's only when you use managed objects that the garbage collector comes into play, and that's not going to cause problems for pre-existing code, now is it?
No, C++/CLI is not stock C++. But it's basically C++ with (a very few) restrictions and a couple added keywords and features. It's certainly close enough that the name C++/CLI applies.
(posting this as a top level comment because I can't reply to EVERY SINGLE COMMENT that is loudly proclaiming that C++/CLI isn't C++ because it doesn't support templates)
Yes, yes it does - it just happens to support generics also: straight from MSDN. Templates, being strictly a compiler phenomenon requiring no post-compilation support from the runtime, are supported just fine. The only real C++ feature that isn't supported is multiple inheritance (with the exception of interface implementation). And that's just fine with me.
So to all you people claiming C++/CLI doesn't support templates, you're dead wrong.
That's a nasty habit! You should really try to quit!
"C++/CLI is, in fact, a strict superset of C++"
So when you do a google search for "C++ programming examples" and it returns something in that strict superset, you won't mind that it doesn't compile?
BadAnalogyGuy, indeed. Please, stop!
I don't care if it's 90,000 hectares. That lake was not my doing.
Second, the official objection is only to the name, not the idea or implememtation of the language itself. In case somebody wants to hear the story more or less directly from the horse's mouth, consider reading one of Francis Glassborrow's Usenet posts where he tells about the situation. The subject's been under discussion to varying degrees for a while, but most of it sheds far more heat than light.
The universe is a figment of its own imagination.
Forgive me for asking the obvious, but why is this important? What would be good reasons for using what's effectively C++ .NET when there are 2 other language choices for .NET (C#, VB .NET) that are much better-suited to writing .NET applications?
.NET.
I thought it kind of was understood that if performance was a priority, you shouldn't be writing for a Microsoft platform in the first place except for a front end, let alone with a framework as performance-shitty (although much more fun to code in) as
I mean, I'm sure there are good reasons to use C++/CLI or whatever it's going to be called, but could someone explain them to me?
Thanks.
About multiply inheritance, I very much regret that I don't have it in .Net.
There are several real cases where I need it, usually for mixins, that are a pain to live without.
--
Two witches watched two watches.
Which witch watched which watch?
I know there are certain situations that MI is extremely useful. But you can always work around it somehow, and it gets abused more often than used legitimately. Overall, I'm of the opinion that MI hurts more than it helps, so I'm not upset to see it gone.
The more experienced you are, the more likely you are to use advanced features like STL and multiple inheritance. Therefore the only code you can reuse with C++/CLI is the half-baked crap produced by knuckle-dragging coders who never managed to understand good C++ style.
Your argument is fruitless. You forgot to define "C++".
What subset of C++ does it need to compile to be a C++ compiler?
Do you even care?
What if it can't compile templates or classes, is that good enough? After all, not everyone uses them.
What if it can do classes and not operator overloads? Is that still a C++ compiler?
The reason the standards exist is to help with this *real* problem -- what is or isn't a compiler for this language.
- Michael T. Babcock (Yes, I blog)
In fact, CLI++ sounds better and would be a better compromise. Between C++, C++/CLI, CLI/C++, CLI and C++ =P You don't have to search forever...
My point is that it isn't well defined. Various people might like to think that C++ means "the programming language C++ as standardised by the ISO in 1997", but in reality what people mean when they say C++ is a whole load of different things, depending on who's saying it and in what context.
The reason the standards exist is to help with this *real* problem -- what is or isn't a compiler for this language.
Yes, and that's fair enough. However, the fact that a language has been standardised doesn't mean that we're not now allowed to use the name for other things that would have been perfectly acceptable prior to that standard being published.
Borland C++ 4.5 is still a C++ compiler, even if it doesn't support function templates or STL. It isn't, however, an ISO-compliant C++ compiler.
The following is still a valid C program, despite the fact that it doesn't follow the syntax prescribed by the ANSI committee when they standardised C:The point I'm making is simply this: "C++" (or "C") isn't something that's all that well defined. "ISO C++" (or "ANSI C") is. That's all.