C++ standard and C++/CLI

Post by Ioannis Vranos
Is there any intention these two standards to merge sometime in the
future? Is it possible to merge? I do not know much of the C++/CLI yet,
but from few things have read the .NET generics are not compatible (a
subset) of C++ templates, so I wonder there will be two kinds of
templates in the future?

There is only one C++ language and only one body responsible for its
Standardisation.

ECMA claims that C++/CLI is merely a set of bindings to C++ somewhat
like the bindings Posix defines for C. I am not alone in thinking that
in the case of C++/CLI this is pushing the concept of 'bindings' outside
that of the known universe.

WG21 in general and most particularly the UK and French C++ Standard's
experts are working very hard to reduce design decisions in ECMA's
TC39-TC5 to those which will not adversely influence the future
development of C++. In the case of the UK we are extremely concerned
that after the completion of C++/CLI that the resulting 'standard' will
be fast-tracked into an ISO Standard but left in the hands of ECMA for
future maintenance and revision.

Please note that I do not wish to imply that any of those participating
in TC39-TG5 have any but the best motives. Indeed they have pushed ECMA
very hard to allow WG21 experts to have access to the confidential
documentation so that they can comment in a timely fashion. However I do
think that ECMA's is probably abusing its Class A liaison position with
ISO, and that JTC1 (the Joint IEC/ISO technical committee with ultimate
oversight of the work of SC22) needs to be more assiduous in promoting
itself and its rules for fast-track standards.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-04 10:56:11 UTC

Post by Francis Glassborow

There is only one C++ language and only one body responsible for its
Standardisation.
ECMA claims that C++/CLI is merely a set of bindings to C++ somewhat
like the bindings Posix defines for C. I am not alone in thinking that
in the case of C++/CLI this is pushing the concept of 'bindings' outside
that of the known universe.
WG21 in general and most particularly the UK and French C++ Standard's
experts are working very hard to reduce design decisions in ECMA's
TC39-TC5 to those which will not adversely influence the future
development of C++. In the case of the UK we are extremely concerned
that after the completion of C++/CLI that the resulting 'standard' will
be fast-tracked into an ISO Standard but left in the hands of ECMA for
future maintenance and revision.
Please note that I do not wish to imply that any of those participating
in TC39-TG5 have any but the best motives. Indeed they have pushed ECMA
very hard to allow WG21 experts to have access to the confidential
documentation so that they can comment in a timely fashion. However I do
think that ECMA's is probably abusing its Class A liaison position with
ISO, and that JTC1 (the Joint IEC/ISO technical committee with ultimate
oversight of the work of SC22) needs to be more assiduous in promoting
itself and its rules for fast-track standards.

However it will be nice to have C++ work natively in VM environments in
a standardised way.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gabriel Dos Reis

2004-07-05 10:11:31 UTC

Ioannis Vranos <***@guesswh.at.grad.com> writes:

[...]

| > Please note that I do not wish to imply that any of those participating
| > in TC39-TG5 have any but the best motives. Indeed they have pushed ECMA
| > very hard to allow WG21 experts to have access to the confidential
| > documentation so that they can comment in a timely fashion. However I do
| > think that ECMA's is probably abusing its Class A liaison position with
| > ISO, and that JTC1 (the Joint IEC/ISO technical committee with ultimate
| > oversight of the work of SC22) needs to be more assiduous in promoting
| > itself and its rules for fast-track standards.
|
|
| However it will be nice to have C++ work natively in VM environments in
| a standardised way.

Sorry, I guess that is too abstract for me. In concrete terms, what
does the above line means?

Thanks,

--
Gabriel Dos Reis
***@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-05 14:58:31 UTC

Post by Gabriel Dos Reis
[...]
| > Please note that I do not wish to imply that any of those participating
| > in TC39-TG5 have any but the best motives. Indeed they have pushed ECMA
| > very hard to allow WG21 experts to have access to the confidential
| > documentation so that they can comment in a timely fashion. However I do
| > think that ECMA's is probably abusing its Class A liaison position with
| > ISO, and that JTC1 (the Joint IEC/ISO technical committee with ultimate
| > oversight of the work of SC22) needs to be more assiduous in promoting
| > itself and its rules for fast-track standards.
|
|
| However it will be nice to have C++ work natively in VM environments in
| a standardised way.
Sorry, I guess that is too abstract for me. In concrete terms, what
does the above line means?

Example code C++/CLI draft standard compliant:

// Garbage collected class
ref class whatever
{
// ...
};

whatever ^p = gcnew whatever;

// No need to call delete

long l=7;

long *lp=new long(7);

// ...

delete lp;

long ^lp=gcnew long(7);

// Operator overloading as usual for GC pointers
whatever^ operator+(whatever ^a, whatever ^b)
{
// ...
}

vector<int>*p = new vector<int>;

// ...

delete p;

// This vector is garbage collected
// We can make any object garbage collected
vector<int>^pvec = gcnew vector<int>;

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Paul Mensonides

2004-07-05 22:35:54 UTC

Post by Gabriel Dos Reis
| However it will be nice to have C++ work natively in VM environments in
| a standardised way.
Sorry, I guess that is too abstract for me. In concrete terms, what
does the above line means?

// Garbage collected class
ref class whatever
{
// ...
};

I think the point is that none of this is C++. It's C++/CLI which, while
similar, is definitely not C++.

Regards,
Paul Mensonides

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-06 11:20:32 UTC

Post by Paul Mensonides

Post by Ioannis Vranos
// Garbage collected class
ref class whatever
{
// ...
};

I think the point is that none of this is C++. It's C++/CLI which, while
similar, is definitely not C++.

It is not ISO C++. However it is (will be) a set of *standardised*
extensions for use in a CLI compliant environment.

"CLI is a ISO-standardized language-neutral runtime environment that
supports garbage collection, security, and other modern features."

So we have, an ISO C++ standard, an ISO CLI environment standard (a VM
with its own assembly language standardised!), and we are going to get a
standard on C++/CLI interaction.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gabriel Dos Reis

2004-07-07 17:59:51 UTC

Ioannis Vranos <***@guesswh.at.grad.com> writes:

[...]

| "CLI is a ISO-standardized language-neutral runtime environment that
| supports garbage collection, security, and other modern features."
|
| So we have, an ISO C++ standard, an ISO CLI environment standard (a VM
| with its own assembly language standardised!), and we are going to get a
| standard on C++/CLI interaction.

That is what the CLI/C++ propaganda says. But not just because the
propaganda says it means it is true. What I care about is the actual
facts. As things stand, the CLI/C++ invention would bring "neutrality"
only on the implied plateform.

llewelly

2004-07-05 22:36:45 UTC

// Garbage collected class
ref class whatever
{
// ...
};
whatever ^p = gcnew whatever;
// No need to call delete
long l=7;
long *lp=new long(7);
// ...
delete lp;
long ^lp=gcnew long(7);
// Operator overloading as usual for GC pointers
whatever^ operator+(whatever ^a, whatever ^b)
{
// ...
}
vector<int>*p = new vector<int>;
// ...
delete p;
// This vector is garbage collected
// We can make any object garbage collected
vector<int>^pvec = gcnew vector<int>;

[snip]

What does this have to do with 'work natively in VM environments'?
There is no necessary relationship between garbage collection and a
virtual machine.

If there is to be a C++ implementation which runs under a virtual
machine, why shouldn't it aim for the existing ISO C++ standard?

Further, having garbage collection in ISO C++ would be a big
improvement, but I would object strongly to semtatics that
required the class declaration be explicitlly decorated. The
storage of most objects (be it stack, (collected) heap,
whatever) should be independent of the object's type. I'm
neutral w.r.t to using a different kind of indirect type for
referencing garbage collected objects, but at the very least,
that goes against the existing practice established by 3rd-party
garbage collectors for C++ such as Boehm's.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-06 11:19:54 UTC

Post by llewelly
What does this have to do with 'work natively in VM environments'?
There is no necessary relationship between garbage collection and a
virtual machine.

CLI is a VM with its assembly language defined. In fact CLI was
previously standardised by ECMA and the standard was available in .pdf
format, together with its assembly language and I did not keep them, so
now that it has become an ISO standard I haven't them. :-(

Post by llewelly
If there is to be a C++ implementation which runs under a virtual
machine, why shouldn't it aim for the existing ISO C++ standard?

Actually CLI is a bout a multilingual VM, and C++/CLI about working in
this VM environment/ The ISO C++ standard does not specify a
standardised way to do that (that is portable to all CLI compliant
machines).

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Nicola Musatti

2004-07-06 11:37:51 UTC

llewelly <***@xmission.dot.com> wrote in message news:<***@Zorthluthik.local.bar>...
[...]

Post by llewelly
Further, having garbage collection in ISO C++ would be a big
improvement, but I would object strongly to semtatics that
required the class declaration be explicitlly decorated. The
storage of most objects (be it stack, (collected) heap,
whatever) should be independent of the object's type. I'm
neutral w.r.t to using a different kind of indirect type for
referencing garbage collected objects, but at the very least,
that goes against the existing practice established by 3rd-party
garbage collectors for C++ such as Boehm's.

Much as I dislike the whole C++/CLI syntax, there is a case for
differentiating certain garbage collected types from other pointers,
to allow their relocation.

My point of view is that this should be achieved by means of a library
or a library-like syntax and not by changing the core language.

Cheers,
Nicola Musatti

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-08 01:23:21 UTC

Post by Ioannis Vranos
// This vector is garbage collected
// We can make any object garbage collected
vector<int>^pvec = gcnew vector<int>;

Actually after some discussions in another newsgroup, I do not think the
above one will be possible, and the latest C++/CLI draft standard that I
have says:

"15.4.6 The gcnew operator

The gcnew operator is similar to the new operator, except that the
former creates an object on the CLI heap. The type of the result of the
gcnew operator is a handle to the type of the object allocated. In
out-of-memory situations, gcnew throws System::OutOfMemoryException.

There is no array form of gcnew. There is no placement form of gcnew.
The gcnew operator cannot be overloaded or replaced. There is no
class-specific form of gcnew.

A program is ill-formed if it attempts to allocate memory for an object
of native type using gcnew.

15.4.6.1 gcnew object creation expressions

In the C++ Standard (=A75.3.4), a new-expression is used to allocate
memory for an object at runtime. This grammar has been extended to
accommodate the addition of the gcnew operator, as follows:

new-expression:
=85
gcnew new-type-id new-initializeropt
gcnew ( type-id ) new-initializeropt

[Add the array case to this grammar.]

The type of the object being allocated shall not be an abstract class
type. The type shall not be incomplete.

[Note: The gcnew operator applied to a value class creates a boxed value
class. end note]"

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Roland Pibinger

2004-07-05 22:37:40 UTC

http://www.codeproject.com/managedcpp/cppcliintro01.asp
http://www.codeproject.com/managedcpp/cppclioverriding.asp

"Oh boy" (Chris Maunder)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gabriel Dos Reis

2004-07-06 11:21:42 UTC

***@yahoo.com (Roland Pibinger) writes:

| On 5 Jul 2004 06:11:31 -0400, Gabriel Dos Reis <***@cs.tamu.edu>
| wrote:
|
| >Ioannis Vranos <***@guesswh.at.grad.com> writes:
| >
| >| However it will be nice to have C++ work natively in VM environments in
| >| a standardised way.
| >
| >Sorry, I guess that is too abstract for me. In concrete terms, what
| >does the above line means?
|
| http://www.codeproject.com/managedcpp/cppcliintro01.asp
| http://www.codeproject.com/managedcpp/cppclioverriding.asp

Thanks for those links, but I still fail to see the meaning of

However it will be nice to have C++ work natively in VM environments in
a standardised way.

Would you mind explaining?

Thanks,

llewelly

2004-07-06 21:38:05 UTC

Post by Roland Pibinger

http://www.codeproject.com/managedcpp/cppcliintro01.asp
http://www.codeproject.com/managedcpp/cppclioverriding.asp

AFAICT, these are articles about how C++/CLI improves or extends
managed C++. There's no hint in them as how closely C++/CLI
is compatible with ISO C++.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-07 07:53:49 UTC

Post by llewelly
AFAICT, these are articles about how C++/CLI improves or extends
managed C++. There's no hint in them as how closely C++/CLI
is compatible with ISO C++.

My understanding is that C++/CLI will be a conforming C++ implementation.
Well, not really, as it will probably not implement certain features of
the current C++ standard, notably the separation model, i.e. exported
templates. However, C++/CLI will compile any standard conforming code
(which stays clear of the few restrictions found in most contemporary
compilers) and execute it in a way conforming to the C++ compiler - at
least on Microsoft's CLI implementation. The resulting code will, however,
take advantage of features not specified in the CLI standard. At least,
this is my understanding. I would be delighted to learn otherwise.

--
<mailto:***@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-07 17:40:07 UTC

