Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Microsoft Programming Software IT Technology

Microsoft's C++/CLI Spec Has an Identity Crisis 154

Posted by CowboyNeal from the all-in-a-name dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft's C++/CLI Spec Has an Identity Crisis More

Microsoft's C++/CLI Spec Has an Identity Crisis

Comments Filter:

  • It's all in how you read it (Score:3, Interesting)

    by smittyoneeach ( 243267 ) * on Thursday February 09, 2006 @10:36PM (#14684588) Homepage Journal
    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.

  • Spellcheck. Please. (Score:3, Funny)

    by lightyear4 ( 852813 ) on Thursday February 09, 2006 @10:36PM (#14684591)
    ..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.

    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.

    On the one hand, you've got Microsoft who is willing to labe

    • Re:Sounds like a molehill masquerading as a mounta (Score:1, Funny)

      by Anonymous Coward
      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 :)

    • Re:Sounds like a molehill masquerading as a mounta (Score:5, Insightful)

      by radtea ( 464814 ) on Thursday February 09, 2006 @11:13PM (#14684827)
      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.

      • Plus Plus! (Score:2, Insightful)

        by tepples ( 727027 )

        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 [wikipedia.org] is fundamentally misleading and dishonest." Along these lines, I don't see anything wrong with something like "

        • c++ was originally" c with classes", plus a bunch of the extensions that had evolved on c.

          c++/cli is NOT descended from c or c++. Its descended from net. Call it net/cli if you want.

          • Re:Plus Plus! (Score:4, Interesting)

            by angel'o'sphere ( 80593 ) <angelo.schneider ... e ['oom' in gap]> on Friday February 10, 2006 @06:30AM (#14686235) Journal
            This is completely wrong.

            C++/CLI might be the name of the standard, what it means is: having a standard that defines how C++ is compiled to .NET byte code and executed in the .NET FrameWork.

            C++/CLI or C++/.NET is essentially: C++. However with added tweakes like finalizers (yepp, thats not a destructor), (optional) garbage collection bublic/private classes liek in C#/Java and a mapping from primitv data types on .NET System Classes like System.Int32 etc.

            Further all primitive datatypes have a determined size, unlikey ISO C++ where still only char <= short <= int <=long is valid which means often that char == 1 byte and the rest is 4 bytes.

            Finally a lot of typical C# (or .NET) like threading etc. and finalization has to have a counterpart in C++/.NET which is defined in C++/CLI.

            a typical C++ clas in .NET mitght look like:

            public class __gc MYClass {
                  !MyClass() { ... } // finalizer - called after/during GC
                  ~MyClass() { ... } // destructor (like in standard C++)
                  MyClass() { ... } // ....
            }


            HINT: don't write new programms in C++/.NET except you need fancy stuff like templates (but I'm not sure how templates exactly work in C++/.NET ... I could imagine tehy are only generics, but I think they are still templates like in Visual C++).

            If you need to write new code in .NET then only use C++/.NET to port/interface with existing C++ code, otherwise all those subtible changes that are made in C++/.NET versus ordinary C++ (or MS Visual C++) will drive you completely mad!!

            angel'o'sphere

            • Re:Plus Plus! (Score:5, Insightful)

              by radtea ( 464814 ) on Friday February 10, 2006 @10:00PM (#14692291)
              C++/CLI or C++/.NET is essentially: C++.

              This is false. To you all the nice people who have thoughtfully replied to my comment with pedantic outrage, let me remind you what hummassa (157160) has pointed out in a mysteriously low-moderated response:

              C++/CLI will not compile the STL.

              This has been my own experience with C++/CLI, and one of the primary reasons for my being so hard-assed about the name. This is not a minor deviation from the standard. It is a radical deficiency. The STL is a core piece of any C++ programmer's toolkit, and any compiler in 2006 that will not compile it is not a C++ compiler, and should never be refered to as C++, and should not have a name that could possibly be confused with C++.

              This is like having a FORTRAN compiler that can't handle LAPACK. If I created something called FORTRAN/CLI that couldn't compile LAPACK people would rightly yell at me. MS deserves to be smacked on the nose with a rolled up newspaper for doing the equivalent to C++.
              • C++/CLI or C++/.NET is essentially: C++.

                This is false.

                OFC its not false, please stop your nitpicking.

                Three are endless of C++ compilers that don't have a standard STL but their own crippled version. As others pointed out: who descides if a compiler is called a C++ compiler? The vendor!

                As all your critics is right, from a language point of view C++/CLI is ofc C++ ... its not "standard" C++, but it is its own standard. Thats why they wanted an ISO recogniced one.

                The whole reason why *I* don't use C++ anymore
          • I preface this by saying I know I'm being anal (sorry) ;-)

            c++/cli is NOT descended from c or c++. Its descended from net.

            I'd have to disagree with that. At least if we are to consider c++ a descendant of c, than calling c++/cli a descendant of c++ could certainly be valid while calling it a descendant of .NET really doesn't make any sense.

            .NET is a common langage runtime, common type system, meta-data about assemblies and thier internals, etc. In a nut-shell you can consider .NET a virtual machine.

        • Re:Plus Plus! (Score:5, Insightful)

          by Anonymous Brave Guy ( 457657 ) on Friday February 10, 2006 @08:32AM (#14686563)
          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."

          You're comparing apples to oranges.

          Stroustrup didn't go around "casually" referring to C++ as C using a multi-million-dollar PR machine. On the contrary, he has written extensively about the relationship between C++ and C as the newer language has evolved, and has always been clear about the significance of having similar syntaxes and where the differences start.

          Microsoft, on the other hand, frequently do refer to C++/CLI simply as C++. They even have a column on their MSDN web site called Pure C++ [microsoft.com]; would you like to guess whether the C++ in question is the ISO standard variety or the C++/CLI one? That one's a real shame, and I'd have expected better from a distinguished C++ expert like Stan Lippman.

        • 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.
      • 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++

        • The problem is that C++/CLI is not ANSII. Even in MS's own documentation, they often refer to their language simply as "C++".

          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.

        • 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.
          • 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.

        • Short answer: no. (Score:4, Informative)

          by hummassa ( 157160 ) on Friday February 10, 2006 @09:10AM (#14686781) Homepage Journal
          > 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 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.

            Yes it does [microsoft.com]. No multiple inheritance, that's true, but as for templates, they're supported just fine.
      • If a language is not ISO C++, it is not C++ and should not have C++ as part of the name.

        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 .NET technologies, then C++/CLI is

      • Re:Sounds like a molehill masquerading as a mounta (Score:1, Insightful)

        by Anonymous Coward
        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.

      • 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.

      • Re:Sounds like a molehill masquerading as a mounta (Score:1, Funny)

        by Anonymous Coward

        I'm dating myself

        Yes... most of us call that "single".

      • 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++
        • 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.
          • Your argument is fruitless. You forgot to define "C++".

            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
      • I'm dating myself
        Just like every other /.'er?
    • I saw this somewhere else the other day. The problem is not that they created this version of the language, but what they are calling it. If they called it "C++.Net" all over the place, no one would complain. Even if they called it "C++/CLI" which I think is a little more unwieldy for general use.

      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.

      • 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.
        • How could you not be confused by it? Here's the sequence of events:
          1. You're working on an ISO C++ project
          2. You some particular functionality, so you search for it on the Internet.
          3. You find a library that seems to do what you want at MSDN.
          4. It's labeled "C++" (not "C++/CLI" or ".NET", just plain old "C++").
          5. 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.
          6. You try to compile, and it fails horribly.
      • 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.

    • Various corrections and more information. (Score:5, Informative)

      by jdennett ( 157516 ) on Friday February 10, 2006 @12:10AM (#14685146)
      (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 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.

      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 pro

      • 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
    • 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


      BadAnalogyGuy, indeed. Please, stop! :^)

  • I thought C++ programs by default were CLI (as opposed to GUI).
  • Just name it --C/CLI :)

  • ANSI (Score:2, Insightful)

    by NullProg ( 70833 )
    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,

    • Re:ANSI (Score:4, Informative)

      by kupci ( 642531 ) on Friday February 10, 2006 @01:03AM (#14685359)
      As a matter of Stroustrup [att.com] has commented. In a nutshell, he says that Microsoft is revising their documentation to minimize confusion.

      • The wealth of new language facilities in C++/CLI compared to ISO Standard C++ tempts programmers to write non-portable code that (often invisibly) become intimately tied to Microsoft Windows.

        This sounds a lot like Microsoft's usual business. The Garbage Collector in particular means that porting the new code to other platforms will result in memory leaks and poor performance.

    • Sometimes you need to use managed extensions, just as with Java you need to use JNI. For example you might have a lump of legacy code which is too hard to rewrite, or a 3rd party DLL with no .NET equivalent and therefore you must wrap it.

      The problem is that Microsoft make it far too easy. Far too easy by half. With JNI you feel the pain a lot more and are therefore encouraged to use Java if at all possible, which as it happens is usually not too hard because the APIs and 3rd party market is massive.

      The

    • Maybe they should do the symmetric process to Visual J++ and call it Cava!
  • 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.

  • Interetingly (Score:4, Interesting)

    by Utopia ( 149375 ) on Thursday February 09, 2006 @11:59PM (#14685086)
    The prominent C++ expert Herb Sutter is the lead architect of C++/CLI.
    He also chair the ISO C++ standards committee.

  • So what? (Score:3, Insightful)

    by kclittle ( 625128 ) on Friday February 10, 2006 @12:31AM (#14685240)
    So what if MS tries to super-set C++ -- big deal! The industry as a whole has only been doing this to C for, oh, 30 years or so? Have you ever looked at list of advanced, non-standard features of "GNU C" (note the full name in quotes)? And I don't recall in which C compiler I first saw support for the end-of-line comment "//" (Vax C?), but is sure as hell was non-standard at the time. I don't recall any pulling of hair and renting of garments over that.

    • What's your point? It's obnoxious when GNU does it, it's obnoxious when DEC does it and its obnoxious when Microsoft does it.

      • Re:So what? (Score:2, Insightful)

        by kclittle ( 625128 )
        The point is, adding non-standard enhancements to C is a long accepted practice. Even when done by big, powerful companies. And, IIRC, no one considered it all that obnoxious, as long as it didn't break old code (i.e., was either a superset feature or could be controlled by compile-time options). It was competing, it was innovation, it was pushing the envelope. Now, all of a sudden, because it's MS, it's "news", it's "oooooooo, scary!". Baloney. This is just slashdot paranoia and/or bias at its worst.

        • Re:So what? (Score:1, Informative)

          by Anonymous Coward
          Here's the problem.

          First, C++ / CLI is not compatible with C++. It's not even close. It's not a strict superset of C++, so old programs might behave differently under C++ / CLI, in much the same way that C programs can behave differently when compiled as C++. They aren't really the same language.

          Second, Microsoft are misrepresenting C++ / CLI as standard C++. Their tools and their documentation lead people to believe that C++ / CLI is actually C++.

          The problem is not that Microsoft have come up with an exten

          • First, C++ / CLI is not compatible with C++. It's not even close. It's not a strict superset of C++, so old programs might behave differently under C++ / CLI, in much the same way that C programs can behave differently when compiled as C++.

            I don't know much about C++/CLI, but this is different from what I've heared before (of course what I've heared before may be wrong). Could you please post a valid C++ program which would behave different under C++/CLI?

            there are a couple of other languages derived from C+

            • Re:So what? (Score:3, Informative)

              by MooCows ( 718367 )
              I don't know much about C++/CLI, but this is different from what I've heared before (of course what I've heared before may be wrong). Could you please post a valid C++ program which would behave different under C++/CLI?

              Well, as far as I know any C++ code compiles just fine in with C++/CLI extensions enabled.
              Just last month I wrote a C++/CLI wrapper class for a large C++ codebase so our .Net applications could link up with it. No code in this substantially large library had to be altered so it could compile

    • Re:So what? (Score:3, Insightful)

      by mrchaotica ( 681592 )
      ...and all the C I write -- despite the fact that it only targets platforms with GCC -- gets compiled with the -ansi flag.

    • Re:So what? (Score:3, Funny)

      by julesh ( 229690 )
      And I don't recall in which C compiler I first saw support for the end-of-line comment "//" (Vax C?), but is sure as hell was non-standard at the time. I don't recall any pulling of hair and renting of garments over that.

      You don't? Obviously you've never read comp.lang.c.
    • So long as they referred to it in every instance as C++/CLI, I don't think there'd be half the fuss, no.

      So long as we hadn't experienced monopoly-powered embrace and extend before, I don't think we'd be so worried.

      But they don't, and we have.

      Justin.
    • In the case of GNU it's not just C. Don't forget all the extensions added to gforth. Try taking gforth code and running it in another forth interpreter. Even after you load the dozen or so libraries of extensions.

  • Link to Groklaw (Score:5, Informative)

    by kupci ( 642531 ) on Friday February 10, 2006 @01:11AM (#14685388)
    Some additional detail with good comments on this subject available over at Groklaw [groklaw.net].

    Stroustrup's comment [att.com]. Apparently Microsoft is revising their documentation to clear up the confusion.

  • I'm glad people are complaining about this. (Score:4, Informative)

    by alyosha1 ( 581809 ) on Friday February 10, 2006 @05:21AM (#14686073)
    I've already been bitten by this - I wrote a perfectly short C++ program as a tutorial for a friend, using VC++ 2003, but when he tried to compile it on VC++ 2005 it gave this warning:
    warning C4996: 'std::_Transform' was declared deprecated
    which implies, at least to the novice developer, that the use of the standard c++ algorithm library is no longer considered appropriate practice. This is extremely annoying and misleading. One of the major strengths of C++ is that you can extend it almost limitlessly without changing the underlying language. As far as I can see, for every extension that people have tried to add to the language to support a particular paradigm, it has been shown that the same effect can be achieved without going beyond the bounds of the language.
    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.
    • Actually, Qt signals can not be achieved by template-based signals, since Qt signals allow limited introspection, which is impossible with template-based ones. This comes in handy when serializing signal-slot-connections, for example.
      • If that's the case, how did Trolltech achieve compatibility between Qt 4's signals/slots and Boost's signals/slots?

        Trolltech themselves have stated that the reason they use a preprocessor instead of a template-based system is for compiler compatibility, and not any functionality that is gained.
  • 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
    • You are wrong if you think standards in languages are a Sun-propagated myth. Most languages (LISP, Pascal, C, C++, etc) are governed by standards. Someone wishing to write a compiler will acquire a copy of this standard, and use it to implement the language. Someone wishing to write code will acquire the standard, learn the language, and then write code in it.

      Now, a lot of compilers don't 100% support the standards, but most come close. This means that code written to the standard that compiles on one

      • Incidentally, most compilers have a 'standards mode' which ignores extensions, so you can check easily whether your code uses them. With GCC, for example, you can compile with -std=c99 to enforce the C99 standard without GNU extensions, or -std=c99 for the C99 standard with GNU extensions.

        You mean like how VS2K5 has /clr for C++ with CLR extensions, and no /clr for standard C++?
      • You are wrong if you think standards in languages are a Sun-propagated myth. Most languages (LISP, Pascal, C, C++, etc) are governed by standards.

        I don't think language standards are a myth. Quite to the contrary, language standards are very important. It is a disgrace that Sun first promised, and then failed to deliver, a language standard for Java.

        Sun's myth is that language standards require enforcement, and/or that language standards should prohibit proprietary extensions.

        The problem is that there is
  • 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.
  • (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 [microsoft.com]. 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 t
    • 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.

      It sure as hell isn't fine with me. I use multiple inheritance a lot, and if Microsoft's language doesn't support it, that means I would have to throw away (or at least, radically redesign) most of my existing code in order to use their compiler. The whole point of having a standardized language specification is so that you can migrate existing code without

      • Sure you can, you'll just have to continue compiling it as regular c++, with an c++/cli interface layer if you want to access it from .net.

        And gratuitous use of multiple inheritance is bad design, so you might want to think about that. Yes it's a good thing sometimes, but this is VERY RARE - it always increases complexity and can cause problems later, it's just that sometimes the benefits are worth it. Usually not, though. Anyway, I'm not getting into that right now.
        • Sure you can, you'll just have to continue compiling it as regular c++, with an c++/cli interface layer if you want to access it from .net.

          Right, I could use a cross-language interface layer, the same as if I had written the code any other non-compatible language. Which is the point: Without MI, C++/CLI is not C++ in any meaningful sense of the term. It's a separate, similar-but-incompatible language, much like C# or Java.

          And gratuitous use of multiple inheritance is bad design, so you might want to thin

  • First of all, I'd like to note for the record that despite comments elsethread, C++/CLI is not actually a strict superset of C++. It appears that they've gone to considerable lengths to make it as close as they consider reasonable to a strict superset, but it's still true that some perfectly legitimate C++ code won't compile as C++/CLI.

    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 fr

Slashdot Top Deals

Avoid strange women and temporary variables.

Close