Thread: C++/CLI arrogance

  1. #1
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607

    C++/CLI arrogance

    Well I just started reading my new book, Pro Visual C++/CLI and the .NET 2.0 platform. It is written by Stephen R. G. Fraser, one of the 4 key people in the devlopment of C++/CLI.

    Right from the start the book is leaving a very Microsoftie taste in my mouth. I have no qualms about attempting to modernize C++ to meet with current demands as that will contribute to it's lifespan. However, I do have a problem with the idea that any code not written for the .NET (CLI) platform being called 'unsafe' code. For instance the book claims any code written in traditional C++ is now 'unsafe' code. We all go to great lengths to ensure our C++ code is indeed memory and thread safe and then for someone to tell us it is 'unsafe' simply because it's ISO-C++ and not C++/CLI (a Microsoftie way of pushing pure .NET 2.0), doesn't make me all that excited about the direction we are heading.

    Check out this code sample:
    Code:
    ref class Wrapper {
      
      Native *pn;
    
    public:
    
      //RAII
      Wrapper(int val) {pn=new Native( val ); }
      ~Wrapper() {delete pn; }
    
      void mfunc();
    
    protected:
    
      //an explicit Finalize() method - as a failsafe ...    
      ! Wrapper() {delete pn; }
      
    };
    
    void f1()
    {
      //normal treatment of a reference type
      Wrapper^ w1=gcnew Wrapper(1024);
    
      //mapping a reference to a lifetime
      Wrapper w2(2048);  //no ^ token !
    
      //just illustrating a semantic difference
      w1->mfunc(); w2.mfunc();
    
      //w2 is disposed of here
    
    }
    
    // ...later, w1 is finalized at some point, maybe ...
    I see some very odd things going on in this code and now I see the reasons that some folks out there totally dislike CLI. One article I read talks about Finalize() and now I see why.

    Ok, let's get this straight. When the object is destroyed, the destructor will be called according to traditional 'unsafe' C++. The destructor then will clean up. So what the heck is Finalize() for? Does Microsoft not understand fundamental memory management in C++? If the object cleans up upon destruction, what the hell is Finalize() gonna do later? There is nothing left to clean up. It seems pointless.

    Secondly, notice the CLI reference ^w1. It is constructed with gcnew, and I assume this is also instantiation, but it is never cleaned up. In fact the last statement is saying the garbage collector will clean it up ....when it feels damn good and ready to do so - if it ever feels damn good and ready. So let's say we have 10 apps up that have 30 or so w1's out there. Since the GC only cares about the current process - a fact that blows my mind in a cooperative pre-emptive multi-tasking environment, it may never clean up any of those objects. So now instead of having 1 or 2 poorly coded C++ apps here and there, now we have 10 apps using the VM that don't care about each other, the system, or anything not related to itself. Seems to me a virtual mess. So as computers get faster, our software gets slower. And for what? So more people can code without using their brain? I don't like the tradeoff. Whoever said code was easy or simple? So because of our beloved new technology called CLI or .NET 2.0, we have an instant leak and it is called 'correct' and 'safe'. This is hideous memory management and is akin to Java and C# memory management, both problem-plagued and doomed memory managers if you ask me.
    So if the w1 reference is never cleaned up, what the heck happens to it? Are we to assume that the user's system has so much memory that we need not worry about little old w1?

    I'm not a professional programmer by any means, but I'm also not an idiot in C++. So far this CLI .NET stuff doesn't look faster or better, it looks bloated and slow. I'm going to read this book in its entirety and give this CLI a chance, but I cringe at the Microsoftie jargon, propoganda, and insistence on 'our way is better, not because it is, but because it's our way'.

    A link to ponder and lead to more links. A quick google of CLI vs C++ would probably yield hours of reading.
    http://www.sysinternals.com/blog/200...im-scared.html

    Everyone's response is 'dude, you get like memory management taken care of for ya'.
    I'm like 'dude, if you can't perform your own memory management, why the hell are you programming?'

    It's pretty simple in C++ folks. If you call new, then by all means call delete when you are done. Damn that was hard eh.


    Comments welcome.

    <confuzzled>
    Last edited by VirtualAce; 07-27-2006 at 12:31 AM.

  2. #2
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,273
    I reckon that by "unsafe" they mean "potentially unsafe". Newbie programmers, for example, may not be so hot on tidying up after themselves and it's not unheard of for a leak to get past pros either, especially when the clock is ticking.

    Garbage collection supposedly guarantees safety, although really if you know how to use new/malloc and delete/free then a garbage collection thread will seem redundant.

  3. #3
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,218
    It's pretty simple in C++ folks. If you call new, then by all means call delete when you are done. Damn that was hard eh.
    Memory management can be far from simple. If it was, there'd be a lot less applications out there with memory leaks.
    So what the heck is Finalize() for?
    Try documentation: http://msdn.microsoft.com/library/de...alizetopic.asp
    If you understand what you're doing, you're not learning anything.

  4. #4
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,246
    There should be a board for C++/CLI. Then I will come there and open a ton of threads about it. C++/CLI is more related to C than C#.
    CLI is not faster or safer, it is just easier for usual tasks. Look at my test code in this thread, .net is a troll. .net means: Microsoft writes the code for you. It is like MFC, but not only for Windows, for all environment and platforms. In Microsoft dream, all devices will support .net. And you can write programs for any device easily and Microsoft has its control over it.
    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

  5. #5
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Dispose() seems to force the object to cleanup or force the GC to do its job.

    Memory management can be far from simple. If it was, there'd be a lot less applications out there with memory leaks.
    It gets complex at times, but it comes down to good design in the end. I'm not sure I want my code leaking objects until the GC sees fit to clean them up. And I'm not saying I hate CLI, but it does seem to fly in the face of what I'm used to in C++ as far as memory management goes. Since MS owns the OS market by far, CLI will be a skill for the future as C# developers probably will come back to C++/CLI with .NET 2.0.

    I've read mixed reviews on CLI and on .NET 2.0. When I start writing the code and stop reading about it, I'll offer up my opinion. Right now I'm in the ...OMG that's ugly stage. However it's clear that Vista and future MS operating systems will probably be pure .NET in the near future. Some of the API has not been incorporated into .NET as of yet, but I look for that to change quickly.

    Last edited by VirtualAce; 07-27-2006 at 04:51 AM.

  6. #6
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    I've always felt that the GUI should be separated from the application. C++/CLI's strength for me is that it provides an interface between standard C++ and the .NET world. I don't really like the syntax for the managed parts, but as long as the gui is separated from the app code you don't really have a problem in my view. This allows your app to be very portable code. No system has the ideal interface to the gui.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  7. #7
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    On this other thread you started I went on to explore a little more about C++/CLI. To see you (even considering the little we know each other) getting an interest in it got me curious. I understood the necessity. However, nvoigt kinda pushed me even further to take a closer look at it's features when he overthrew most of my arguments against it.

    It's Microsoft that is pushing the comparison between C++ and C++/CLI, no doubt in an effort to move existing C++ programmers to their beloved .Net. While they were very careful in establishing from the start C# was not C++, they also make this distinction with C++/CLI. But this time they do it in the style of a one liner to say they aren't the same, followed by 100 pages saying they are better. This forces the brain into accepting C++ and C++/CLI are similar and comparable.

    The fact is that C++/CLI is an attempt at provide a programming language to support CLI in a C++ fashion. I don't see anything wrong in this. C++/CLI is a new programming language, completely unrelated to C++ (only by name and a similar syntax).

    I still think that C++/CLI will give more headaches than provide solutions. It's slow, bloated and it will always be slow and bloated in the best Microsoft tradition. It presents a garbage collector as the mother solution to the root of all evil, and yet C++ garbage collectors can be found by poking in the dark by a drunk one-armed man suffering from hallucinations. C++ is also on it's way to present a RAII-friendly solution as a de facto standard. And the tools are already
    there for anyone to use. Heck, I am! On my 5th month of learning C++.

    I cannot conceive a .Net only operating system with no bindings to pure C++. Maybe I'm wrong. But this would throw away a big slice of windows programmers, not to mention it can't really be done untill Microsoft provides the multi-billion dollar game industry with a fast platform. One of the driving forces of Microsoft success has been the poor-man programmer. The one which provides shareware, freeware and comparably small commercial applications. These are the "garage" type of programmers that depend less on business decisions (like the ones influencing a big company to migrate all their existing C++ code to C+/CLI), and more on their passion and believes.

    Either the transition will never be done, or it will be done very slowly and on the opposite direction. Towards C++, not away from it.

    One thing though is also true... Microsoft still has a rabbit inside that marketing hat of theirs waiting to be pulled out. CLI is sort of language-neutral. They have yet to show other language bindings. VB/CLI, Delphi/CLI...
    Last edited by Mario F.; 07-27-2006 at 06:21 AM.
    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.

  8. #8
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    the compiler... cl.exe is the same compiler they use for standard C++. When you add the /clr flag, it still compiles standard C++. The difference being you can reference the C++/CLI stuff if you wanted to. The idea that its a totally different language is simply untrue. It isn't slower. You can argue that referencing the .NET parts might be slower. But the language is in fact C++ when you ignore the managed parts.

    You can wrap the gui stuff up if you like so that you never have to look at it when you're writing your C++ stuff and everyone should be relatively happy. Unless you're insane of course.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  9. #9
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by Mario F.
    ...They have yet to show other language bindings. VB/CLI, Delphi/CLI...
    VB.NET?

    C#, VB.NET, C++/CLI...... Other companies also are providing support for many other languages. There's even an Ada version. A# its called.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  10. #10
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,246
    the compiler... cl.exe is the same compiler they use for standard C++. When you add the /clr flag, it still compiles standard C++. The difference being you can reference the C++/CLI stuff if you wanted to. The idea that its a totally different language is simply untrue. It isn't slower. You can argue that referencing the .NET parts might be slower. But the language is in fact C++ when you ignore the managed parts.
    No, with /clr swith cl.exe will be a completely different compiler.
    For example my 20KBs program will be 80KBs with /clr switch.
    With clr, C++ is not itself.
    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

  11. #11
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    in spite of the fact that the compiler will link in more stuff with the clr flag, your C++ program will still compile native code, exactly the same as before and equally fast.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  12. #12
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by siavoshkc
    No, with /clr swith cl.exe will be a completely different compiler.
    For example my 20KBs program will be 80KBs with /clr switch.
    With clr, C++ is not itself.
    I figured I'd verify this. my results:
    Code:
    #include <stdio.h>
    int main (void)
    {
       printf("hello world\n");
       return 0;
    }
    compiled as follows...
    cl test.cpp
    produced test.exe
    size 53k

    cl /clr test.cpp
    produced test.exe
    size 23k

    with the clr flag its actually SMALLER
    Sometimes I'm guilty of not verifying before I post too.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  13. #13
    pwns nooblars
    Join Date
    Oct 2005
    Location
    Portland, Or
    Posts
    1,094
    In any significantly complex code, I doubt the findings will be the same.

  14. #14
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    compile something then. All you need to do is add the flag. then check the filesize. It's native code either way. Why is this hard to understand? Why indeed. built in bias against microsoft. or should I say Micro$oft? All they did was add the ability to do managed stuff to the existing compiler. This shouldn't be that hard to grasp people.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  15. #15
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I'm not against it per se. Mind you.

    All I do care though is if they are going to take away my precious invested time learning a programming language like ISO C++ if then I will not be able to use anymore under Windows.

    I think this day will not come...
    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.

Popular pages Recent additions subscribe to a feed