Post by llewelly
AFAICT, these are articles about how C++/CLI improves or extends
managed C++. There's no hint in them as how closely C++/CLI
is compatible with ISO C++.

I think you are correct as of today. However once we have constrained
C++/CLI and standardised it (note that that does not mean I accept the
current way that ECMA language standards get fast-tracked to ISO ones)
we are in a strong position to require the CLI standard to acknowledge
the need for C++/CLI code (all of it) to be portable to any platform
implementing CLI + CLR. I.e. once C++ in its C++/CLI form is a fully
conforming member of the CLI family of languages we can start on any
inadequacies in the CLI Standard that prevent that same code running on
Mono. However, in fairness, Java also supports system specific code.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:09:35 UTC

Post by llewelly
AFAICT, these are articles about how C++/CLI improves or extends
managed C++. There's no hint in them as how closely C++/CLI
is compatible with ISO C++.

It is designed to be a set of pure extensions to ISO C++, and the intent
going forward is to serve and track ISO C++ as ISO C++ evolves. For
example, the new keywords are mostly not reserved words, so that they
don't affect the meaning of variables with those names in existing code --
this part was sometimes hard to do, but I think the effort was worth it.

The only conforming ISO C++ code whose meaning would change is code that
is highly contrived (and disambiguation is easy) or has macros with the
names of some of the new keywords (but even macro conflict cases have been
limited).

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 21:33:52 UTC

Post by llewelly
AFAICT, these are articles about how C++/CLI improves or extends
managed C++. There's no hint in them as how closely C++/CLI
is compatible with ISO C++.

I don't think C++/CLI is just a pure extensions to ISO C++. It is an
extensions in order to fit CLI or .NET framework or whatever MS calls.
To call such an extensions to serve and track ISO C++ as ISO C++
evolves is misleading. CLI is just one run-time environment. ISO C++
evolving doesn't mean to tie one platform. Even in the CLI platform,
an ISO C++ application cannot be portable between Windows and Linux.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Nicola Musatti

2004-07-05 14:56:43 UTC

Ioannis Vranos <***@guesswh.at.grad.com> wrote in message news:<cc7b1u$g4l$***@ulysses.noc.ntua.gr>...
[...]

Post by Ioannis Vranos
However it will be nice to have C++ work natively in VM environments in
a standardised way.

Evidently this was not considered a requirement by those that designed
their VM's to be incompatible with the C++ object model.

Cheers,
Nicola Musatti

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-06 11:17:09 UTC

Post by Ioannis Vranos
However it will be nice to have C++ work natively in VM environments in
a standardised way.

What is the big advantage over "normal" executables? From statements of
people working on the C++/CLI at Microsoft I understand that code outside
the "managed" capabilities will not work on other than the Microsoft VM:
the mechanisms to implement this stuff are not specified in the standard
for the .NET virtual machine. That is, if you are doing anything in your
C++ code which you could not have done with C#, too, it will not run e.g.
for Mono: no templates, no multiple inheritance (unless you are using
interfaces), no destruction at end of blocks, etc. (I would be delighted
to learn that MSVC++.Net compiled code using e.g. the features mentioned
above can run on any conforming virtual machine for .Net).

Ioannis Vranos

2004-07-06 21:05:12 UTC

Post by Ioannis Vranos
However it will be nice to have C++ work natively in VM environments in
a standardised way.

What is the big advantage over "normal" executables? From statements of
people working on the C++/CLI at Microsoft I understand that code outside

At first we are talking about a CLI environment (and .NET is one).
Managed and unmanaged code can be combined, including vectors with GC
objects for example (this will be possible with VC++ 2005). Also you
will be able to do:

// Garbage collected int
int ^p= gcnew int(5);

vector<int> *p=new vector<int>;

// ...

delete p;

// This vector will be garbage collected
vector<int> ^p=gcnew vector<int>;

// A vector with GC handles
vector<Button ^>buttonArray;

Also you will be able to create ref objects in the stack (=with
deterministic finalisation). Not all of this will be able with VC++ 2005
but some will be available in next versions, but lets not be vendor
specific.

This is what we are talking about, standardised C++ extensions which
work seamlessly in a standardised *multilingual* VM environment, which
also has a standardised assembly language.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-07 07:51:14 UTC

Post by Ioannis Vranos
However it will be nice to have C++ work natively in VM environments
in a standardised way.

What is the big advantage over "normal" executables? From statements of
people working on the C++/CLI at Microsoft I understand that code outside

At first we are talking about a CLI environment (and .NET is one).

As stated above, the Microsoft implementation is the only one where C++
code outside the managed stuff will run. This is, at least, what was stated
by Microsoft people. How is this state of affairs different from x86
binaries which only run on a Windows platform (well, of course, it would
allow Microsoft to reach out for whatever system they decide to support
which may be considered to be a benefit to some; I just don't happen to be
among those).

Post by Ioannis Vranos
Managed and unmanaged code can be combined, including vectors with GC
objects for example (this will be possible with VC++ 2005). Also you
// Garbage collected int
int ^p= gcnew int(5);

If I want to use C#, I use C#.

Post by Ioannis Vranos
vector<int> *p=new vector<int>;
...
delete p;

... and the resulting code will not run on a different CLI implementation
than Microsoft's.

Post by Ioannis Vranos
// This vector will be garbage collected
vector<int> ^p=gcnew vector<int>;

This is what C# generics can do for me, too. Thus, again: if I want to use
C#, I use C#.

Post by Ioannis Vranos
// A vector with GC handles
vector<Button ^>buttonArray;

This may be a neat application which is, again, confined to Microsoft's
implementation of the CLI.

I can see where the benefit of this stuff is for Microsoft. Where is mine?
If I want to use garbage collection in C++, I don't have to mutate the
syntax of C++, I use an add-on garbage collector. ... and I'm already
capable of creating executable which only run on Windows machines.

Post by Ioannis Vranos
Also you will be able to create ref objects in the stack (=with
deterministic finalisation). Not all of this will be able with VC++ 2005
but some will be available in next versions, but lets not be vendor
specific.

I don't care about creating "ref objects" at all. You seemed to indicate
that C++/CLI is some form of virtual machine for standard C++ which it
isn't, at least not in a form which would give me any benefit, e.g. in
the form of allowing C++ code to run within Mono, another CLI
implementation, on my Linux box. I can see that C++/CLI is a superior
choice for writing code for Microsoft's CLI than is C#. If I want the
code to also run e.g. on Mono, I should stay clear of this, however. In
some sense this avoids the Java problem of "implement once, test
everywhere" because there is only one supported virtual machine, namely
Microsoft's which is likely to be available only on Windows machines.

Post by Ioannis Vranos
This is what we are talking about, standardised C++ extensions which
work seamlessly in a standardised *multilingual* VM environment, which
also has a standardised assembly language.

... and why should I get excited about this: I'm working on a Linux machine
where all this stuff will not be available. Personally, I don't see much
advantage in having a company mutate C++ into what they want to look it. I
hope that the WG21 members involved in this will try to prevent the worst
damage and retain a language core which will continue to be available on
all platforms.

Ioannis Vranos

2004-07-07 17:47:56 UTC

Post by Ioannis Vranos
At first we are talking about a CLI environment (and .NET is one).

As stated above, the Microsoft implementation is the only one where C++
code outside the managed stuff will run.

For now. Again we are talking about an ISO standardised CLI
(multilingual VM) environment and not a particular implementation.

Post by Dietmar Kuehl
This is, at least, what was stated
by Microsoft people. How is this state of affairs different from x86
binaries which only run on a Windows platform (well, of course, it would
allow Microsoft to reach out for whatever system they decide to support
which may be considered to be a benefit to some; I just don't happen to be
among those).

However there is no standard defining how C++ will interoperate in such
a standardised VM multilingual environment, portably. That is code
written in ISO C++ and C++/CLI will compile to every CLI environment.
C++/CLI is an extension to ISO C++ and does not replace it.

If I want to use C#, I use C#.

Post by Ioannis Vranos
vector<int> *p=new vector<int>;
...
delete p;

... and the resulting code will not run on a different CLI implementation
than Microsoft's.

Why?

Post by Ioannis Vranos
// This vector will be garbage collected
vector<int> ^p=gcnew vector<int>;

This is what C# generics can do for me, too. Thus, again: if I want to use
C#, I use C#.

They are not the same. Generics will also be included in C++/CLI
standard. What are the major differences between templates and generics?

Templates are instantiated at compile time while Generics at run-time.

Also Generics do not allow specialisations. So C++ will support both of
them.

Post by Dietmar Kuehl
I don't care about creating "ref objects" at all. You seemed to indicate
that C++/CLI is some form of virtual machine for standard C++ which it
isn't, at least not in a form which would give me any benefit, e.g. in
the form of allowing C++ code to run within Mono, another CLI
implementation, on my Linux box.

It is for CLI environments. So yes, C++/CLI code will run OK in Mono (I
guess in the future), since it is CLI compliant.

CLI is a standardised *multilingual* VM environment.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hyman Rosen

2004-07-08 01:41:53 UTC

Post by Dietmar Kuehl
I can see where the benefit of this stuff is for Microsoft. Where is mine?

What an odd question! Microsoft is enhancing its C++ implementation
for the benefit of programmers who are using it. Your benefit is that
you have new features available for you to use. Any other compiler maker
is free to imitate this behavior if they want to. If the enhancements
turn out to be useful and successful, they could be incorporated into a
future version of the Standard.

Post by Dietmar Kuehl
If I want to use garbage collection in C++, I don't have to mutate the
syntax of C++, I use an add-on garbage collector.

But those have to be conservative collectors. With the enhanced syntax,
the garbage collection can be precise because the runtime system knows
where all the pointers are.

Post by Dietmar Kuehl
... and why should I get excited about this: I'm working on a Linux machine
where all this stuff will not be available.

Well, that's *your* problem, isn't it? Microsoft is providing very
interesting enhancements to the language for people who use their
software. From what I've seen, it appears to be a pretty good way to
incorporate garbage collection into C++ while still allowing the old
pointer-twiddling style.

Post by Dietmar Kuehl
Personally, I don't see much advantage in having a company mutate C++ into
what they want to look it. I hope that the WG21 members involved in this
will try to prevent the worst damage and retain a language core which will
continue to be available on all platforms.

This sounds excatly like what Microsoft says its opponents do - deliberately
trying to stifle innovation because they are incapable of keeping up. Think
about what you have said - instead of Linux being a viable alternative to
Windows, it has now become a reason to halt progress, because no one will do
the work to give you for free what Microsoft is providing for a fee.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-08 12:11:21 UTC

Post by Hyman Rosen
This sounds excatly like what Microsoft says its opponents do - deliberately
trying to stifle innovation because they are incapable of keeping up. Think
about what you have said - instead of Linux being a viable alternative to
Windows, it has now become a reason to halt progress, because no one will do
the work to give you for free what Microsoft is providing for a fee.

You might want to note the context of my statements: Someone claimed that
C++/CLI will bring C++ to a VM and that this is a benefit for C++ in some
form. All I did was pointing out that this is no real difference than
compiling to binary code. It is this way because the binding of C++/CLI
features which do not fit into the managed subset are in no way standardized
and thus the code will run only on a very specific VM. My point is to make
clear that C++/CLI will *NOT* give you any form of platform independence, as
is e.g. provided by Java, and that you shall *NOT* use C++/CLI if you wish
to support multiple platforms.

I don't consider this to be "stifling innovation". And to make things clear:
I'm not against .Net or modifying C++ to be a viable language for running on
a virtual machine. What I'm disputing is the implied benefit that C++/CLI
will give C++ any advantage other than being a superior .Net language with
the caveat of restricting the resulting assemblies to just one VM. As a
consequence, I don't see any benefit for me to move to C++/CLI rather than
staying with C# (if I target .Net) or C++ (if I target binary executables)
because to me it is important that the customer can choose the appropriate
platform to run my applications.

Ioannis Vranos

2004-07-08 23:28:20 UTC

Post by Dietmar Kuehl
It is this way because the binding of C++/CLI
features which do not fit into the managed subset are in no way standardized
and thus the code will run only on a very specific VM.

? We are talking about C++/CLI which is about working with CLI and not
anything else. Will not this

ref class whatever
{ };

whatever ^h=gcnew whatever;

compile in every CLI compliant VM for which there will be a C++
compiler? So it will be portable to all CLI VMs.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-09 13:16:52 UTC

Post by Dietmar Kuehl
It is this way because the binding of C++/CLI
features which do not fit into the managed subset are in no way
standardized and thus the code will run only on a very specific VM.

? We are talking about C++/CLI which is about working with CLI and not
anything else.

As I mentioned before: if I want to program C#, I use C# not something which
resembles C# with slight differences called C++/CLI. The advantage of
C++/CLI over C# comes into play when using things which are not available
in C# like deterministic destruction, templates, multiple inheritance, etc.
Plus, of course, the ability to use a well-known and familiar language. All
this will stay clear of managed code, however, and will thus not be
portable to other VMs.

