C++/CLI arrogance

This is a discussion on C++/CLI arrogance within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by FillYourBrain mario f, the only problem is that half of what that guys is saying is a ...

  1. #61
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,411
    Quote Originally Posted by FillYourBrain
    mario f, the only problem is that half of what that guys is saying is a lie. multiple inheritance not there? lie. It's only not there on a ref or value class. On the traditional classes it's most certainly there. iostream and string not there? lie. I use them in my current .NET project.
    Just goes to show one can't trust arbitrarly anything they read. Something I know for a long time and yet seem to keep forgetting. However, I suggest you read it slower, Fill. The author is not saying there is no iostream. It is saying C++/CLI doesn't support the Standard Library. This is important in the context of that paragraph since he is debating Microsoft's argument of C++/CLI being an extension to C++. You certainly can't have an extension to a language if you don't fully support that language.

    There is one strong argument for C++/CLI, if you ask me. And it is in my opinion a very strong argument. In fact many businesses depend on it; development speed. After nvoigt reply to me on a related thread, I made a lot of reading and experimented a little with C++/CLI and I have to agree that it makes C++ based development much quicker. Many of its features ease the traditional C++ development and even "patch" (here not used derogatorily) some of the most time consuming and error prone code. Memory management to name one.

    But you cannot deny the disadvantages either. I think you too need to open up your mind to the other side. Everything comes at an expense and certainly you cannot say here to programmers who have used more than a good share of different programming languages in their lifetime that C++/CLI answers all your problems.

    Lack of portability; too many assumptious making your code bloated and uncaring for machines with lack of resources; speed issues to the point of the technology not being interesting enough for game development; and probably the most interesting one, does the world really need another managed programming language? I mean, could this had been done some other way?

    No matter what, I have to say that the argument above for C++/CLI is the strongest one and it puts everything else to shame. Programming is about business decisions. And I bet that has been the major reason why C++/CLI has been welcomed by many.

    But the purpose has been in this thread to dispel a few lies and some of the arrogance coming with it.

    . C++/CLI is not an extension to C++. It is a whole new programming language that looks remarkably (read purposedly) like C++.
    . C++/CLI is not the solution to all your problems. If you shut down the door to unmanaged code, you will effectively limit your operating system usability from the development point of view.
    . C++/CLI use of the unsafe term is misleading and completely wrong. ISO C++ was never meant, and never will be a programming language built to be either safe or unsafe. Programmers on the other hand are unsafe. And I'm sure you can show me a millions ways in which C++/CLI can produce ugly, broken, and unsafe code or dangerous code. More, C++ has all manner of garbage collector libraries. On the other hand Boost offers smart pointers in many flavors and these are already part of the proposed TR1.
    Last edited by Mario F.; 07-30-2006 at 04:31 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #62
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    One major problem I have with it is that it's name has C++ in it. I'm no hardcore microsoft bashing linux fanboy, but it doesn't take a genius to notice the name is purposefully deceitful. I think it should have a completely separate name--something like CLI++ (or better yet, CLIpp) at the least. If it can't be compiled with a standards compliant C++ compiler then it shouldn't tote itself as C++.

    It's an underhanded business stragety targeting a market of suckers, for example http://msdn.microsoft.com/visualc/de...tFramework.asp go look at the Visual "C++" examples.

  3. #63
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    Isn't WinFX now just the new .NET 3.0?
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  4. #64
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The relation between C++ and C++/CLI is similar to the relation between C and C++. In both cases, the latter is a language intended by the creator(s) to be better than the original, but intentionally keeps most if not all of the features of the old language in order to provide compatibility and thus ease the transition.

    I nevertheless still find C++/CLI syntax to be ugly (though not as ugly as ME-C++), especially compared to C#, and thus see no reason to use C++/CLI over C# except in order to make C++ code available to .Net applications.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #65
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by CornedBee
    ...and thus see no reason to use C++/CLI over C# except in order to make C++ code available to .Net applications.
    Which is my reason as well. I don't mind C#. But I'd hate for it to take over as some kind of dominant language while C++ goes away. C++/CLI is an opportunity that we have to help keep C++ in business.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  6. #66
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,231
    C++/CLI is an opportunity that we have to help keep C++ in business.
    God bless Microsoft for giving us this opportunity.
    Learn C++ (C++ Books, C Books, FAQ, Forum Search)
    Code painter latest version on sourceforge DOWNLOAD NOW!
    Download FSB Data Integrity Tester.
    Siavosh K C

  7. #67
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by FillYourBrain
    Which is my reason as well. I don't mind C#. But I'd hate for it to take over as some kind of dominant language while C++ goes away. C++/CLI is an opportunity that we have to help keep C++ in business.
    Actually, by C++ code I meant the C++ code that's still around, while your company really wants to migrate to .Net.

    I personally don't see C++/CLI as a way of keeping C++ in business. It doesn't matter much to me if people migrate to C++/CLI or C# - in both cases, a classical C++ programmer is lost.
    Actually I prefer C# - at least Mono has a compiler for that.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #68
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    As a sidenote, you seem to assume that "unsafe" means Microsoft wants to get rid of C++ and arrogantly calls C++ unsafe. That's simply not the case. "unsafe" means that the .NET verifier will not be able to verify the code as "safe" because it cannot possibly know what the code does. This has security implications. You can tune the .NET Framework to not execute that kind of code from sources you don't trust. Assemblies you downloaded from the net will not be allowed to execute code that could not be verified for example ( this is the default, you can set it to whatever you want though ). "unsafe" has nothing to do with C++. You can write "unsafe" code in any language, even in C#. It just means that you are using constructs like pointers that cannot be verified and therefore aren't considered safe by the runtime.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  9. #69
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    It just means that you are using constructs like pointers that cannot be verified and therefore aren't considered safe by the runtime.
    This is the crux of my entire post. I, too, agree that this is probably the intended meaning of 'unsafe' but in the book they more often than not simply make the statement than if you use traditional C++ it is automatically "unsafe" w/o clarifying that it is "unsafe" in so far as the .NET framework is concerned - and not "unsafe" from a pure programming perspective.
    It's a war of semantics but unfortunately it is painfully obvious that this is an attempt by MS to hijack a language and not just another API option to mill around in your head. If it were being touted as such, I would have no issue with it. Instead it is being touted as the only way to do things which is a mindset that I just cannot go along with.

    I'm sure we will see more debate on this issue in the coming months and years and probably will depend on the success or failure of the entire .NET idea. If it succeeds we will hear a lot of debate as to what it's proper name of the CLR in a C++ context should be. I would not mind it simply being called the CLR instead of having to include every language in the mix. VB/CLI is just as much of a misnomer as Java/CLI or C++/CLI. If CLI is indeed just a framework then it needs to be touted as such instead of being advertised as an 'extension' to an existing language.
    It is an 'extension' to the Windows API and perhaps an 'extension' that is cross-platform, but it is not an extension to any language.

    I also do not like the fact that they added keywords to C++ to get .NET functionality. This, to me, seems like a slap in the face to C++. Couldn't they have achieved the same thing w/o altering/adding keywords?
    Last edited by VirtualAce; 07-31-2006 at 03:14 AM.

  10. #70
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    No, they couldn't have.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #71
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,411
    I am curious to know if that same book takes on the examples of what it calls unsafe code in C++ and explains how it could be done safe in C++.

    I'm certain that instead of showing that it is all in fact just a matter of quality of code, its argumentation is all based on exploring bad code without showing the correct way of doing things.

    Publicity stunt.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #72
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    I just looked over http://www.ecma-international.org/pu...s/Ecma-372.htm and I agree the addition of some of the keywords is required simply because it's a concept which doesn't exist in C++. However, much of the added syntax and modification is unnecessary and could have been implemented in a syntactically equivalent method and deduced from the context.

    I also feel that the emphasis on safety is overly marketed. With a good programmer, applications like valgrind, electric fence, and debuggers, memory problems are much less of an issue.
    Last edited by valis; 07-31-2006 at 04:13 AM.

  13. #73
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    I am curious to know if that same book takes on the examples of what it calls unsafe code in C++ and explains how it could be done safe in C++.
    It cannot. Because C++ is a language that the .NET verifier cannot verify, no matter if it's groundbreakingly good or bad, it's just not verifiable. So it's considered unsafe. There is no "safe" ( = being checked by the .NET runtime ) way to handle pointers and a C++ application without pointers of some sort is probably not even worth coding.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  14. #74
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    I agree that this is the accepted definition of safe code, however, I definitely see a trend in the manipulation of its use, just like the issue C++ is in the name of the language (they are often simply leaving out CLI or any reference to .net).

  15. #75
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,411
    Make no mistake it is a very convenient labelling. One easy to manipulate and explore. Most probably a very well thought of, too.

    Considering C++/CLI is not C++, what it basically is telling us is that "since I cannot use this so called programming language named C++ through my verifier, I hereby label it unsafe". There, problem solved.

    Of course this means, Java is unsafe, as is Objective C, D, Ada, Visual Basic, Cobol, Fortran and good ol' QBASIC.

    And of course, C++ considers .Net very unsafe too because it can't verify its pointers.

    And here we are exploring semantics because they were badly used the first time no matter the excuses we can now come up with to justify the unjustifiable.

    EDIT: Food for thought... Go to the MSDN main page. Click on Visual C++ on the left hand menu bar. Where are you taken? To a C++ information page or to a C++/CLI? Click on the Hello World link in the center of the page. And read what Micosoft has to say about C++ and C++/CLI. It's all there.

    I'll give you this precious bit:

    You can say that C++/CLI is to C++ as C++ is to C. More generally, you can view the evolution leading to C++/CLI in the following historical context:

    * BCPL (Basic Computer Programming Language)
    * B (Ken Thompson, original UNIX work)
    * C (Dennis Ritchie, adding type and control structure to B)
    * C with Classes (~1979)
    * C84 (~1984)
    * Cfront, release E (~1984-to universities)
    * Cfront, release 1.0 (1985-to the world )—20th birthday
    * Multiple/Virtual Inheritance (MI) programming (~1988)
    * Generic Programming (~1991) (templates)
    * ANSI C++/ ISO-C++ (~1996)
    * Dynamic Component programming (~2005) (C++/CLI)
    Now... isn't that arrogance?
    Last edited by Mario F.; 07-31-2006 at 04:47 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Page 5 of 8 FirstFirst 12345678 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21