a pre-beginner's question: what is the pros and cons of .net, compared to ++

[Nick Malik [Microsoft]]

Hello Gerry,

I do enjoy a good argument. However, it appears that this one will not go
very far in actually enlightening anyone. It is my intent that this is my
last full post on this topic. I hope to be clear in this message, as best I
can. I may respond to a single point if, by doing so, I can clarify
something outside the realm of opinion.

framework.

I'm not sure I follow.

C++ can do everything .NET can do and a lot more besides.

If you take C++, and add ATL and MFC ... now you can do more directly in C++
than in C#, mostly because the APIs were designed for C++. The 2.0
Framework is filling in a very large number of the useful calls that were
not present in the current framework, making even this point less important.

There are a few language features in C++ that are not carried through,
TTBOMK, like multiple inheritance but all in all, the languages themselves
are syntactically very similar. Since C# compiles (eventually) to the
machine code level, code written in either language is fast. It's not
really a question of the language.

Maybe "powerful" is the wrong thing to argue about? You can't really say "C#"
in the above line, because it basically means "managed code" and that
limits it just as much as VB.NET or any other "plug-in" language. (as
pointed out by "C.E.O Gargantua" below).

IMHO, Managed code is not much of a limitation. It simply places the C#
code in the context of a comprehensive system of managing system resources.
I argue that C++ is in a similar context, one with fewer features designed
to catch common errors. C++ users call malloc() without thinking about the
fact that there is an entire system for memory management under the
covers... a system you didn't write. This system is easily corruptible. In
..Net, it is much harder to corrupt the heap. That's hardly a limitation.

There's probably plenty "plus" points of .NET you could cite, but I
don't think "powerful" is one of them...

we will have to disagree on that point.

I hear what you're saying here, but personally I'm not convinced. The
current reality is that C++ is far more portable and has fewer
dependencies, not only across platforms, but even across Windows itself!

C++ is more cross-platform that C#. My statement is that it doesn't buy you
as much as you'd think it would. Certainly not enough to cite C++ as more
powerful than C#. To truly write cross platform code in C++, you have to
rely on libraries that cross over the specific platforms that you wish to
bridge. That is equally limiting. IMHO, this is a toss-up.

In terms of being difficult to read, I agree, but outside the realm of
students and beginners, the maintenance factor is a small price to pay
for not being tied to an ever-changing series of incompatible
frameworks. I'm glad I didn't invest in WinForms or Microsoft's "web
controls" for example.

Why not? Win forms will run on Longhorn. Web controls will run on newer
versions of IIS. The thing that is changing is the cutting edge, not the
supported body.

But people are fed up with all these silly "controls"! That's why
so-called "ActiveX" was such as disaster in Internet Explorer and
Outlook Express.

Controls as a form of personalization has certainly not worked out very
well. However, controls as a form of development paradigm, where reusable
bits of U/I code can be developed by one party, and used by another, has
been successful for many years. That paradigm will survive. The language,
and the context it runs in, has to support them. The framework is much more
suitable for this kind of capability. (Of course, controls are not limited
to just the U/I, however, in .Net, it also makes sense, IMHO, to provide an
assembly instead of a control if the intent is not to provide a design-time
interface.)

Regarding the "web" and "web services", it's very simple. You have HTTP,
HTML, XML and various CGI/ISAPI interfaces. Everything else is just
marketing hype from people trying to make it sound complicated. You
certainly don't need .NET to run web services.

True. However, .Net gives you so many nice things that it is difficult to
imagine comparing the two. Very few C++ applications make any real attempt
to use Web Services. Thousands of LOB applications, OTOH, use Web Services
today, largely because the support offered by Visual Studio and the
framework. That is a successful adoption strategy.