Post by Ioannis Vranos
Will not this
ref class whatever
{ };
whatever ^h=gcnew whatever;
compile in every CLI compliant VM for which there will be a C++
compiler? So it will be portable to all CLI VMs.

I don't see any C++ in the above excerpt! Why would I want to use something
like this? Just to claim that I'm programming C++? What is the point? I see
a huge advantage in using C++ to write .Net programs due to the capabilities
unique to C++ and I understand that this will require some abominations.
However, if it isn't portable, it is useless to me and I rather stick to
using C#. The portable stuff in C++/CLI is not at all unique and is actually
available in C#.

Bronek Kozicki

2004-07-10 02:30:30 UTC

Post by Dietmar Kuehl
I don't see any C++ in the above excerpt! Why would I want to use
something like this? Just to claim that I'm programming C++? What is
the point? I see a huge advantage in using C++ to write .Net programs
due to the capabilities unique to C++ and I understand that this will
require some abominations. However, if it isn't portable, it is
useless to me and I rather stick to using C#. The portable stuff in
C++/CLI is not at all unique and is actually available in C#.

What makes you think that following:

ref class Whatever
{
public:
int Data() {return 0;}
};

std::vector<Whatever ^> handles;
handles.push_back(gcnew Whatever);

or:

// ref class Whatever defined as above

template <typename Type>
void f()
{
Type t;
std::cout << t.Data() << std::endl;
}

f<Whatever>();

won't be portable?

B.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:11:48 UTC

Post by Dietmar Kuehl
However, if it isn't portable, it is useless to me and I rather stick to
using C#. The portable stuff in C++/CLI is not at all unique and is actually
available in C#.

Actually, deterministic destruction, templates, and other C++ features are
available only in C++ and generate fully portable CLI assemblies.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-12 11:14:16 UTC

Post by Dietmar Kuehl
However, if it isn't portable, it is useless to me and I rather stick to
using C#. The portable stuff in C++/CLI is not at all unique and is
actually available in C#.

Actually, deterministic destruction, templates, and other C++ features are
available only in C++ and generate fully portable CLI assemblies.

This is different information than I got from someone from Microsoft when I
asked him whether I can run a standard C++ conforming program compiled with
MSVC++.net on Mono (and I explicitly made clear that I'm not referring to
the current Mono but actually to any conforming implementation of the
CLR/CLI/whatever). Of course, there is also a difference in the two
statements: my question also includes the standard C++ library while your
statement does not. On the other hand, I have my own standard C++ library
implementation and can, apparently, compile it to portable CLI assemblies
anyway (with the minor caveat that I probably can't use namespace std).

As I stated before: I'm quite happy to learn that assemblies written in
C++ are fully portable to all conforming implementations of the CLI.

Francis Glassborow

2004-07-12 21:29:38 UTC

Post by Dietmar Kuehl
This is different information than I got from someone from Microsoft when I
asked him whether I can run a standard C++ conforming program compiled with
MSVC++.net on Mono (and I explicitly made clear that I'm not referring to
the current Mono but actually to any conforming implementation of the
CLR/CLI/whatever). Of course, there is also a difference in the two
statements: my question also includes the standard C++ library while your
statement does not. On the other hand, I have my own standard C++ library
implementation and can, apparently, compile it to portable CLI assemblies
anyway (with the minor caveat that I probably can't use namespace std).

If you can compile your library implementation as a fully portable CLI
assembly, even if you cannot use namespace std (though surely C++/CLI
must support namespaces in some way) it is a good proof of principle and
should encourage MS to make CLI assemblies for the Standard C++
libraries available.

Dietmar Kuehl

2004-07-13 10:47:34 UTC

Post by Francis Glassborow
If you can compile your library implementation as a fully portable CLI
assembly, even if you cannot use namespace std (though surely C++/CLI
must support namespaces in some way) it is a good proof of principle and
should encourage MS to make CLI assemblies for the Standard C++
libraries available.

Well, it will be more than just compiling the library :-) I will need to
replace the few places where I rely on some platform specific stuff, e.g.
when it comes to I/O access. But I'm pretty sure that these can be
implemented in terms of CLR classes. ... and I won't have a C library
because I haven't implemented that one, yet. Actually, I always intended
to implement the C library in terms of the C++ library (this way is much
more reasonable than the usual other way around as the C++ library is
much more powerful). This makes it easier when porting to the CLI where
no C library is available (well, it is apparently there but would tie
assemblies to just one platform).

David Eng

2004-07-12 21:33:30 UTC

Post by Dietmar Kuehl
However, if it isn't portable, it is useless to me and I rather stick to
using C#. The portable stuff in C++/CLI is not at all unique and is actually
available in C#.

Actually, deterministic destruction, templates, and other C++ features are
available only in C++ and generate fully portable CLI assemblies.
Right, there are no plans at the moment to try to make either a C++ stdlib
or C stdlib that's compiled to IL.

That is, an ISO application is not protable under CLI

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Anthony Williams

2004-07-09 14:03:37 UTC

I would hope that if you compiled such code with one C++ compiler targetting
CLI, it would run on any CLI VM. However, even this is not guaranteed.

When I first heard about C++/CLI, I hoped that C++/CLI would treat "CLI" as
the platform, require that the C++ Standard libraries were compiled for CLI,
and define a C++ ABI for CLI, which would be implemented by all C++/CLI
compilers on all platforms, so I could compile some C++/CLI code with one
compiler on Windows, and other code with another compiler on 64-bit Solaris,
link them together on Linux and have the application work.

Consequently, I was very disheartened to hear that this is not the case. The
C++/CLI "binding" does not provide a binding for C++ onto CLI. Quite the
reverse, it provides a set of "extensions" to C++ which allow the use of CLI
facilities directly through language constructs. This is not limited to merely
those constructs which are outside the current scope of C++ (e.g. gcnew), but
also includes things that could be implemented as library code, such as
enhanced "for" loops to deal with CLI collections (that implement the
System::Collections.IEnumerable interface):

for each(int i in someCollection)
{
// do stuff with i
}

IIRC, it is not even guaranteed that simple things like "int" have the same
size across all C++/CLI compilers, specifically in order than the C++/CLI
compiler can target a specific VM on a specific platform, and *use the
existing platform-specific C++ standard library for that platform*.

Consequently, it is down to the individual compiler vendor to specify what
constraints are placed on the CLI code generated by their C++/CLI compiler ---
whether or not it is restricted to a specific VM/platform, and whether or not
you Can link against C++ code compiled for the CLI by other compilers.

Anthony

--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-10 01:01:16 UTC

Post by Anthony Williams
Consequently, it is down to the individual compiler vendor to specify what
constraints are placed on the CLI code generated by their C++/CLI compiler ---
whether or not it is restricted to a specific VM/platform, and whether or not
you Can link against C++ code compiled for the CLI by other compilers.

CLI has not a specific API. So a CLI compliant VM can have a different
GUI API than .NET for example.

CLI standard defines the internals of the VM and its assembly language.
Basically the main advantage of CLI is that it is multilingual, that is
due to the existence of a VM with an intermediate language (bytecode)
means that you can define things in C++ and use them in Pascal, inherit
a C++ managed class in Oberon and all these in the same program (you can
write a program with many languages) on a specific platform. And there
is also the GC help.

Also CLI types map directly to the types of the supported languages
where available, so System::Int32 maps as int in .NET. You can use both.

I think this is good, if we had the same stuff for all platforms this
means that there would be inefficiencies on the various platforms.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Eugene Gershnik

2004-07-10 19:32:52 UTC

Post by Ioannis Vranos
CLI standard defines the internals of the VM and its assembly
language. Basically the main advantage of CLI is that it is
multilingual, that is due to the existence of a VM with
an intermediate language (bytecode) means that you can
define things in C++ and use them in Pascal, inherit
a C++ managed class in Oberon and all these in the same program
(you can write a program with many languages) on a specific
platform. And there is also the GC help.

AFAIK there is no previously existing language that can work on CLI without
heavy modifications. (Java may be an exception but I am not even sure about
this). So yes one can inherit a C# class in mutilated VB and use it in
mutilated JScript or C++ and all of them look, feel and smell exactly the
same. IOW CLI isn't multilingual. It supports just one language/programming
paradigm but allows to express it using different syntaxes. C++ is pretty
close to this paradigm so the modifications required to make it work are
pretty minor. Languages farther away like VB or JScript are hardly
recognizable in their .NET form.

--
Eugene

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Anthony Williams

2004-07-10 02:08:57 UTC

Post by Anthony Williams
IIRC, it is not even guaranteed that simple things like "int" have the same
size across all C++/CLI compilers

Just to correct myself on that, the latest working draft does specify sizes
for the fundamental types, but notes that "This mapping is still under
discussion".

Anthony

--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:11:04 UTC

Post by Dietmar Kuehl
I don't see any benefit for me to move to C++/CLI rather than
staying with C# (if I target .Net) or C++ (if I target binary executables)
because to me it is important that the customer can choose the appropriate
platform to run my applications.

That's perfectly valid. Have you considered, though, that with C++/CLI you
can do both of those things, and both to their fullest degree, without
switching languages?

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 21:31:54 UTC

That's perfectly valid. Have you considered, though, that with C++/CLI you
can do both of those things, and both to their fullest degree, without
switching languages?

However, you have to learn two sets of APIs: one from CLI framework
and one from ISO C++ library. For generic programming, you get CLI
generic and ISO C++ templates. To me, it is very weird for a person
have to have two personalities. CLI is designed for C# a language
suitable for VM and GC. What's the rational to use C++ instead of C#
if you target CLI or .NET platform?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hyman Rosen

2004-07-13 10:44:55 UTC

Post by David Eng
What's the rational to use C++ instead of C#
if you target CLI or .NET platform?

Because you get to use all of your favorite C++ features that
made you choose that language in the first place. Template
metaprogramming is just one example.

In any case, since we have a vendor who is motivated to create
this hybrid of C# and C++, we will have an opportunity to evaluate
how successful it is. Given the expense which must be involved in
this undertaking, I can only believe that there is a strong perceived
need for it.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-13 10:48:15 UTC

Post by David Eng
What's the rational to use C++ instead of C#
if you target CLI or .NET platform?

Deterministic destruction and generic algorithms are two very powerful
features available in C++ but not in most of the alternatives. C# has
neither of those: the "using" approach is clutch and puts the burdon on
all users of a class rather than letting the implementer handle it. An
although all .Net language have "generics" these not at all about
generic programming...

Michel André

2004-07-06 21:45:27 UTC

Post by Dietmar Kuehl
What is the big advantage over "normal" executables? From statements of
people working on the C++/CLI at Microsoft I understand that code outside
the mechanisms to implement this stuff are not specified in the standard
for the .NET virtual machine. That is, if you are doing anything in your
C++ code which you could not have done with C#, too, it will not run e.g.
for Mono: no templates, no multiple inheritance (unless you are using
interfaces), no destruction at end of blocks, etc. (I would be delighted
to learn that MSVC++.Net compiled code using e.g. the features mentioned
above can run on any conforming virtual machine for .Net).

Actually as I understood it from a couple of TechEd sessions last week
by Herb Sutter amongst others we where told that compiling C++ to target
the .CLR actually compiled the C++ code to IL (intemediate language) and
not x86 and this included everything C++ has to offer. The one thing
you sacrifice is verifiability of the assembly compiled. This can
verfied by looking at the generated dll/exe when adding /CLR. So
actually i think the dll would be executable on another VM but there can
be issues with the hardware having to be similar since the C++ to IL
compiler basically uses the stack base machine and the ordinary stack to
implement the C++ part and not the object model and native datatypes of
the CLR. Do you have any references to the information you have received?

/Michel

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-07 07:53:08 UTC

This is my understanding, too. However, C++ making use of unmanaged features
will contain stuff whose behavior is not standardized by the CLI standard
and thus not portable beyond virtual machines which have an intrinsic
knowledge on how to interpret it.

Post by Michel AndrÃ©
The one thing
you sacrifice is verifiability of the assembly compiled.

Although this is a sacrifice from the viewpoint of managed code, it is not
a sacrifice when it comes down to standard C++ code: this is not
verifiable anyway.

Post by Michel AndrÃ©
So
actually i think the dll would be executable on another VM but there can
be issues with the hardware having to be similar since the C++ to IL
compiler basically uses the stack base machine and the ordinary stack to
implement the C++ part and not the object model and native datatypes of
the CLR.

Things like this, e.g. representation of C++ built-in types, pointers,
etc. were mentioned as the problematic issues. ... and lets face it: "there
can be issues with ..." is a synonym to "it does not work". Either the
details are specified in some standard or different implementations will
have different interpretations. Actually, even if there is a standard,
different implementations will still have different interpretations.

Post by Michel AndrÃ©
Do you have any references to the information you have received?

I managed to nail some persons at some point into a discussion and insisted
on getting answers. I don't know whether I managed to get statements out of
them which they are not supposed to make. That is: no, I won't disclose
where I got the information from. However, it is easy enough to Microsoft
people to either confirm what I have said or clarify that my statements are
wrong (the former would not require any verification, the latter should be
verifyable using a MSVC++.net compiled executable on Mono). ... and, BTW,
I would personally appreciate either statement made publically, too :-)

