Re: Is VC++ any "better" than C#?

[Peter Duniho]

On Fri, 18 Jul 2008 10:41:23 -0700, jmDesktop <ne***********@gmail.com>
wrote:

Thanks. One example I came across was video capture. There are folks
out there that have written .net wrappers, but they do not appear to
be "official" and state things like "Don't use this in production."

Well, that's an interesting example, if for no other reason than that the
DirectShow video capture stuff is a reasonably straight-forward and
natural thing to access from .NET using the p/invoke stuff. You may be
referring to the DirectShow.NET project, which I haven't used but
understand to be a pretty good wrapper for DirectShow.

As far as it not being "official" and not for "use in production", that
sort of thing is true for pretty much anything you find outside the normal
Microsoft API documentation. Even plain old C++ samples often come with a
similar caveat.

Personally, I don't think I'd ever write "don't use this in production" in
any sample code I make available, but I certainly feel that there's an
implied "use at your own risk" that goes along with _any_ sample code.

Well, if I do and it breaks, then when can I say? "Uh, I used this
guy's stuff off of CodeProject and yeah, he said not too." If I'm
going to use it I have to understand it to maintain it.

That's true...if you're going to incorporate some code into your own
projects, it may behoove you to understand what the code is doing. If
nothing else, doing otherwise risks getting someone's trojan hidden in
your own code. :)

But to some extent, it's hard to know where to draw the line. If a
component you use in your own code comes from a trusted source, do you
really need to know how it works? After all, I assume you haven't tried
to examine the implementation of .NET to determine for yourself how it
works, even though much of .NET is basically just a wrapper on the
unmanaged Windows API.

Likewise, if you find a library that you can use in your own .NET code and
which has a public API that is completely defined in terms of managed
code, as long as you trust the source, does it matter whether you know
exactly what's going on within the library?

Again, I realize in some such cases there may be warning against using the
library in production code, but to a large extent I believe that those
kinds of warnings are "CYA" measures. Any rational, thinking person
should be able to make a decision for themselves as to whether a publicly
available code sample or library is actually of high enough quality to use
in production code, regardless of whatever warnings come with it, with the
expectation that with adequate testing one can confirm or refute any
assumption of quality.

[...] I have had some C++, just
beginner stuff, so I can follow it and know what the constructs mean,
but that's about it. It's the low level stuff that I'd like to know
how to do because it seems to come in handy at times when looking at
MS's documentation.

Well, as I said...I do believe that there's value in learning the
unmanaged API as well as being familiar enough with C/C++ to navigate any
example code related to the unmanaged API. So if you're of the mind to
learn that, by all means do. But I wouldn't consider it a prerequisite to
writing .NET code, and it may be that you will find it just as effective
to learn as you go along, inasmuch as you need that knowledge at all.

Pete

[jmDesktop]

On Jul 18, 2:03*pm, "Peter Duniho" <[e-mail]>
wrote:

On Fri, 18 Jul 2008 10:41:23 -0700, jmDesktop <[e-mail]*
wrote:

Thanks. *One example I came across was video capture. *There are folks
out there that have written .net wrappers, but they do not appear to
be "official" and state things like "Don't use this in production."

Well, that's an interesting example, if for no other reason than that the*
DirectShow video capture stuff is a reasonably straight-forward and *
natural thing to access from .NET using the p/invoke stuff. *You may be*
referring to the DirectShow.NET project, which I haven't used but *
understand to be a pretty good wrapper for DirectShow.

As far as it not being "official" and not for "use in production", that *
sort of thing is true for pretty much anything you find outside the normal *
Microsoft API documentation. *Even plain old C++ samples often come with a *
similar caveat.

Personally, I don't think I'd ever write "don't use this in production" in *
any sample code I make available, but I certainly feel that there's an *
implied "use at your own risk" that goes along with _any_ sample code.

Well, if I do and it breaks, then when can I say? *"Uh, I used this
guy's stuff off of CodeProject and yeah, he said not too." *If I'm
going to use it I have to understand it to maintain it.

That's true...if you're going to incorporate some code into your own *
projects, it may behoove you to understand what the code is doing. *If *
nothing else, doing otherwise risks getting someone's trojan hidden in *
your own code. *:)

But to some extent, it's hard to know where to draw the line. *If a *
component you use in your own code comes from a trusted source, do you *
really need to know how it works? *After all, I assume you haven't tried *
to examine the implementation of .NET to determine for yourself how it *
works, even though much of .NET is basically just a wrapper on the *
unmanaged Windows API.

Likewise, if you find a library that you can use in your own .NET code and *
which has a public API that is completely defined in terms of managed *
code, as long as you trust the source, does it matter whether you know *
exactly what's going on within the library?

Again, I realize in some such cases there may be warning against using the *
library in production code, but to a large extent I believe that those *
kinds of warnings are "CYA" measures. *Any rational, thinking person *
should be able to make a decision for themselves as to whether a publicly*
available code sample or library is actually of high enough quality to use *
in production code, regardless of whatever warnings come with it, with the *
expectation that with adequate testing one can confirm or refute any *
assumption of quality.

[...] I have had some C++, just
beginner stuff, so I can follow it and know what the constructs mean,
but that's about it. *It's the low level stuff that I'd like to know
how to do because it seems to come in handy at times when looking at
MS's documentation.

Well, as I said...I do believe that there's value in learning the *
unmanaged API as well as being familiar enough with C/C++ to navigate any*
example code related to the unmanaged API. *So if you're of the mind to*
learn that, by all means do. *But I wouldn't consider it a prerequisiteto *
writing .NET code, and it may be that you will find it just as effective *
to learn as you go along, inasmuch as you need that knowledge at all.

Pete

I think I have/had a fundemental misunderstanding here. Does VC++ use
the .NET runtime? I was thinking it did and was just another language
choice like C# or VB.NET. I thought this because all the express
editions were on the same download page. Is VC++ totally separate?

Thanks again.

[Peter Duniho]

On Fri, 18 Jul 2008 12:17:09 -0700, jmDesktop <ne***********@gmail.com>
wrote:

I think I have/had a fundemental misunderstanding here. Does VC++ use
the .NET runtime? I was thinking it did and was just another language
choice like C# or VB.NET. I thought this because all the express
editions were on the same download page. Is VC++ totally separate?

Visual C++ 2008 Express _can_ use the .NET runtime. But you don't _have_
to use the .NET runtime. I don't recall whether the 2008 versions still
include MFC, but I'd guess they do, and of course you can target the
non-.NET Windows API directly. I do recall that the Express version
doesn't provide a complete resource editor for unmanaged code; they really
want you to use .NET. If you're not familiar with the .rc resource file
language, it could be a big headache to construct complicated GUI
applications using VC++ Express. But using .NET isn't mandatory.

If you intend to use the .NET runtime, IMHO a language like VB.NET or C#
is probably more appropriate. I prefer C# because of its similarity to
C++ and what I perceive to be a better, more consistent and more reliable
design with respect to the language. But you can write .NET programs in
any of those languages, and frankly it's mostly a matter of personal
taste. It's not like C++ prevents you from using .NET in ways that would
be otherwise allowed in other languages.

Pete