I do agree that ASP and ASP.NET are good for web applications and web
scripting, but Microsoft's direction is now moving away from open web
standards and that means .NET will become less attractive. It's already
much more difficult than it should be to leverage x-browser DHTML in
Microsoft's .NET products, whereas it's very easy in ASP, PHP or PERL.
This is where you end up fighting with the framework; in ASP you can add
a few lines of JavaScript/css and it's done in five minutes; with .NET
you have to learn the ins and outs of an oddball "web server control"
and are tied to what it can (and can't) do.

Kinda off topic to comparing C# to C++. Little like my OS/2 sidebar. I'm
not disagreeing though. It's a bit more difficult to simply pass along a
tidbit of JScript. I'm willing to live with the tradeoff.

We also see Microsoft's HTA
technology (which supports open standards) moving towards XAML which
does not - another step backwards in the realm of Enterprise computing,

HTA was fairly specific to IE, and with the open internet being a mixed bag
of browsers (even more so in the past six months with the rise of Firefox),
very few companies invested in HTA outside of the firewall. Therefore the
scope of HTA was limited to the intranet. However, XAML is more powerful
than HTA, and it tailored to be a technology that is not dependent on the
browser (per se) but is actually provided by the workstation environment
itself. This should make the technology more palatible and increase its
adoption. One of the current problems, that XAML will help us solve, is
that too many developers still don't seperate their U/I from the business
layer. Hopefully XAML will provide a clean, consistent, powerful, and
secure thin client interface, which will be adopted by more folks than HTA
was, and will provide an architecturally superior approach to software
development.

It's time we let the browser go back to browsing, and not try to host every
application in the world in it.

Yes, but what about the FrameWork objects themselves? How many of them
are just wrappers around COM objects?

Weren't you just arguing that C++ is more powerful? Now, you are
complaining about portions of the framework that call C++ objects? I find
that confusing.

BTW, from what I understand, the majority of the present framework is
entirely C#, and the new framework takes that percentage higher. Clearly,
as long as you are running on Windows 2000 or Windows XP or even Windows
2003, you have C++ under the covers. Eventually, all of the system services
have a C++ interface on them. I don't find it a contradiction that C# uses
the same interfaces as C++ when it can.

I think the word "if" is the important one here! Is this going to be
ready for Longhorn?

Your argument was that C# couldn't do the job. I'm stating that C# is not
the problem... the interfaces are often designed in such a way that it is
difficult to call them from C#. (to be fair, the men and women who designed
them did so long before C# was invented). I do not know if Longhorn will
provide interfaces that are more suitable to coding a device driver in C#.

I've read all that, but this is way of the topic we were talking about.
I agree about OS/2 in the realm of desktop computers, but I don't see
what this has to do with C++ vs .NET?

The analogy was off topic, I admit. My apologies. The point is that if
someone says "MS invented a new technology but didn't immediatly rewrite
everything to use the new technology to the exclusion of the old," I would
say "bravo!" While you many not have intended it, I took your argument as a
statement that MS was at fault for not immediately dumping millions of lines
of existing, working code. I challenged that. Apparently, without success.
Alas.

Let's say you want to add a new Anti-Virus service account to all
workstations in the OFFICE4 OU - "User Rights Assignment". You can't use
AD and GPO, because doing so would delete all rights of the local
WSxx\ASPNET service accounts, so you have to add the account to the list
of user-rights on the actual machines. Can this be done with .NET, or
can you even list the existing ones with .NET?

I'm not an expert in this area, and I'm going to shut up before I swallow my
feet completely.

I notice you avoided the question about writing a video capture (or
video editing) application with .NET - will this be ready for Longhorn?

As another post points out, you can do this now in C#.

As for the last bit, I had no place to suggest your enterprise wasn't
keeping up with good security practices. My statement was hasty and I
humbly withdraw it.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Gerry Hickman]

Hi Daniel,

Less then one might expect. I would wager that in the average window app the
amount of COM interfaces being called would be roughly equal between
framework wrappers and C++ templates,

OK, try deleting all the COM interface CLSIDs from the registry of a
test workstation, then run a full-featured fully managed .NET
application on it. Does it work?

Also, out of curiosity, how does wrapping a COM object change cause code to
not be machine code?

I didn't mean to imply that 16 layers down it is not machine code. All
I'm asking is whether the framework is just a facade with the same
interfaces in the background, or is it really the brand new, registry
independent, "next generation", "ground braking" technology?

What I'm seeing so far, is a bloated mess with no clear roadmap or
future strategy.

Actually, you can do both now, although video editing is more complicated as
there are no clean, predefined interfaces to access DirectShow or any of the
rest of the windows codec framework. That doesn't mean tehy cannot be

WIA only works on XP, and I'm having trouble finding ANY pure managed
examples of it's use for video capture. All I can find are examples that
use C++.

with WIA capable input devices. The more complicated, DirectX capture
mechanisms would require considerably more...probably somewhere along the
lines of what you'd have to write in C++ without templates for COM support.

But you are saying it's POSSIBLE to use the DirectX capture mechanism
from PURE managed code right? Let's forget how many lines of code for a
minute. Can you clarify or expand this statement?

Now, video encoding and decoding is not something that is appropriate in
managed code as it stands now. The current JITs don't deal with SIMD
instructions well, if at all, and the runtime currently has no way to
express the concepts SIMD uses(note that C++ really doesn't nativly either,
the compiler adds extensions). Without this type of support in the runtime,
the JIT has to guess when its appropriate to attempt such work...its just
not fesible.

Fair point.

However, the only thing this shows, and the only thing much of your
arguments have shown, is that it is maturity, not inherent capability at
question here.

Yes, but some of us have to deliver NOW, not in three years time, and by
then it will all have changed again.

Anyway, as for video tools, I know of only one app written in managed code
and that only provides its UI and some other bits(I can't say I understand
exactly whats managed and whats not, most of the unmanaged stuff looks like
codecs), but that would be CleanerXL, by Discreet:
http://www4.discreet.com/cleanerxl/cleaner.php?id=124

Well I don't see any code on that site, and any fool can switch to
unmanaged C++ when they need to do something useful. The debate is
whether .NET is ready to take on unmanaged C++ and operate without it.

