Re: Array optimizing problem in C++?
On 2008-04-01 20:52, Ioannis Vranos wrote:
Erik Wikstr??m wrote:
On 2008-04-01 14:07, Ioannis Vranos wrote:
Lew wrote:
Ioannis Vranos wrote:
If SUN [sic] wanted, they could open their JVM to more languages like
C++, as
MS does for .NET.
Which they have done, as have other JVM vendors. In fact, there's
absolutely nothing at all about any of these JVM implementations to
prevent anyone from targeting them with any language's compilers at any
time, nor has there ever been. What more is needed to "open" these JVMs?
OK, but SUN could provide C++ support for JVM as MS does for .NET.
Just because C++/CLI have C++ in the name does not make it C++.
C++/CLI is a *standardised extension* to ISO C++.
Extension to C++ yes, but it is not C++. While it does have similar
syntax the fact that it targets the CLR (and that you'll be
It maps directly to CLI facilities and provides the necessary guarantees
for ISO C++ and C++/CLI code interaction (for example making a managed
interface of native ISO C++ code to be used by C++/CLI and other CLI
languages (e.g. C#, VB, etc), or the opposite, create an ISO C++
interface of managed CLI code (e.g. written on C#, VB, etc), or mixing
managed and native code, for example a managed class having as members
std::string and probably (I am not sure) the opposite, a native C++
class having managed code, e.g. having a managed String object as a
member). With C++/CLI, C++ is the systems programming language of .NET.
Actually you can not mix very well, the following two things are not
allowed:
// Managed class with "native" member
ref struct Foo
{
std::string s;
};
// "Native" class with managed member
struct Foo
{
String^ s;
};
I like it (although I am not using it), because C++/CLI keeps managed
and native notions separate, while providing deterministic destruction
for managed objects too.
My experience is that you really can not mix managed and native code
very well before running into problems.
So if you like .NET, C++/CLI is ideal for writing applications or
*libraries* for it.
For writing wrappers around native code it is quite useful but if you
want to write something larger I would suggest C#, it is less "cumbersome".
PS.
Removed cross-post to c.l.j.p.
--
Erik Wikstr??m