Board index » cppbuilder » An interesting reading - objection to the fast track C/C++

An interesting reading - objection to the fast track C/C++


2006-01-31 04:54:57 AM
cppbuilder104
public.research.att.com/~bs/uk-objections.pdf
 
 

Re:An interesting reading - objection to the fast track C/C++

Alex Bakaev [TeamB] wrote:
Quote
public.research.att.com/~bs/uk-objections.pdf
I'd be interested in hearing how much confusion the residents of this
NG believe this new standard going out with the name C++/CLI would
cause - given that the document has completely bypassed the C++ working
group and their parent sub-committee, and is almost entirely unrelated
to work in that group.
I have already seen at least one poster here quote from this as-if it
was the new C++ standard who I hoped would know better (names spared to
protect the guilty ;? so I believe it is a real issue - as do other
members of the panel.
I happen to believe the ECMA committee have delivered an excellent
piece of work, given the constraints CLR places on a language
implementation.
I very much like the fact this new language swallows most conforming
C++ programs as-is. I just have a hard time reconciling that also
replaces standard C++ idioms (like RAII) with new CLR idioms
(try/finally, finalizers) with the name C++. (The guarantees
underpinning RAII are undermined, so it can no longer be relied on.)
--
AlisdairM(TeamB)
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
Alex Bakaev [TeamB] wrote:

>public.research.att.com/~bs/uk-objections.pdf

I'd be interested in hearing how much confusion the residents of this
NG believe this new standard going out with the name C++/CLI would
cause
I think there will be people who see it as C++ on .NET, i.e. they
expect a fully compliant C++. The fact that C++/CLI is close, but not
quite the same, might cause confusion alright (the fact that RAII might
not work properly looks like a serious problem).
So perhaps a different name could help prevent the confusion. I will
refrain from proposing a name, though. Too hot a subject. <g>
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Why yes-- a bulletproof vest." - James Rodges, {*word*190}er, on his final
request before the firing squad.
 

{smallsort}

Re:An interesting reading - objection to the fast track C/C++

Andre Kaufmann wrote:
Quote
Quote:

"The for each loop syntax (remember "for each" is
a single keyword) only works on containers from the
C++/CLI library which implement certain"

:End of Quote


What about:

std::vector<string>list;
for each(string s in list) { cout << s << endl; }

Compiles without any problems in native C++
Huh? It does? In which version did you test this? It does not compile,
let alone do anything useful, in C++Builder 2006.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"The only difference between me and a madman is that I'm not mad."
- Salvador Dali (1904-1989)
 

Re:An interesting reading - objection to the fast track C/C++

Andre Kaufmann wrote:
Quote
Alex Bakaev [TeamB] wrote:
>public.research.att.com/~bs/uk-objections.pdf

While I think BS is a very notable person as the creator of C++, he
should on the other side respect the efforts of other people
integrating the managed world in C++ by testing his samples and
verifying his accusations before he states them in a public document.
Please note that Bjarne Stroustrup is not the author of the document,
he is merely drawing attention to a document from the British Standards
Institute C++ panel, objecting to the fast track adoption of this ECMA
standard by ISO under its current name (bypassing the existing ISO
working group for the C++ language)
Quote
What about:

std::vector<string>list;
for each(string s in list) { cout << s << endl; }

Compiles without any problems in native C++
But is that the expected behaviour from a pure conforming C++/CLI
platform? I believe you are relying on extensions in STL.NET, library
features that are NOT a part of the ECMA proposal which delibrately
avoids libraries in this standard.
Quote
I will never understand why the C++ committee is so restrictive about
new keywords.
That is because you are not trying to support the code of everyone who
ever wrote a line of C++, only the large subset that makes sense to
you. I do indeed have to support headers written in C using C++
keywords, and it is not fun. Library problems can usually be worked
around, but stealing identifiers as keywords is a serious break.
Quote
Why is there no "override" keyword in C++. (New keyword introduced in
C++/CLI and is also usable in native C++) ?
I am currently working on a paper addressing that very issue, and I'd
sure another TeamB member is thinking of giving me a swify
kick-up-the-pants to get a move on as I write!
However, there is no guarantee the approach approrpiate for ISO C++
would match the specific constraints imposed by .NET, with a competing
set of overload rules.
Quote
I also cannot follow his statements about the language name and the
new keywords:

