vc++.net, Server Application?

[batista]

Hello to all,

I want to know that wat's the future of vc++.net? I mean is it going to
remain there or not, and if does then wud there be big changes to it or
they'll stick with the current one?

I want to know this because there is client/server application
that i want to build. Now the server side has to be very fast in
processing request and efficient in all other server related issues. I
searched on internet(including the google grps) and the answer i found
was that to use vc++ on server side.

But i read in msdn that vc++.net offers the same performance as vc++

So wat wud u guys suggest me on choosing from both of them
vc++ or vc++.net?

BTW, wat if i build the whole application in C# or vb.net?
wat performance issues wud i face then?

Bcoz the server has to be very fast in processig client's requests
and wat language wud provide me with the best performance?

Thanks in advance...
Cheers...

Bye

 

[Carl Daniel [VC++ MVP]]

Hello to all,

I want to know that wat's the future of vc++.net? I mean is it going to
remain there or not, and if does then wud there be big changes to it or
they'll stick with the current one?

I want to know this because there is client/server application
that i want to build. Now the server side has to be very fast in
processing request and efficient in all other server related issues. I
searched on internet(including the google grps) and the answer i found
was that to use vc++ on server side.

But i read in msdn that vc++.net offers the same performance as vc++

So wat wud u guys suggest me on choosing from both of them
vc++ or vc++.net?

BTW, wat if i build the whole application in C# or vb.net?
wat performance issues wud i face then?

Bcoz the server has to be very fast in processig client's requests
and wat language wud provide me with the best performance?

You're confusing products with technologies.

There's only one product, Visual C++ (currently Visual C++ .NET 2003, soon
to be Visual C++ 2005).

That single product supports three different languages:

1. ANSI C
2. ISO C++
3. Managed Extensions for C++ (aka MC++)

The first two generate "native" (or unmanaged) code (e.g. x86 or x64), while
the latter generates IL for execution on the CLR.

Visual C++ 2005 adds one more language to the list:

4. C++/CLI

which is a new implementation of C++ for managed code.

With that foundation, I can now answer your question: none of these are
going to go away for a very long time.

The performance difference between managed and native code can vary widely,
but is generally within 15-30%. In some cases managed code will be faster
than native.

HTH

-cd

 

[aa]

Microsoft has introduced OS/2, C#, J++, J#, COM, DCOM, ADO, etc, promising
an exciting future for all. Microsoft can and will change on a dime.

 

[William DePalo [MVP VC++]]

Microsoft has introduced OS/2, C#, J++, J#, COM, DCOM, ADO, etc, promising
an exciting future for all. Microsoft can and will change on a dime.

Yeah, change is ineveitable. And change they do. But like Intel they
maintain compatibility with what came before with a vengeance.

For instance, 16 bit Windows programs written two decades ago -when many
..Net developers were still eating baby food btw - will still run. It
won't be until sometime late next year when there is a platform with Windows
in its name which will finally obsolete support for 16 bit applications.

So, what's your point?

Regards,
Will

 

[aa]

Yeah, change is ineveitable. And change they do. But like Intel they
maintain compatibility with what came before with a vengeance.

For instance, 16 bit Windows programs written two decades ago -when many
.Net developers were still eating baby food btw - will still run. It
won't be until sometime late next year when there is a platform with
Windows in its name which will finally obsolete support for 16 bit
applications.

So, what's your point?

The OP:

"I want to know that wat's the future of vc++.net? I mean is it going to
remain there or not, and if does then wud there be big changes to it or
they'll stick with the current one?"

Microsoft will do as it pleases; it doesn't particularly care what pleases
its customers. If you heavily invested in Microsoft OS/2, for instance, you
were badly mauled by Microsoft when they chose to change direction. I
understood this to be the concern expressed by the OP.