vc in .NET

[BilfFord X]

I'm shopping around to figure out where I'm going to devote my finite
energies as I get back into the windows world. A question that pops up
right away for a lot of fellas is, if I'm going to be doing stuff in the dot
net world, do I go c++/CLI or c#. Some people might be able to do both, but
I would go cross-eyed. Legacy code is not as big an issue for me as opposed
to a refusal to leave the c world behind completely. I'm given to believe
that I can wrap c stuff so as to make it compile the way I want, i.e. as ISO
C, and then can make that available to the managed environment. An informed
opinion from nearby was: "If anything, I would interop with it, through the
P/Invoke layer, COM interop, or by creating managed wrappers for it."
news:%2****************@TK2MSFTNGP04.phx.gbl...
This answer raises as many questions as it solves, as, for example, I
thought the managed environment was the end of COM. I was hoping that there
would be persons around here looking at this scenario in their rearview
mirror who might have advice. cheers, bfx

[William DePalo [MVP VC++]]

"BilfFord X" <in*****@invalid.nyetwrote in message
news:44***********************@news.usenetmonster. com...

I'm shopping around to figure out where I'm going to devote my finite
energies as I get back into the windows world. A question that pops up
right away for a lot of fellas is, if I'm going to be doing stuff in the
dot net world, do I go c++/CLI or c#.

Nine times out of ten, C# is the right choice, IMO.

Some people might be able to do both, but I would go cross-eyed.

:-)

I'm given to believe that I can wrap c stuff so as to make it compile the
way I want, i.e. as ISO C, and then can make that available to the managed
environment.

Well, you certainly can not compile a file with the C compiler AND have it
generate managed code. Of course, you can do that with the C++ compiler.

Actually there are at least two managed versions of C++ for .Net - there is
the Managed Extensions for C++ that is compatibile with version 1.1 of the
..Net platform and C++/CLI (hopefully "soon" to be an ECMA/ISO standard) that
is available on the 2.0 version of the framework.

An informed opinion from nearby was: "If anything, I would interop with
it, through the P/Invoke layer, COM interop, or by creating managed
wrappers for it."

That's one way to go.

This answer raises as many questions as it solves, as, for example, I
thought the managed environment was the end of COM. I was hoping that
there would be persons around here looking at this scenario in their
rearview mirror who might have advice. cheers, bfx

I think Nick was adopting the "if it ain't broke, don't fix it" stance in
that post. In other words I think he favors creating a "little" shim to sit
between a managed consumer and a native producer. That's not a bade choice
when the producer's code base is large.

Writing the shim in a managed version of C++ is likely be the easiset way to
go as both MC++ and C++/CLI, IMO, shine where interop is the goal. YMMV.

Regards,
Will

[Tamas Demjen]

BilfFord X wrote:

if I'm going to be doing stuff in the dot net world, do I go c++/CLI or c#.

It depends what you're doing, and how much C++ experience you have. I'm
a very big C++ advocate, so here's my point of view, which is nothing
more than an opinion.

If you need to mix unmanaged and managed code extensively, C++/CLI gives
you the most control, flexibility and ease of use. C++ interop just works.

For visual form development C# has the advantage. The biggest problem
with C++/CLI is that the designer automatically puts your event handlers
in the .h file, instead of generating an implementation entry in the
..cpp file. Also C# 2.0 has some very nice features that won't be
available in C++ anytime soon, such as partial classes, labmda
expressions (anonymous event handlers), and LINQ in the next version of
VS. The C# compiler is incomparably faster, and there are fewer things
to worry about. Despite being a huge C++ fan, even I'd consider using C#
for developing large, feature rich GUIs. But I'd separate the business
logic functionality from the form's code.

I personally choose C++/CLI for non-visual classes, and even for visual
components, where the designer is not involved, because I feel more
comfortable with that. But this is truly your choice. It really doesn't
make sense to start an argument about it.

If you're good at C++ and feel very familiar with the language, try
C++/CLI and chances are you'll like it. If you have reservations
regarding ISO C++, or you're not fluent with the language, don't bother,
just jump to C# instead. The C# using syntax can achieve the same level
of exception safety as the C++/CLI stack syntax, and value classes can't
have destructors in C++/CLI either. There are no templates in C#, but
generics are available in both languages. Constant member functions are
not supported in C++/CLI either.

Tom

[BilfFord X]

[x-posted to microsoft.public.vc.mfc]

Thanks all for replies. I'm at the point where I need to make a decision
and run with it. There are two things that aren't helping me right now.
One is that I can't make a screen dump on xp. My vision is such that if I'm
doing something like debugging, I need to do it at arm's length with a pen,
or post it on my site to let people smarter than me look at it. This was
the only use I made of Word: to use as a container to paste in the pixels
after hitting the printscreen (or alt printscreen). If saved as html, my
pixels become a jpeg under win98se and winMe. Winxp, in so many ways
superior, doesn't let me do it. How do I get around this?

Also, is WinFX supported in vc2005Express? cheers, bfx

"Tamas Demjen" <td*****@yahoo.comwrote in message
news:%2******************@TK2MSFTNGP02.phx.gbl...

BilfFord X wrote:

>if I'm going to be doing stuff in the dot net world, do I go c++/CLI or
c#.

It depends what you're doing, and how much C++ experience you have. I'm a
very big C++ advocate, so here's my point of view, which is nothing more
than an opinion.

If you need to mix unmanaged and managed code extensively, C++/CLI gives
you the most control, flexibility and ease of use. C++ interop just works.

For visual form development C# has the advantage. The biggest problem with
C++/CLI is that the designer automatically puts your event handlers in the
.h file, instead of generating an implementation entry in the .cpp file.
Also C# 2.0 has some very nice features that won't be available in C++
anytime soon, such as partial classes, labmda expressions (anonymous event
handlers), and LINQ in the next version of VS. The C# compiler is
incomparably faster, and there are fewer things to worry about. Despite
being a huge C++ fan, even I'd consider using C# for developing large,
feature rich GUIs. But I'd separate the business logic functionality from
the form's code.

I personally choose C++/CLI for non-visual classes, and even for visual
components, where the designer is not involved, because I feel more
comfortable with that. But this is truly your choice. It really doesn't
make sense to start an argument about it.

If you're good at C++ and feel very familiar with the language, try
C++/CLI and chances are you'll like it. If you have reservations regarding
ISO C++, or you're not fluent with the language, don't bother, just jump
to C# instead. The C# using syntax can achieve the same level of exception
safety as the C++/CLI stack syntax, and value classes can't have
destructors in C++/CLI either. There are no templates in C#, but generics
are available in both languages. Constant member functions are not
supported in C++/CLI either.

Tom

[Tamas Demjen]

BilfFord X wrote:

One is that I can't make a screen dump on xp.

There are many inexpensive applications for making screen shots. Help
and Manual (http://helpandmanual.com/) has a good one built in, or you
can try Hyper Snap, just to mention two I used before. I'm sure there
are countless great screen shotter tools. Or simply use Microsoft Paint,
it can save pictues as PNG files.

Also, is WinFX supported in vc2005Express? cheers, bfx

WinFX was just renamed to .NET 3.0. A technology preview is downloadable
from Microsoft:

http://msdn.microsoft.com/winfx/

The release notes indicate that you can use it with the Express Edition,
but be careful, it's a preview only, not intended for development. The
final version will be available in the next Visual Studio, code named Orcas.

Tom