a) What's the difference between keywords introduced with __newkeyword
compared to newkeyword. Yes the first is standard conformant.
But the code is not portable in both variants.
__newkeyword was always reserved to the implementation, so no
conforming code will be using that keyword as an identifier today.
Yes, you would still need a new compiler to use the new keyword, but
you would not break existing code that happened to use the name you
chose for its own (valid) purposes. This is the general version of the
argument you raised with abstract earlier.
Quote
b) A C++ compiler is not a full conformant C compiler.
Yet he can compile most of the C code. The same applies
to a C++/CLI compiler. A C++ programmer should be able
to distinguish the variants.
We already have a hard time explaining "C++ is not C". Do you want to
compound that with "C++/CLI is not C++"?
Quote
But I wouldn't have any problem with a new name like:
CLIC++.
Yes, that is the point <g>
Quote
To sum it up I would state just the contrary as BS. C++/CLI is not
more complex because it has introduced new keywords, but C++ is so
hard to handle because it's missing some essentially needed keywords
and modern language constructs.
You are right/wrong on both counts <g>
New keywords/features will make C++ an easier language to use, and the
ISO committee has been hard at work doing exactly that for several
years now.
New keywords/features do make the language significantly more complex
to implement, and the complexity of things that can be done with the
language, intentionaly or not, is the geometric combination of all the
language features.
--
AlisdairM(TeamB and BSI panel member)
 

Re:An interesting reading - objection to the fast track C/C++

Rudy Velthuis [TeamB] wrote:
Quote
Huh? It does? In which version did you test this? It does not compile,
let alone do anything useful, in C++Builder 2006.
It is C++/CLI code, so unlikely to compile outside VisualC++ 8.0 at the
moment <g>
I believe it also relies on properties of the iterators in STL.NET that
are a further extension of the MS platform, and not part of the ECMA
standard.
--
AlisdairM(TeamB)
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
Rudy Velthuis [TeamB] wrote:

>Huh? It does? In which version did you test this? It does not
>compile, let alone do anything useful, in C++Builder 2006.

It is C++/CLI code, so unlikely to compile outside VisualC++ 8.0 at
the moment <g>
Exactly. But he said it was native C++. Well, no, it isn't.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Opportunities multiply as they are seized." -- Sun Tzu
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
I believe it also relies on properties of the iterators in STL.NET
that are a further extension of the MS platform, and not part of the
ECMA standard.
I know how it works. Delphi can do the same (observing the same
provisos -- i.e. the class must provide GetEnumerator and IEnumerator
must be implemented). It is not native C++, however.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"The concept is interesting and well-formed, but in order to earn
better
than a 'C', the idea must be feasible."
-- A Yale University management professor in response to student Fred
Smith's paper proposing reliable overnight delivery service (Smith
went on to found Federal Express Corp.)
 

Re:An interesting reading - objection to the fast track C/C++

