jpb@iris85.biosym.com (Jan Bielawski) writes:

>Operator -> can be overloaded, operator . cannot.  The distinction
>between . and -> provides an extra safety check from the compiler
>in case where the programmer thinks there is an overloaded ->
>but really there isn't.

This is no justification for the distinction. Surely if the '.'
operator is used by the compiler to conceptually access, whether
the implementation is direct access or dereference, then the
'->' operator is free to be defined and overloaded as you like.

>  (If operator->() is missing, the compiler
>expects p.member, so p->member becomes a _compilation_ error.
>I think this has a potential for bug-hunt time savings).
>Equivalently, if p is a class instance, having only the . operator
>would make the statement  p.m  ambiguous with overloaded . present:
>is it  (operator.()( p )).m  or just plain  p.m ?  The only solution
>would be to change the semantics of operator.() -- which may or
>may not be a good idea, I don't know.

><Sections 7 makes the bold claim "C is not applicable for large scale
><production".

>Yeah, I also thought this was rather silly...

OK, I'll explain it again. It does not say that you can't use C for
large scale production. It merely suggests that in large environments
you need better support for design, shared activities, and maintenance
than C gives you. We need better language support for these considerations,
which are considerations in large scale production. Even Bjarne
Stroustrup says that is a strong reason he developed C++, to get
the strengths that Simula had in these areas into C.
--
Ian Joyner           |"for when lenity and cruelty play   |All opinions are
Unisys (ACUS)        | for a kingdom, the gentler gamester|personal and are not
ian@syacus.acus.oz.au| is the soonest winner" W.S. Henry V|Unisys official comment

In article <NEWTNews.12503.798700128.muzaffer@omer1.smixedsignal.com> muzaffer@smixedsignal.com writes:
<
<I agree that the distinction between '.' and '->' for member access is
<unneccessary. I haven't investigated this very carefully but I don't
<know any case where the compiler can't infer the right method. Knowing
<C as it is, I guess it is possible that there are such cases though (any
<takers?).

Operator -> can be overloaded, operator . cannot.  The distinction
between . and -> provides an extra safety check from the compiler
in case where the programmer thinks there is an overloaded ->
but really there isn't.  (If operator->() is missing, the compiler
expects p.member, so p->member becomes a _compilation_ error.
I think this has a potential for bug-hunt time savings).
Equivalently, if p is a class instance, having only the . operator
would make the statement  p.m  ambiguous with overloaded . present:
is it  (operator.()( p )).m  or just plain  p.m ?  The only solution
would be to change the semantics of operator.() -- which may or
may not be a good idea, I don't know.

<Sections 7 makes the bold claim "C is not applicable for large scale
<production".

Yeah, I also thought this was rather silly...
--
Jan Bielawski    |\      _,,,---,,_
Biosym Technologies   /,`.-'`'    -.  ;-;;,_
San Diego, CA   |,4-  ) )-,_. ,\ (  `'-'   | ph.: (619) 458-9990
jpb@biosym.com  '---''(_/--'  `-'\_)        fL   | fax: (619) 458-0136
--
****************************************************************************
* DISCLAIMER: Unless indicated otherwise, everything in this note is       *
* personal opinion, not an official statement of Biosym Technologies, Inc. *
****************************************************************************

muzaffer@smixedsignal.com writes:


>hi,

>I am not a "language lawyer"; I am a practitioner doing development
>in a couple of different application domains. My machine hosts three
>different OSs and I've had installations of various version scheme,
>BETA, dylan, eiffel at one time or another on it too. Having implemented
>a FixedPointNumber class and used it to instantiate a template FIR class in
>addition to double leaves me wondering about the questions like "is
>ComplexNumber a useful class ?" I try to keep up with the current
>developments and keep myself informed. Reading "A critique
>of C++" [1] is the result of such efforts. The following are my humble
>comments and thoughts about this work.

Thank you, its nice to get some feedback.

>First of all I should say that I found this work useful. It points to
>some important issues but in general my feeling is that it is looking
>for a solution which "whitens your teeth while you sleep" to
>programming :-).

