Hello Esteemed Developers and Experts,
I have been using Microsoft Visual C++ .NET for 1 year. During this time,
I have searhed some topics over internets. Most of the topics about .NET is
related to C# and Visual Basic .NET. There are less documents about Visual
C++ .NET or Managed C++.
I wonder the reasons of below questions:
1) Is C# more powerful than Managed C++ and Visual C++ .NET?
2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?
3) Can C# take the place of standard C++ in terms of performance?
4) What kind of advantages C# have compare to Managed C++ and Visual C++
..NET?
I thank your kind responses and guidances in advance.
Best Regards
--
~~~~~~~~~~~~~~~~~~~
İyi Çalışmalar
Alper AKÇAYÖZ (Bil Muh)
Wish You Good Work
Alper AKCAYOZ (Bil Muh)
30  2754 
> I have been using Microsoft Visual C++ .NET for 1 year. During this time, I have searhed some topics over internets. Most of the topics about .NET
is related to C# and Visual Basic .NET. There are less documents about Visual
C++ .NET or Managed C++.
I wonder the reasons of below questions:
1) Is C# more powerful than Managed C++ and Visual C++ .NET?
No. C# us not more powerfull than C++.
But C# is far easier to create .NET programs than unmanaged C++. Far more
readable and much faster to compile.
C# appears to be designed from the scracth up to be pure .NET programs. C++
still have a need for this backward compatibility issuses, so the language
gets complicated with all these addtion macro's and keywords....
The nice things about the .NET is that all code in VB, C# and managed C++
looks the same except for syntax.
Another reason is maybe that C++ programmers tend to like very optimized
code, even if it takes an few months to create while a C# programmer needs a
day or so to create something like that. So I believe that a lot of C++
programmers don't like the .NET way of programming because they lose their
years of experience and have to relearn everything from scratch becoming a
newbie.
Another reason could be that a lot of C++ programmers get in their 40's and
have a hard time to keep up with the new technology.
Then again, a C++ programmers, like me that don't mind to get scared away of
becoming a newbie again also exist and they are very fond of .NET :-)
2) Is Microsoft intending to support C# and V.B. .NET more than
Managed C++?
I don't think so, C++ is still very important because of the huge code base.
C++ is still ery important for the next 10 years, so is the MFC.
3) Can C# take the place of standard C++ in terms of performance?
Not at this moment but it gets pretty close according to my tests.
I discovered that you lose speed in some places, but gain speed in other
places. Especially the .NET framework contains very high optimized code. In
my code I have the feeling that I lose about 5% speed on average compared to
a pure C++ program, but I did make the C# version 7 times faster.
Tests suggests that the .NET match library is actually faster than the
unmanaged C++ library.
Maybe they redesigned the .NET match library for even better performance
gain, while the older C++ library has not been updated.
4) What kind of advantages C# have compare to Managed C++ and Visual
C++ .NET?
See the topic "In need of .NET advocacy" in this news group. Everything you
ever want to know is discussed there.
-- http://www.skyscan.be
Thank you very much for your response.
Many of the systems that require performance -like image processing, voice
recognition, military software- are developed in C++. In the course of the
time, can C# find a considerable a good place in these areas?
Within the projects that are in C#, using the C++ codes is possible.
Therefore, can C# be used in Performance-Required areas?
"Olaf Baeyens" wrote:
> Thank you very much for your response. Many of the systems that require performance -like image processing, voice
recognition, military software- are developed in C++. In the course of the
time, can C# find a considerable a good place in these areas?
Within the projects that are in C#, using the C++ codes is possible.
Therefore, can C# be used in Performance-Required areas?
I create imaging software, and I try to create the user interface part and
the stuff that is less performance critical in C# because I can create that
part much faster.
But a huge part of my code base is unmanaged C++ using MFC. And I simply do
not have the time to port it to C# or managed C++ at this moment, so I have
created a mixed C++ assembly that has both managed as unmanaged code acting
as wrappers.
The nice thing about .NET is that I can create components in C#, managed
C++, VB.NET... and freely mix them with each other without any problems.
Just make sure that you avoid case sensitivity in de class naming to make
sure that it can still be used in VB.NET. But you have a program that checks
compatibility called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.
Now the problem is that you either create a C# assembly or a C++ managed
assembly. You cannot compile C++ code in a C# project. So you end up with
multiple assemblies (dll's), which at first sounds scary for the
installation procedure, but a .NET program is best installed using a setup
so that does not pose any problem. The setup can automatically configure the
computer for enough user rights to run that program across a network and
so... So no more complicated installation and user righst. :-)
One thing I had problems with in the beginning was this MFC thing. I
discovered that I need to compile with MFC in a DLL, and this gave me
problems because I used the assemblies in a subfolder which is a nice system
to avoid dll clashes if one assembly needs v1.2 of a dll and the other
assemblie used in your same program uses that same assebly name but with a
different vesrion v1.1. I discoverd that the subfolder thing was perfect for
none-MFC dll's. The MFC dll's should reside in the same folder of your dll
and executable.
You will lose some speed if you move from managd to unmanaged code and back.
So it is best to concentrate the code into managed or managed code, but try
to avoid the transition as much as possible. But it works greate.
I faced one small problem. one of the projects I created is a dll plugin for
a conventional exe program. The dll is a mixed manged/unmanaged dll that
have the user interface as a managed part. But it turned out that the .NET
framework did not find the correct assemblies even though they were located
in the same folder of the main dll. The reason was because the executable
was located in another folder, the plugin in yet another folder. The .NET
framework tried to locate the dll's in the .EXE folder instead of the plugin
..DLL folder. Since creating a setup is not desired that installs plug-ins in
the program folder of the exe, suppose you have 2 plugins with the same
name? I found a sollution in installing the assemblies into the GAC. I don't
like that but it is the best solution so far I have come up with that is
reliable. Setting the current directory didn't solve the problem.
So I hope that you have now an overview of what is possible. :-)
-- http://www.skyscan.be
Thank you Baeyens. Your expriences and explanations are important for me.
These comparisons helped me to visualize the logic in my mind.
I thank you again for sharing your time with me.
Best Regards.
"Olaf Baeyens" wrote:
Hello Vranos,
I would like to advance much further on a programming language. Therefore, I
wonder the differences of prog. lang. in .NET.
With your explanations, can we say that C++ will keep its popularity,
performance and its other advantages for a long time both in .NET technology
and other Performance-Required fields?
My aim is to work on Performance-Required software. Therefore, is it
possible to say that Visual C++ .NET/Managed C++ is the correct choice?
"Ioannis Vranos" wrote:
On Mon, 4 Apr 2005 06:39:04 -0700, "Alper AKCAYOZ"
<bi*********@hotmail.com_SiLiNiZ_REMOVE> wrote: Hello Vranos,
I would like to advance much further on a programming language. Therefore, I
wonder the differences of prog. lang. in .NET.
With your explanations, can we say that C++ will keep its popularity,
performance and its other advantages for a long time both in .NET technology
and other Performance-Required fields?
My aim is to work on Performance-Required software. Therefore, is it
possible to say that Visual C++ .NET/Managed C++ is the correct choice?
Unmanaged code will usually provide better performance for
time-critical things such as image and signal processing; should you
commit yourself to .NET, you'll probably use both managed and
unmanaged C++.
If standard or portable C++ knowledge is important to you, use
unmanaged C++.
--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real
> My aim is to work on Performance-Required software. Therefore, is it possible to say that Visual C++ .NET/Managed C++ is the correct choice?
In my opinion, yes.
User interface = managed C++
Performant code = unmanaged C++
Look for the specifications of the new Visual Studio 2005 which includes
C++ and C# standard, it has interesting features.
First of all, it compiles you code (loops) in certain conditions to execute
it as hypethreading even though you do not program with threading. And it
has a featur to analyze the most used functionality by profiling and then it
can optimize even furter depending on the most used functions.
And you can freely mix managed/unmanaged within the same methods. :-)
But much less readable than C#.
-- http://www.skyscan.be
Will VS 2005 Managed C++ be usable for applications targeting the .NET
Compact Framework?
Jon Gabel
> Will VS 2005 Managed C++ be usable for applications targeting the .NET Compact Framework?
I believe yes, but not the Express version.
-- http://www.skyscan.be
"Olaf Baeyens" wrote: And you can freely mix managed/unmanaged within the same methods. :-)
But much less readable than C#.
I think, we need a special glasses to read the managed/unmanaged C++ codes
more easily :-).
Alper AKCAYOZ wrote: Hello Vranos,
I would like to advance much further on a programming language. Therefore, I
wonder the differences of prog. lang. in .NET.
With your explanations, can we say that C++ will keep its popularity,
performance and its other advantages for a long time both in .NET technology
and other Performance-Required fields?
Yes, definitely. C++ produces the best optimised managed code and the best optimised
native code. Also C++ has access to low level CLR features that other languages lack.
And also it provides features that no other languages provide. An example is both template
and generics support for managed types in VS 2005, while other languages will have only
generics. Another example is implicit deterministic destruction by using objects with
stack semantics.
In few words it goes like this in terms of power/simplicity.
Visual Basic .NET the simplest programming language and the less powerful.
C# provides more features and thus more power.
C++ provides the most features and has the most power.
IL Assembly, the assembly of .NET. The second thing that one should know along with C++ in
the .NET world ,according to my opinion. A book on this:
http://www.amazon.com/exec/obidos/tg...glance&s=books
:-)
My aim is to work on Performance-Required software. Therefore, is it
possible to say that Visual C++ .NET/Managed C++ is the correct choice?
Yes. In the upcoming VS 2005, "managed extensions" are replaced with C++/CLI, the newly
standardised set of extensions. The switch is not difficult, for example instead of writing
__gc class SomeClass;
for managed classes, you will be writing
ref class SomeClass;
The .NET APIs are not affected from this, that is they remain the same.
So in summary, .NET is a CLI compliant VM. The CLI standard is publicly available from
here (the standard contains the assembly language of the VM, so it is interesting to
download it and take a look): http://www.ecma-international.org/pu...s/Ecma-335.htm
C++/CLI is a standardised set of extensions for taking advantage of a CLI machine,
replacing current "managed extensions". The latest C++/CLI draft is this: http://www.plumhall.com/C++-CLI%20draft%201.10.pdf
The ECMA working group of C++/CLI: http://www.ecma-international.org/memento/TC39-TG5.htm
Also VC++ 2005 works with OpenMP 2 multithreading, in addition to the .NET multithreading.
OpenMP standard can be downloaded from here: http://www.openmp.org
And since we are on it, the current C# standard (which more accurately is named C#/CLI)
can be downloaded from here: http://www.ecma-international.org/pu...s/Ecma-334.htm
Integrating C++ with CLR is not a simple job. The first shot was
"managed extensions for C++. However, this was not what C++ community
expected. Visual C++, in Visual Studio 2005 release, aims to be the
"systems programming language of CLR", or "closer to the metal" (it is
close to both managed and unmanaged metal). Because C++ exposes more
(low-level) CLR features than other .NET languages does. C++ has no
problem integrating managed and unmanaged worlds, C++ has templates, we
already had them, C# met with "generics" with .NET framework 2.0.
Templates and generics are not interchangable - they are dealing about
different (but closer) concepts. However, if you take a look at "what's
new with Visual C++ 2005", you can see we have both templates, AND,
generics. We have deterministic destruction, stack semantics, we have
STL.NET. Conclusion: we have a very rich language that is a bridge
between managed and unmanaged worlds.
On the other hand, it is not wise/right to compare languages. C# is a
productive language, it is simpler. On simplicity, C++ may not provide
as much facilities as C# does. C# may not provide lower level
facilities to programmers as much as C++ does. So, for me, for example,
C++ is better. But my coworker next to my table thinks C# does better.
That depends on what you expect and what language gives.
Managed extensions for C++ will be deprecated by C++/CLI soon (I mean,
totally). I don't know famous projects written with mc++, but I expect
serious projects with C++/CLI.
C++ is a mature language, it has been 20 years. Now, compilers perform
better optimization (see Visual C++ 2005's POGO), they generate "better
code" (better may mean either faster, or shorter, depending on what you
expect), they understand more keywords, they have more directives, they
are more compliant with ISO C++ standard, etc.
Ismail
On Mon, 4 Apr 2005 15:04:10 +0200, "Olaf Baeyens"
<ol**********@skyscan.be> wrote: I create imaging software, and I try to create the user interface part and
the stuff that is less performance critical in C# because I can create that
part much faster.
But a huge part of my code base is unmanaged C++ using MFC. And I simply do
not have the time to port it to C# or managed C++ at this moment, so I have
created a mixed C++ assembly that has both managed as unmanaged code acting
as wrappers.
Olaf, I'm not the OP of this thread, but thanks for the interesting
post. I've been wondering how others do the C#->mgdC++->unmgdC++
transition. It sounds like you have had time to optimise your
approach. Do you happen to have a small 'test-subset' of your code
that will compile and transition from C# to C++? I'd love to see that,
especially if you've marshaled some data in the process.
Where did you find the original template for your code? (I am
assuming that you're using 'C++ Interop', not P-Invode/attributes.)
But you have a program that checks
compatibility called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.
First I've heard of FxCop. I'll look for info.
I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.
_R
> Olaf, I'm not the OP of this thread, but thanks for the interesting post. I've been wondering how others do the C#->mgdC++->unmgdC++
transition. It sounds like you have had time to optimise your
approach. Do you happen to have a small 'test-subset' of your code
that will compile and transition from C# to C++? I'd love to see that,
especially if you've marshaled some data in the process.
Two things: I created a managed C++ wrapper to my unmanaged classes.
So using the managed C++ classes is very simple from C#. Just like any other
C# class.
Where did you find the original template for your code? (I am
assuming that you're using 'C++ Interop', not P-Invode/attributes.)
I didn't! Looked at examples including this newsgroup and created my own
version that works.
The managed C++ to unmanaged C++ is performed by the C++ compiler. :-)
I cannot give you our code but I can give you the important parts that
works;
(This can be found on the Internet)
public __gc class MRegistery : public System::IDisposable {
private: sLib::CSkyScanReg *m_pRegistery; // The C++ unmanage
class
private: System::IntPtr __nogc * CSkyScanReg;
private: bool disposed;
public: MRegistery(void) {
disposed=false;
m_pRegistery=new sLib::CSkyScanReg();
};
public: virtual ~MRegistery(void) {
Dispose(true);
};
public: virtual void Init() {
m_pRegistery->Init();
};
public: virtual void Dispose() {
Dispose(true);
System::GC::SuppressFinalize(this);
}
protected: virtual void Dispose(bool disposing) {
if(!disposed) {
if(disposing) {
if (m_pRegistery) delete m_pRegistery;
m_pRegistery=NULL;
}
CSkyScanReg = 0;
disposed = true;
}
}
}
Only a big problems with the string stuff and boolean but I found this to do
the trick.
This is how I process string: (not CString!)
public: __property virtual System::String __gc * get_TopicName() {
return m_pRegistery->TopicName.c_str();
}
public: __property virtual void set_TopicName(System::String __gc
*asTopicName) {
m_pRegistery->TopicName=LPCTSTR((char*)(void*)System::Runtime:: InteropServic
es::Marshal::StringToHGlobalAnsi(asTopicName));
}
This is how I process boolean:
public: __property virtual void set_ForceDot(bool abForceDot) {
m_pRegistery->ForceDot=abForceDot;
}
public: __property virtual bool get_ForceDot() {
return m_pRegistery->ForceDot!=0;
}
I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.
I have no idea, I try to avoid it as much as possible.
I either operate internally the unmanaged code or I keep outside in the
managed code, but I avoid the transition as much as I can.
I have duplicate functionality. So the unmanaged parts gets replaced in type
by the managed types. Only the really performance critical code is kept in
unmanaged C++ code right now.
-- http://www.skyscan.be
"_R" <_R@nomail.org> wrote in message
news:au********************************@4ax.com... I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.
IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.
Olaf Baeyens wrote: Will VS 2005 Managed C++ be usable for applications targeting the .NET
Compact Framework?
I believe yes, but not the Express version.
Only when writing "safe"mode applications (compiled with /clr:safe). The
current CF implementation lacks several features of the desktop version
that the Visual C++ compielr uses to enable native classes and native
code to interoperate.
Ronald Laeremans
Visual C++ team
On Wed, 6 Apr 2005 16:18:31 +0200, "Sean Hederman"
<em*******@codingsanity.blogspot.com> wrote: "_R" <_R@nomail.org> wrote in message
news:au********************************@4ax.com.. . I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.
IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.
Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.
Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.
"_R" <_R@nomail.org> wrote in message
news:ll********************************@4ax.com...
[Snip] Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.
Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.
50 cycles inside a tight loop can get nasty fast. Also, this is just the
transition and does not include marshalling.
_R wrote: Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.
Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.
I do not know if this helps, but I recall that the additional run-time cost of DirectX 9
which is managed and wraps the previous version which is unmanaged, is 2%.
However wrapping must always be careful if we want to preserve performance. We must not
wrap things inside a loop, but rather the whole thing.
--
Ioannis Vranos http://www23.brinkster.com/noicys
> > Even 50 doesn't sound extraordinarily high. I've always heard that the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.
Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.
50 cycles inside a tight loop can get nasty fast. Also, this is just the
transition and does not include marshalling.
But in this case, you create a mixed managed/unmanaged C++ assembly that
does this thing in unmanaged C++ and then comes back to managed C++. This
way only one transition.
Creating assemblies is far easier done than creating normal dll's in .NET.
"Alper AKCAYOZ" wrote: 2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?
Apparently that's already happened, even before VS 2005 is released. Over
on the "Channel 9" section of MSDN there is a sequence of videos proclaiming
the Class Designer as a truly wonderful tool you will use to build your
codes. This tool will be available for C#, VB, and J#, but the C++ version
was dropped from "whidbey" sometime in early March because it couldn't be
finished in the remaining time, with the needed quality. It is promised for
"a future release" of Visual Studio. Note too that along with Visual Studio
2005, MS will be selling the companion Visual Studio Tools for Office. It's
what you will use for programming with Word, Excel, etc. The supported
languages are C# and VB.NET.
At least that's my understanding of the current state of affairs. I welcome
any corrections, clarifications, or insight from MS VIPs or other insiders.
Wil
Wil wrote: Apparently that's already happened, even before VS 2005 is released. Over
on the "Channel 9" section of MSDN there is a sequence of videos proclaiming
the Class Designer as a truly wonderful tool you will use to build your
codes. This tool will be available for C#, VB, and J#, but the C++ version
was dropped from "whidbey" sometime in early March because it couldn't be
finished in the remaining time, with the needed quality. It is promised for
"a future release" of Visual Studio. Note too that along with Visual Studio
2005, MS will be selling the companion Visual Studio Tools for Office. It's
what you will use for programming with Word, Excel, etc. The supported
languages are C# and VB.NET.
At least that's my understanding of the current state of affairs. I welcome
any corrections, clarifications, or insight from MS VIPs or other insiders.
Well I think there may be some tendency to leave C++ one step behind in each release of
VS. First it was the lack of designer support in VS 2002 -added in VS 2003-, then the
smart devices development support in VS 2003 -added in VS 2005 as far as I know -.
Now if you are correct the class designer, however for this there may be complexity
reasons, remember C++ is both worlds, managed and unmanaged and perhaps they could do not
make the class designer support both of them, in time.
However not provided C++ support for Visual Tools for Office, or support for web
programming, I think is clearly for leaving C++ a bit behind. As far as I can get, they
may feel better having you using VB and VC#, the same way that Borland for example may be
feeling better if you use Delphi (vendor lock-in).
However I think this is a mistake for MS, for two reasons. First there is *.NET* C#
support (more than .NET support for C++) from companies other than Microsoft. An example
is C# IDE by Borland. Another example is C# (and I think also VB) compilers by Mono and
run-time support of them (that is even C#/VB programs compiled with Visual Studio under
Windows, can run under Mono in Linux).
So I do not think there is any vendor lock-in for VC# and VB if this is the intention, and
C# especially, since C# is standardised (ECMA C#/CLI standard).
Ioannis Vranos wrote: Well I think there may be some tendency to leave C++ one step behind in
each release of VS. First it was the lack of designer support in VS 2002
-added in VS 2003-, then the smart devices development support in VS
2003 -added in VS 2005 as far as I know -.
Now if you are correct the class designer, however for this there may be
complexity reasons, remember C++ is both worlds, managed and unmanaged
and perhaps they could do not make the class designer support both of
them, in time.
However not provided C++ support for Visual Tools for Office, or support
for web programming, I think is clearly for leaving C++ a bit behind. As
far as I can get, they may feel better having you using VB and VC#, the
same way that Borland for example may be feeling better if you use
Delphi (vendor lock-in).
However I think this is a mistake for MS, for two reasons. First there
is *.NET* C# support (more than .NET support for C++) from companies
other than Microsoft. An example is C# IDE by Borland. Another example
is C# (and I think also VB) compilers by Mono and run-time support of
them (that is even C#/VB programs compiled with Visual Studio under
Windows, can run under Mono in Linux).
So I do not think there is any vendor lock-in for VC# and VB if this is
the intention, and C# especially, since C# is standardised (ECMA C#/CLI
standard).
Second (and additionally), C++ is probably the dominant general purpose programming
language, and leaving behind this audience can only result them leaving you in the first
opportunity.
So in summary, leaving behind many *millions* of C++ programmers while at the same time
there is no real vendor lock in for C# and VB programmers, can only result in becoming
second or more behind, in the first opportunity.
Please tell me if I am missing something.
"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... Well I think there may be some tendency to leave C++ one step behind in
each release of VS.
I guess that depends of your definition of "tendency". If you mean that
there is a clearly articulated strategy deliberately to limit the feature
set provided for the version of C++ that ships in VS.Net 2003 or 2005, then
this is quite simply not the case.
The C++ team members have posted here many times that their _goal_ is to get
C++ to the lofty place in the .Net food-chain that it occupies on the
unmanaged side.
Now, I can't tell you why some features do or don't make the cut for
inclusion into future products - obviously its an internal decsion - but I
can speculate.
My guess is that it is just harder to do because the language is so much
more complex by comparison to the others. And no organization, not even MS,
has unlimited resources. So, with deadlines looming, when push comes to
shove managers tend to look for the "biggest bang for the buck" directing
resources at those parts of a product that are most critcial to most of
their customers and putting off what they think will have the the smallest
payoff. That's just my opinion.
On the other hand, if by tendency, you aren't speaking of a strategy, but
rather just the nature of the more complex relationship between the language
and the platforms - Win32 and .Net - you may be correct. Time will tell.
Regards,
Will
"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:42**********************@news.skynet.be... > Even 50 doesn't sound extraordinarily high. I've always heard that
> the transition was a limiting runtime factor, but that sounds like the
> equivalent of calling a tiny subroutine.
>
> Strange thing though, I've worked with code that didn't transition
> smoothly when translated to VC++ with a managed wrapper/bridge.
> I had assumed that it was the transition cycles. I guess I should
> look elsewhere.
50 cycles inside a tight loop can get nasty fast. Also, this is just the
transition and does not include marshalling.
But in this case, you create a mixed managed/unmanaged C++ assembly that
does this thing in unmanaged C++ and then comes back to managed C++. This
way only one transition.
Keep in mind that any variables declared in one "section" and used in the
other will have to be marshalled. If they're blittable types, it'll be fast,
but it's still added cycles.
#pragma unmanaged <-- transition
char * hello = "Whatever\0";
#pragma managed <-- transition
hello++; <-- marshalling
Creating assemblies is far easier done than creating normal dll's in .NET.
"Ioannis Vranos" wrote: Now if you are correct the class designer, however for this there may be complexity
reasons, remember C++ is both worlds, managed and unmanaged and perhaps they could do not
make the class designer support both of them, in time.
For a discussion straight from the horse's mouth about the dropping of Class
Designer from the C++ side of Visual Studio 2005, see: http://blogs.msdn.com/classdesigner/...04/384764.aspx
along with the comments from C++ programmers who had planned on using it.
The omission of C++ from Visual Studio Tools for Office would seem to be a
policy decision, rather than just a not-enough-time-since-it's-too-complex
issue. This Office-is-for-C#-and VB-only policy, if it is indeed that, would
seem to indicate that C++ is **not** regarded as a first-class language for
systems development under .NET.
Actually, I presonally don't care all that much about systems development
with or wothout Office, but I care a great deal about numerical applications
development (traditionally the bailiwick of C, C++ and FORTRAN) and
especially about applications integration. I had hoped that the wave of the
future for making these codes share data and processing results would be Web
services using Indigo. Will this work for C++ applications or only for C#/VB
applications? Given the current state of affairs with ASP.NET, I must wonder
what is planned in that arena. The precedent of "no C++ allowed" in Visual
Tools for Office certainly gives me cause for worry, though. Surely we shall
be able to tie together C++ back-end apps using these SOAP-based services
without having to jump through **too** many hoops, compared with C#/VB apps?
Please????
William DePalo [MVP VC++] wrote: I guess that depends of your definition of "tendency". If you mean that
there is a clearly articulated strategy deliberately to limit the feature
set provided for the version of C++ that ships in VS.Net 2003 or 2005, then
this is quite simply not the case.
The C++ team members have posted here many times that their _goal_ is to get
C++ to the lofty place in the .Net food-chain that it occupies on the
unmanaged side.
Now, I can't tell you why some features do or don't make the cut for
inclusion into future products - obviously its an internal decsion - but I
can speculate.
My guess is that it is just harder to do because the language is so much
more complex by comparison to the others.
OK this may be true for some features, however why there is no direct C++ support for
Visual Studio Tools for Office? I suppose it is a managed interface/dlls and it can work
with all managed languages including C++. Perhaps I am missing something here?
The same applies for ASP .NET (although I do not care for web development so far). Since
all languages produce IL code, why this is also not available in C++?
"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl... OK this may be true for some features, however why there is no direct C++
support for Visual Studio Tools for Office? I suppose it is a managed
interface/dlls and it can work with all managed languages including C++.
Perhaps I am missing something here?
I don't know why. I do know that current MC++ assemblies are unverifiable.
Perhaps that figures into it. Perhaps not.
The same applies for ASP .NET (although I do not care for web development
so far). Since all languages produce IL code, why this is also not
available in C++?
I don't know why this is so, either.
But it is too early to draw the conclusion that there is a deliberate
"tendency" to be an also-ran as you postulated in a earlier post. The
introduction of C++/CLI, the ECMA standardization effort and the fact that
Herb Sutter and Stanley Lippman are both on the team seem to me to refute
that.
Regards,
Will
> >> > Even 50 doesn't sound extraordinarily high. I've always heard that > the transition was a limiting runtime factor, but that sounds like
the > equivalent of calling a tiny subroutine.
>
> Strange thing though, I've worked with code that didn't transition
> smoothly when translated to VC++ with a managed wrapper/bridge.
> I had assumed that it was the transition cycles. I guess I should
> look elsewhere.
50 cycles inside a tight loop can get nasty fast. Also, this is just
the transition and does not include marshalling.
But in this case, you create a mixed managed/unmanaged C++ assembly that
does this thing in unmanaged C++ and then comes back to managed C++.
This way only one transition.
Keep in mind that any variables declared in one "section" and used in the
other will have to be marshalled. If they're blittable types, it'll be
fast, but it's still added cycles.
#pragma unmanaged <-- transition
char * hello = "Whatever\0";
#pragma managed <-- transition
hello++; <-- marshalling
I don't know about that part.
I only use memory blocks for the fast processing (image buffers) using the
fixed keyword to pin down any memory and get the pointers to the data.
I do use strings, so these also slow down, but these strings ar small
compared to the real processing stuff. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Alper AKCAYOZ |
last post by:
Hello Esteemed Developers and Experts,
I have been using Microsoft Visual C++ .NET for 1 year. During this time,
I have searhed some topics over internets. Most of the topics about .NET is...
|
by: Stephen Walch |
last post by:
Error C2392 is hitting me hard!
I have a managed C++ library that implements a bunch of fixed interfaces.
For example, one interface is:
public abstract interface IDbCommand
{
public...
|
by: Rachel Suddeth |
last post by:
What is the difference between a managed/unmanaged resource, and how do you
tell which is which? I'm trying to understand how to write some Dispose()
methods, and we are supposed to put code that...
|
by: =?Utf-8?B?RWR3YXJkUw==?= |
last post by:
I would greatly appreciate some help on passing managed object into unmanaged
code.
I need to pass a reference (address of) of a managed class into unmanaged
code (written by a thrid party). The...
|
by: Ryanivanka |
last post by:
hi,
is the stackframe in managed code the same as in unmanaged?
or they are not related at all.... :)
if I use some asm codes (get the esp register or something about
stackframe) in a...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
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:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
