---

Hej alle,

Har netop modtaget nedenstående mail, der åbner for truende
fremtidsudsigter for ISO C++. Hvordan er jeres holdning til nedenstående?

From: Lois Goldthwaite <lois@loisgoldthwaite.com>
Subject: C++/CLI DIS is here
Date: Tue, 3 Jan 2006 03:37:28 +0000

Hi,

JTC1 N8037 has arrived at BSI -- that is the notice that Ecma is
submitting its C++/CLI standard for fast track approval by ISO/IEC. The
first stage of the process is a 30-day review period to determine if
there are any contradictions with existing JTC1, ISO, or IEC standards.
The deadline for pointing out such contradictions to the JTC1
secretariat is January 23rd. (You would think they might give us a bit
of extra time with all the holidays around now!)

The UK C++ panel intends to raise an objection on the grounds that there
is indeed a contradiction -- with the existing C++ standard. There is
substantial material in this FDIS which is so different from standard
C++ that we think Ecma should withdraw the document until it can find a
new name for its language.

C++/CLI adds at least two dozen new keywords to the 63 in standard C++,
plus some new syntax for old keywords, and changes the semantics of
many code constructs, depending on whether they apply to traditional
objects or the managed objects of its totally different object model
("member functions of native classes use hidebyname lookup ... On the
other hand, member functions of ref classes, value classes, interface
classes, and delegates use hidebysig lookup.")

The new features go far beyond anything that could be described as a
"binding" to the CLI environment, in our opinion. There is a clear
parallel with the circumstances which caused Bjarne to seek a name for
his new language which would more clearly differentiate it from C. Not
only is this a new language wrapped in the old name, the differences
can only grow larger over time as separate organisations maintain these
documents.

When C++ already has a reputation as a complicated language to learn and
use, and when many programmers have only a hazy notion about the
differences between C++ and C, we think it would cause great confusion
in the industry to give any sanction to a C++ dialect which is at least
50% larger than standard C++ and adds an immense number of even more
complicated rules for using it.

There is clear evidence that this confusion is already causing a
problem. Just take a look at the Microsoft online documentation --
start with the article on "New C++ Language Features" at
http://msdn2.microsoft.com/en-us/library/xey702bw.aspx, which explains
about all the new keywords that have been added to C++ -- NOT
"C++/CLI" or even "C++.Net". Another example is
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dndotnet/html/NetFramework.asp,
which has many examples showing parallel code for "C#", "Visual Basic",
and "C++" (without qualifier). None of these examples would compile in
a Standard C++ environment. If Microsoft can't understand the
difference between Standard C++ and the C++/CLI dialect it invented,
what hope is there for the ordinary programmer in the trenches?

If your national body shares our concerns about the damage to industry
that would be caused by adopting two not-very-compatible standards for
C++, I hope you will express those concerns to JTC1 before the Fast
Track Ballot gets underway for this DIS.

If you need a copy of N8037, or would like to see the comments we will
submit, I will be glad to send them to you.

Best regards,
Lois

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.01.05.22.02.53.310982@miras.org...
> Hej alle,
>
> Har netop modtaget nedenstående mail, der åbner for truende
> fremtidsudsigter for ISO C++. Hvordan er jeres holdning til nedenstående?

Først bemærker jeg at det er Lois der har skrevet mailen - jeg har dyb
respekt for hendes arbejde og ydermere er hun rar og hyggelig at tale med.

Vedrørende indholdet:
Den proces der beskrives med at tage ECMA Standarden og køre den igennem som
en fast trac approval hos ISO/IEC er hvad Microsoft hele tiden har sagt de
vil gøre. Det er reelt Microsoft der sidder på specifikationen af C++/CLI og
de har frigivet en implementering i Visual Studio .NET 2005.

Det er ikke overraskende at Microsoft har en interesse i ikke at gøre
forskellene mellem ISO C++ og C++/CLI klare - det gælder også for deres
online dokumentation i Visual Studio .NET 2005. Men det er der egentlig ikke
noget nyt eller overraskende i - leverandører har altid forsøgt at binde
programmører til deres platform mere eller mindre åbenlyst.
Det har altid været udviklernes og projekternes egen opgave at sikre at man
har de afhængigheder man (forhåbentlig) bevidst har valgt - der er intet nyt
under solen.

C++/CLI forekommer mig at være en klar forbedring i forhold til Managed C++,
som var Microsoft tidligere bud på integration mellem C++ og CLI (.NET).
Jeg syntes med al tydelighed at Microsofts skift fra MFC til Managed C++ og
videre til C++/CLI med al ønskelig tydelighed viser værdien i at holde
væsentlige dele sin kode i ISO C++, så det kan klare disse skift - altså
forudsat at man skriver applikationer der har et langt liv. Det gælder vel
at mærke selvom man kun ønsker at applikationen skal køre på MS-Windows.

Personligt syntes jeg C++/CLI med WinForms er et udemærket bud på hvordan
man kan lave en GUI til et C++ på MS-Windows platformen, men kernen af
applikationen ville jeg holde som ISO C++.

Alternativet C++/CLI ville være at vælge at C++ ikke skulle være noget
væsentligt sprog på .NET platformen, hvilket ville være uheldig al den stund
at Microsoft har bestemt at .NET platformen er en væsentlig del af deres
strategi.

Men truende skyer over ISO C++ - nej bestemt ikke som jeg ser det.

Venlig hilsen

Mogens Hansen

---

On Thu, 05 Jan 2006 23:32:06 +0100, Mogens Hansen wrote:


> Alternativet C++/CLI ville være at vælge at C++ ikke skulle være
> noget væsentligt sprog på .NET platformen, hvilket ville være uheldig
> al den stund at Microsoft har bestemt at .NET platformen er en
> væsentlig del af deres strategi.
>
Jeg har ingen indvendinger mod, hvad MS føler/mener er vigtigt på deres
platform, og det deraf afledede ændringer af C++/CLI. Humlen er dog her,
at de vil have udvidelserne indlemmet i ISO C++, hvilket jeg mener er helt
hen i været. C++ er, og skal fortsat være, et generel purpose
programming language, og ikke skræddersyet til Windows platformen. Alle
de ændringer de foreslår, har jo ingen relevans, hvis din kode skal
oversættes på en anden platform, hvorfor det blot vil tilføje støj og
unødig kompleksitet til en i forvejen stor specifikation. Et andet
argument imod indlemmelsen er, at det på afgørende punkter bryder med
bagud kompatibiliteten med eksisterende kodebase.

I stedet for denne fastlåsning af GUI til winforms, burde den korrekte
måde, efter min mening, at indføre GUI-udvidelser til C++ være i stil
med Java's JDBC. Følgende er mit forslag, jeg har sendt til Matt Austern:

A proposal for implementing a standard GUI interface in C++

The main architecture resembles the idea behind Java's JDBC. E.g. the
language/library provides a standard interface or set of interfaces and
developers of graphics libraries does the actual implementation. If put
into a design pattern terminology the standard interface is a factory
hiding all implementation specific stuff from the programmer. The standard
interface would specify features and their dependencies but otherwise
leave implementation descessions to the developers of the graphics
library.

There are many advantages to this architecture of which I will point out
the most important ones:

   Portability: Write one GUI class and reuse it on any platform providing a
   C++ GUI standards compliant implementation. Simplicity: The C++ language
   does not need to maintain a binary code base on every available platform.
   All the language needs to maintain is a specification for the interface.
   Compatibility: If the architecture is chosen backwards compatibility can
   be maintained because the interface will be purely written in standard
   C++ and have no ties to the underlying platforms graphics specifications
   and/or hardware. Control: No graphics library will be able to extend or
   change the functionality of the GUI interface in the language. This means
   that the community will be in full control of the direction and
   development but at the same time the community will not in any way
   prevent developers of graphics libraries to go further. A core will be
   standards compliant and the extention will not be.

It is hard for me to point out some disadvantages but of course one is
obvious: The success depends on adaptation from developers of graphics
libraries

Altså: C++/CLI bør derfor holdes ude fra ISO C++, men bør så være
MS's implementation af ISO C++'s standard gui interface.

> Men truende skyer over ISO C++ - nej bestemt ikke som jeg ser det.
>
Og jo, det synes jeg i høj grad. MS's motto har alle dage været embrace
and extend!

Quotes from the Halloween documents:

* "Recent case studies (the Internet) provide very dramatic evidence
... that commercial quality can be achieved / exceeded by OSS
projects."

* (Open source software) "is long-term credible ...
FUD tactics can not be used to combat it."

* "Linux can win as long as services / protocols are commodities."

* (Microsoft should) "De-commoditize protocols & applications"

The last strategy has been described by others as "embrace, extend
and extinguish".

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.01.05.23.03.24.568659@miras.org...

[8<8<8<]
> Jeg har ingen indvendinger mod, hvad MS føler/mener er vigtigt på deres
> platform, og det deraf afledede ændringer af C++/CLI. Humlen er dog her,
> at de vil have udvidelserne indlemmet i ISO C++,

Her mener jeg at du misforstår noget.
ISO C++ (altså ISO/IEC 14882) sammen med det arbejde der foregår i WG21 (så
vidt jeg husker) har formelt set ikke noget at gøre med den ISO standard der
muligvis kommer til at dække C++/CLI - det er 2 forskellige standarder. Der
er godt nok et vist sammenfald i personerne (mest oplagt Herb Sutter).
Forholdet mellem ISO C++ og den muligvis kommende ISO C++/CLI minder meget
om forholdet mellem ISO C og ISO C++.
Dog virker det som om fast track ISO C++/CLI i højere grad er et forsøg på
blåstempling end egentlig, åben standardisering - tænk blot på hvor lang tid
det har taget for både C og C++ kommiterne at nå til enighed om indholdet.

Venlig hilsen

Mogens Hansen

---

On Fri, 06 Jan 2006 00:14:56 +0100, Mogens Hansen wrote:

> Dog virker det som om fast track ISO C++/CLI i højere grad er et forsøg på
> blåstempling end egentlig, åben standardisering - tænk blot på hvor lang tid
> det har taget for både C og C++ kommiterne at nå til enighed om indholdet.
Synes du de to link fra Lois' mail indikerer "New C++ Language Features",
at det er de hensigter, der ligger til grund for ønsket?

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.01.05.23.22.06.149429@miras.org...
> On Fri, 06 Jan 2006 00:14:56 +0100, Mogens Hansen wrote:
>
>> Dog virker det som om fast track ISO C++/CLI i højere grad er et forsøg
>> på
>> blåstempling end egentlig, åben standardisering - tænk blot på hvor lang
>> tid
>> det har taget for både C og C++ kommiterne at nå til enighed om
>> indholdet.
> Synes du de to link fra Lois' mail indikerer "New C++ Language Features",
> at det er de hensigter, der ligger til grund for ønsket?

Jeg kiggede ikke på de links inden jeg svarede - det er blot links til MSDN.

Når lige skimmer linket til MSDN artiklen "New C++ Language Features", så
står skelnen mellem ISO C++, Visual C++ og C++/CLI måske ikke så tydelig.
Men det er beskrives er den nye syntaks til at skrive applikationer til
CLR - altså C++/CLI, der erstatter Managed C++.

Jeg forstår nok ikke helt hvad du mener - det er måske ved at være lidt sent


Venlig hilsen

Mogens Hansen

---

Michael Rasmussen wrote:
> Jeg har ingen indvendinger mod, hvad MS føler/mener er vigtigt på deres
> platform, og det deraf afledede ændringer af C++/CLI. Humlen er dog her,
> at de vil have udvidelserne indlemmet i ISO C++, hvilket jeg mener er helt
> hen i været. C++ er, og skal fortsat være, et generel purpose
> programming language, og ikke skræddersyet til Windows platformen.

Hm. Nu synes jeg faktisk ikke at .NET klasse bilblioteketer
specielt meget værre end Win32 API eller MFC eller
et tilfældigt valgt Linux bibliotek.

Det slemme er nye keywords og andre grundliggende
ændringer af sproget.

Og disse er nok ikke specielt Windows specifikke.

Eneste sammenhæng er at de windows specifikke
klasse biblioteker er lavet så de kræver
udvidelserne til sproget.

> Alle
> de ændringer de foreslår, har jo ingen relevans, hvis din kode skal
> oversættes på en anden platform, hvorfor det blot vil tilføje støj og
> unødig kompleksitet til en i forvejen stor specifikation.

Jeg køber unødvendig og kæmpe specifikation.

> I stedet for denne fastlåsning af GUI til winforms, burde den korrekte
> måde, efter min mening, at indføre GUI-udvidelser til C++ være i stil
> med Java's JDBC. Følgende er mit forslag, jeg har sendt til Matt Austern:
>
> A proposal for implementing a standard GUI interface in C++
>
> The main architecture resembles the idea behind Java's JDBC. E.g. the
> language/library provides a standard interface or set of interfaces and
> developers of graphics libraries does the actual implementation. If put
> into a design pattern terminology the standard interface is a factory
> hiding all implementation specific stuff from the programmer. The standard
> interface would specify features and their dependencies but otherwise
> leave implementation descessions to the developers of the graphics
> library.

Der må være masser af andre eksempler end JDBC. Det er vel ret
gængs best practice.

> Altså: C++/CLI bør derfor holdes ude fra ISO C++, men bør så være
> MS's implementation af ISO C++'s standard gui interface.

Som nævnt ovenfor betragter jeg managed C++ og .NET GUI klasse bibliotek
som værende ikke det samme.

> Og jo, det synes jeg i høj grad. MS's motto har alle dage været embrace
> and extend!

> The last strategy has been described by others as "embrace, extend
> and extinguish".

Jeg synes ikke at det skal gøres til en "vi hader MS" sag
med opbakning fra enhver OSS tilhænger.

Men mere køre på at C++ skal være en enkelt standard. Og
at man skal forsøge at undgå at standarden udvikler
sig til en ulden standard med flere forskellige inkompatible
understandarder.

Bolden ikke manden !

Arne

---

Mogens Hansen wrote:
> "Michael Rasmussen" <mir@miras.org> wrote in message
> news:pan.2006.01.05.22.02.53.310982@miras.org...
>> Hej alle,
>>
>> Har netop modtaget nedenstående mail, der åbner for truende
>> fremtidsudsigter for ISO C++. Hvordan er jeres holdning til nedenstående?
>
> Først bemærker jeg at det er Lois der har skrevet mailen - jeg har dyb
> respekt for hendes arbejde og ydermere er hun rar og hyggelig at tale med.
>
> Vedrørende indholdet:
> Den proces der beskrives med at tage ECMA Standarden og køre den igennem som
> en fast trac approval hos ISO/IEC er hvad Microsoft hele tiden har sagt de
> vil gøre. Det er reelt Microsoft der sidder på specifikationen af C++/CLI og
> de har frigivet en implementering i Visual Studio .NET 2005.
>
> Det er ikke overraskende at Microsoft har en interesse i ikke at gøre
> forskellene mellem ISO C++ og C++/CLI klare - det gælder også for deres
> online dokumentation i Visual Studio .NET 2005. Men det er der egentlig ikke
> noget nyt eller overraskende i - leverandører har altid forsøgt at binde
> programmører til deres platform mere eller mindre åbenlyst.
> Det har altid været udviklernes og projekternes egen opgave at sikre at man
> har de afhængigheder man (forhåbentlig) bevidst har valgt - der er intet nyt
> under solen.

Men bør "vi" så ikke bede dem om at kaldet det for noget andet end C++?

> C++/CLI forekommer mig at være en klar forbedring i forhold til Managed C++,
> som var Microsoft tidligere bud på integration mellem C++ og CLI (.NET).
> Jeg syntes med al tydelighed at Microsofts skift fra MFC til Managed C++ og
> videre til C++/CLI med al ønskelig tydelighed viser værdien i at holde
> væsentlige dele sin kode i ISO C++, så det kan klare disse skift - altså
> forudsat at man skriver applikationer der har et langt liv. Det gælder vel
> at mærke selvom man kun ønsker at applikationen skal køre på MS-Windows.
>
> Personligt syntes jeg C++/CLI med WinForms er et udemærket bud på hvordan
> man kan lave en GUI til et C++ på MS-Windows platformen, men kernen af
> applikationen ville jeg holde som ISO C++.

Det er sådan set ikke relevant for spørgsmålet.

> Alternativet C++/CLI ville være at vælge at C++ ikke skulle være noget
> væsentligt sprog på .NET platformen, hvilket ville være uheldig al den stund
> at Microsoft har bestemt at .NET platformen er en væsentlig del af deres
> strategi.

Men problemet er netop at det ikke længere er C++

> Men truende skyer over ISO C++ - nej bestemt ikke som jeg ser det.

Jo, for Microsofts strategi er at få afskaffet ISO C++

/b

---

"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:43bdaec1$0$174$edfadb0f@dread11.news.tele.dk...

[8<8<8<]
> Men bør "vi" så ikke bede dem om at kaldet det for noget andet end C++?

Jo for min skyld gerne. Men det er vel ikke meget anderledes end da
Microsoft kaldte forgængeren for "Managed C++".
Og jeg kunne da bestemt godt ønske mig at Microsoft i deres dokumentation
klart skelnede mellem ISO C++ og C++/CLI.

[8<8<8<]
> Det er sådan set ikke relevant for spørgsmålet.

Det kan du have ret i.

[8<8<8<]
> Men problemet er netop at det ikke længere er C++

Nej, det er ikke C++ - det er C++/CLI.
Det er et bud på hvordan man kan kombinere ISO C++ kode med kode der
udnytter CLR.

Jeg har prøvet skrive noget "business logic" i ISO C++ og lave en .NET
WinForm GUI med C++/CLI.
Det er ikke perfekt, men det virkede rimeligt fornuftigt og jeg skulle ikke
gøre noget ved min "businness logic" for at få det til at køre.

>
>> Men truende skyer over ISO C++ - nej bestemt ikke som jeg ser det.
>
> Jo, for Microsofts strategi er at få afskaffet ISO C++

Det tror jeg er langt mindre Microsoft strategi idag end det var for 10 år
siden.
Prøv blot at se hvilke forbedringer der faktisk er blevet lavet i de senere
versioner af deres native C++ compiler i forhold til overholdelse af ISO C++
Standarden - den er tæt på state-of-art.

Venlig hilsen

Mogens Hansen

---

Michael Rasmussen wrote:
> Har netop modtaget nedenstående mail, der åbner for truende
> fremtidsudsigter for ISO C++. Hvordan er jeres holdning til nedenstående?

> JTC1 N8037 has arrived at BSI -- that is the notice that Ecma is
> submitting its C++/CLI standard for fast track approval by ISO/IEC. The
> first stage of the process is a 30-day review period to determine if
> there are any contradictions with existing JTC1, ISO, or IEC standards.
> The deadline for pointing out such contradictions to the JTC1
> secretariat is January 23rd. (You would think they might give us a bit
> of extra time with all the holidays around now!)
>
> The UK C++ panel intends to raise an objection on the grounds that there
> is indeed a contradiction -- with the existing C++ standard. There is
> substantial material in this FDIS which is so different from standard
> C++ that we think Ecma should withdraw the document until it can find a
> new name for its language.

Jeg er faktisk meget enig med englænderne.

Managed C++ (både i 7.0/7.1 og i 8.0 implementationen) er
grundliggende forskelligt fra C++.

Det er ikke bare de sædvanelige 7000 platform/compiler
specifikke funktioner/klasser - det er selve sproget
som er anderledes.

Det er ret vigtigt at få forskellen mellem C++ og
Microsofts sprog understreget.

Generelt mner jeg at erfaringerne med 2 versioner
af standarden for det samme er ret dårlige.

Så selvom det er lidt plat så er forslaget om
et andet navn for sproget måske ikke helt
malplaceret.

Jeg kan iøvrigt ikke se det store behov for den
standardisering. For mens .NET er en kæmpe success,
så er managed C++ ikke blevet særligt udbredt.

Arne

---

Mange af udvidelserne i C++/CLI virker praktiske, veldesignede og
generelle, og jeg tror de kan være med til at puste nyt liv til C++,
hvis de finder vej til ISO C++ standarden.

Jeg er ikke bange for størrelsen, C++ bliver aldrig et minimal sprog
for purister. Det er et praktisk flerparadigmesprog, hvor man kun
bruger (og sætter sig ind i) en delmængde.

At ændringerne er store betyder ikke nødvendigvis at der er behov for
et nyt navn. Ændringerne mellem det C++ jeg i sin tid lærte (hvor
"overload" var et keyword), og det nuværende C++ med RTTI, exceptions,
templates og STL er også betragtelige.

At Microsoft sætter en ære i at vildlede kunderne er kedeligt, men det
har de altså gjort systematisk de sidste 20 år, og det gider jeg ikke
hidse mig op over mere. En myg stikker, en hugorm hugger, og
Microsoft manipulerer. Sådan er verden nu engang skruet sammen.

---

Per Abrahamsen wrote:
> Mange af udvidelserne i C++/CLI virker praktiske, veldesignede og
> generelle, og jeg tror de kan være med til at puste nyt liv til C++,
> hvis de finder vej til ISO C++ standarden.

Det er højst tvivlsomt at ret mange features vil finde vej ind i ISO C++.

Her er et par links til info om C++0x:

http://www.artima.com/cppsource/cpp0x.html

http://erfa.teknologisk.dk/erfavc/download/36mode2005/next_cpp.pdf

Så vidt jeg kan bedømme er der stort set ingen features, som vil komme
fra C++/CLI ind i ISO C++. Og hvad måske er værre, de to vil have
forskellige og inkompatible måder at gøre det samme på (GC, for exempel).

-Thorsten

---

Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:

> Så vidt jeg kan bedømme er der stort set ingen features, som vil komme
> fra C++/CLI ind i ISO C++.

Det kan nå at ændre sig i næste standard, hvor C++/CLI vil være
"existing practice".

> Og hvad måske er værre, de to vil have forskellige og inkompatible
> måder at gøre det samme på (GC, for exempel).

Det er kedeligt. Jeg ville have troet at Herb Sutter og resten af
kommiteerne ville gøre en del for at undgå det. Det vil skade begge
sprog, ligesom C99 kommiteens ignorering af C++ har skadet både C og
C++.

---

On Thu, 05 Jan 2006 23:02:56 +0100, Michael Rasmussen wrote:

> Hej alle,
>
> Har netop modtaget nedenstående mail, der åbner for truende
> fremtidsudsigter for ISO C++. Hvordan er jeres holdning til nedenstående?
>
Modtog i går UK's officielle klage til ECMA fra Lois. Da det er en
længere tekst, vil jeg ikke lave copy/paste til NG. Hvis i har interesse
i at læse den, kan den hentes her:
http://www.datanom.net/c++/Objection_to_Fast-track_Ballot_ECMA-372_in_JTC1_N8037.pdf

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917