Not really. I am concerned with the economical production of quality
software.

 I find claims like "... more importantly, the
>compiler should check that the programmers [sic] expression of the
>system is complete, valid and consistent." worrisome.

Well let me put this back into its context:

"A language definition should enable the development of integrated
automated tools to support software development.  For example, browsers,
editors and debuggers.  The compiler is another such tool.  The role of
a compiler is twofold.  Firstly, to generate code for the target
machine.  The role of the machine is to execute the produced programs.
A compiler has to check that a program conforms to the language syntax
and grammar, so it can understand the program in order to translate it
into an executable form.  Secondly, and more importantly, the compiler
should check that the programmers expression of the system is complete,
valid and consistent.  A compiler should perform semantics checking.
This is checking that a program is internally consistent.  Generating a
system that has detectable inconsistencies is pointless. "

This is the current state of language/compiler technology. Nothing
pie in the sky. Everyone is familliar with compilers that make
sure the program is complete, ie no undefined variables. validity
and consistency can be done by techniques such as type checking.

 To expect a
>compiler to check that the expression of the system is complete and valid
>requires that the compiler understands the system requirements (ie
>problem domain) and can check that I expressed it completely in which
>case I don't see why I should bother writing the code.

Right. Perhaps my expression of this confused you a little. I hope the
above explains better what I had in mind. Of course there is no
way computer technology can second guess you.

> The author says
>that "this critique criticises C++ in its own right, without comparison
>to other languages." but we see many occasions where this is done (ie pg
>6, pr (paragraph) 2).

Well in some situations I wanted to show that the alternative has been
implemented and works well. But the critique is really not a language
comparison overall.

>Section 3.2 pr 2 asks "But what do you look for in the case of '= 0' ?".
>One answer is the regular expression ').*=.*0'. You can search for
>this in any decent editor. I haven't read the grammar but if values
>other than 0 are valid for pure virtual functions, any programmer
>who uses 13 (or any other non-zero value) should be taken out and
>shot to save him the misery of his own stupidity :-|

Well I'm saying that you need to know what to look up in the index
of a book. Unless you have the book online, an editor isn't going
to help much. Bjarne Stroustrup also does not like the '=0' much
either from his Design and Evolution of C++. But he decided this was
easier to get in than another keyword.

>Section 3.11 pr 4 says " if a temporary is created, a constructor is
>called as a side effect, which can change the state of the object.
>Different C++ implementations could therefore return different results
>for the same code". I don't see how this conclusion can be reached.
>Other than some extra calls, the contents of the resulting object
>should be the same regardless a temporary is created or not.

Well the section explains, it is the ARM that is saying this is
implementation dependent. Implementation dependent means the result
is a matter of interpretation.

>Section 3.22 complains about unnecessary recompilations when private
>parts of the classes are changed. Any C++ user worth his salt knows
>why this is done and what to do if a different scheme is required (
>see [2], envelope/letter idiom)

All I am saying is that the private parts should not be in the
class header at all. It doesn't help knowing that this will
cause a complete recompilation. The fact is it is not necessary.

>Section 3.25 mentions that a new linker/tool is missing for type-safe
>linkage. I definitely don't volunteer for such a project, FYI :-)

And I was looking forward to your efforts :-)

>Section 3.30 claims that " C is tightly couple to the Unix environment".
>The people who use C in all kinds of OSs and environments (including
>8 bit embedded micro-controllers) would find this claim weak.

You're right. I am a little terse in this explanation. In a future
edition, (I am not volunteering that I will do such a project :-))
I would probably need to say more about the environments that
C is suited for, and make some comments about why C is not
a universally applicable language.

>In section 4 pr 3, it says "for example if someone sneezes, we often
>"bless" them". Actually we don't have that authority. At least in my
>religion we ask the blessing from the Creator.

