 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ioannis Vranos
Guest
|
 Posted: Sat Jul 03, 2004 10:40 am Post subject: C++ standard and C++/CLI |
 |
|
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?
Regards,
Ioannis Vranos
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Francis Glassborow
Guest
|
| Posted: Sat Jul 03, 2004 8:39 pm Post subject: Re: C++ standard and C++/CLI |
|
|
In article <cc54pn$1mha$1 (AT) ulysses (DOT) noc.ntua.gr>, Ioannis Vranos
<ivr (AT) guesswh (DOT) at.grad.com> writes
| Quote: | 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! ]
|
|
| Back to top |
|
|
Max Polk
Guest
|
| Posted: Sat Jul 03, 2004 8:44 pm Post subject: Re: C++ standard and C++/CLI |
|
|
Ioannis Vranos wrote:
| Quote: | 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?
|
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! ]
|
|
| Back to top |
|
|
Ioannis Vranos
Guest
|
| Posted: Sun Jul 04, 2004 10:56 am Post subject: Re: C++ standard and C++/CLI |
|
|
Francis Glassborow wrote:
| Quote: | In article <cc54pn$1mha$1 (AT) ulysses (DOT) noc.ntua.gr>, Ioannis Vranos
[email]ivr (AT) guesswh (DOT) at.grad.com[/email]> writes
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.
|
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! ]
|
|
| Back to top |
|
|
Ioannis Vranos
Guest
|
| Posted: Sun Jul 04, 2004 10:56 am Post subject: Re: C++ standard and C++/CLI |
|
|
Max Polk wrote:
| Quote: | Ioannis Vranos wrote:
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?
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.
| Quote: |
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! ]
|
|
| Back to top |
|
|
Carl Daniel
Guest
|
| Posted: Mon Jul 05, 2004 9:56 am Post subject: Re: C++ standard and C++/CLI |
|
|
Max Polk wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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++.
| Quote: |
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! ]
|
|
| Back to top |
|
|
Andre Kaufmann
Guest
|
| Posted: Mon Jul 05, 2004 10:04 am Post subject: Re: C++ standard and C++/CLI |
|
|
| Quote: | 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! ]
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Jul 05, 2004 10:11 am Post subject: Re: C++ standard and C++/CLI |
|
|
Ioannis Vranos <ivr (AT) guesswh (DOT) at.grad.com> writes:
[...]
| Quote: | 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
[email]gdr (AT) cs (DOT) tamu.edu[/email]
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! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Mon Jul 05, 2004 2:56 pm Post subject: Re: C++ standard and C++/CLI |
|
|
Ioannis Vranos <ivr (AT) guesswh (DOT) at.grad.com> wrote
[...]
| Quote: | 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! ]
|
|
| Back to top |
|
|
Ioannis Vranos
Guest
|
| Posted: Mon Jul 05, 2004 2:58 pm Post subject: Re: C++ standard and C++/CLI |
|
|
Gabriel Dos Reis wrote:
| Quote: | Ioannis Vranos <ivr (AT) guesswh (DOT) 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?
|
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! ]
|
|
| Back to top |
|
|
Paul Mensonides
Guest
|
| Posted: Mon Jul 05, 2004 10:35 pm Post subject: Re: C++ standard and C++/CLI |
|
|
"Ioannis Vranos" <ivr (AT) guesswh (DOT) at.grad.com> wrote
| Quote: | | 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
{
// ...
};
|
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! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Mon Jul 05, 2004 10:36 pm Post subject: Re: C++ standard and C++/CLI |
|
|
Ioannis Vranos <ivr (AT) guesswh (DOT) at.grad.com> writes:
| Quote: | Gabriel Dos Reis wrote:
Ioannis Vranos <ivr (AT) guesswh (DOT) 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?
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>;
[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! ]
|
|
| Back to top |
|
|
Roland Pibinger
Guest
|
|
| Back to top |
|
|
Paul Mensonides
Guest
|
| Posted: Mon Jul 05, 2004 10:38 pm Post subject: Re: C++ standard and C++/CLI |
|
|
"Carl Daniel" <cpdaniel_remove_this_and_nospam (AT) mvps (DOT) org.nospam> wrote
| Quote: | 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.
| Quote: | 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! ]
|
|
| Back to top |
|
|
Dietmar Kuehl
Guest
|
| Posted: Tue Jul 06, 2004 11:17 am Post subject: Re: C++ standard and C++/CLI |
|
|
Ioannis Vranos <ivr (AT) guesswh (DOT) at.grad.com> wrote:
| Quote: | 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).
--
<mailto:dietmar_kuehl (AT) yahoo (DOT) 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! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
