a pre-beginner's question:
what is the pros and cons of .net, compared to ++
I am wondering what can I get if I continue to learn C# after I have learned
C --> C++ --> C# ??
I think there must be many know the answer here.
thanks
BR
----------------
Lester
44  1882 
Lester
Simply answer, it is a next step in the evolution of that language, and than
you ask "yes and than?
It is more logical to write, however as with all evolutions are there staid
some legacy, where the users are used too however could have been as well
changed however that is not done direct.
I give no examples because that goes always to endless discussions.
Cor
"lester" <ho**************@etang.com> schreef in bericht
news:e7******************@TK2MSFTNGP15.phx.gbl... a pre-beginner's question:
what is the pros and cons of .net, compared to ++
I am wondering what can I get if I continue to learn C# after I have
learned
C --> C++ --> C# ??
I think there must be many know the answer here.
thanks
BR
----------------
Lester
thank you Cor,
maybe I have to study some abc about .NET before I know for whom .NET is
designed.
about C++, we should say"C++ really makes program very natural, simple, easy
to understand, easy to maintain..., than C."
about C# we should say"????"
Anyone can tell your understanding of .NET(esp, C#) to me?
------------
Lester
"Cor Ligthert" <no************@planet.nl> дÈëÏûÏ¢ÐÂÎÅ
:OP**************@TK2MSFTNGP09.phx.gbl... Lester
Simply answer, it is a next step in the evolution of that language, and
than you ask "yes and than?
It is more logical to write, however as with all evolutions are there
staid some legacy, where the users are used too however could have been as well
changed however that is not done direct.
I give no examples because that goes always to endless discussions.
Cor
"lester" <ho**************@etang.com> schreef in bericht
news:e7******************@TK2MSFTNGP15.phx.gbl...a pre-beginner's question:
what is the pros and cons of .net, compared to ++
I am wondering what can I get if I continue to learn C# after I have
learned
C --> C++ --> C# ??
I think there must be many know the answer here.
thanks
BR
----------------
Lester
"lester" <ho**************@etang.com> wrote in
news:e7******************@TK2MSFTNGP15.phx.gbl... a pre-beginner's question:
what is the pros and cons of .net, compared to ++
(I assume "++" means "C++"?)
You can write perfect .NET programs using C++: Types marked as "managed"
(using some cryptic new keywords) will benefit of .NET's advantages: Garbage
Collection, Reflection, language interoperability to name just a few. Plus,
you can use any managed type (e.g. types from the .NET framework library) in
your "ordinary" C++ code.
On the other hand, this also means you have another String class, another
Array class, another memory management pattern (...) to choose from - as if
C++ didn't have enough already.
That's the point where C# comes in: It sacrifices backwards compatiblity for
clarity - one string type, one array type...
I am wondering what can I get if I continue to learn C# after I have
learned
C --> C++ --> C# ??
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
Lester,
..NET is a platform on which programs run. You then use a programming
language (like C#, or VB.NET, or C++/CLI) to write programs for that
platform. The .NET platform is a bit different from the standard
Windows/Linux platforms, and very similar to the JVM in that there is a
unified type system, and garbage collection. Now, C++ doesn't port to this
kind of world very easily, so they created C#. C# is built with the .NET
platform in mind. It's a bit simpler than C++, and waaay easier to program
in. For that you sacrifice a little speed and a few fairly esoteric features
(goodbye MI, we hardly knew you). In many ways C# is very similar to the
Java programming language, since they both come from the C-style of families
and are both targeted at garbage-collected (or managed) environments.
As for that quote of yours about C++, that really cracked me up. I suppose
you were comparing it to C, and in that context C++ is more natural, simpler
and easier to use. I think you'll find that C# is quite a bit more natural,
simple, and easy to use than C++.
Regards
Sean
"lester" <ho**************@etang.com> wrote in message
news:un****************@TK2MSFTNGP11.phx.gbl... thank you Cor,
maybe I have to study some abc about .NET before I know for whom .NET is
designed.
about C++, we should say"C++ really makes program very natural, simple,
easy
to understand, easy to maintain..., than C."
about C# we should say"????"
Anyone can tell your understanding of .NET(esp, C#) to me?
------------
Lester
"Cor Ligthert" <no************@planet.nl> дÈëÏûÏ¢ÐÂÎÅ
:OP**************@TK2MSFTNGP09.phx.gbl... Lester
Simply answer, it is a next step in the evolution of that language, and
than you ask "yes and than?
It is more logical to write, however as with all evolutions are there
staid some legacy, where the users are used too however could have been as well
changed however that is not done direct.
I give no examples because that goes always to endless discussions.
Cor
"lester" <ho**************@etang.com> schreef in bericht
news:e7******************@TK2MSFTNGP15.phx.gbl... >a pre-beginner's question:
> what is the pros and cons of .net, compared to ++
>
> I am wondering what can I get if I continue to learn C# after I have
> learned
> C --> C++ --> C# ??
>
> I think there must be many know the answer here.
>
> thanks
>
> BR
> ----------------
> Lester
>
>
Comments inline
Sean Hederman wrote: Lester,
.NET is a platform on which programs run. You then use a programming
language (like C#, or VB.NET, or C++/CLI) to write programs for that
platform. The .NET platform is a bit different from the standard
Windows/Linux platforms, and very similar to the JVM in that there is a
unified type system, and garbage collection.
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.
Ron,
Java is full of English.
The real one right programming tool would have at least Chinese words
instead of that.
For me that is not necessary by the way however when you state something do
it than at least right, while have overthought what that right programming
tools would be.
Cor
Good point, Cor.
Why not create a simple parser/translator that can be used to preprocess the
C#. That way, a developer in China could use a localized name instead of
the english words (like 'if' and 'while'). The preprocessor can change the
names of the keywords back to english before compiling.
With a little imagination, this could work for many natural languages.
Arabic and Hebrew may be a challenging because of the right-to-left word
order, but I'm sure that could be worked out. Such a tool could make it
more natural for non-english-speaking people to write code.
Hmmmmm....
--
--- 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.
--
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OP****************@TK2MSFTNGP09.phx.gbl... Ron,
Java is full of English.
The real one right programming tool would have at least Chinese words
instead of that.
For me that is not necessary by the way however when you state something
do it than at least right, while have overthought what that right programming
tools would be.
Cor
Nick,
I write this, however don't think it is right, so forget please the idea.
When you want to know why tell that, than I will write it to you. I am a
little bit ill the last days so is it not good to answer those things when
it has to be serious as the mind is not as it should be.
(you have my email)
Cor
I should have sent you this too your email address, however as I said a
little bit ill. I stop answering for today.
Cor
Hi Lester, a pre-beginner's question:
what is the pros and cons of .net, compared to C++
The first thing to understand, is that C++ is much more powerful than .NET
With C++ you can program any hardware/platform/os from the most
low-level device drivers right through to the most complex user
interface (UI) such as a professional grade drawing package, a video
editor, or a high performance game. There are also libraries available
that work cross-platform; windows/linux/solaris/mac.
..NET (other than MONO - another story) will only work on windows, is
slower, and can only be used for high-level programming. It's also
fallen into the old Java trap of having multiple vulnerable frameworks
that are incompatible with each other, meaning you can't just deploy
your project world-wide without dozens of issues related to "what
framework are your 500,000 users running?"
..NET is good for beginners, in the same way Visual Basic allowed you to
drag and drop "controls" onto "forms", you can also do this in .NET but
it's become a mess with WebForms being incompatiible with WinForms and
now they're dropping WinForms alltogether. Like any framework, the price
of being tied to the framework is often too high and can cause more
problems than it's worth - look into Longhorn and .NET 2.0 if you don't
believe me.
Even Microsoft's own technology is incompatible with .NET - for example,
see if you can write a video capture application, or a tool to
manipulate the LSA of a remote machine in .NET
If you live in the teddy-bear land of "Macromedia XP" then you'll LOVE
..NET, but if you live in the real world of Enterprise Computing, you'll
have to think twice...
--
Gerry Hickman (London UK)
thank you! for your kindness and expertise.
I think I really got much knowledge of .NET before I decide to use it.
thank u very much.
--
Lester(Dalian PRC)
"lester" <ho**************@etang.com> дÈëÏûÏ¢ÐÂÎÅ
:e7**************@TK2MSFTNGP15.phx.gbl... a pre-beginner's question:
what is the pros and cons of .net, compared to ++
I am wondering what can I get if I continue to learn C# after I have
learned C --> C++ --> C# ??
I think there must be many know the answer here.
thanks
BR
----------------
Lester
In my opinion, you are not correct in your assertion.
In my opinion, C++ is much _less_ powerful that C# with the .Net framework.
C++ is more portable (for now), but also more expensive to use. The code is
considerably more difficult to read and understand, making maintenance costs
much higher. Libraries are needed to perform fairly basic things, and the
libraries are not available cross-platform in many cases. This effectively
defeats any advantage you have with a cross-platform language. Your comment
about asking 500,000 users what framework they have, is magnified if you
have to ask them if their platform will support 12 different libraries from
four vendors.
The code runs fast in C++, but the adding support for web services or third
party controls is expensive... and adoption is slow. C# code is very fast
as well, since it is compiled to the machine level by the framework. C++ is
faster, and isn't tied to the Garbage Collector, but it is far more prone to
memory leaks and security holes that can't be fixed easily.
C++ hasn't gone away, and it shouldn't (just yet). So many interfaces were
design for C++ that many new bits of code that have to talk to those
interfaces still should be written in C++. Those interfaces include device
drivers. However, if the OS has fundamental support for interfaces in .Net,
there is no reason that a device driver cannot be written in C#. C# is fast
enough to write device drivers. Even Microsoft's own technology is incompatible with .NET - for example,
see if you can write a video capture application, or a tool to
manipulate the LSA of a remote machine in .NET
I've heard this argument before... in 1992, when I was working at IBM on
OS/2. IBM wanted the new OS to have all the newest technology and a better
API. Microsoft insisted that backward compatibility was important for
adoption. The partnership between the two, that had originally launched MS
into its dominant position, ended on this disagreement. IBM went the way
that you are recommending: trash the old stuff and start over with the new
technology. Microsoft produced two lines of Operating systems that allowed
better management on the server, and fast applications on the client.
Microsoft won that battle in the marketplace. OS/2 was a huge failure for
IBM, as was the PS/2 (the same argument, only in hardware instead of
software).
I was there. Microsoft made the right choice then, and they made it again
with .Net. New stuff should filter in, but old stuff has to keep running.
Oh, and to your own point, the Local Security Authority (LSA) is managed by
the LSASS service. This model is a left over from NT4. Windows server 2003
leverages the Active Directory, as does XP. If you are still using the LSA,
you are about seven years behind the times. There is no need for Microsoft
to write new APIs in .Net to support an antiquated model. Anyone who wants
to use the old API can still do so (as you know), but new users will use a
new object model that leverages new technology... a model that is secure
from hacking. Perhaps the problem is really that your enterprise has
decided not to keep up with best practices in security, and you are taking
that out on Microsoft's technology.
--
--- 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" <ge********@yahoo.co.uk> wrote in message
news:Oj****************@TK2MSFTNGP09.phx.gbl... Hi Lester,
a pre-beginner's question:
what is the pros and cons of .net, compared to C++
The first thing to understand, is that C++ is much more powerful than .NET
With C++ you can program any hardware/platform/os from the most
low-level device drivers right through to the most complex user
interface (UI) such as a professional grade drawing package, a video
editor, or a high performance game. There are also libraries available
that work cross-platform; windows/linux/solaris/mac.
.NET (other than MONO - another story) will only work on windows, is
slower, and can only be used for high-level programming. It's also
fallen into the old Java trap of having multiple vulnerable frameworks
that are incompatible with each other, meaning you can't just deploy
your project world-wide without dozens of issues related to "what
framework are your 500,000 users running?"
.NET is good for beginners, in the same way Visual Basic allowed you to
drag and drop "controls" onto "forms", you can also do this in .NET but
it's become a mess with WebForms being incompatiible with WinForms and
now they're dropping WinForms alltogether. Like any framework, the price
of being tied to the framework is often too high and can cause more
problems than it's worth - look into Longhorn and .NET 2.0 if you don't
believe me.
Even Microsoft's own technology is incompatible with .NET - for example,
see if you can write a video capture application, or a tool to
manipulate the LSA of a remote machine in .NET
If you live in the teddy-bear land of "Macromedia XP" then you'll LOVE
.NET, but if you live in the real world of Enterprise Computing, you'll
have to think twice...
--
Gerry Hickman (London UK)
Nick,
Although there is not one millimeter difference between our idea's we should
stay proffesionals.
Everything you write in this is as my idea.
However I was there. Microsoft made the right choice then, and they made it again
with .Net. New stuff should filter in, but old stuff has to keep running.
You never know if there comes somebody with something better about what you
and I did never thought about.
:-)
Cor
lester wrote: a pre-beginner's question:
what is the pros and cons of .net, compared to ++
I am wondering what can I get if I continue to learn C# after I have
They all have the letter *c* in them, but IMHO, they are all completely
different animals!
c: a powerful, near assembly type language, used for everything from the
hardware up through the OS ( Linux is written in Gnu c ).
c++: a hybrid language, somewhere between a procedural and an OO. It's /c/
with OO ideas that extend existing syntax like struct into classes, and so
on. In many ways, c already had the capability to do OO, but c++ exposes
it and makes it clearer. c++ is popular because it is the bedrock of the
Windows API and COM/COM++ programming. If you want to manipulate Windows
natively, Visual c++ was usually the only answer.
c#: We can't talk about c# in a vacuum, because c# is part and parcel
of .Net and all that it implies: managed code. Managed code is a machine
within a machine...it virtualizes the computer like java did, but far more
tightly ( the IL ) which allows it to support such amazing features as
Reflection.Emit and the ILGenerator.
Each of these languages requires a higher level of commitment to the
machinery that supports it...but to say that /c/ is more *advanced*
or /powerful/ than c# is silly. c# gives you the ability to manipulate
the entire computer, whether OSX, Linux or Windows, using an OO model.
That is /very/ powerful. It's so powerful, that people, again IMHO, have
not yet begun to understand it, or use it beyond what they know already.
learned C --> C++ --> C# ??
I think there must be many know the answer here.
thanks
BR
----------------
Lester
-- http://texeme.com
Textcasting Technology
Lester.. I would learn enough C++ to be dangerous and then go on to C#.
By
learning C++ I mean using streams and the Standard Template Library. I
would try to learn OOP and multi-threaded programming in C#. IMHO, it is
harder to reverse engineer C++ than C#, but there is nothing stopping
you
from putting your algorithm into a C++ ATL COM dll and calling it from
C#,
JScript or VB.
Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jeff Louie <je********@yahoo.com> wrote: Lester.. I would learn enough C++ to be dangerous and then go on to C#.
In C++ you are dangerous by not learning ENOUGH of it!
If you have some programming background
"Accelerated C++: Practical Programming by Example"
by Andrew Koenig, Barbara E. Moo.
Addison Wesley Professional
ISBN: 020170353X http://www.amazon.com/exec/obidos/ASIN/020170353X http://www.awprofessional.com/title/020170353X
is an excellent place to start.
You'll still need this though:
C++ Standard Library, The: A Tutorial and Reference
By Nicolai M. Josuttis.
Addison Wesley Professional.
ISBN: 0201379260 http://www.amazon.com/exec/obidos/ASIN/0201379260 http://www.awprofessional.com/title/0201379260
You're probably better off learning C++ "in isolation" first
- i.e. don't immediately head for material that uses C++ in
the context of manipulating MS technologies as it tends to
be used with a "C" slant. And C++.NET is simply a "flavour"
in a managed environment, again not ideally suited to learn
standard "C++/STL" per se.
I recall that using VS6 VC++ was kind of a pain with
"Accelerated C++" as the STL shipping with VS6 was severely
outdated. With VS 2003 (VC++ 7.1) that should not be a
problem though.
'Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.'
Martin Fowler,
'Refactoring: improving the design of existing code', p.15
Hi Nick, In my opinion, you are not correct in your assertion.
In my opinion, C++ is much _less_ powerful that C# with the .Net framework.
I'm not sure I follow.
C++ can do everything .NET can do and a lot more besides. 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).
There's probably plenty "plus" points of .NET you could cite, but I
don't think "powerful" is one of them...
C++ is more portable (for now), but also more expensive to use. The code is
considerably more difficult to read and understand, making maintenance costs
much higher. Libraries are needed to perform fairly basic things, and the
libraries are not available cross-platform in many cases.
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!
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.
The code runs fast in C++, but the adding support for web services or third
party controls is expensive... and adoption is slow.
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. The idea was that people would want pop-up UI elements
bouncing out of every email, but all it did was cause a slew of security
headaches and gradually they had to be turned off, and now everyone is
grabbing Mozilla and FireFox so they can can SAFE plain-text email and
pop-up free browsing.
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.
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. 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,
but pretty cool if you want to view your sales figures in a spinning 3d
cube.
C# code is very fast
as well, since it is compiled to the machine level by the framework.
Yes, but what about the FrameWork objects themselves? How many of them
are just wrappers around COM objects?
C++ hasn't gone away, and it shouldn't (just yet). So many interfaces were
design for C++ that many new bits of code that have to talk to those
interfaces still should be written in C++.
OK.
Those interfaces include device
drivers. However, if the OS has fundamental support for interfaces in .Net,
there is no reason that a device driver cannot be written in C#.
I think the word "if" is the important one here! Is this going to be
ready for Longhorn?
Even Microsoft's own technology is incompatible with .NET
I've heard this argument before... in 1992, when I was working at IBM on
OS/2.
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?
I was there. Microsoft made the right choice then,
I agree.
and they made it again
with .Net. New stuff should filter in, but old stuff has to keep running.
Well I'm not so sure. Why does so much of the MSDN documentation now say
that it's "archived content"?
Oh, and to your own point, the Local Security Authority (LSA) is managed by
the LSASS service. This model is a left over from NT4. Windows server 2003
leverages the Active Directory, as does XP.
We're currently running Win2000, but as far as I know XP still uses the
LSA in the context of "Local Security Policy"? I can check this next
week. But let's assume it does NOT use the LSA for a moment.
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 notice you avoided the question about writing a video capture (or
video editing) application with .NET - will this be ready for Longhorn?
from hacking. Perhaps the problem is really that your enterprise has
decided not to keep up with best practices in security, and you are taking
that out on Microsoft's technology.
To date we have an excellent record on security and I'm not taking
anything out on Microsoft's technology - just discussing pros/cons of
C++ and .NET (as per the subject line).
--
Gerry Hickman (London UK)
Gerry/Nick,
What I miss in both of your articles is the background.
To explain a little bit what I mean with that can I do by telling that what
is good policy for China has not to be good policy for Monaco.
I can explain that more, however I think you both understand what I want to
tell. When not, than tell me and I explain it more.
Cor
> > C# code is very fast as well, since it is compiled to the machine level by the framework.
Yes, but what about the FrameWork objects themselves? How many of them are
just wrappers around COM objects?
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, with the C++ code potentially
producing more COM interfaces(for example if you write an ActiveDocumentHost
or the like, pretty sure one of the standard windows templates does...just
forget if its MFC or WTL).
Also, out of curiosity, how does wrapping a COM object change cause code to
not be machine code?
<snip>
I notice you avoided the question about writing a video capture (or video
editing) application with .NET - will this be ready for Longhorn?
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, it
just means you would have to do some work to do it(similarly, if the C++
headers from DirectX didn't expose any DirectShow types you'd have to
manually define the interfaces and provide classes to call them, not really
fun stuff eh?). Don't mistake the functionality not being there in the
standard package as an impliciation the function cannot be achieved. If so
C++ is pretty weak in and of itself as well.
Simple capture is maybe 200 lines of code(plus some generated interface
definitions), but only works with WIAs video acquisition mode, and thus only
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.
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.
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. C++ and x86(or any other existing CPU architecture, excluding
IA64) are quite mature, C# and the .NET VM is not(although the .NET VM was
based off java's VM, java's VM seems to have gone to great lengths to avoid
maturing its instruction set, lest incompatibilities come about).
The VM needs certain features, like a more controllable garbage collecter
and a better way to express paralelled or paralellable code. The languages
need certain features as well, including better ways to manage resources.
However the need for those features will be solved.
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
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. In my opinion, C++ is much _less_ powerful that C# with the .Net
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.
C++ is more portable (for now), but also more expensive to use. The
code is considerably more difficult to read and understand, making maintenance
costs much higher. Libraries are needed to perform fairly basic things, and
the libraries are not available cross-platform in many cases.
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.
The code runs fast in C++, but the adding support for web services or
third party controls is expensive... and adoption is slow.
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.
> C# code is very fast
as well, since it is compiled to the machine level by the framework.
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.
> Those interfaces include device
drivers. However, if the OS has fundamental support for interfaces in
..Net, there is no reason that a device driver cannot be written in C#.
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#.
Even Microsoft's own technology is incompatible with .NET
I've heard this argument before... in 1992, when I was working at IBM on
OS/2.
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.
--
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.
I notice you avoided the question about writing a video capture
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 (London UK)
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()
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.
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.
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.
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++:)
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#.
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:)
--
Gerry Hickman (London UK)
>> 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?
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.
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?
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.
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++.
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?
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?
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.
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.
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).
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 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.
"Ron Ruble" wrote:
Comments inline
Sean Hederman wrote: Lester,
.NET is a platform on which programs run. You then use a programming
language (like C#, or VB.NET, or C++/CLI) to write programs for that
platform. The .NET platform is a bit different from the standard
Windows/Linux platforms, and very similar to the JVM in that there is a
unified type system, and garbage collection.
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...12/351958.aspx)
"Niki Estner" wrote:
....
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.
"DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:21**********************************@microsof t.com... ...
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
"DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:5B**********************************@microsof t.com... "Niki Estner" wrote:
...
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.
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
"Niki Estner" wrote: "DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:21**********************************@microsof t.com... ...
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
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.
"Niki Estner" wrote: "DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:5B**********************************@microsof t.com... "Niki Estner" wrote:
...
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.
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. 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
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).
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:uL**************@TK2MSFTNGP15.phx.gbl... 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/...saOpenPolicy):
[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
);
"DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:65**********************************@microsof t.com...
"Niki Estner" wrote:
"DerSchreiner" <De**********@discussions.microsoft.com> wrote in
news:21**********************************@microsof t.com... > ...
> 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
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
Hi Daniel, 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,
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.
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,
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.
--
Gerry Hickman (London UK)
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:eV**************@TK2MSFTNGP12.phx.gbl... Hi Daniel,
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,
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.
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. (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...
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.
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
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.
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).
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)
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...
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? 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.
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.
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.
--
Gerry Hickman (London UK)
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:u2***************@TK2MSFTNGP11.phx.gbl... 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.
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".
Gerry Hickman <ge********@yahoo.co.uk> wrote: 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.
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.
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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Sean, I agree, but is Word 2003 written in .NET,
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 (London UK)
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.
--
Gerry Hickman (London UK)
> 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.
--
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:OH**************@TK2MSFTNGP15.phx.gbl... Hi Sean,
I agree, but is Word 2003 written in .NET, 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
Yes, but why? Why toss all that existing code down the drain in order to
make it easier to code a product you already have?
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.
I don't know who told you that .NET was completely independent of COM, but I
don't ever remember being told that. You can write applications that don't
directly call COM, but I don't ever recall anything saying that at no point
would COM or the OS be used to perform the actual work.
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.
Not neccesarily, as noted before, they could just be unwilling to throw away
hundreds of millions of dollars of existing code. I expect you'll see more
and more products coming out with more and more .NET support. First the
API's to access them will become .NETified, and gradually so will the core.
PS. I'd like to apologize for the angry tone in my previous post. I was
irritated by something else, and took it out on you. Didn't follow my "save
and edit rule" :-(
Gerry Hickman <ge********@yahoo.co.uk> wrote: 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.
Were those products which previously hadn't used C/C++ though, or was
it just that they were adapted to use the new features? There's a big
difference.
.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.
A lot of it is in the web app market rather than shrink-wrapped
software - there's also a lot of vertical market apps being written, I
believe.
As it happens, the company I work for *does* sell a shrink-wrapped
product which is largely written in .NET. I won't name them (in this
post at least), but the product is doing well.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Nick, 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.
I agree with everything you say here.
--
Gerry Hickman (London UK)
Hi Sean, Sure, and with the "excellent COM interop" you outline below, it should
not be a problem to write ALL the applications in .NET
Yes, but why? Why toss all that existing code down the drain in order to
make it easier to code a product you already have?
Simple. It's called "leading by example":)
No, it's the other way round. The hype of .NET is that it does not rely on
COM and the registry.
I don't know who told you that
You must have managed to avoid some of the hype better than I:)
Seriously though, I'm glad this is clear now. It's something I had not
understood properly.
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.
Not neccesarily, as noted before, they could just be unwilling to throw away
hundreds of millions of dollars of existing code. I expect you'll see more
and more products coming out with more and more .NET support. First the
API's to access them will become .NETified, and gradually so will the core.
Maybe at that point it will be worth taking seriously, but my guess is
that the "big guns" programmers at Microsoft are thinking EXACTLY the
same as I am:)
New MS employee: "Hey, let's write Word 2003 in .NET! Dude it Rocks!"
Chief Architect: "Don't be silly!"
Actually, these senior Microsoft guys are pretty smart. For example the
Office team don't have to worry one jot about .NET 2.0 or "Longhorn".
They know their program will run first time on the new system and have
ZERO dependencies on the drunken framework. Imagine if they'd written it
to target .NET 1.1 and XP - it would be OUT OF DATE before it even got
off the shelf!
PS. I'd like to apologize for the angry tone in my previous post. I was
irritated by something else, and took it out on you. Didn't follow my "save
and edit rule" :-(
Hehe, you were probably irritated reading about the "Avalon" layer, or
some other wizz-bang-go-faster-over-hyped aspect of the new system:)
--
Gerry Hickman (London UK)
Hi Jon, 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.
Were those products which previously hadn't used C/C++ though, or was
it just that they were adapted to use the new features? There's a big
difference.
Yes, they were in C/C++, but not using MFC and ATL, but the big names
grabbed them with both hands and (as we can see) were right to do so.
A lot of it is in the web app market rather than shrink-wrapped
software
Yup, that's where I'm currently using it. The client side is a disaster
in my view, but the server only needs one framework version and there's
no WinForms or silly XAML to worry about. Just fire up Mozilla/Firefox
from any platform on any machine, anywhere in the world and off you
go... (runs on legacy browsers like IE too).
--
Gerry Hickman (London UK) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Headless |
last post by:
I've marked up song lyrics with the <pre> tag because it seems the most
appropriate type of markup for the type of data. This results in
inefficient use of horizontal space due to UA's default...
|
by: Alan Illeman |
last post by:
How do I set several different properties for PRE in
a CSS stylesheet, rather than resorting to this:
<BODY>
<PRE STYLE="font-family:monospace;
font-size:0.95em;
width:40%;
border:red 2px...
|
by: Buck Turgidson |
last post by:
I want to have a css with 2 PRE styles, one bold with large font, and
another non-bold and smaller font.
I am new to CSS (and not exactly an expert in HTML, for that matter). Is
there a way to...
|
by: Porthos |
last post by:
I'm authoring an XML document and using the <pre> html tag for the
portions that are not dynamically generated. The <pre> text is
displaying in a smaller font size (and I believe different font)...
|
by: Michael Shell |
last post by:
Greetings,
Consider the XHTML document attached at the end of this post.
When viewed under Firefox 1.0.5 on Linux, highlighting
and pasting (into a text editor) the <pre> tag listing will...
|
by: Jarno Suni not |
last post by:
It seems to be invalid in HTML 4.01, but valid in XHTML 1.0. Why is there the difference? Can that pose a problem when such a XHTML document is served as text/html?
|
by: Rocky Moore |
last post by:
I have a web site called HintsAndTips.com. On this site people post tips
using a very simply webform with a multi line TextBox for inputing the tip
text. This text is encode to HTML so that no...
|
by: Eric Lindsay |
last post by:
I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash...
|
by: Xah Lee |
last post by:
The Concepts and Confusions of Pre-fix, In-fix, Post-fix and Fully
Functional Notations
Xah Lee, 2006-03-15
Let me summarize: The LISP notation, is a functional notation, and is
not a...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| | |
