.NET (managed code) confusion

  • Thread starter Thread starter Z.K.
  • Start date Start date
Z

Z.K.

I am curious as to why this code works:

Form2 ^OC = gcnew Form2();
OC->Text = "Child";
OC->MdiParent = this;
OC->Show();

and this does not:

Form2 *OC = new Form2();
OC->Text = "Child";
OC->MdiParent = this;
OC->Show();


I have looked through all my .NET books about managed code and I can not
find any reference to using gcnew or the '^' which appears to be a
pointer notation. I am using the new Visual Studio 2005 if that
matters. I was wondering if someone could clear up my confusion.

Z.K.
 
Z.K. said:
I am curious as to why this code works:

Form2 ^OC = gcnew Form2();
OC->Text = "Child";
OC->MdiParent = this;
OC->Show();
Click to expand...

The above is the new C++/CLI syntax (default in VC++ 2005)
and this does not:

Form2 *OC = new Form2();
OC->Text = "Child";
OC->MdiParent = this;
OC->Show();
Click to expand...

This is the old managed C++ syntax of VC++ 2003
 
SvenC said:
The above is the new C++/CLI syntax (default in VC++ 2005)


This is the old managed C++ syntax of VC++ 2003
Click to expand...

Which had all kinds of problems, including silently passing unpinned
pointers to native code and startup deadlock.

Use the C++/CLI syntax exclusively.

A lot of authors, caring about profit and not correctness, were racing to
get their books out first and didn't care to mention all the reasons Managed
Extensions shouldn't be used. They couldn't have had a good understanding
of the material. Anyone who tried to sell a "Managed C++" book using VC2003
instead of an article "Why Managed C++ isn't ready for the real-world" is a
profiteer, not a programmer, and you shouldn't buy any books by that author
ever again.

C++/CLI has finally existed long enough for some published books to be
available. I don't have it myself, but Nish's book is probably quite good
http://voidnish.com/NishBooks.aspx. He's another MVP and seems to know his
stuff.
 
Ben Voigt said:
Anyone who tried to sell a "Managed C++" book using VC2003 instead of an
article "Why Managed C++ isn't ready for the real-world" is a profiteer,
not a programmer, and you shouldn't buy any books by that author ever
again.
Click to expand...

You mean like Siva Challa and Artur Laksberg - both on the compiler team at
MS - who wrote this one?:

http://www.amazon.com/Essential-Guide-Managed-Extensions-C/dp/1893115283

Theirs is a _good_ book.

While it is true that the language had problems, four years ago it was just
about the only option if one needed to straddle the fence between managed
and native development with C++.

C++/CLI is better to be sure but MC++ is far from unusable.

Regards,
Will
 
I approach these things in a different way. I realize that every computer
language is capable of creating any application any other can. They are all
equivalent in that sense.

As such, EVERY language (or flavor of language) will have advantages and
disadvantages over another. So I'm not concerned so much in how one language
is not as good at implemnetation as another. Instead, I take on issues ala
'how can I do that in this language' instead of fretting over how another
language might be better...

In the case on managed vs. unmanaged. The tradeoff I've noticed is that I
have to learn a new syntax. But the payoff is great... I no longer have to
worry about destruction and ownership of objects! And, in fact, I could
argue that there are problems for which this is the 'only' way to do it
(meaning, the unmanaged way would require writing a managed layer anyway).

An example I like to give is textures in computer games. The same texture
might be used by both objects running around that get created and deleted
all the time, as well as walls that are there some of the time. Only an
overviewer of the ENTIRE process can therefore determine when the texture is
no longer needed and its memory allocation released... that or have walls
and objects 'talk' to each other ala 'I'm done with it if you are' in order
to determine that everybody is done. And if you happen to add some other
type of object that uses the same texture? Then this means multiple
communication amongst all objects. Thus. it is better if something at the
level of the entire application is responsible, and so managed languages do
this for it. This is how it SHOULD be done, so I'll take managed code and
any of the learning curve required over legend code any day (managing object
ownership has always been the source of most if not all of my high-end
problems (past the bugs and typos), so this is great for me!))...
 
Back
Top