C++/CLI arrogance

**Bubba** · 07-27-2006, 12:08 AM

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>

SMurf · 07-27-2006, 02:16 AM

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.

itsme86 · 07-27-2006, 03:17 AM

Quote:

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.

Quote:

So what the heck is Finalize() for?

Try documentation: http://msdn.microsoft.com/library/de...alizetopic.asp

siavoshkc · 07-27-2006, 04:05 AM

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.

**Bubba** · 07-27-2006, 04:47 AM

Dispose() seems to force the object to cleanup or force the GC to do its job.

Quote:

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.

FillYourBrain · 07-27-2006, 05:45 AM

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.

Mario F. · 07-27-2006, 06:19 AM

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

FillYourBrain · 07-27-2006, 06:28 AM

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.

FillYourBrain · 07-27-2006, 06:42 AM

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.

siavoshkc · 07-27-2006, 08:28 AM

Quote:

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.

FillYourBrain · 07-27-2006, 09:15 AM

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.

FillYourBrain · 07-27-2006, 09:41 AM

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.

Wraithan · 07-27-2006, 09:43 AM

In any significantly complex code, I doubt the findings will be the same.

FillYourBrain · 07-27-2006, 09:53 AM

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.

Mario F. · 07-27-2006, 10:06 AM

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

07-27-2006, 12:08 AM	#1
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,814	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> __________________ If you aim at everything you will hit something but you won't know what it is. Last edited by Bubba; 07-27-2006 at 12:31 AM.
Bubba is offline

07-27-2006, 02:16 AM	#2
SMurf Registered User Join Date: Aug 2001 Location: Newport, South Wales, UK Posts: 1,094	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.
SMurf is offline

07-27-2006, 04:05 AM	#4
siavoshkc System Novice Join Date: Jan 2006 Location: Tehran Posts: 1,075	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. __________________ Microsoft Visual Studio 2008 Professional (On Microsoft Windows XP SP2) Learn the language before using it. (C++ Books and C Books) Read the FAQ before making a problem. Then make a Google and Forum search. My code painter new version Version 0.97 DOWNLOAD NOW! (Let the pop up, pop!) SiavoshKC
siavoshkc is offline

07-27-2006, 05:45 AM	#6
FillYourBrain pronounced 'fib' Join Date: Aug 2002 Posts: 2,289	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
FillYourBrain is offline

07-27-2006, 06:19 AM	#7
Mario F. (?<!re)tired Join Date: May 2006 Location: Portugal Posts: 5,656	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... __________________ 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. Last edited by Mario F.; 07-27-2006 at 06:21 AM.
Mario F. is offline

07-27-2006, 06:28 AM	#8
FillYourBrain pronounced 'fib' Join Date: Aug 2002 Posts: 2,289	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
FillYourBrain is offline

07-27-2006, 09:15 AM	#11
FillYourBrain pronounced 'fib' Join Date: Aug 2002 Posts: 2,289	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
FillYourBrain is offline

07-27-2006, 09:43 AM	#13
Wraithan 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. __________________ Enlighten Yourself I'm back!
Wraithan is offline

07-27-2006, 09:53 AM	#14
FillYourBrain pronounced 'fib' Join Date: Aug 2002 Posts: 2,289	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
FillYourBrain is offline

07-27-2006, 10:06 AM	#15
Mario F. (?<!re)tired Join Date: May 2006 Location: Portugal Posts: 5,656	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.
Mario F. is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode