C++/CLI standard

[Ioannis Vranos]

I have initiated a similar discussion thread in clc++m, however because
of the "m" in the name, the discussion is progressing slowly, so I am
setting another thread here.



Well the story is this. 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).



Check a nice article about this *standardised* syntax:

http://www.codeguru.com/columns/Kate/article.php/c7405/



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

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

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



So, what do you think of this upcoming standard?






Regards,

Ioannis Vranos

 

[Alf P. Steinbach]

* Ioannis Vranos:

There is an official ISO standard about CLI runtime environment

Are you sure?

I thought that was only a (proposed) ECMA standard?

Do you have a link?

 

[Ioannis Vranos]

* Ioannis Vranos:



Are you sure?

I thought that was only a (proposed) ECMA standard?

Do you have a link?

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36769&ICS1=35&ICS2=60&ICS3=






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

I have initiated a similar discussion thread in clc++m, however because
of the "m" in the name, the discussion is progressing slowly, so I am
setting another thread here.



Well the story is this. 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).



Check a nice article about this *standardised* syntax:

http://www.codeguru.com/columns/Kate/article.php/c7405/



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

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

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



So, what do you think of this upcoming standard?

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

 

[Ioannis Vranos]

Really? CLI mainly has three parts that C++ is lack of: VM, garbage
collection, and middleware platform. For the VM and garbage
collection, it is not in the spirit of C++. Would Andy Koenig prefer
those?

Please take a look at TC++PL 3 on page 844 in C.9.1 (Automatic Garbage
Collection).

However, if C++ is evolving toward CLI or likes, i.e. interface first
following by implementation without changing C++ language, I have no
object to this process. The C++/CLI stuff is coming from
implementation first following by changing C++ in order to fit the
interface. It is not revolutionary but revolting (thanks for teaching
me some English).

C++/CLI comes after CLI standard. Keep in mind that there is a C#/CLI,
Fortran/CLI and other languages/CLI standards!

OH,yea! You are the one who vigorously promote C++/CLI. It is
certain that you can sell more C++/CLI libraries to Microsoft. For
C++ programmers, we get more ugly syntax and confusion, and less
spirit of C++. I think you have created a perfect shoe for yourself
to wear.

C++/CLI is a set of *extensions* to ISO C++, it doesn't change C++, nor
it keeps it as a subset, it is just standardised *extensions*.

We all see C++ is declining.

Now that is very untrue! C++ has been the dominant general purpose
programming language, and Java and VB have been *millions* of
programmers behind.

However, if someone criticizes C++
standard committee, they either censor different opinions or shut up
criticism by saying "no participate and no voice". As one poster
stated, it was waste time to participate C++ standard process since
the C++ standard committee never achieved anything after C++ was
standardized in 1999. I concur! The reason of C++ declining, IMO, is
C++ is lack of libraries in a standard way for common programming
tasks into applications, such as thread library. The committee
responded to this criticism was they didn't have time or no one
participated. But there are plenty good open source libraries, for
example, ACE has a nice thread implementation. If they are
incompetent to create one, why do they just accept one from open
source? If you put open source technology QT/KDE for desktop, ACE for
run-time environment, TAO for CORBA middleware implementation, Apache
C++ implementation for XML and Web Services together under C++ roof,
IMO, it is far superior to J2EE and .NET. Why they have to tie C++ to
..NET instead of standardizing the above technologies so that C++ can
compete with Java and .NET?

Where do you base your thought that "C++ is declining"?

The reason I am againt C++/CLI is very simple. If C++ binds to CLI,
C++ shouldn't be changed.

It doesn't.

The binding should be through library
instead of changing C++ syntax. CLI is just like CORBA. The binding
between C++ and CORBA never requires C++ change. Why does the binding
between C++ and CLI require C++ change?

It doesn't change. So far we had "managed extensions" in .net framework,
now we will get standardised extensions to standardised CLI environment!

Certainly, it is Microsoft,
the bigot. People praise CLI, calling it platform independent.
Please hold your breath. Since Windows is a proprietary OS, there is
always one single vendor. Even if CLI becomes standard,

CLI is already a standard, and Mono is a CLI compliant VM in GNU/Linux.

check http://www.mono-project.com



The future of C++ is bright in any case.






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

"C++/CLI also streamlines the manner in which managed data types are
defined and consumed. The new standard introduces keywords that are more
intuitive to C++ developers than the underbar-underbar keywords of
current Managed Extensions. In C++/CLI, the ref keyword is used in a
manner similar to the Managed Extensions __gc keyword to define a
garbage-collected class:

ref class MyRefClass { /* ... */ };

In addition, C++/CLI introduces a new category of type, the handle,
which is used to signify the use of automatic garbage collection.
Handles borrow the syntax of pointers, but use the carat (^) in place of
the asterisk (*). The keyword gcnew is used to create these garbage
collected objects, and returns a handle:

MyRefClass ^ c = gcnew MyRefClass();

With C++/CLI, developers will also be able to incorporate traditional
C++-style deterministic finalization for handle types. This means that a
reference type may be optionally instantiated as an object using normal
C++ stack-allocation syntax. In doing so, the object will automatically
have its destructor called when it falls out of scope. This feature
enables a style of programming not available in other languages
targeting the CLR."






Regards,

Ioannis Vranos