Sounds like social interaction to me?

>In section 6. Generic C criticisms, it says "Anyone who reads the C++
>ARM will realize just how poorly defined the language is". I guess this
>is why we have a ANSI C++ standards comitte (sp?)

I guess so. One thing that struck me about Bjarne's frankness in
Design and Evolution of C++, is that C++ is hardly a finished
language. It has many areas that must be researched and fixed
up. Do we really have time to wait? Are all these areas actually
fixable?

>section 6.4 asks "is void* the C equivalent of an oxymoron ?" I don't
>think so. A "void*" is just a pointer to an object of which you don't
>know the type. You can either figure out the type yourself or make
>an assumption. It is a dangerous construct though.

>Section 6.11 complains about case distinction and the only non-C looking
>sample in the paper uses a mixed case coding. It looks like that you
>have to type INTEGER in upper case. C never forces you to touch the
>shift key but obviously this language does.

Um, where is INTEGER in this section? Whether you type INTEGER,
Integer, integer, or inTeGer, should be stylistic. They should
all be reconised as the same thing. After all they are all
spelt with the same letters.

>Sections 7 makes the bold claim "C is not applicable for large scale
>production". I don't know the which definition of "large scale production"
>is used here but having observed systems with MLOCs in C, I think some
>restraint is necessary before making such claims. One can argue that
>"C is not the ideal language for large scale production" but it is
>definitely applicable because it has been.

And I go onto say, "Hence C++'s attempt to improve it." Really that
comment is based on the fact that OO exists because it is a way
of organising large projects. Of course you can use C to do
large scale projects if you want, but the OO paradigm gives you
better ways to organise things. Bjarne also states this in
the Design and Evolution of C++. Just he is more tactful about
the deficiencies of C.

>references:
>[1] Ian Joyner, C++?? A critique of C++ 2nd edition
>[2] James Coplien, Advanced C++ programming styles and idioms.

>PS: all the references to pronouns him/his/he should be understood
>as him or her, his or her, he or she respectively. As english doesn't
>have gender neutral pronouns such misuse is utilized to preserve the
>clarity of content.

OK. Thanks for your comments by the way. I hope I have cleared things
up a bit. Your comments will be useful if I ever get any time to
do a third edition.
--
Ian Joyner           |"for when lenity and cruelty play   |All opinions are
Unisys (ACUS)        | for a kingdom, the gentler gamester|personal and are not
ian@syacus.acus.oz.au| is the soonest winner" W.S. Henry V|Unisys official comment

In article <NEWTNews.12503.798700128.muzaffer@omer1.smixedsignal.com>,
muzaffer@smixedsignal.com wrote:

>I agree that the distinction between '.' and '->' for member access is
>unneccessary. I haven't investigated this very carefully but I don't
>know any case where the compiler can't infer the right method.
It is possible for both to be used on the same member if someone is
overriding operator-> (eg: "smart pointers" with "->" mandated for all
application code and the ".' used inside some classes).

> I also agree that redefining a non-virtual function in a derived
>class should give at least a warning
It does, depending on your compiler (eg: BC4.5)

because in my experience this is
>almost never what I want to do.
>
>Section 3.30 claims that " C is tightly couple to the Unix environment".
Those of us programming the Mac in c++ who aren't even given the CHOICE of
Eiffel find this claim similarly weak!

Andy Dent, Product Architect, A.D. Software Western Australia
Authors of the OOFILE cross-platform ODBMS framework
ftp://perth.highway1.com.au/pub/adsoftware/
http://www.highway1.com.au/adsoftware/

hi,

I am not a "language lawyer"; I am a practitioner doing development
in a couple of different application domains. My machine hosts three
different OSs and I've had installations of various version scheme,
BETA, dylan, eiffel at one time or another on it too. Having implemented
a FixedPointNumber class and used it to instantiate a template FIR class in
addition to double leaves me wondering about the questions like "is
ComplexNumber a useful class ?" I try to keep up with the current
developments and keep myself informed. Reading "A critique
of C++" [1] is the result of such efforts. The following are my humble
comments and thoughts about this work.

First of all I should say that I found this work useful. It points to
some important issues but in general my feeling is that it is looking
for a solution which "whitens your teeth while you sleep" to
programming :-). I find claims like "... more importantly, the
compiler should check that the programmers [sic] expression of the
system is complete, valid and consistent." worrisome. To expect a
compiler to check that the expression of the system is complete and valid
requires that the compiler understands the system requirements (ie
problem domain) and can check that I expressed it completely in which
case I don't see why I should bother writing the code. The author says
that "this critique criticises C++ in its own right, without comparison
to other languages." but we see many occasions where this is done (ie pg
6, pr (paragraph) 2).