Ioannis Vranos

2004-07-07 17:55:45 UTC

Post by Dietmar Kuehl
I managed to nail some persons at some point into a discussion and insisted
on getting answers. I don't know whether I managed to get statements out of
them which they are not supposed to make. That is: no, I won't disclose
where I got the information from. However, it is easy enough to Microsoft
people to either confirm what I have said or clarify that my statements are
wrong (the former would not require any verification, the latter should be
verifyable using a MSVC++.net compiled executable on Mono). ... and, BTW,
I would personally appreciate either statement made publically, too :-)

Keep in mind that the (ISO C++ and C++/CLI) compliant code will have to
be recompiled for the platform to be used. For example there is not any
standardised API, so .NET API is system specific.

The CLI (multilingual VM) and its assembly language are standardised
only. C#/CLI is standardised, and C++/CLI is upcoming.

Check this (from ECMA site) regarding C#/CLI standard:

Intel sees the CLI and C# specifications as instrumental in fostering
innovation and giving developers more choices." said Colin Evans,
Director, System Software Lab, Intel Research and Development. "For
example, Intels Open CLI Library will continue to expand the scope and
performance of the standards-based CLI platform". (The Open CLI Library
is available at SourceForge http://sourceforge.net/projects/ocl)

Ximian CTO and Mono Project leader Miguel de Icaza commented, The CLI
and C# are the most advanced runtime and development technologies
available today. The ECMA/ISO standardization efforts enable separate
implementations of this platform to interoperate. The Mono project, for
example, is a multi-platform and open source implementation which builds
on these public standards to create a complete, open source .NET
implementation for Unix and Linux systems. (See http://www.go-mono.com/)"

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-08 12:11:43 UTC

Post by Ioannis Vranos
The CLI (multilingual VM) and its assembly language are standardised
only. C#/CLI is standardised, and C++/CLI is upcoming.

Note that C#/CLI is developed in close relation to the standard for the
underlying virtual machine, effectively resulting in a perfect match
between C# and the CLI. This will be different with C++/CLI which will
require features from the underlying platform, e.g.using P/Invoke.
I don't dispute the usefulness of C#/CLI! Actually, I'm using C# for
several of my projects. However, I don't see any reason to project this
to C++/CLI because this won't give me the platform neutrality I get from
C#/CLI. Of course, I can restrict myself to the managed portion of
C++/CLI but this does not yield any benefits from C# and would instead
require rules to toe the line.

Ioannis Vranos

2004-07-10 01:05:39 UTC

Post by Dietmar Kuehl
I don't dispute the usefulness of C#/CLI! Actually, I'm using C# for
several of my projects. However, I don't see any reason to project this
to C++/CLI because this won't give me the platform neutrality I get from
C#/CLI. Of course, I can restrict myself to the managed portion of
C++/CLI but this does not yield any benefits from C# and would instead
require rules to toe the line.

It looks like you are missing a crucial fact. CLI (and MS .NET) was not
created for C#, but to be a *multilingual* environment. That means that
whatever you can do with C# you will be able to do with other languages.
There are CLI bindings to many other languages like Fortran and Cobol.

Check these URLs:

http://msdn.microsoft.com/msdnmag/issues/02/03/stuff/default.aspx

http://msdn.microsoft.com/netframework/technologyinfo/overview/default.aspx
"Supported programming languages
APL Fortran Pascal
C++ Haskell Perl
C# Java Language Python
COBOL Microsoft JScript® RPG
Component Pascal Mercury Scheme
Curriculum Mondrian SmallTalk
Eiffel Oberon Standard ML
Forth Oz Microsoft Visual Basic®"

And the new language MS is up to, F#!

http://research.microsoft.com/projects/ilx/fsharp.aspx

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-10 11:00:15 UTC

Post by Ioannis Vranos
It looks like you are missing a crucial fact. CLI (and MS .NET) was not
created for C#, but to be a *multilingual* environment.

If you consider using different words for the same things to be
"multilingual" you are right. This is what I'm referring to as C#:
C# essentially exactly exposes the layout and capability of .Net's
object model. You can replace C# by VB.Net and do exactly the same
as in C# except that you are using a notion which resembles more
VB. I'm in no way in the position to judge the language bindings you
have listed other than C# and VB.Net because I haven't looked at
them but I'm pretty sure that they are essentially C# using the look
and feel of the respective languages. Depending on their original
object model, this may fit more or less. For example, I would expect
that Eiffel and Java (the language, apparently the class system is
ignored) can be mapped without much changes while Smalltalk and
Python programmers may be more comfortable with the respective .Net
version than with C# but would not really consider the .Net version
to be an implementation of their respective language - unless the
.Net versions of these language also rely on non-standardized features
of the underlying VM in which case they become as useless as C++/CLI.

Returning from guessing and focussing on C++/CLI again: I don't care about
the "managed" portion of C++/CLI because I can already use a semantically
equally powerful language, C#, to express this stuff. The advantage of
C# is that it does not use abominations forced into a language with an
inherently different object model than C#: the C++ object model does not
really fit the .Net object model at all. There are portions which are
similar but even these don't really fit. As a consequence, C++/CLI
mutates C++ even at the very core, namely when it comes to pointers and
references. It also retains the original C++ stuff but essentially using
any of those will render the resulting assemblies non-portable. As a
consequence, C++/CLI is a complete non-option to people concerned about
the portability of their applications. ... and to make things plain: it
is not really my choice to desire portability! It is a necessity because
my customers use a variety of platforms and it is typically not really an
option for them to change - or, put differently, if I would not support
their platform, they would choose a different provider who supports their
platform.

Post by Ioannis Vranos
That means that
whatever you can do with C# you will be able to do with other languages.

Yes but it will do me no good anyway: first of all, none of the language
bindings I looked at leaves the original language unchanged. That is, I
have to learn a new language anyway. Although it may resemble what I'm
already used to, it has the inherent danger of luring me into believing
that I know what is going on when I actually don't. Thus, I'm better off
learning a new language and its associated semantics anyway. ... and this
does not only apply to me but to everybody. I know that many people are
really learn resistant but just pretending that this is OK is not a
solution as it will introduce subtle problems. That is, the solution is
not to make these people comfortable but to get rid of them (yes, I am an
asshole if comes to people who refuse to move on and learn something new).

That said, I can see that offering people something they feel more
comfortable with is appealing to many. Personally, I have different reasons
to be appealed by the .Net environment, namely that it provides a
standardized platform (this does not apply e.g. to the Java VM as I don't
consider the definitions imposed by one company to be a standard) with quite
a few desirable features. However, I consider the abilities of this platform
exposed in their typical languages (i.e. C#, possibly in the instance of
being labeled to be actually a different language) to be inferior to what
I'm used to. Sure enough, I can [at least conceptually] realize everything
on this platform which I can realize in C++ but I prefer to do it the C++
way. My complaint about C++/CLI (excluding the process how it is created) is
essentially, that it does not let me program for .Net in the C++ way -
portably.

... and there is no point in pointing me to a gazillion of languages
available for .Net or to pretend that there is a standard for C++/CLI. I
think I have a pretty firm grasp on what this stuff is all about and I'm
already using it. Essentially I'm just pointing out that the world is not
as nice as the advertisement is saying it is. That is, you are ****** if
you use C++/CLI beyond the managed parts although this is where the power
of C++/CLI lies and the remainder of C++/CLI has no real relation to C++
at all, despite its name. Whether C++/CLI is a service or disservice to
the C++ community will depend strongly on whether assemblies using stuff
outside the usual managed stuff will become portable or not.

Ioannis Vranos

2004-07-10 20:09:55 UTC

Post by Dietmar Kuehl
If you consider using different words for the same things to be
C# essentially exactly exposes the layout and capability of .Net's
object model. You can replace C# by VB.Net and do exactly the same
as in C# except that you are using a notion which resembles more
VB. I'm in no way in the position to judge the language bindings you
have listed other than C# and VB.Net because I haven't looked at
them but I'm pretty sure that they are essentially C# using the look
and feel of the respective languages. Depending on their original
object model, this may fit more or less. For example, I would expect
that Eiffel and Java (the language, apparently the class system is
ignored) can be mapped without much changes while Smalltalk and
Python programmers may be more comfortable with the respective .Net
version than with C# but would not really consider the .Net version
to be an implementation of their respective language - unless the
..Net versions of these language also rely on non-standardized features
of the underlying VM in which case they become as useless as C++/CLI.

I think there is much confusion. Today in .NET with C++ we work in this way:

__gc class whatever
{
// ...
};

// Equivalent to whatever *p=__gc new whatever;
whatever *p=new whatever;

// Managed type in non GC heap
whatever *p=__nogc new whatever;

class whatever
{
// ...
};

// Here not garbage collected
whatever *p=new whatever;

With the new syntax:

ref class whatever
{
// ...
};

whatever ^p=gcnew whatever;

// I *guess* this will be managed type in non GC heap
whatever *p=new whatever;

Also it is possible:

// GC object (working as if it is) in the stack.
// It is destroyed at the end of its scope
// (deterministic finalisation)
whatever x;

C++/CLI *is* more natural.

With C++ it is possible to do more things than with C#, since you can
work in the managed and unmanaged worlds combined.

Post by Dietmar Kuehl
Returning from guessing and focussing on C++/CLI again: I don't care about
the "managed" portion of C++/CLI because I can already use a semantically
equally powerful language, C#, to express this stuff. The advantage of
C# is that it does not use abominations forced into a language with an
inherently different object model than C#: the C++ object model does not
really fit the .Net object model at all. There are portions which are
similar but even these don't really fit. As a consequence, C++/CLI
mutates C++ even at the very core, namely when it comes to pointers and
references. It also retains the original C++ stuff but essentially using
any of those will render the resulting assemblies non-portable. As a
consequence, C++/CLI is a complete non-option to people concerned about
the portability of their applications. ... and to make things plain: it
is not really my choice to desire portability! It is a necessity because
my customers use a variety of platforms and it is typically not really an
option for them to change - or, put differently, if I would not support
their platform, they would choose a different provider who supports their
platform.

How portable do you think you are when using .NET API? The API is not
standardised, only some minor library parts.

What is portable in CIL VMs are the language constructs, the C++/CLI
(and C#/CLI).

Also .NET will replace the Windows application environment, so it could
not be restricted to one language only.

Post by Dietmar Kuehl
Yes but it will do me no good anyway: first of all, none of the language
bindings I looked at leaves the original language unchanged. That is, I
have to learn a new language anyway. Although it may resemble what I'm
already used to, it has the inherent danger of luring me into believing
that I know what is going on when I actually don't. Thus, I'm better off
learning a new language and its associated semantics anyway. ... and this
does not only apply to me but to everybody. I know that many people are
really learn resistant but just pretending that this is OK is not a
solution as it will introduce subtle problems. That is, the solution is
not to make these people comfortable but to get rid of them (yes, I am an
asshole if comes to people who refuse to move on and learn something new).

C++/CLI does not replace ISO C++, it is a set of extensions to ISO C++.

One can also use ISO C++ for .NET applications (I do!). I am programming
in mixed mode, which is the most efficient and portable - portability
regarding C++ code recompiling only. I do not care for portability of
the compiled .exe to another platform as it is, since the API is not
portable anyway.

I will consider C++/CLI restricted use, only when I will want to make my
interfaces accessible in other .NET languages, while the definitions
themselves have not be in pure "C++/CLI". This is the kind of
flexibility only C++ has.

For example you can make a std::string to String * conversion easily.
C++ is better than C#!

Post by Dietmar Kuehl
That said, I can see that offering people something they feel more
comfortable with is appealing to many. Personally, I have different reasons
to be appealed by the .Net environment, namely that it provides a
standardized platform (this does not apply e.g. to the Java VM as I don't
consider the definitions imposed by one company to be a standard) with quite
a few desirable features. However, I consider the abilities of this platform
exposed in their typical languages (i.e. C#, possibly in the instance of
being labeled to be actually a different language) to be inferior to what
I'm used to. Sure enough, I can [at least conceptually] realize everything
on this platform which I can realize in C++ but I prefer to do it the C++
way. My complaint about C++/CLI (excluding the process how it is created) is
essentially, that it does not let me program for .Net in the C++ way -
portably.

You must define what you mean by "portability".

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Bronek Kozicki

2004-07-11 10:23:57 UTC

Post by Dietmar Kuehl
It also retains the original C++ stuff but
essentially using any of those will render the resulting assemblies
non-portable.

If you refrain from using pointers and standard C++ library and compile
with /clr:safe, your _assemblies_ will be portable accross all CLI
compliant platforms, at the same time allowing you to use templates,
deterministic destruction and other C++ features (not available in C#,
like RAII and multiple inheritance from non-interfaces). This is more
that current C++ standard may give you (binary compatibility between
different platforms), at the cost that you may not use anything that
depends on external non-CLI runtime (like complete standard C++ library,
but who says that it cannot be compiled to CLI?) and some features may
only be used internally, like C++ templates (with their full power) and
multiple inherintance (from non-interfaces).

If you use standard C++ library, pointers or other "unsafe" (from CLI
pov) C++ stuff and compile with /clr:pure, your assambly might not be
portable, but source code still may be. And I believe that source code
portability is all you have right now in C++. If you need more, see
above.

Post by Dietmar Kuehl
As a consequence, C++/CLI is a complete non-option to people concerned

about
I guess that its also your opinion about ISO C++? It also does not
provide binary portability. If you want binary portability, while still
retanining full power of C++, please think about differences of pointer
sizes on different platforms (64bit anyone?). C++/CLI will give you
_most_ power of C++ with binary portability (in fact there will be part
of standard C++ library ported to CLI), and all power of C++ if you just
want what's provided by C++ today: source code portability, and you want
it in CLI. That's what good standard (and producers of conforming
compilers) can give you.

B.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-11 23:44:04 UTC

Post by Bronek Kozicki

Post by Dietmar Kuehl
It also retains the original C++ stuff but
essentially using any of those will render the resulting assemblies
non-portable.

If you refrain from using pointers and standard C++ library

Under those constraints why would I want to use C++? There is just about
nothing above kindergarten programming that I could do efficiently if I
must avoid pointers and libraries that use pointers, and in particular
the Standard Library. How, for example, do I output anything?

Now what would be useful would be a C Runtime provided via IL. Indeed
the more issues of portability between .NET and mono (+ any latter
comers) the more attractive C++/CLI becomes. IMO the main focus from the
major vendor should be to work hard to minimise non-portable elements. A
serious commitment to that would go some way to defuse claims that all
they want to do is further corner software development.

Actually a source that I will not name (and if I did the name would be
unfamiliar to most people here, so no jumping to wrong conclusions)
recently told me that in his opinion MS (his employer) needs a strong
Linux community to keep in honest and keep it progressing.

Without strong competitors many MS employees would have to look for
alternative employment. Eliminating the opposition is always bad news
for the ordinary employee.

Francis Glassborow

2004-07-10 19:35:08 UTC

Post by Ioannis Vranos
It looks like you are missing a crucial fact. CLI (and MS .NET) was not
created for C#, but to be a *multilingual* environment. That means that
whatever you can do with C# you will be able to do with other languages.
There are CLI bindings to many other languages like Fortran and Cobol.

Actually that is a slight overstatement as there is a distinction
between client languages that can use CLI based components and authoring
languages that have sufficient 'power' to create those components.
Standard C++, IIUC, compiles perfectly well as a client language but
what MS is seeking is to make C++/CLI a first class authoring language
with full access to all the features of CLI (something which I believe
isn't even yet available in C#)

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:06:48 UTC

Post by Ioannis Vranos
The CLI (multilingual VM) and its assembly language are standardised
only. C#/CLI is standardised, and C++/CLI is upcoming.

Why not? IL is IL regardless of the source language used to generate it.
(The only difference would be if you chose a source language that didn't
support all CLI features, but both C# and C++ do support essentially all
CLI features -- in Whidbey (VS 2005), C++ actually supports slightly more
of them than C#.)

Post by Dietmar Kuehl
Of course, I can restrict myself to the managed portion of
C++/CLI but this does not yield any benefits from C# and would instead
require rules to toe the line.

Actually, there are some significant benefits to writing the same .NET
code in C++ instead of C#.

Perhaps the biggest is deterministic cleanup. The destructor is Dipose, so
C++ programmers don't need such fragile and error-prone workarounds as the
Dispose pattern (a la Java) or the using pattern (a la C#); we have
automatic storage duration, and everything that entails including RAII.
This is a significant correctness benefit (correctness by default), and
also a significant performance benefit.

Another is that the equivalent code compiled with (V)C++ instead of C# is
typically 25% faster in C++. This is because VC++ often can generate
better IL; it runs everything through the full optimizing back-end before
it spits out IL. The C# compiler does nearly no optimization (IIRC it does
only constant folding) before it spits out IL.

Later on, regardless of the language, the JIT compiler eventually compiles
the IL down to the native instruction set and does some optimization at
that time, but the JIT has limited optimization ability because it has to
be fast. The main difference is that the C# compiler relies on the JIT for
nearly all optimization, whereas for C++-generated assemblies it's just
icing on the cake.

I think you will be happily surprised if you try C++ in some of your CLI
projects, in the Whidbey release that just went into beta (VC++ 2005).

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 21:57:39 UTC

Post by Herb Sutter
Perhaps the biggest is deterministic cleanup. The destructor is Dipose, so
C++ programmers don't need such fragile and error-prone workarounds as the
Dispose pattern (a la Java) or the using pattern (a la C#); we have
automatic storage duration, and everything that entails including RAII.
This is a significant correctness benefit (correctness by default), and
also a significant performance benefit.

Every language designer has his own philosophy. Language Java or C#
is designed for VM and GC, and is more concern with pointer and
automatic cleanup instead of deterministic cleanup. If you call this
is fragile and error-prone, you miss the big point. To me, there is
no any benefit for C++ to target CLI which is designed for C#. If I
want to target CLI, what is the reason I have to care about
deterministic cleanup? What is the rational to learn all these ISO
C++ and APIs (standard library) just for deterministic cleanup under
CLI environment?

Post by Herb Sutter
Another is that the equivalent code compiled with (V)C++ instead of C# is
typically 25% faster in C++. This is because VC++ often can generate
better IL; it runs everything through the full optimizing back-end before
it spits out IL. The C# compiler does nearly no optimization (IIRC it does
only constant folding) before it spits out IL.

I don't think this is valid argument. It is a compiler issue. When
C# become mature, it can generate equivalent IL code to C++

Post by Herb Sutter
Later on, regardless of the language, the JIT compiler eventually compiles
the IL down to the native instruction set and does some optimization at
that time, but the JIT has limited optimization ability because it has to
be fast. The main difference is that the C# compiler relies on the JIT for
nearly all optimization, whereas for C++-generated assemblies it's just
icing on the cake.

This is not true. Based on Java vs C++ discussion, dynamic compiler
can generate better optimization code than static compiler. C# can
use optimization to generate IL code. To me, C# eliminate pointers so
that it can generate better optimized IL code than C++

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl

2004-07-13 10:49:33 UTC

Post by David Eng
Every language designer has his own philosophy. Language Java or C#
is designed for VM and GC, and is more concern with pointer and
automatic cleanup instead of deterministic cleanup. If you call this
is fragile and error-prone, you miss the big point.

Actually, Herb is not missing the point at all! The point indeed *is* that
no support for deterministic destruction is resulting in fragile code. Not
when it comes to the relatively cheap resource of memory: this is handle
solidly by garbage collection. However, garbage collection fails to handle
the expensive resources which need to be reclaimed as soon as possible,
like database connections, or which shall be held only for an absolute
minimum of time like all forms of locks. There are approaches for this
stuff in C# but this requires that the user of a class religiously uses
e.g. the "using" statements. Using deterministic destruction, these
resources are handled automatically when the corresponding object goes out
of scope. This is dramatically less error prone! Actually, I wonder why
other language designers don't realize that C++'s destructors are an
important device for things like this, not a mere clutch to address
memory management.

Post by David Eng
To me, there is
no any benefit for C++ to target CLI which is designed for C#. If I
want to target CLI, what is the reason I have to care about
deterministic cleanup?

Code correctness...?

Post by David Eng
What is the rational to learn all these ISO
C++ and APIs (standard library) just for deterministic cleanup under
CLI environment?

Generic programming is another big thing about C++ which is not available
in any other language I'm aware of.

Herb Sutter

2004-07-10 11:02:26 UTC

It's even simpler than that: Any parts of a project or library that are
compiled to IL are automatically portable across CLI implementations
(modulo the usual guidelines all languages follow), and any parts that are
compiled to a particular processor's native instruction set follow the
same rules as today (they'll only run on a compatible processor).

It's a matter of having both worlds fully available with each world's
usual rules, and being able to choose either one at any point.

Post by Dietmar Kuehl
using a MSVC++.net compiled executable on Mono

Mono has for at least a year now been shown runing several Microsoft demos
out of the box, i.e., straight from the binary assemblies. It doesn't make
a difference which language was used to author the assemblies.

Of course, if you use C++ to generate an assembly that contains non-CLI
stuff (e.g., x86 instructions), that won't be portable. I think that's
probably what you were referring to.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 21:56:26 UTC

It's even simpler than that: Any parts of a project or library that are
compiled to IL are automatically portable across CLI implementations
(modulo the usual guidelines all languages follow), and any parts that are
compiled to a particular processor's native instruction set follow the
same rules as today (they'll only run on a compatible processor).
It's a matter of having both worlds fully available with each world's
usual rules, and being able to choose either one at any point.

Post by Dietmar Kuehl
using a MSVC++.net compiled executable on Mono

then, why is it not in CLI standard to compile C++ stdlib or C stdlib to IL?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

llewelly

2004-07-12 22:07:59 UTC

It's even simpler than that: Any parts of a project or library that are
compiled to IL are automatically portable across CLI implementations
(modulo the usual guidelines all languages follow), and any parts that are
compiled to a particular processor's native instruction set follow the
same rules as today (they'll only run on a compatible processor).
It's a matter of having both worlds fully available with each world's
usual rules, and being able to choose either one at any point.

Post by Dietmar Kuehl
using a MSVC++.net compiled executable on Mono

How do you know if the assembly contains non-CLI stuff? Is non-CLI
stuff generated by using pointers and or standard C++ library
features? This is what Bronek implied in his post (xrl.us/cdum) .

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Michel André

2004-07-07 17:21:37 UTC

Post by Michel AndrÃ©
Actually as I understood it from a couple of TechEd sessions last week
by Herb Sutter amongst others we where told that compiling C++ to target
the .CLR actually compiled the C++ code to IL (intemediate language) and
not x86 and this included everything C++ has to offer. The one thing
you sacrifice is verifiability of the assembly compiled. This can
verfied by looking at the generated dll/exe when adding /CLR. So
actually i think the dll would be executable on another VM but there can
be issues with the hardware having to be similar since the C++ to IL
compiler basically uses the stack base machine and the ordinary stack to
implement the C++ part and not the object model and native datatypes of
the CLR. Do you have any references to the information you have received?

Thinking more closely about i guess the compiled IL code will use
PInvoke to invoke some or all of the C runtime library functions which
most likely makes the IL/assembly platform dependent or dependent on the
C runtime being available in some form.

So taking that to account I guess C++/CLI assemblies from VS2005 wont be
pure IL if it's not possible to link to a C runtime thats compiled in
IL which it probably isn't based on the information Dietmar had. But the
code generated from your source code is in IL although not verifiable.

Maybe someone could shed a light on this?

Rgds
/Michel

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:03:02 UTC

Post by Michel AndrÃ©
Thinking more closely about i guess the compiled IL code will use
PInvoke to invoke some or all of the C runtime library functions which
most likely makes the IL/assembly platform dependent or dependent on the
C runtime being available in some form.
So taking that to account I guess C++/CLI assemblies from VS2005 wont be
pure IL if it's not possible to link to a C runtime thats compiled in
IL which it probably isn't based on the information Dietmar had. But the
code generated from your source code is in IL although not verifiable.
Maybe someone could shed a light on this?

Yes, any parts that directly call C runtime library functions (or that are
themselves explicitly compiled to, say, x86 instructions instead of to IL)
wouldn't be portable in binary form. Such code is as source-portable as it
is today, meaning you can recompile/relink against a different target C
runtime library.

One way to minimize this is to partition the parts that make C runtime
library calls into their own assembly (DLL), so that when you ship your
product you can provide a system-specific binary version of that assembly
and for the rest still ship just the same binaries to run on any CLI
implementation.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Michel André

2004-07-11 10:12:28 UTC

Post by Michel AndrÃ©
Maybe someone could shed a light on this?

Thanks for the reply, it was as I suspected.

Will it be possible to see which parts of the standard library that
Dinkumware is implementing for C++/CLI will call the C runtime/Win32
apis directly or will do trial and error watching the linker output? I
guess some parts like iostreams is hard do make work without C
runtime/Win32, but large parts like containers, algorithms would be
rather portable?

And I guess it would be possible to make a C runtime compiled into IL
and linked to your assembly and make it fully portable. But thats not in
the plans for now as I understand it.

Regards
/Michel

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-11 23:48:15 UTC

Post by Michel AndrÃ©
And I guess it would be possible to make a C runtime compiled into IL
and linked to your assembly and make it fully portable. But thats not in
the plans for now as I understand it.

But definitely should be.

Herb Sutter

2004-07-12 00:11:38 UTC

Post by Michel AndrÃ©

Post by Herb Sutter
Yes, any parts that directly call C runtime library functions (or that are
themselves explicitly compiled to, say, x86 instructions instead of to IL)
wouldn't be portable in binary form. Such code is as source-portable as it
is today, meaning you can recompile/relink against a different target C
runtime library.
One way to minimize this is to partition the parts that make C runtime
library calls into their own assembly (DLL), so that when you ship your
product you can provide a system-specific binary version of that assembly
and for the rest still ship just the same binaries to run on any CLI
implementation.

Note that what I wrote above also applies to the use of the C++ standard
library types and functions, as usually people want to bind to their local
compiler- and/or platform-specific C++ std lib.

We are, however, doing something called STL.NET which is designed to show
how STL containers and idioms work when extended with generics (e.g.,
cli::vector is a template that implements the generic IList<T> and
ICollection<T>, so you can instantiate a cli::vector<int> and be able to
pass it to C# or VB code and they can use it sensibly). The basic idea is
that generics are find for containers and iterators, but not algorithms;
STL.NET uses templates that implement generic interfaces to do the
containers and iterators part (they're pretty much identical to their
standard std:: versions with generics extensions such as that they also
implement generic interfaces), and the algorithms are templates only.

Right, there are no plans at the moment to try to make either a C++ stdlib
or C stdlib that's compiled to IL. There is, however, the STL.NET stuff I
mentioned above.

Herb

---
Herb Sutter (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Anthony Williams

2004-07-12 11:26:13 UTC

Note that what I wrote above also applies to the use of the C++ standard
library types and functions, as usually people want to bind to their local
compiler- and/or platform-specific C++ std lib.

How have you got enough experience with C++/CLI to decide what people "usually
want"?

If I was writing a CLI-based app in C++, I would expect to be able to use the
full C++ Standard Library, and have it run on *any* CLI implementation.

Post by Herb Sutter
Right, there are no plans at the moment to try to make either a C++ stdlib
or C stdlib that's compiled to IL.

Ouch.

Anthony

--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

llewelly

2004-07-12 22:10:29 UTC

Herb Sutter <***@gotw.ca> writes:
[snip]

Post by Herb Sutter
Right, there are no plans at the moment to try to make either a C++ stdlib
or C stdlib that's compiled to IL. There is, however, the STL.NET stuff I
mentioned above.

[snip]

So C++/CLI offers two choices:

(a) Use the standard C++ library, but abandon CLI's promise of binary
portablity.

(b) Do not use standard C++ library, and get binary portablity.

Is that more or less correct? What about the non-use of pointers
which Bronek mentioned?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 21:55:24 UTC

Again, why is it not in CLI standard to compile C++ stdlib and C
stdlib to IL? Do you have plan to do so or that will never happen?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:10:33 UTC

Post by Ioannis Vranos
However it will be nice to have C++ work natively in VM environments in
a standardised way.

What is the big advantage over "normal" executables? From statements of
people working on the C++/CLI at Microsoft I understand that code outside
the mechanisms to implement this stuff are not specified in the standard
for the .NET virtual machine. That is, if you are doing anything in your
C++ code which you could not have done with C#, too, it will not run e.g.
for Mono: no templates, no multiple inheritance (unless you are using
interfaces), no destruction at end of blocks, etc. (I would be delighted
to learn that MSVC++.Net compiled code using e.g. the features mentioned
above can run on any conforming virtual machine for .Net).

To take just one of your examples, actually with C++/CLI you do get
automatic destruction at end of blocks -- portably (in an assembly that
will run on any CLI implementation) and for any type (including CLI types
that were authored in languages without destructors that use the Dispose
pattern instead).

To take another, templates of (or instantiated with) CLI types work just
fine; they disappear before the IL is emitted, and the resulting
assemblies are fully portable.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Max Polk

2004-07-03 20:44:17 UTC

The .NET version of C++, to become compatible with the common language
runtime, modified the language and place restrictions on it in many ways.

Since ISO/IEC 14882:1998(E) defines the C++ programming language, using the
characters "C++" in a product named Visual C++ .NET is not correct. Changing
the Java Programming Language this way and still calling it "Java" was
ultimately not tolerated legally, but I'm thinking there is no legal power to
forbid abuse of the characters "C++", so I'll use "C++ .NET" to describe the
divergent language reminicent of C++.

One big thing about C++ .NET is that you place "__gc" in front of classes to
make them automatically garbage collected. You then create them only with
new, then never delete them, which also means no automatic variable
instantiation of these garbage collected classes. This is just the beginning.

Other syntax changes, restrictions, and new keywords give me the impression
that it may be wiser to use C# over C++ .NET since C# was written with .NET in
mind from the beginning and it's a cleaner way to program .NET.

All the .NET languages compile into an intermediate language, so you can use
Visual Basic .NET, Visual C++ .NET, and Visual C# .NET to produce compatible,
interoperable code. The side effect is that it makes sense for these all to
share the same library.

Note that since these three languages compile into this intermediate language,
it seems possible to reverse IL back into source code from another .NET
language, such as Visual Basic .NET IL back to Visual C++ .NET source code.

The Mono project complies to a standards-based C# to compile on Linux, so .NET
is not necessarily tied to running on closed, proprietary operating systems.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-04 10:56:33 UTC

Post by Max Polk

The .NET version of C++, to become compatible with the common language
runtime, modified the language and place restrictions on it in many ways.

Since it will be a standard, it should be better to not call it ".NET
C++". Also Mono framework exists for example.

Post by Max Polk
Since ISO/IEC 14882:1998(E) defines the C++ programming language, using the
characters "C++" in a product named Visual C++ .NET is not correct. Changing
the Java Programming Language this way and still calling it "Java" was
ultimately not tolerated legally, but I'm thinking there is no legal power to
forbid abuse of the characters "C++", so I'll use "C++ .NET" to describe the
divergent language reminicent of C++.
One big thing about C++ .NET is that you place "__gc" in front of classes to
make them automatically garbage collected. You then create them only with
new, then never delete them, which also means no automatic variable
instantiation of these garbage collected classes. This is just the beginning.
Other syntax changes, restrictions, and new keywords give me the impression
that it may be wiser to use C# over C++ .NET since C# was written with .NET in
mind from the beginning and it's a cleaner way to program .NET.
All the .NET languages compile into an intermediate language, so you can use
Visual Basic .NET, Visual C++ .NET, and Visual C# .NET to produce compatible,
interoperable code. The side effect is that it makes sense for these all to
share the same library.
Note that since these three languages compile into this intermediate language,
it seems possible to reverse IL back into source code from another .NET
language, such as Visual Basic .NET IL back to Visual C++ .NET source code.
The Mono project complies to a standards-based C# to compile on Linux, so .NET
is not necessarily tied to running on closed, proprietary operating systems.

I do not think C++/CLI standard as ".NET C++" only.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Carl Daniel

2004-07-05 09:56:56 UTC

Post by Max Polk
Since ISO/IEC 14882:1998(E) defines the C++ programming language,
using the characters "C++" in a product named Visual C++ .NET is not
correct.

Rubbish.

Post by Max Polk
One big thing about C++ .NET is that you place "__gc" in front of
classes to make them automatically garbage collected. You then
create them only with new, then never delete them, which also means
no automatic variable instantiation of these garbage collected
classes. This is just the beginning.

You're not talking about C++/CLI here. You're talking about "Managed
Extenstions for C++", the solution that was created for VC 7{.1}.

C++/CLI is a very different thing, which does add significantly to C++
grammar, but in a way that's much more comfortable to a C++ programmer than
the managed extensions did. With only a couple of very small exceptions,
every valid ISO C++ program is also a valid C++/CLI program. It's possible
that by the time the ECMA committee gets finished with C++/CLI that those
remaining cases will have been addressed making C++/CLI 100% compatible with
ISO C++ (the incompatibility is related to new keywords and there are
several possible strategies for eliminating those incompatibilities
altogether). See
http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx for a discussion
of this by Herb Sutter.

Post by Max Polk
Other syntax changes, restrictions, and new keywords give me the
impression that it may be wiser to use C# over C++ .NET since C# was
written with .NET in mind from the beginning and it's a cleaner way
to program .NET.

As one who'se written a great deal of C# and a great deal of C++, I will
absolutely switch as much of my CLI development to C++/CLI as possible once
it's available. C# may be a fine language for CLI development, but it's not
the best language for large-scale development, especially for someone that
grew-up on C++.

Post by Max Polk
Note that since these three languages compile into this intermediate
language, it seems possible to reverse IL back into source code from
another .NET language, such as Visual Basic .NET IL back to Visual
C++ .NET source code.

One key difference is that (at least with VC8) the C++ compiler does a great
deal of optimization work on the generated MSIL while C# and VB do only
straightfoward generation of IL. In practice this means that C++/CLI code
is likely to be slightly faster and more difficult to reverse engineer.

-cd

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Paul Mensonides

2004-07-05 22:38:55 UTC

Post by Carl Daniel
the managed extensions did. With only a couple of very small exceptions,
every valid ISO C++ program is also a valid C++/CLI program.

But not vice versa. (Granted, compiling a program that expects garbage
collection without it is not generally a good idea.)

The main problem, IMO, is that the CLI adds a set of extensions to the language
that may not _currently_ interfere with existing C++ syntax (which they do
anyway because of macro expansion--which isn't too terrible), but could
interfere in the future--unless C++ attempts to align itself with a similar
thing in the CLI or avoids any syntax that is similar to a CLI-specific syntax.
Therein lies a backdoor into the future of C++ that I and others dislike.

Post by Carl Daniel
It's possible
that by the time the ECMA committee gets finished with C++/CLI that those
remaining cases will have been addressed making C++/CLI 100% compatible with
ISO C++ (the incompatibility is related to new keywords and there are
several possible strategies for eliminating those incompatibilities
altogether). See
http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx for a discussion
of this by Herb Sutter.

Note that the language already has a facility for passing extra linguistic
instructions to the compiler--pragmas. If C++ follows C's route, then it will
get the _Pragma operator, which, in turn, can be the result of macro expansion,
which can, in turn, allows "keywords" to be introduced by
headers/undefined/defined as something else, etc..

#define gcnew _Pragma("__CLI__ gcnew")

Regards,
Paul Mensonides

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andre Kaufmann

2004-07-05 10:04:06 UTC

Post by Max Polk
One big thing about C++ .NET is that you place "__gc" in front of classes to
make them automatically garbage collected. You then create them only with
new, then never delete them, which also means no automatic variable
instantiation of these garbage collected classes. This is just the beginning.

But thatŽs not true for C++/CLI. You use a new keyword spelled "gcnew" to
create garbage collected objects. Also you may create such objects also
like stack allocated objects.
I would say C++/CLI has much differences (for the good) compared to
managed C++.

Also what i very like about that standard is that you are able
to specify the binary size of an enum - which i donŽt know
why it hasnŽt been in the first ISO C++ standard.

Andre

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-06 11:27:12 UTC

You must be confused. C++/CLI is polluting C++ by Microsoft helped
with some C++ standard committee members. It is not about possibility
to merge. It should be a possibility for C++ community to file a
lawsuit against Microsoft. Microsoft has no rights to change the C++
language in order to fit .NET. She did exactly same thing to Java
before but lost the lawsuit to SUN. It is time to wake up for C++
community and say no to Microsoft's effect to pollute C++.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-06 13:09:05 UTC

Post by David Eng
You must be confused. C++/CLI is polluting C++ by Microsoft helped
with some C++ standard committee members.

You mean people like Bjarne Stroustrup? Surely you misunderstand their
motives for participating. I have all kinds of reservations about the
use of ECMA to fast-track material into an ISO Standard. I have serious
reservations about ISO allowing ECMA to retain exclusive responsibility
for maintaining and developing new versions of fast-tracked ISO
Standards. However none of those justify the kind of imputations you are
making about those WG21 members who are either part of ECMA's TC39/TG5
or who are acting as liaison between that group and WG21.

Unlike the Java case, MS are seeking help from an acknowledged Standards
body. They are responding to technical arguments and listening to
reasons why specific proposed extensions should either not be included
or be done differently.

On a negative side you could characterise much of WG21's involvement as
damage limitation. OTOH it is a practical reality that if C++/CLI were
to influence the next release of the CLI Standard it had to be done in a
more timely fashion than could be achieved through ISO. Note that had
ISO not apparently conceded all maintenance of CLI to ECMA we would not
be in this position.

Post by David Eng
It is not about possibility
to merge.

Unless you are actively participating in the process I cannot imagine
how you could be in a position to make such an assertion.

Post by David Eng
It should be a possibility for C++ community to file a
lawsuit against Microsoft.

And every other major implementor of C++? Every single one of them ships
a product with extensions.

Post by David Eng
Microsoft has no rights to change the C++
language in order to fit .NET.

They aren't, they are attempting to standardise a number of extensions
to extend the way that C++ can work within the .NET environment. WG21
are trying to ensure that those same extensions do not pre-empt future
development decisions for C++.

Post by David Eng
She did exactly same thing to Java
before but lost the lawsuit to SUN.

Not really. In that case MS was possibly guilty of breaching the
licensing agreements it had with the holder of the IPR.

Post by David Eng
It is time to wake up for C++
community and say no to Microsoft's effect to pollute C++.

Difficult when a very substantial part of the C++ community wants to
work on MS platforms. Indeed I could argue strongly that ignoring .NET
would lead to the ultimate death of C++. If you would prefer to see C#
become the dominant language on the desktop I think ignoring .NET would
be a good way to go.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-07 07:55:49 UTC

Post by Francis Glassborow
Difficult when a very substantial part of the C++ community wants to
work on MS platforms. Indeed I could argue strongly that ignoring .NET
would lead to the ultimate death of C++. If you would prefer to see C#
become the dominant language on the desktop I think ignoring .NET would
be a good way to go.

I see the opposite. Tying C++ to .NET would lead to the death of C++.
C++ can survive by itself. There are plenty good open source C++
technologies. You have desktop technology QT/KDE, run-time
environment ACE, CORBA middleware implementation TAO, Apache C++
implementation of XML and Web Services. If you put all these piece
together, add C++ servlet and server page (it is easy to implement in
Apache), it is far superior to either J2EE or .NET. The problem is
current structure of C++ standard and its committee. It is clear to
me that there is lack of leadership in its committee. Why they have
to focus on .NET instead of focusing on Linux and open source? If C++
can form a C++ foundation, much like Perl or Java community, which
consist of C++ language, C++ run-time environment, and C++ platform
(these implementation and technologies are already there as I
mentioned above), I have no any doubt that C++ are far better than
J2EE or .NET. J2EE is only good at server side while .NET is good at
desktop. However, C++ can do both and can do much better than Java or
.NET. The problem is these technologies do not coherently tie
together because each technology belongs to individual entity. If we
can merge these technologies together under a single roof of C++
Foundation, C++ can and will compete with Java or .NET. Tying C++ to
.NET is like forcing .NET to accept step-C++ like a step-son.
Ultimately, C++ will lose its identity like having no parents and no
one will care about C++.

Post by Francis Glassborow
You mean people like Bjarne Stroustrup?

No, I have great respect of Bjarne Stroustrup. I don't think he'd
like to see C++/CLI based on his interviews with media. If he
supports C++/CLI, I will switch to Java without a second. I wish
Bjarne Stroustrup can stand up to lead C++. Current C++ standard will
not work and we must change it.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-07 17:41:57 UTC

In article <***@posting.google.com>, David Eng
<***@yahoo.com> writes

<snipped material about how C++ might become more than a language, which
is outside the scope of WG21, even if it wanted it not to be.>

Post by David Eng

Post by Francis Glassborow
You mean people like Bjarne Stroustrup?

And you missed my point. Active participation in something does not
necessarily mean that the participant approves of the work. If I know
something is going to happen and I am not an Ostrich (head in sand) I
can act to mitigate the consequences.

You seem to have a somewhat inaccurate view of the Standardisation
process and the motives of those involved with it. The real world is
composed of many shades of grey. Many of us try to do our best and do
not take kindly to having motives attributed to us by others on the
basis of their prejudices.

If your neighbour starts making alterations to his house in a way that
is likely to cause an explosion, you have three quick choices:

1) Go on holiday having checked your house insurance is fully paid up
2) Ignore it having checked that your life insurance is paid up
3) Volunteer to help him and ensure that he changes things in such a way
that any explosions will be confined to his property.

Of course you might involve the legal system, but at the speed that
normally works you would still be advised to consider options 1-3.

Gabriel Dos Reis

2004-07-07 18:04:12 UTC

***@yahoo.com (David Eng) writes:

| Apache), it is far superior to either J2EE or .NET. The problem is
| current structure of C++ standard and its committee. It is clear to
| me that there is lack of leadership in its committee. Why they have

Is that assertion based on actual active participation in C++
standards committee meeting?

P.J. Plauger

2004-07-08 01:25:47 UTC

Post by David Eng
The problem is
current structure of C++ standard and its committee. It is clear to
me that there is lack of leadership in its committee. Why they have
to focus on .NET instead of focusing on Linux and open source?

a) The C++ committee is *not* focusing on .NET. ECMA TC39/TG5 is
doing so. Several people from ISO SC22/WG21 (the C++ committee) are
either participating in TG5 or at least monitoring what it's doing.
Not quite the same thing.

b) People from the free software community often gripe about not
getting the consideration they deserve from the C and C++ committees,
but *they don't come to the meetings.* We focus on refining the
proposals of people who actively work on the committees. No work,
no focus.

Post by David Eng

Post by Francis Glassborow
You mean people like Bjarne Stroustrup?

Sounds like we really need you. Our next meeting is in Redmond WA
(hosted by You Know Who) in mid October. Or you can brush up your
Java skills.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Roland Pibinger

2004-07-08 23:54:04 UTC

Post by P.J. Plauger

Post by David Eng
No, I have great respect of Bjarne Stroustrup. I don't think he'd
like to see C++/CLI based on his interviews with media. If he
supports C++/CLI, I will switch to Java without a second. I wish
Bjarne Stroustrup can stand up to lead C++. Current C++ standard will
not work and we must change it.

Sounds like we really need you. Our next meeting is in Redmond WA
(hosted by You Know Who) in mid October.

Hm, something must have changed in the last 2 years:
http://www.ddj.com/documents/s=7536/ddj0209o/

Anyone with a little imagination can forsee the future of C++ (the
lack of) on the Windows platform and elsewhere.

Post by P.J. Plauger
Or you can brush up your Java skills.

Good idea anyway.

Best regards,
Roland Pibinger

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Phil

2004-07-08 23:18:04 UTC

I was initially concerned by C++/CLI. As I really have little
understanding of the standards process, the relationship between ISO
and ECMA, TC/TG's, fast-tracks or anything else beyond what I've
picked up from people chatting on this group. So I just listened to
what you guys were saying. But now I have a couple of questions:

1. Is C++/CLI going to become part of the standard or is it an
extension to it? I assume this is where Francis is talking about
"fast-track"-ing into the standard. Can this happen and if so, who
approves this? I only ask this because I assume Microsoft wouldn't be
able to do this (on their own) and that it would be the whole
standards committee?

2. If C++/CLI did move towards standardisation, is there any
possibility of the 'CLI part' becoming the platform and vendor neutral
C++ ABI that people have talked about on here in the past? In my
overly simple view of the world, this seems like a good thing
(although I imagine it's a huge amount of work, especially for those
providing free tools for us to use).

I apologise if my questions seem naive...it's very daunting posting to
this group as a relatively new C++ programmer!

Thanks in advance,
Phil

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

P.J. Plauger

2004-07-09 13:21:06 UTC

Post by Phil
1. Is C++/CLI going to become part of the standard or is it an
extension to it? I assume this is where Francis is talking about
"fast-track"-ing into the standard. Can this happen and if so, who
approves this? I only ask this because I assume Microsoft wouldn't be
able to do this (on their own) and that it would be the whole
standards committee?

ECMA is developing a C++/CLI standard (as they have done with CLI
and C#) in the form of a "binding" or bolt-on to Standard C++.
Microsoft has made a serious effort to minimize conflicts with
the C++ Standard, but there remain a few areas where the meaning
of a currently conforming C++ program will change (almost certainly
to one that is ill formed).

ECMA has "fast track" privileges with ISO, so the expectation is
that soon (about a year) after ECMA approves C++/CLI it will also
become an ISO standard. Note that it is a *separate* standard from
ISO/IEC 14882:2003, which is the current C++ Standard, and which
is maintained by ISO JTC1/SC22/WG21 (aka the C++ committee).

So:

-- No, the C++ Standard itself will not be modified by the
standardization of C++/CLI. The latter will be a standardized
extension to C++.

-- Yes, Microsoft has given up control of C++/CLI to ECMA
TC39/TG5. And they've promised to change their product to
match the ECMA Standard if the two eventually differ.

Post by Phil
2. If C++/CLI did move towards standardisation, is there any
possibility of the 'CLI part' becoming the platform and vendor neutral
C++ ABI that people have talked about on here in the past? In my
overly simple view of the world, this seems like a good thing
(although I imagine it's a huge amount of work, especially for those
providing free tools for us to use).

The ECMA Standards are indeed vendor neutral standards, in the sense
that Microsoft has given up control. But folks from Microsoft are
doing much of the heavy lifting in completing the documents, and
they have by far the most commercially important implementation of
CLI, and they will certainly be listened to carefully in future as
well as now. So, yes, there's room for other players, but so far
only one player weighs over 800 pounds.

Post by Phil
I apologise if my questions seem naive...it's very daunting posting to
this group as a relatively new C++ programmer!

Nope, good questions. And you didn't even get flamed (this time).

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ioannis Vranos

2004-07-09 13:21:44 UTC

Post by Phil
I was initially concerned by C++/CLI. As I really have little
understanding of the standards process, the relationship between ISO
and ECMA, TC/TG's, fast-tracks or anything else beyond what I've
picked up from people chatting on this group. So I just listened to
1. Is C++/CLI going to become part of the standard or is it an
extension to it? I assume this is where Francis is talking about
"fast-track"-ing into the standard. Can this happen and if so, who
approves this? I only ask this because I assume Microsoft wouldn't be
able to do this (on their own) and that it would be the whole
standards committee?

C++/CLI will be a separate, standardised set of *extensions* to ISO C++.
However some of the features may, and I say may, become part of a future
revision of the C++ standard.

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-09 14:04:27 UTC

Fast-tracking is an ISO mechanism whereby a publicly available standard
produced elsewhere can be made into a ISO Standard by a single round of
NB votes. The idea was fine, however I am not alone in thinking that
ECMA is abusing it.

What would happen if all went according to plan is that there would be
an entirely separate C++/CLI ISO Standard. Even accepting that much
leaves the question of who should be responsible for its future. I can
just about live with that body being SC22 and WG21, though I am firmly
of the belief that what we should have is an ISO Technical Report titled
C++/CLI but I do not think the current procedures allow for an ECMA
Standard to be fast tracked to an ISO TR.

What I am adamantly against is for something that clearly is not just a
set of bindings (as, e.g. Posix provides for C) but an extended dialect
of C++ to be maintained by anyone other than WG21, or at the very least
a Committee in which WG21 (i.e. the NB delegates) are full, official
voting members.

As a once off piece of work in a highly constrained time-frame, the
pragmatic view is to work with it. As a long term solution it should be
strongly resisted by all.

No one can 'fast track' something into an existing standard. That
mechanism is for the creation of new standards (and TRs but only, IIUC,
from other bodies' TRs)

Not really, because it only actually runs on a single platform, in the
same way that Java only runs on a single platform -- the JVM)

Post by Phil
I apologise if my questions seem naive...it's very daunting posting to
this group as a relatively new C++ programmer!

The whole world of Standardisation is daunting even for those who have
been involved in it for more than a decade.

Hyman Rosen

2004-07-10 02:06:01 UTC

Post by Francis Glassborow
What I am adamantly against is for something that clearly is not just a
set of bindings (as, e.g. Posix provides for C) but an extended dialect
of C++ to be maintained by anyone other than WG21, or at the very least
a Committee in which WG21 (i.e. the NB delegates) are full, official
voting members.
As a once off piece of work in a highly constrained time-frame, the
pragmatic view is to work with it. As a long term solution it should be
strongly resisted by all.

I am reminded of when the nimble and open egcs forked away from gcc,
and subsequently became gcc. It is clearly impossible to add the new
features of C++/CLI through the regular C++ committee process - it
would never countenance such changes on its own unless they were in
wide practice. This way, we will get the extensions as a standard,
and if it proves successful, it can be rolled back into full C++.

Think about the fact that even for C, the C++ and C committees could
not manage to work in unison.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-10 19:36:25 UTC

Post by Hyman Rosen
Think about the fact that even for C, the C++ and C committees could
not manage to work in unison.

I will accept that statement with reservations as long as you keep it
strictly in the past tense. Currently the co-operative work between WG14
and WG21 is so extensive that new ways had to be found to do it. ISO has
no concept of WGs actually working together rather than just telling
each other what they are doing and asking for support (via traditional
liaison).

Even the liaison between WG14 and WG21 greatly exceeds the traditional
form with almost a dozen designated two-way liaisons.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

llewelly

2004-07-12 22:11:34 UTC

Post by Francis Glassborow

Post by Hyman Rosen
Think about the fact that even for C, the C++ and C committees could
not manage to work in unison.

This is great news (well, maybe not new, but still great), and
congratulations to those members who've been
aiding and advocating WG21 and WG14 co-operation.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:07:45 UTC

On 9 Jul 2004 10:04:27 -0400, Francis Glassborow

Francis is quite correct, WG21 should have that option. FWIW, I should add
here that Tom Plum (convenor of TG5, C++/CLI) has already taken the step
of getting ECMA's agreement that, assuming that there eventually is an ISO
C++/CLI standard, if WG21 wants to take over maintenance and technical
ownership then there is no objection to them doing so. (This is unlike C#
and CLI, where there was no comparable existing ISO WG with either the
expertise or the willingness to take on the work.)

If and when we get to the point where there is an ISO C++/CLI, I'm as
curious as the next person whether WG21 will want to take over active
responsibility for it. As of right now, it is my understanding that the
TG5 participants' views (those that I've talked to) and ECMA's view is
that WG21 could take it if they wanted it.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-11 16:39:46 UTC

Post by Herb Sutter
Francis is quite correct, WG21 should have that option. FWIW, I should add
here that Tom Plum (convenor of TG5, C++/CLI) has already taken the step
of getting ECMA's agreement that, assuming that there eventually is an ISO
C++/CLI standard, if WG21 wants to take over maintenance and technical
ownership then there is no objection to them doing so. (This is unlike C#
and CLI, where there was no comparable existing ISO WG with either the
expertise or the willingness to take on the work.)
If and when we get to the point where there is an ISO C++/CLI, I'm as
curious as the next person whether WG21 will want to take over active
responsibility for it. As of right now, it is my understanding that the
TG5 participants' views (those that I've talked to) and ECMA's view is
that WG21 could take it if they wanted it.

And my opinion is that regardless of whether we want it, we should
nonetheless take it. WG21 are custodians of C++ and the only long term
way to manage C++\CLI in ways that do no damage to C++ is to take
responsibility for it. Of course I envisage that the maintenance work
will be undertaken by interested parties with understanding of the
issues but that is, in essence, no different from the way we work on
library and core.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Eng

2004-07-12 22:00:51 UTC

Post by Francis Glassborow

MS creates a perfect dilemma for ISO C++. WG21 has to take control
C++/CLI in order to limit damage to C++. Then, C++ will be an true MS
language (C++ already has a bad reputation as being a MS language)
since whenever C++ evolves, it has to confirm with CLI and whenever
CLI changes, C++ has to add more extensions.

IMO, I would be strongly against WG21 taken custody of C++/CLI. I
don't see any future of C++/CLI. If you want to target CLI or .NET,
use C#; if you want to target JVM or J2EE, use Java; if you want to
target binary, us C++. If C++ cannot evolve itself, it is nature for
other language to replace C++.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

P.J. Plauger

2004-07-06 21:10:30 UTC

Post by David Eng

You must be confused. C++/CLI is polluting C++ by Microsoft helped
with some C++ standard committee members.

Uh, thanks for the vote of confidence.

Post by David Eng
It is not about possibility
to merge.

You know this for a certainty?

Post by David Eng
It should be a possibility for C++ community to file a
lawsuit against Microsoft.

If so, then the C++ community has a pretty strong case against WG21
too.

Post by David Eng
Microsoft has no rights to change the C++
language in order to fit .NET.

Really? Sez who? (Besides you, that is.)

Post by David Eng
She did exactly same thing to Java
before but lost the lawsuit to SUN.

Not *exactly.* Java is a proprietary language owned by Sun
Microsystems. They have repeatedly offered to let the language
be standardized and repeatedly reneged somewhere along the way.
Microsoft licensed Java from Sun and failed to honor all the
terms of the license, so I understand from the court decisions.
Practically every other major player in the Java community
appears to have done the same, but Sun didn't sue them.

By contrast, C++ is *not* a proprietary language. Nor are there
any laws requiring that all vendors ship only fully conforming
versions of Standard C++. Good thing, too.

Post by David Eng
It is time to wake up for C++
community and say no to Microsoft's effect to pollute C++.

Perhaps. But you might be interested to learn that Andy Koenig
woke up a few years ago and gave a talk proposing changes to
Standard C++ that are remarkably close to what Microsoft had
already begun and has now become C++/CLI.

Conservation and conservatism evolved from the same root word,
as did revolutionary and revolting. A lot depends upon your
point of view.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gerhard Menzl

2004-07-07 17:39:25 UTC

Post by P.J. Plauger
Perhaps. But you might be interested to learn that Andy Koenig
woke up a few years ago and gave a talk proposing changes to
Standard C++ that are remarkably close to what Microsoft had
already begun and has now become C++/CLI.

There isn't an online version of this talk available, or is there?

--
Gerhard Menzl

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gabriel Dos Reis

2004-07-07 18:02:15 UTC

***@yahoo.com (David Eng) writes:

| Ioannis Vranos <***@guesswh.at.grad.com> wrote in message news:<cc54pn$1mha$***@ulysses.noc.ntua.gr>...
| > Is there any intention these two standards to merge sometime in the
| > future? Is it possible to merge? I do not know much of the C++/CLI yet,
| > but from few things have read the .NET generics are not compatible (a
| > subset) of C++ templates, so I wonder there will be two kinds of
| > templates in the future?
|
| You must be confused. C++/CLI is polluting C++ by Microsoft helped
| with some C++ standard committee members.

I can't speak for others, but I'm certainly not helping anybody to
"pollute" C++. I believe you're light-years away from the reality of
the situation and its complexity.

Ioannis Vranos

2004-07-08 11:56:56 UTC

Some useful information on the topic summarised:

There is an official ISO standard about CLI runtime environment, which
is about a standardised *multilingual* virtual machine environment
together with its assembly language. There are two CLI compliant virtual
machines today, .NET framework in the Windows world, and Mono in GNU/Linux.

There is also an official ISO C#/CLI standard that describes C# and how
it works in CLI environments.

There is also an upcoming C++/CLI standard (currently draft), that is a
standardised set of *extensions* to ISO C++ which will make C++ programs
to take advantage of the CLI abilities.

Some examples are:

// Garbage collected class
ref class whatever
{
// ...
};

whatever ^h=gcnew whatever;

// A vector with GC handles
vector<Button ^>buttonArray;

Also we will be able to create ref objects in the stack (=with
deterministic finalisation).

The draft standard is free to download, and you can download the latest
version from here:

http://www.plumhall.com/C++-CLI%20Standard.pdf

(ref page: http://www.plumhall.com/public-drop.htm)

Also in contrast to ISO, ECMA provides for free the final CLI standard
(take a look at its assembly language!):

http://www.ecma-international.org/publications/standards/Ecma-335.htm

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Old Wolf

2004-07-09 13:28:35 UTC

Post by Ioannis Vranos
There is an official ISO standard about CLI runtime environment, which
is about a standardised *multilingual* virtual machine environment
together with its assembly language. There are two CLI compliant virtual
machines today, .NET framework in the Windows world, and Mono in GNU/Linux.
There is also an upcoming C++/CLI standard (currently draft), that is a
standardised set of *extensions* to ISO C++ which will make C++ programs
to take advantage of the CLI abilities.
http://www.plumhall.com/C++-CLI%20Standard.pdf

This looks like Java with a few minor syntax changes..
will C++/CLI offer anything that C#/CLI doesn't? If not,
then what's the point?

(PS. this isn't a troll.. just some groping for understanding)

One more thing in that document catches my eye: its wchar_t is
16-bit. Everyone except Microsoft seems to have noticed that
there are more than 65,535 Unicode characters defined -- wchar_t
is 32-bit on every other platform except Visual C++. The point of
wide chars is to avoid having to use encodings like UTF-n,
so why not get it right now while you have the chance??
Or is C++/CLI just another case of Microsoft inserting junk
all through perfectly good existing standards?
(at least this time they have put what they're doing in writing..)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hyman Rosen

2004-07-10 01:00:18 UTC

Post by Old Wolf
This looks like Java with a few minor syntax changes..
will C++/CLI offer anything that C#/CLI doesn't? If not,
then what's the point?

It offers all of C++ in addition to the new features.

Post by Old Wolf
its wchar_t is 16-bit.

To quote the document:
This mapping is still under discussion;
it is by no means settled yet.[[#93]]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Old Wolf

2004-07-11 10:32:52 UTC

Post by Hyman Rosen

Post by Old Wolf
This looks like Java with a few minor syntax changes..
will C++/CLI offer anything that C#/CLI doesn't? If not,
then what's the point?

It offers all of C++ in addition to the new features.

I had heard in this NG that multiple-inheritance won't be
supported for objects derived from CLI objects. I guess
there is still a lot of FUD and draft stuff around.

Also, will CLI objects be permitted to be members of
standard containers (eg. std::list<System::String> or whatever)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow

2004-07-10 01:09:34 UTC

Post by Old Wolf

Post by Ioannis Vranos
http://www.plumhall.com/C++-CLI%20Standard.pdf

This looks like Java with a few minor syntax changes..
will C++/CLI offer anything that C#/CLI doesn't? If not,
then what's the point?

Well one of the motives for the team leads from Microsoft on C++/CLI is
that they do not want C++ to continue as a second class citizen in the
.NET world. They positively do not want to see C++ programmers migrating
to C# (and increasingly staying there). There mechanism for mitigating
that may not be perfect but they certainly have their hearts in the
right place in so far as the C++ community is concerned.

The motivation is to ensure that Standard C++ will run as a CLI client
(or whatever the correct term is) and that C++/CLI will be a full
authoring program for .NET components. Of course that means that much of
the C++/CLI extensions will look like C# with some minor syntax changes.
However they also tell me that C++/CLI will be able to utilise some
aspects of CLI that C# cannot (at least in its current release).

Of course it is in the career interests of those working on C++ tools in
Microsoft to ensure that C++ continues to be a major player in Visual
Studio. However those interests largely coincide with the interests of
the C++ community as a whole.

Ioannis Vranos

2004-07-08 23:30:16 UTC

Isn't there any other managed code switch (like current /clr) which
allows mixing of managed and unmanaged code?

error C4956: 'char *' : this type is not verifiable
Safe programming means System::String ^s instead of std::string s, and
Collections::Generic::List<int> ^v instead of std::vector<int> v. If
you don't do it the new way, you don't get the advantages.

Why?

And
preserving the ability to mix and match freely has another cost: a
language with a split personality, impossible to explain to a beginner
without trawling through decades of history.

In a managed and unmanaged scenario, I think it is possible to explain
to a beginner, like with the current managed extensions syntax. System
dependent stuff and ISO C++ stuff.

It can be argued that if C++ doesn't evolve, something like C# may
replace it. But the new features of C++/CLI are really just C# with an
uglier syntax. It looks suspiciously like C# has been dropped onto
C++, but with the C# part artfully mangled to make it coexist with
C++.
- deterministic finalization through destructors. I spent a while
trying to evaluate this without any luck, before finding a comment in
Stan Lippman's blog to the effect that it didn't make it into the beta
release!
- C++ templates, which are far more powerful than CLI generics.
But having two kinds of generics in one language has to be someone's
idea of a joke. :) And as for deterministic finalization, there are
other ways to achieve that besides destructors, and C# already has a
fairly neat way (the 'using' keyword).

Actually generics are executed at run-time while templates in
compile-time (from source code to IL compilation).

Regards,

Ioannis Vranos

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Herb Sutter

2004-07-10 11:08:44 UTC

Post by Ioannis Vranos
Is there any intention these two standards to merge sometime in the
future?

There's no such intention I know of.

Post by Ioannis Vranos
Is it possible to merge?

Probably, but there are certainly things in C++/CLI that are very specific
to CLI and IMO are unlikely to ever be part of ISO C++ (e.g., support for
the CLI operators). Other things are more general-purpose and could be
considered for ISO C++ on an individual-feature basis (e.g., nullptr is
being proposed).

Post by Ioannis Vranos
I do not know much of the C++/CLI yet,
but from few things have read the .NET generics are not compatible (a
subset) of C++ templates, so I wonder there will be two kinds of
templates in the future?

C++/CLI supports both C++ templates and .NET generics. You can even use
them together very powerfully; e.g., a template can inherit from a generic
interface, and a generic can match a template template parameter.

I'll soon write more about this, especially on the benefits of being able
to use either one, or better still use both together, in the same
language. In short, C++ templates are much more flexible than generics,
but generics have their own advantages (notably that they are
cross-language and cross-assembly). Each is designed to do things the
other isn't.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Daniel

2004-07-08 11:54:52 UTC