VC++.NET ????

[borhan]

Hi folks,

I am using vs.net 2003 for a time, however since last week I was
using MFC. Now, I am into managed C++ and windows forms.

I can say that I am very much confused with it, and I have some
questions I hope I can find some answers here...

1. First of all, I got the answer to this question but I have to
point that out! What kind of c++ programming is that to write all the
code in the header file ??? MS annnounced that it didn't market a new
product after vs6 for a long time coz they were working on vs.net ???
and now they say that the c++ win froms was designed by c# people
because there wasn't enough time???? Who would buy this ???

2. Ok, the first thing that I noticed with vc++.net is that It
compliles and complies and compiles ... I would have compiled 5
projects in MFC and my vc++.net code still compiles... Is there a
reason for this ????

3. And my other major question, I am also a vb programmer since vb5
and when I have upgraded from vb6 to vb.net I was really charmed with
the features of vb.net. Does all the namespace functions work the
same speed for all languages?? For example if I code the same project
with c++.net or vb.net or c# using namespaces and managed code would
all work at the same speed coz they all use the same shared
namespaces??? This is my concern till I started to code in vc++.net.
If it is the case why should I switch to vc++.net and code in c++, I
would just code in vb.net.

Thanks in advance,

 

[Carl Daniel [VC++ MVP]]

Hi folks,

I am using vs.net 2003 for a time, however since last week I was
using MFC. Now, I am into managed C++ and windows forms.

I can say that I am very much confused with it, and I have some
questions I hope I can find some answers here...

1. First of all, I got the answer to this question but I have to
point that out! What kind of c++ programming is that to write all the
code in the header file ??? MS annnounced that it didn't market a new
product after vs6 for a long time coz they were working on vs.net ???
and now they say that the c++ win froms was designed by c# people
because there wasn't enough time???? Who would buy this ???

This has been adequately covered many times. You're completely entitled to
not like it.

2. Ok, the first thing that I noticed with vc++.net is that It
compliles and complies and compiles ... I would have compiled 5
projects in MFC and my vc++.net code still compiles... Is there a
reason for this ????

The VC7.1 compiler is unquestionably slower than the VC6 compiler, although
I would have a very hard time believing it's 5 times slower. That said, I
haven't done much with compiling managed C++ with VC - it's possible that
there's a significant slow-down there due to all the meta-data loading &
reading that goes on. That's just a guess though.

3. And my other major question, I am also a vb programmer since vb5
and when I have upgraded from vb6 to vb.net I was really charmed with
the features of vb.net. Does all the namespace functions work the
same speed for all languages?? For example if I code the same project
with c++.net or vb.net or c# using namespaces and managed code would
all work at the same speed coz they all use the same shared
namespaces??? This is my concern till I started to code in vc++.net.
If it is the case why should I switch to vc++.net and code in c++, I
would just code in vb.net.

There's no difference in the performance of the .NET framework classes based
on the language from which you call them. For a simple Winforms app, it's
unlikely you'll see any significant difference in performance between C++,
C# and VB.NET (or JScript.NET or J# or ...).

Note that namespaces have nothing to do with any of this: namespaces are
simply a mechanism to organize the 10's of 1000's of names that exist in the
..NET framework into somewhat manageable chunks. Whether a class is in such
and such namespace or not has no performance implications at all.

-cd

 

[borhan]

cd first of all thank you for your quick reply and kind interest,

[quote:0a2e2b7932]The VC7.1 compiler is unquestionably slower than
the VC6 compiler, although
I would have a very hard time believing it's 5 times slower. That
said, I
haven't done much with compiling managed C++ with VC - it's possible
that
there's a significant slow-down there due to all the meta-data loading
&
reading that goes on. That's just a guess though.
[/quote:0a2e2b7932]

I think I was a bit over exaggerating about it, but I was trying to
highlight the delay in the compiling time that made me really
disappointed.

There's no difference in the performance of the .NET framework classes based
on the language from which you call them. For a simple Winforms app, it's
unlikely you'll see any significant difference in performance between C++,
C# and VB.NET (or JScript.NET or J# or ...).

Note that namespaces have nothing to do with any of this: namespaces are
simply a mechanism to organize the 10's of 1000's of names that exist in the
..NET framework into somewhat manageable chunks. Whether a class is in such
and such namespace or not has no performance implications at all.

Sorry about that missusage of the word. By saying namespaces I was
trying to mean managed .net classes. So I got the answer, all
managed classes work the same for all languages.. So where is the
power if c++ ?? If I use managed .net classes ?

Thanks for your interest,

cheers,

 

[Carl Daniel [VC++ MVP]]