I'm saying that it can't. (I'm happy to be proved wrong, but we need to
see examples based on facts, not links to sites that "may or may not be
managed".

 

[Gerry Hickman]

Hi Nick,

Thanks for the replies.

I do enjoy a good argument. However, it appears that this one will not go
very far in actually enlightening anyone.

I'm not so sure, maybe it's a good thing to thrash out these topics. The
original poster said it had been helpful, and it's raised some
interesting topics for the rest of us.

can. I may respond to a single point if, by doing so, I can clarify
something outside the realm of opinion.
Cool.

If you take C++, and add ATL and MFC ... now you can do more directly in C++
than in C#, mostly because the APIs were designed for C++. The 2.0
Framework is filling in a very large number of the useful calls that were
not present in the current framework, making even this point less important.

This will be one to watch...

There are a few language features in C++ that are not carried through,
TTBOMK, like multiple inheritance
Boo

but all in all, the languages themselves
are syntactically very similar. Since C# compiles (eventually) to the
machine code level, code written in either language is fast. It's not
really a question of the language.

I have to disagree here. Pointer arithmetic and pure byte streams in
memory with no bloated wrappers, layers, frameworks and marshalling?

I argue that C++ is in a similar context, one with fewer features designed
to catch common errors. C++ users call malloc() without thinking about the
fact that there is an entire system for memory management under the
covers... a system you didn't write.

I agree about malloc()

Why not? Win forms will run on Longhorn.

They'll probably run, but you can guarantee they'll be relagated to the
"legacy" section once XAML is in place.

Web controls will run on newer
versions of IIS.

Sorry, I was referring to "client web controls", the ones that now come
under the heading of "archived content" on MSDN.

The thing that is changing is the cutting edge, not the
supported body.

Yes, but this is where I feel Microsoft have lost the plot. What we're
seeing are "gadgets" and "gizzmos", they are not enhancing core business
services. Up until 2001, everything Microsoft did was a shining example
to the rest of the IT industry. While Lotus, Borland (Imprise) and
Netscape played with the color of their latest wizz-bang Flash
animation, Microsoft were handing out free tools and SDKs backed up by
closely-typed, well-written, HTML-based white papers, and that's why I
kept insisting on buying everything Microsoft. Servers, client o/s,
office suites, AD and Exchange.

It was the release of XP that changed my mind, and our budget for XP
upgrades is still sitting in the bank. The other shinanigans with
Internet Explorer and Media player were what really convinced me it was
time to "think the unthinkable" and start gearing up for Microsoft
alternatives. It's the "office assistant" gone mad, and our users in the
XP test lab were bombarded with confusing and unhelpful "enhancements"
that made them come back begging for the clean lines of Win2k. We also
hit other issues such as the anti-privacy policies of DirectX 9.0b and
Media player together with unauthorised sending of information to
WindowsMedia.com. Even with the classic theme and various group policies
it was still stuck in Disney land and this is what they call XP "pro",
LOL! I don't see any return to enterprise computing with Longhorn. No
one has cited a single useful feature, the only thing Microsoft are
claiming is good is the "Avalon" layer, where you can render your
year-end accounts worksheet as a spherical surface, and rotate it around
in 3d space!

Personally, I don't see any of this as "cutting edge". Conversely, the
new Solaris is hard-line big business all the way. Excellent
multi-processor hardware leverage, super clean and adjustable code
footprints and super fast TCP/IP, and they're even talking about giving
it away (well kind of). They don't force you to have "Internet Explorer"
and "Media Player" on production servers, meaning (with Microsoft) you
have to keep patching and rebooting them even when they're in locked rooms!

Controls as a form of personalization has certainly not worked out very
well. However, controls as a form of development paradigm, where reusable
bits of U/I code can be developed by one party, and used by another, has
been successful for many years. That paradigm will survive.

Controls come and go, and in my experience don't last very long. Plus
you get a nasty shock when the vendor changes the control and suddenly
your app is either broken or acts in a completely different way to when
you designed it. Check it out with Media Player 6.4 vs 9.x if you don't
believe me.

HTA was fairly specific to IE, and with the open internet being a mixed bag
of browsers (even more so in the past six months with the rise of Firefox),

I don't see it being that specific, most of what it could do was based
on the DOM and W3C, only the initialization code was specific. It would
be even better if it worked with Mozilla/Firefox too, but since it's
built into Windows it's a reasonable UI option and far smaller footprint
than .NET and also quicker to code. You can also share JScript code
between HTAs, IE, Mozilla, ASP and WSH.

very few companies invested in HTA outside of the firewall. Therefore the
scope of HTA was limited to the intranet. However, XAML is more powerful
than HTA, and it tailored to be a technology that is not dependent on the
browser (per se) but is actually provided by the workstation environment

In other words it's tied to Windows, whereas HTAs could have been
enhanced to work on Macs and Unix?

It's time we let the browser go back to browsing, and not try to host every
application in the world in it.

LOL! It's unfortunate Microsoft didn't think of this about three years ago

Weren't you just arguing that C++ is more powerful? Now, you are
complaining about portions of the framework that call C++ objects? I find
that confusing.

I'm just saying "when it's time to do some real work, they all go
running for C++".

Your argument was that C# couldn't do the job. I'm stating that C# is not
the problem... the interfaces are often designed in such a way that it is
difficult to call them from C#.

I never said C# was a problem. I was careful to avoid the word "C#" and
instead spoke about ".NET", the reason being to clarify "managed" vs
"unmanaged" code.

I like C# because it's ECMA approved.

say "bravo!" While you many not have intended it, I took your argument as a
statement that MS was at fault for not immediately dumping millions of lines
of existing, working code. I challenged that. Apparently, without success.
Alas.

No, I didn't mean to imply that anyone should "immediately dump" anything.

I'm not an expert in this area, and I'm going to shut up before I swallow my
feet completely.

OK, I've looked into this and the LSA is the same on XP as it was on
Win2k and NT4 and even NT 3.51; it's the subsystem that sets up things
like trusts and secure channels when you join a workstation to a domain.
Here's a small extract from the Jan 2005 platform SDK

To administer the local security policy of a local or remote system, you
must call the LsaOpenPolicy function to establish a session with that
system's LSA subsystem. LsaOpenPolicy connects to the LSA of the target
system and returns a handle to the Policy object of that system. You can
use this handle in subsequent LSA function calls to administer the local
security policy information of the target system.

Of course this is only available in C++

As another post points out, you can do this now in C#.

Are you sure? I mean have you actually looked into it, or seen it
working. Will we see the next version of Adobe Premiere written in .NET?
I think we have to be careful here to separate fantasy and reality.

As for the last bit, I had no place to suggest your enterprise wasn't
keeping up with good security practices. My statement was hasty and I
humbly withdraw it.

It's ok. I think the confusion of me saying "LSA" was the problem. I
should have said "Local Security Policy", it's just they keep calling it
the LSA in the SDKs...

And again it reinforces some of what I was saying above. You've got
..NET, but when they need to do something important like manage a secure
channel, they turn to C++ and forget .NET even exists

 

[Daniel O'Connell [C# MVP]]

Less then one might expect. I would wager that in the average window app

OK, try deleting all the COM interface CLSIDs from the registry of a test
workstation, then run a full-featured fully managed .NET application on
it. Does it work?

Likely not, as the windows forms architecture wraps a number of activex
controls, if memory serves(also, fwiw, on some systems the system may well
be using COM to host the CLR). Outside of that, a pretty large portion of
code can be run without using COM, and if someone chose to it wouldn't be
difficult to drop COM entirely(using GTK# instead of WinForms, for example).

Now, tell me, does what one would call a full featured C++ app run? Not one
written to avoid using COM, but one with proper shell or system integration
and windows controls(more than just buttons and text boxes, at that)? I'm
sure its possible, but I would suspect it would take an effort.

I didn't mean to imply that 16 layers down it is not machine code. All I'm
asking is whether the framework is just a facade with the same interfaces
in the background, or is it really the brand new, registry independent,
"next generation", "ground braking" technology?

Of course a large part of it is a facade(I mean come on, half of the STL is
a facade for underlying interfaces as well). The question I have is why you
consider a facade a bad thing. If it wasn't for facades we'd still be using
the NT api, note I don't mean the *Win32* or *posix* api to do a great deal,
I mean the kernel API and whatever we wrote to support it. Facades are the
rule, not the exception.

Are there any specific classes\functions you are curious about? String is
one I can point to as being partially implemented in unmanaged code, but
those are internal calls to the frameworks string management routines not
the stl's string implementation or what have you.

What I'm seeing so far, is a bloated mess with no clear roadmap or future
strategy.

It'd be easy to make a snide retort here, but I don't think I will. I must
say I've not gotten the impression you've ever actually researched the
framework or have much of an idea of how it really works.

WIA only works on XP, and I'm having trouble finding ANY pure managed
examples of it's use for video capture. All I can find are examples that
use C++.

I don't recall if there are any examples or not, I was toying with it ages
ago and I'm pretty sure I got managed code to work with it. Again, if your
definition of "pure" is no COM interop, then your standards are too high.
Its like saying "pure" C++ doesn't ever access the OS. It'd be ridiculus,
what good is a program that cannot access the file system or allocate
memory?

But you are saying it's POSSIBLE to use the DirectX capture mechanism from
PURE managed code right? Let's forget how many lines of code for a minute.
Can you clarify or expand this statement?

PURE as in no unmanaged code? If that is your definition of pure a managed
executable couldn't even execute, since the JIT is written in unmanaged
code.

Anyway, the DirectX capture mechanism is COM based, thus you cannot really
avoid using COM. However, it is quite possible to interop the required COM
interfaces.

Yes, but some of us have to deliver NOW, not in three years time, and by
then it will all have changed again.

Sure. And some of us have to write applications that will fit in 256k of
memory along with any libraries, etc. Some of your arguments thus far have
been almost like "Its not good for what I do so it must suck". If I'm
writing an application for a small embedded machine, chances are C++ with
the STL is not the best approach(a lightweight C\C++ might be, but thats a
different matter, since we're talking more than language here).

Well I don't see any code on that site, and any fool can switch to
unmanaged C++ when they need to do something useful. The debate is whether
.NET is ready to take on unmanaged C++ and operate without it.

I did expect you'd figure out that it was a commercial product and actually
*download* the trial and examine it. Perhaps that was a touch to high of
expectations.

Anyway, the question this debate is targeting is far to finely defined. C++
is good for a lot, but at this point I do not think it should be automatic
for anything but what would be classed as high to high-medium performance.
..NET, Java, python, VB6 and Delphi all already are far easier to use than
C++ with performance that is quite suitable for the medium to low
performance range(with Delphi probably capable of standing toe to toe with
C+ in the medium-high range). The problem you have, I really think, is
assuming that things need to supercede C++ to matter. It was a luxury C++
developers had for a long time, the concept of C++ ever becoming irrelevent
was pretty far fetched up until right about the 2ghz barrier was
broken(atlesat for me). At this point you can see that eventually it will
die off, perhaps even in your lifetime(I expect it will within mine,
although I imagine I will not still be programming anything more complex
than a VCR by that point in my life).

Anyway, the question is not can .NET operate without C++, but can .NET
replace C++ in some of its old domains(in other words, is it relevent?).

It can, and it will, and as time goes on more and more of C++'s strongholds
will fall to .NET, java, python and others. C++ will likely always be
required in some small manner, if for no reason other than that its
established and there will always been a need for low level code(very bottom
level of the kernel and bios). And code will always rely on C++ in some
manner. But it will not always be the #1 language in use. Other languages
are not huge armies assaulting C++'s citadel with the intent of toppling it
overnight, they are little guerilla bands slowly taking their share of the
territory(or marketshare as it is in this circumstance). There are many of
them, really, the ones I've listed are the largest but far from the only
languages\runtimes that are growing fesible for more than academic or geeky
applications.

 

[Guest]

Comments inline



Also, Lester, note that a key difference in the design of
the DotNet platform and the JVM is that the JVM was built
to support Sun's idea of the one right language, Java.
DotNet was designed to be language agnostic.

Java: any platform, one virtual machine, one language.
Tools were left to the users to work out.

DotNet: any language, one primary virtual machine, one
primary platform, but open enough to support multiple
platforms. Google for the Mono project for details.
Tools were designed by MS, largely unified tool set
for any language *


* imperfectly done, but that was the goal. getting better.

Well honestly there is no real difference between Java Bytecode and CLI.
After all there are different languages you can compile to Java Bytecode
(http://www.robert-tolksdorf.de/vmlanguages.html). And VB.NET is not the VB
you knew.

CLI does "shine through" any of the .NET languages. You just can´t change
that much...

From my (a bit limited) experience I´d recommend to anyone trying .NET to
try C# only, as it offers (from my view) the most advanced language concept.

The CLR and a JAVA VM are not very different
(http://weblogs.asp.net/brada/archive/2005/01/12/351958.aspx)

 

[Guest]

:

....

You'd learn a modern, clean, purely-object-oriented language. If you ever
thought "why do I need all those different string types like char*,
wchar_t*, string, CString, BSTR...", then should really give C# a try.

Niki

Well C# were a lot "purely-object-oriented" if it would not have the concept
of unsafe code.

Or if you could not do your own memory-layout.

Or if you would not need the above.

 

[Niki Estner]

...
Well honestly there is no real difference between Java Bytecode and CLI.
After all there are different languages you can compile to Java Bytecode
(http://www.robert-tolksdorf.de/vmlanguages.html). And VB.NET is not the
VB
you knew.

CLI does "shine through" any of the .NET languages. You just can´t change
that much...
...

You didn't really check many languages then, I'd guess.
Have a look at some of these:
http://www.arunmicrosystems.netfirms.com/others.html

Niki

 

[Niki Estner]

:

...


Well C# were a lot "purely-object-oriented" if it would not have the
concept
of unsafe code.

Or if you could not do your own memory-layout.

Maybe (depends on your understanding of the term "purely-object-oriented"),
but it would be a lot less usable as well.

Or if you would not need the above.

Many programming languages have been build with that paradigm, none of them
really became mainstream. Language designers can't possibly forsee every
problem programmers will face, so pragmatic decisions are often a good
choice (unless you want to create a language for purely academical reasons).
Good example: AFAIK Pascal (as N. Wirth designed it) didn't have casts; But
it really got usable (and mainstream) with Turbo Pascal - which introduced
casts and many other "impure" language concepts. You see the moral?

Niki

 

[Guest]

You didn't really check many languages then, I'd guess.
Have a look at some of these:
http://www.arunmicrosystems.netfirms.com/others.html

Niki

If it weren´t so, just why did the change VB into VB.NET, and why is managed
C++ a lot more restrictive?

You CANNOT have a runtime that has certain requirements, and expect that
every language you can think of can be transformed into something that will
run on that runtime;

The runtime is implicitly defining limits.

 

[Guest]

Maybe (depends on your understanding of the term "purely-object-oriented"),
but it would be a lot less usable as well.

Well I think there is an agreement that it is very similar to Java. Just why
do you think C# needs any of the above more than Java does? Because of COM
Interop? This is just poor excause for a lack of willpower concerning a real
change.

Many programming languages have been build with that paradigm, none of them
really became mainstream. Language designers can't possibly forsee every
problem programmers will face, so pragmatic decisions are often a good
choice (unless you want to create a language for purely academical reasons).
Good example: AFAIK Pascal (as N. Wirth designed it) didn't have casts; But
it really got usable (and mainstream) with Turbo Pascal - which introduced
casts and many other "impure" language concepts. You see the moral?

Niki

Of course the "purest" way is not allways the best. It´s just that C# is so
full of pragmatic decisions like: "Oh this safes developers a couple of lines
of code" that I would not consider it a good example for an OO programming
language.

That aside Turbo Pascal afaik become very popular because of it´s fast
compiler (as the primary reason).

 

[Sean Hederman]

Hi Nick,
To administer the local security policy of a local or remote system, you
must call the LsaOpenPolicy function to establish a session with that
system's LSA subsystem. LsaOpenPolicy connects to the LSA of the target
system and returns a handle to the Policy object of that system. You can
use this handle in subsequent LSA function calls to administer the local
security policy information of the target system.

Of course this is only available in C++

From PInvoke.NET
(http://www.pinvoke.net/default.aspx/advapi32.LsaOpenPolicy):

[DllImport("advapi32.dll", SetLastError=true, PreserveSig=true)]
static extern uint LsaOpenPolicy(
ref LSA_UNICODE_STRING SystemName,
ref LSA_OBJECT_ATTRIBUTES ObjectAttributes,
uint DesiredAccess,
out IntPtr PolicyHandle
);

 

[Niki Estner]

If it weren´t so, just why did the change VB into VB.NET, and why is
managed
C++ a lot more restrictive?

Dunno why they changed VB that much, probably they felt it was already
messed up and would need a little cleaning.
BTW: Did you ever compile a native project into a mixed-mode one? If you
had, you would know MC++ isn't more restrictive than C++ is.
I'd suggest you have a look at the managed versions of Haskel, SML, Perl and
Eiffel before commenting on that topic again. It's hard to take you serious
otherwise...

You CANNOT have a runtime that has certain requirements, and expect that
every language you can think of can be transformed into something that
will
run on that runtime;

Ever heared of the term "turing-completeness". Look it up. In a good
textbook, you should find a proof for what you claim to be impossible.

The runtime is implicitly defining limits.

That's why C#'s designers allowed unsafe blocks, custom memory layout and
other pragmatic constructs, to let you get out of those limits if you need
to. Weren't you the one who said this made it "non-pure-OO"??? I think you
start contradicting yourself...

Niki

 

[Gerry Hickman]

Hi Daniel,

Likely not, as the windows forms architecture wraps a number of activex
controls,

OK, now we're getting somewhere.

if memory serves(also, fwiw, on some systems the system may well
be using COM to host the CLR). Outside of that, a pretty large portion of
code can be run without using COM,
OK.

Now, tell me, does what one would call a full featured C++ app run? Not one
written to avoid using COM,

No, but the difference is that C++ does not pretend to be "new" or
"different" or "cutting edge" or "independent of COM", whereas .NET
does. Someone recently commented in this group "COM must die", so I just
want to get the facts straight.

Of course a large part of it is a facade

OK, that's my point.

(I mean come on, half of the STL is
a facade for underlying interfaces as well).

Again, the difference is, that it does not claim to be otherwise...

Are there any specific classes\functions you are curious about?

Not really, but thanks for letting me know about String.

I don't recall if there are any examples or not, I was toying with it ages
ago and I'm pretty sure I got managed code to work with it. Again, if your
definition of "pure" is no COM interop,

Yes of course I'm excluding COM interop! If you say "C#.NET can do this
and C#.NET can do that", then obviously we're talking about what Nick
calls the "cutting edge" - fire up VS.NET and pretend it's just like VB6
- drag and drop a few "controls" and double click to add some event
handlers. I agree I should have stated that more clearly, but any fool
can make calls to COM and get COM functionality, but suddenly the whole
teddy-bear land of .NET comes crashing to a halt, and if you're going to
use COM interop, you may as well cut out all the nonsense, bloat and
middle-layers and make the calls in C++.

The bottom line is back to where we started. .NET is "limited". It can't
do video capture and it can't manage Local Security Policy and it would
not surprise me if v2.0 is just as bad.

PURE as in no unmanaged code? If that is your definition of pure a managed
executable couldn't even execute, since the JIT is written in unmanaged
code.

Obviously I'm talking about "within the .NET environment", not what goes
on behind the scenes. What use is it, if you have to keep making calls
to COM and unmanaged code everytime you need to do something useful?
There's also too much of it that's dependent of certain operating
systems being installed (e.g. WIA on XP).

Anyway, the DirectX capture mechanism is COM based, thus you cannot really
avoid using COM. However, it is quite possible to interop the required COM
interfaces.

OK, well that's clear now.

Sure. And some of us have to write applications that will fit in 256k of
memory along with any libraries, etc. Some of your arguments thus far have
been almost like "Its not good for what I do so it must suck".

Not my intention, and I didn't say it sucks, I just said it was limited
and gave examples.

I did expect you'd figure out that it was a commercial product and actually
*download* the trial and examine it.

You mean reverse engineer it? I actually received Cleaner with Adobe
Premiere but quickly uninstalled it as I disliked it in quite a serious
way. I prefer open source tools for encoding/decoding.

developers had for a long time, the concept of C++ ever becoming irrelevent
was pretty far fetched up until right about the 2ghz barrier was
broken(atlesat for me). At this point you can see that eventually it will
die off, perhaps even in your lifetime

That's fine with me if it dies off, provided we have a viable
alternative - at present we do not. For example do you think we'll be
seeing the next version of Adobe InDesign or Photoshop written in .NET,
or how about Quake v4?? You are claiming that .NET is just as powerful
and just as fast so the above should work just fine...

Anyway, the question is not can .NET operate without C++, but can .NET
replace C++ in some of its old domains(in other words, is it relevent?).

I think it was really good for server side web, but even that's becoming
more of a mess than it should be, due to disparate framework versions
and certain features being tied to certain o/s versions.

It can, and it will, and as time goes on more and more of C++'s strongholds
will fall to .NET, java, python and others.

Don't forget PERL, but you are forgetting this is Microsoft. Java,
python and PERL do not exist, and currently Microsoft's own core SDK and
the very heart of what makes Windows tick, is still only accessible from
C++, and I'm talking here about the Jan 2005 SDK docs, not something
from years ago. There's been no serious windows development since 2001,
everything since is veneer. Scratch away the surface and it's NT 3.51 at
the core, and if you need any really useful information about windows,
you'll actually have to load up the NT 3.51 docs, because that's the
last place it was properly documented. Where is the resource kit for
Windows Server 2003 and why is it that this so-called "enterprise"
server forces the installation of security risk teddy-bear components
such as IE and Media Player?

Not only that, but have you noticed Microsoft have started to silently
remove pages from the MSDN they consider to be "a bit too complicated"
for the new breed of XP and VB.NET heads? For example in Jan 2005 MSDN
they've taken down the resource kits which include chapters on things
like Active Directory domain and forest strategy.

People like me (who work on big networks) are getting the message that
Microsoft are losing interest in this market sector and I understand why
- It's much more profitable to have home users downloading pay-per-view
movies EVERY night than worry about a few volume license customers who
only upgrade once a year.

 

[Daniel O'Connell [C# MVP]]

Hi Daniel,



OK, now we're getting somewhere.


No, but the difference is that C++ does not pretend to be "new" or
"different" or "cutting edge" or "independent of COM", whereas .NET does.
Someone recently commented in this group "COM must die", so I just want to
get the facts straight.

C++ cannot pretend to be new...but I'd bet that it did years back when it
was new. Every single app in existance that claims to be written in C++
actually interfaces with C and assembly code somewhere within the operating
system(and windows apps using COM may well be accessing VB6 or using dlls
may be calling into delphi). So are you sure it actually doesn't pretend to
be something?

Also, where did you hear the .NET framework is independent of COM? .NET is
the next step of COM and if you dig deep enough into the .NET runtime you'll
find references *to* COM3, as .NET was once known. The two are entirely
inseperable.

Classic COM has some huge weaknesses: VARIANT, no overloading, and it was
hell to write without either alot of knowledge or alot of templates to do
the work for you. .NET fixes all of those, increases portability(no
recompilation for 64 bit systems, most of the time(it is possible to compile
for 32 or 64 bit processors in some circumstances for performance reasons)),
and retains backwards compatibility with both COM and the classic Win32 api.
What disgusts me most about your claims is that while C++ is accessing
librarys and COM for functionality, you seem to think that that is ok and
means that functionality is only available to C++, while no other language
shoudl be allowed to access it. That really smacks of a level of arrogance.

Again, the difference is, that it does not claim to be otherwise...

Nor does .NET, it certainly isn't my fault if you think it does. I would bet
most people think the STL isn't a facade either.

Yes of course I'm excluding COM interop! If you say "C#.NET can do this
and C#.NET can do that", then obviously we're talking about what Nick

Which, frankly, is stupid, and this argument is losing its point quickly. If
your standards are this high the only way any language but C++ can be
relevent would be to entirely throw C++ away and start from scratch...I
don't know about you but I'm not interested in

The bottom line is back to where we started. .NET is "limited". It can't
do video capture and it can't manage Local Security Policy and it would
not surprise me if v2.0 is just as bad.

Neither can C++...without access to a library. Its not like C++ inherently
has the ability to modify your local security policy, it has to call a
system API, period. C++ lacks this ability as well.
C++ cannot inherently do video capture either, since you have to import COM.

Obviously I'm talking about "within the .NET environment", not what goes
on behind the scenes. What use is it, if you have to keep making calls to
COM and unmanaged code everytime you need to do something useful? There's
also too much of it that's dependent of certain operating systems being
installed (e.g. WIA on XP).

I guess our opinoins of useful are different. I know your examples are
blindingly obviously designed to get the answer you want. No, I cannot write
anything in .NET without calling the API, since it has to call VirtualAlloc
or CreateFile eventually to do something. However I can do plenty of useful
stuff without accessing COM, I do it every day.

You mean reverse engineer it? I actually received Cleaner with Adobe
Premiere but quickly uninstalled it as I disliked it in quite a serious

It doesn't take much, the version stamp would have been enough to figure it
out.

way. I prefer open source tools for encoding/decoding.

Not a surprise, can't say I expected any different(you strike me as an open
source guy)

That's fine with me if it dies off, provided we have a viable
alternative - at present we do not. For example do you think we'll be
seeing the next version of Adobe InDesign or Photoshop written in .NET, or
how about Quake v4?? You are claiming that .NET is just as powerful and
just as fast so the above should work just fine...

I never claimed either, and if you recall I told you that video encoding
wouldn't be valid because of runtime deficencies. That goes equally well for
other high performance apps....(also, since you consider DirectX off limits,
its pretty hard to write a game since you can't draw to the screen).

However, heres the rub. I use photoshop about 1/100th as often as I use
Outlook or Word or IM programs, each of which would run in managed code
without much of an issue. So why is C++ that important if its usage is only
needed in an app I run less often than I run anything on my machine?

I think it was really good for server side web, but even that's becoming
more of a mess than it should be, due to disparate framework versions and
certain features being tied to certain o/s versions.

Again I do wonder if you have any real knowledge of the system or just
preinclinations.

And, like Nick before me, I am finished with this conversation. You have
quite clearly already made up your mind(despite your protests you'd like to
be convinced) and I don't believe this discussion will get anywhere. You
will refuse to see any point I make.

I must say I have been disappointed in your arguments...they range from
irrelevent to wrong.

 

[Gerry Hickman]

Hi Daniel,

However, heres the rub. I use photoshop about 1/100th as often as I use
Outlook or Word or IM programs,

I agree, but is Word 2003 written in .NET, and if not why? It's been
around plenty long enough and Microsoft have huge teams of programmers
with excellent .NET skills.

You
will refuse to see any point I make.

I've carefully read everything you said, I just may not agree with it.

I must say I have been disappointed in your arguments...they range from
irrelevent to wrong.

Well the original thing that started the argument was that I said C++ is
more "powerful" than .NET, and then I asked about PhotoShop, Premiere
and Quake4. People in this thread claimed that .NET was "fast" and "more
powerful than C++", so I ask again, will we see Photoshop, Premiere,
InDesign and Quake4 using .NET in their next versions?

If the answer is "no" then I don't think your disappointment stated
above is reasonable. If the answer is "yes" then I am clearly the person
who is in the wrong.

 

[Sean Hederman]

Hi Daniel,


I agree, but is Word 2003 written in .NET, and if not why? It's been
around plenty long enough and Microsoft have huge teams of programmers
with excellent .NET skills.

Are you really being serious? Writing Word 2003 would mean rewriting the
entire office suite since they are all interdependent. There is also tonnes
of code throughout the world that works off Offices COM interfaces. What
exactly would be the point of rewriting such a massive product suite into
..NET? I don't care how many programmers they have, it's a waste of time and
effort.

I've been reading these posts, and what I can't get into my head is this
rabid hatred you seem to have for COM Interop. Here's a hint, COM Interop
allows you to use COM objects within your .NET code as if they were .NET
objects. Admittedly there is a slight performance hit, but that's actually
improving with later versions of the Framework. For these sins, you feel
that everything written in COM should be destroyed and rewritten in .NET?

Hah! Here's a hint, technology builds on the past. It is mainly
evolutionary, and only very, very rarely revolutionary. Even when it's
revolutionary, it almost always uses existing technology as a base. I'm glad
that you, in your infinite wisdom, have come up with a new paradigm for us
all to follow when switching between inter-compatible frameworks. But you
know what, I think I'll stick with the simple "If it ain't broke, don't fix
it".

 

[Jon Skeet [C# MVP]]

I agree, but is Word 2003 written in .NET, and if not why? It's been
around plenty long enough and Microsoft have huge teams of programmers
with excellent .NET skills.

There's no compelling reason to convert Office to .NET immediately.
Over time I suspect there will be more and more bits written in .NET,
and some will gradually replace the unmanaged part. Just replacing them
for the sake of it all in one go, however, would be a huge waste of
resources. Don't forget that there's also the backwards compatibility
problem in terms of plug-ins which need to be able to interface with
Office.

I've carefully read everything you said, I just may not agree with it.


Well the original thing that started the argument was that I said C++ is
more "powerful" than .NET, and then I asked about PhotoShop, Premiere
and Quake4. People in this thread claimed that .NET was "fast" and "more
powerful than C++", so I ask again, will we see Photoshop, Premiere,
InDesign and Quake4 using .NET in their next versions?

If the answer is "no" then I don't think your disappointment stated
above is reasonable. If the answer is "yes" then I am clearly the person
who is in the wrong.

I think the problem is that you're equating "more powerful" with "the
better option for every single possible application". That's simply not
true. I think .NET is more powerful than C++ in terms of ease of
development and maintenance, and that for many/most applications it's
easily fast enough. There are some areas where it's significantly
slower than native code - in particular when you'd need fairly direct
hardware access - and things like games tend to concentrate very
heavily on getting close to the hardware for performance reasons.

There are also the reasons I mentioned above with Office - you don't
rip out an existing, working code base for no good reason. Even though
developing in .NET is easier than developing in C++, converting a large
code base is still extra work.

 

[Gerry Hickman]

Hi Sean,

Are you really being serious? Writing Word 2003 would mean rewriting the
entire office suite since they are all interdependent.

Sure, and with the "excellent COM interop" you outline below, it should
not be a problem to write ALL the applications in .NET

I've been reading these posts, and what I can't get into my head is this
rabid hatred you seem to have for COM Interop.

No, it's the other way round. The hype of .NET is that it does not rely
on COM and the registry. What this thread has proved is that not only is
it inextricably linked to COM, but that Microsoft's own product teams
have been incapble (or unwilling) to migrate.

It seems to me that the "real" programmers at Microsoft (flagship lines)
actually AGREE with me that C++ is still "more powerful" and "faster"
than .NET - that's all I was saying.

 

[Gerry Hickman]

Hi Jon,

There's no compelling reason to convert Office to .NET immediately.
Over time I suspect there will be more and more bits written in .NET,
Cool!

I think the problem is that you're equating "more powerful" with "the
better option for every single possible application". That's simply not
true. I think .NET is more powerful than C++ in terms of ease of
development and maintenance, and that for many/most applications it's
easily fast enough. There are some areas where it's significantly
slower than native code - in particular when you'd need fairly direct
hardware access - and things like games tend to concentrate very
heavily on getting close to the hardware for performance reasons.

Makes sense. You do have to ask yourself, however, how many big-name
flagship products have been released in .NET so far? When Visual C++ 5.0
and 6.0 were released, every big-name vendor grabbed a copy and released
products instantly based on them.

..NET has been around for ages now (I remember the betas), and yet hardly
anyone in the big leagues is showing any interest. From what I can tell
most of the interest is from the VB6/Student market.

 

[Nick Malik [Microsoft]]

Makes sense. You do have to ask yourself, however, how many big-name

flagship products have been released in .NET so far? When Visual C++ 5.0
and 6.0 were released, every big-name vendor grabbed a copy and released
products instantly based on them.

.NET has been around for ages now (I remember the betas), and yet hardly
anyone in the big leagues is showing any interest. From what I can tell
most of the interest is from the VB6/Student market.

Most of the software written each year is not written for commercial
products. It is written by IT departments inside companies. These folks
never were big on C++ because of the high costs of maintenance. There are
10 developers in this market for every one in commercial software.

And they have switched to .Net in droves. Many organizations that had
switched to Java have switched back.

Millions of lines a year in .Net. That's success.

Oh, and Biztalk 2004, a high-performance transaction server, is written
entirely in .Net.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--