469,934 Members | 1,792 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,934 developers. It's quick & easy.

Mixture of Managed and Unmanaged

In my current project (my first project using vc w/ managed extensions), I'm
directly #using <mscorlib.dll>, so it's necessary for me to use the __nogc
and __gc constructs when defining classes or structs.

The concept seems simple... some classes are managed, some aren't. I'm just
wondering if there are any major caveats here... anything I need to take
into consideration or keep an eye on.

I'm only using managed extensions so I can harness easy GUI creation... in
order words, no MFC or direct WinAPI stuff. But in terms of logic, I'd like
to keep everything unmanaged.

Is it not as simple as it seems?

Thanks!

--
Bill Merrill
Lead Developer
Merchant Companion
http://www.merchantcompanion.com
Nov 17 '05 #1
2 1141
TOM
Hi Bill,

I enjoy using the maanged code, hope you will as well. Unmanaged code
has a couple of
things to watch for:

1) You are responsible for constructor (except default) and destructor
invocation for unmanaged
variables, the CLR takes care of lifetime management for managed objects.

2) The CLR can move managed objects (and thus pointers to them) at any
time [usually
during garbage collection]. Thus you cannot pass a pointer to a managed
object to your unmaanged
class - otherwise the pointer could go stale or worse and your unmanged code
will do [very] bad things.
You need to __pin the pointer before passing it to unmanaged code. The
compiler tries to help
you here by making casts to managed objects cause errors in unmanaged code.
PINned pointers
can be cast easily.

3) The #include files for VC7.x, Win32, and WinDDK have a lot of
conflicts, and really mess up a
lot of legacy code. My solution is to isolate unmanaged code to separate
files so that headers don't
cross between the files. You can declare a forward reference pointer to a
non-managed object from
within your managed code without the compiler complaining -- so that helps
reduce the #include
dependency problem.

-- Tom

"The unProfessional" <sp**@shitbits.com> wrote in message
news:qL********************@mpowercom.net...
In my current project (my first project using vc w/ managed extensions),
I'm
directly #using <mscorlib.dll>, so it's necessary for me to use the __nogc
and __gc constructs when defining classes or structs.

The concept seems simple... some classes are managed, some aren't. I'm
just
wondering if there are any major caveats here... anything I need to take
into consideration or keep an eye on.

I'm only using managed extensions so I can harness easy GUI creation... in
order words, no MFC or direct WinAPI stuff. But in terms of logic, I'd
like
to keep everything unmanaged.

Is it not as simple as it seems?

Thanks!

--
Bill Merrill
Lead Developer
Merchant Companion
http://www.merchantcompanion.com

Nov 17 '05 #2
The unProfessional wrote:
In my current project (my first project using vc w/ managed extensions), I'm
directly #using <mscorlib.dll>, so it's necessary for me to use the __nogc
and __gc constructs when defining classes or structs.

The concept seems simple... some classes are managed, some aren't. I'm just
wondering if there are any major caveats here... anything I need to take
into consideration or keep an eye on.

I'm only using managed extensions so I can harness easy GUI creation... in
order words, no MFC or direct WinAPI stuff. But in terms of logic, I'd like
to keep everything unmanaged.

Is it not as simple as it seems?

Thanks!


Yes it is as simple as it seems. This is the power of C++.NET.

Actually this is why I love .NET so much - C++.NET just makes it so
useable in a way which VB6 never ever got even close to.

C# is a great language too - I'd seriously consider writing most of your
app in C# and only use C++.NET to interface with native code (in an
assembly obviously).

David.
Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Eric Twietmeyer | last post: by
5 posts views Thread by Chris Kiechel | last post: by
4 posts views Thread by repstat | last post: by
2 posts views Thread by Martin Zenkel | last post: by
9 posts views Thread by Amit Dedhia | last post: by
25 posts views Thread by Koliber (js) | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.