Sorry about that missusage of the word. By saying namespaces I was
trying to mean managed .net classes. So I got the answer, all
managed classes work the same for all languages.. So where is the
power if c++ ?? If I use managed .net classes ?

The power is where it's always been for C++ : more power to create your own
classes. If your programs are going to do little more than bolt a bunch of
framework classes together, then use whichever language you like the best.

In the next version of Visual Studio, C++ will have some definite advantages
for .NET development. Today there's less (but not none). The main thing is
that VC++ allows you to mix native and .NET code in the same executable
(e.g. calling a WinForms form from an MFC applicaiton). None of the other
..NET languages let you do that.

-cd

 

[Arnold the Aardvark]

In the next version of Visual Studio, C++ will have some definite
advantages for .NET development.

Today there's less (but not none). The main thing
is that VC++ allows you to mix native and .NET code in the same executable
(e.g. calling a WinForms form from an MFC applicaiton). None of the other
.NET languages let you do that.

Hmm... I'm used to writing a thin GUI (bolting together a bunch of framework
classes), and then putting all the meat in other classes, making very heavy
use of the STL, iostreams and so on.

From what I have learned so far, I can still do this, but there will be a
big performance penalty on switching from managed to unmanaged code. I have
to say it does seem to work as advertised.

OTOH if I try to write entirely managed code, it turns out I lose just
about all the programming paradigms I like. In particular, I usually manage
resources perfectly well with stack sentinels, smart pointers and the like.
I neither need nor want __finally or IDisposable, but it seems that I will
be forced to use them. Losing iostreams for TextReader/Writer is truly
horrible. And as for Collections, there's all that casting: I want the STL.

Doesn't anyone else get itchy new-ing objects willy nilly with not
a thought for their timely demise?


Arnold the Aardvark

 

[borhan]

ok I got the point thanks for guidance and time.

 

[Carl Daniel [VC++ MVP]]

Doesn't anyone else get itchy new-ing objects willy nilly with not
a thought for their timely demise?

Yep. The Whidbey (aka VS.NET 2004) release will greatly improve this
situation.

-cd

 

[Gerhard Menzl]

OTOH if I try to write entirely managed code, it turns out I lose just
about all the programming paradigms I like. In particular, I usually manage
resources perfectly well with stack sentinels, smart pointers and the like.
I neither need nor want __finally or IDisposable, but it seems that I will
be forced to use them. Losing iostreams for TextReader/Writer is truly
horrible. And as for Collections, there's all that casting: I want the STL.

Doesn't anyone else get itchy new-ing objects willy nilly with not
a thought for their timely demise?

I am 100% with you there. Managed C++ is Standard C++ bereft of
virtually every useful and trusted C++ idiom. Deterministic resource
cleanup? Const correctness? Truly type-safe containers? Hey, Java
doesn't have it, hence C# doesn't have it, and all the world's a web
site anyway, so why do you think you should get extra privileges?

From what I have seen so far, I doubt that Whidbey will remedy this
unfortunate situation. While I trust that Herb Sutter does his best to
remove the ugliest syntactic warts, I doubt that he will be able to work
against the fact that by its very design .NET forces the Java paradigm
upon C++. What ist the use of getting rid of all those double
underscores when you still can't put managed objects into an STL
container or an STL container into a managed object?

I would be happy to be shown I am wrong.

Gerhard Menzl

 

[Arnold the Aardvark]

Yep. The Whidbey (aka VS.NET 2004) release will greatly improve this
situation.

Thanks. I'll look at the spec.

 

[Arnold the Aardvark]

I am 100% with you there. Managed C++ is Standard C++ bereft of
virtually every useful and trusted C++ idiom. Deterministic resource
cleanup? Const correctness? Truly type-safe containers? Hey, Java
doesn't have it, hence C# doesn't have it, and all the world's a web
site anyway, so why do you think you should get extra privileges?

I can understand Microsoft trying to compete with Java, hence C#. It
is not in their nature to follow other people's standards. But I simply
don't get this idea of language neutrality. Why is it desirable to
hobble C++ to make it compatible with C#, or to radically change VB
for the same reason. It just seems like a lot of hype to me.

If one likes C++ garbage collectors then it is possible to add them
without throwing away the standard. Personally I think C++ garbage
collectors are for people who write garbage. My less than entirely
humble opinion.

As GUI component libraries go .NET is OK, but lacks some whizzy
features that Borland put into their VCL. Still, there is nothing
to prevent them from being added in the future. Hmmm.. action lists.

I guess .NET has some other 'benefits', but they are still opaque to
me.


Arnold the Aardvark