I agree that the distinction between '.' and '->' for member access is
unneccessary. I haven't investigated this very carefully but I don't
know any case where the compiler can't infer the right method. Knowing
C as it is, I guess it is possible that there are such cases though (any
takers?). I also agree that redefining a non-virtual function in a derived
class should give at least a warning because in my experience this is
almost never what I want to do.

Most of the issues which are related to tools can be (and are) solved
by existing C++ environments, IF you have a US$20,000 machine with 64M
to run them. Literate programming tools also supply some of the
editor/compiler integration but for some reason they are not very
wide-spread.

Section 3.2 pr 2 asks "But what do you look for in the case of '= 0' ?".
One answer is the regular expression ').*=.*0'. You can search for
this in any decent editor. I haven't read the grammar but if values
other than 0 are valid for pure virtual functions, any programmer
who uses 13 (or any other non-zero value) should be taken out and
shot to save him the misery of his own stupidity :-|

Section 3.11 pr 4 says " if a temporary is created, a constructor is
called as a side effect, which can change the state of the object.
Different C++ implementations could therefore return different results
for the same code". I don't see how this conclusion can be reached.
Other than some extra calls, the contents of the resulting object
should be the same regardless a temporary is created or not.

Section 3.22 complains about unnecessary recompilations when private
parts of the classes are changed. Any C++ user worth his salt knows
why this is done and what to do if a different scheme is required (
see [2], envelope/letter idiom)

Section 3.25 mentions that a new linker/tool is missing for type-safe
linkage. I definitely don't volunteer for such a project, FYI :-)

Section 3.30 claims that " C is tightly couple to the Unix environment".
The people who use C in all kinds of OSs and environments (including
8 bit embedded micro-controllers) would find this claim weak.

In section 4 pr 3, it says "for example if someone sneezes, we often
"bless" them". Actually we don't have that authority. At least in my
religion we ask the blessing from the Creator.

In section 6. Generic C criticisms, it says "Anyone who reads the C++
ARM will realize just how poorly defined the language is". I guess this
is why we have a ANSI C++ standards comitte (sp?)

section 6.4 asks "is void* the C equivalent of an oxymoron ?" I don't
think so. A "void*" is just a pointer to an object of which you don't
know the type. You can either figure out the type yourself or make
an assumption. It is a dangerous construct though.

Section 6.11 complains about case distinction and the only non-C looking
sample in the paper uses a mixed case coding. It looks like that you
have to type INTEGER in upper case. C never forces you to touch the
shift key but obviously this language does.

Sections 7 makes the bold claim "C is not applicable for large scale
production". I don't know the which definition of "large scale production"
is used here but having observed systems with MLOCs in C, I think some
restraint is necessary before making such claims. One can argue that
"C is not the ideal language for large scale production" but it is
definitely applicable because it has been.

Muzaffer

standard disclaimer

references:
[1] Ian Joyner, C++?? A critique of C++ 2nd edition
[2] James Coplien, Advanced C++ programming styles and idioms.

PS: all the references to pronouns him/his/he should be understood
as him or her, his or her, he or she respectively. As english doesn't
have gender neutral pronouns such misuse is utilized to preserve the
clarity of content.