Alex Bakaev [TeamB] wrote:
Quote
public.research.att.com/~bs/uk-objections.pdf
While I think BS is a very notable person as the creator of C++, he
should on the other side respect the efforts of other people integrating
the managed world in C++ by testing his samples and verifying his
accusations before he states them in a public document.
May be that he has tested an older beta version of C++/CLI, but then he
should delete the document or correct it.
At the first read I found several, as I would interpret it, wrong
statements:
E.g.:
a)
Quote:
"The for each loop syntax (remember "for each" is
a single keyword) only works on containers from the
C++/CLI library which implement certain"
:End of Quote
What about:
std::vector<string>list;
for each(string s in list) { cout << s << endl; }
Compiles without any problems in native C++
His example about the interface and derived class implementing functions
with the same name but different signature does not compile in C++/CLI.
Either the function must be declared as public or must be "sealed".
Yes another keyword.
I will never understand why the C++ committee is so restrictive about
new keywords.
Example:
Why use "= 0" for abstract functions ? I know the story, but a abstract
keyword could have been introduced later as an alternative.
Why is there no "override" keyword in C++. (New keyword introduced in
C++/CLI and is also usable in native C++) ?
So many times I just searched in my complex class hierarchy for errors,
which simply have been caused by slight changes in the interfaces. With
the override keyword I can specify the method to be an overridden method
and the compilers throws an error if it does not fit to the base class
definition.
I also cannot follow his statements about the language name and the new
keywords:
a) What's the difference between keywords introduced with __newkeyword
compared to newkeyword. Yes the first is standard conformant.
But the code is not portable in both variants.
The first has been called managed C++ and was a closed standard,
which couldn't be implemented by other compiler vendors.
Which would have BCB restricted to be a native compiler. So
a future version could not compile or call (easily) managed code.
b) A C++ compiler is not a full conformant C compiler.
Yet he can compile most of the C code. The same applies
to a C++/CLI compiler. A C++ programmer should be able
to distinguish the variants.
But I wouldn't have any problem with a new name like:
CLIC++.
To sum it up I would state just the contrary as BS. C++/CLI is not more
complex because it has introduced new keywords, but C++ is so hard to
handle because it's missing some essentially needed keywords and modern
language constructs. I don't speak of GC and the other .NET related
keywords introduced in C++/CLI. But of such simple keywords like
"abstract" and "override".
Or specifying the size of an enum or ......
Andre
 

Re:An interesting reading - objection to the fast track C/C++

Rudy Velthuis [TeamB] wrote:
Quote
Exactly. But he said it was native C++. Well, no, it isn't.
He said the code compiled in MS implementation of C++/CLI, implying
that it should work in all C++/CLI implementations. I do not believe
this was claimed to be conforming ISO C++ code (yet!)
There are proposals in front of the evolution group to do something
similar! I don't believe they involve a new keyword though - a
'simple' extension of for syntax should suffice.
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1868.html
--
AlisdairM(TeamB)
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
He said the code compiled in MS implementation of C++/CLI, implying
that it should work in all C++/CLI implementations.
Er... did I misread:
<<
What about:
std::vector<string>list;
for each(string s in list) { cout << s << endl; }
Compiles without any problems in native C++
Quote
>
I either misread "native C++", or I totally misunderstand. If with
"native C++" standard C++ is meant, it is wrong. Or does VC++ contain
C++/CLI idioms in the Win32 native version as well? Or what am I
missing?
--
Rudy Velthuis [TeamB] rvelthuis.de/
"When ideas fail, words come in very handy."
- Goethe (1749-1832)
 

Re:An interesting reading - objection to the fast track C/C++

Rudy Velthuis [TeamB] wrote:
Quote
Er... did I misread:
No, I did - my bad :(
I guess that shows the risk of confusion is real :(
--
AlisdairM(TeamB)
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
Rudy Velthuis [TeamB] wrote:

>Er... did I misread:

No, I did - my bad :(

I guess that shows the risk of confusion is real :(
Indeed.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"To the Honourable Member opposite I say, when he goes home to night,
may his mother run out from under the porch and bark at him."
-- John G. Diefenbaker
 

Re:An interesting reading - objection to the fast track C/C++

Good link. Instead of the wild railing commonly seen in articles on the
Internet, their arguments are presented profesisonally, even with a bit of
understatement.
It seemed obvious that the C++/CLI conflicting and confusing name would be
changed but until now nobody seems to have made a serious effort to do that.
It is good that someone now calls for it.
. Ed
Quote
Alex Bakaev wrote in message
news: XXXX@XXXXX.COM ...

public.research.att.com/~bs/uk-objections.pdf
 

Re:An interesting reading - objection to the fast track C/C++

Alisdair Meredith[TeamB] wrote:
Quote
It is C++/CLI code, so unlikely to compile outside VisualC++ 8.0 at the
moment <g>

I believe it also relies on properties of the iterators in STL.NET that
are a further extension of the MS platform, and not part of the ECMA
standard.

You have your first example of confusion.
.a