In article <Cun8t3.DAw@boi.hp.com> flanagin@boi.hp.com (George Flanagin) writes:
|Garry Wiegand (garry@autodesk.com) wrote:
|
|: All of in favor of renaming this the "Ronald F. Guilmette Memorial
|: Newsgroup" say "aye".
|
|I would hate to draw the ire of RFG, but I tend to agree with GW.
|More so than in most of the other groups to which I subscribe, I
|get the feeling that csc++ is a minor league for alt.flame.

Well, I'll disagree and take RFG's side.  While I seldom agree with his
positions, and often dislike how he states them, I find them interesting
and intelligent enough often enough not to dismiss them as purely flame bait.
Without his opposing opinions, I would fear that this forum would
disintegrate into a purely saccharine committee lovefest.

Perhaps more distasteful to my mind, is the number of postings on this
forum that simply vacuously support existing "features" of the language
as being "right" simply because they "are".  Such postings do little or nothing
towards helping understand the issues.

In article <9408111620.AA03429@tdat.ElSegundoCA.NCR.COM>
swf@ElSegundoCA.NCR.COM (Stan Friesen) writes:

|> In article <KANZE.94Aug10184342@slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:

|> |> I think that amongst people actually developing programs, ISO 8859 (or
|> |> the IBM PC code) is already the standard.  Things happen fast in our
|> |> world, and it has been years since the quoted article appeared.

|> Indeed so, the standard X11r4 fonts are all ISO 8859.
|> Since X11 is now up to r6, I think that, combined with PC's
|> makes ISO 8859 one of the most predominant chracter sets today.

Just to clarify: the IBM PC code is *not* the same as ISO 8859/1.  It
does, however, have many of the same characters, and in particular, it
contains both the various accents *and* the full 7 bit ASCII.

In this sense, finding new solutions for terminals which only support
the local variants of ISO 646 seems no longer an important problem.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

Garry Wiegand (garry@autodesk.com) wrote:

: All of in favor of renaming this the "Ronald F. Guilmette Memorial
: Newsgroup" say "aye".

I would hate to draw the ire of RFG, but I tend to agree with GW.
More so than in most of the other groups to which I subscribe, I
get the feeling that csc++ is a minor league for alt.flame.


george

George Flanagin     <- My name
flanagin@boi.hp.com <- repository for hate & flame mail, etc.
116.13W, 43.34N     <- close enough if you buy from Kim Jong-Il

>>>>> "Olaf" == Olaf Weber <olaf@cwi.nl> writes:

Olaf> No doubt you'd call them prejudiced, but in their article in
Olaf> EUUG Notices (Vol 9, No 2 Summer 1989, pp 15-18) Simonsen and
Olaf> Stroustrup write:

What they wrote was correct in 1989.

EUUG> In many countries in Europe, South America and Africa the
EUUG> national character set standard is a version of the ISO 646-1983
EUUG> international standard for 7-bit character sets.  ASCII (ANSI
EUUG> X3.4-1968) is the national version of ISO 646 in the USA.  It is
EUUG> the impression of the authors that ASCII and the national
EUUG> standard competes bravely from country to country for being the
EUUG> national industry standard.  Also, on IBM mainframes there are
EUUG> national EBCDIC implementations very close in character
EUUG> repetoire to the formal national standards.  In some areas, such
EUUG> a Scandinavia, the national character sets are predominant both
EUUG> the in the 7-bit and the EBCDIC world.

Might be correct (I would like to see numbers, though), but it ignores
the PC world (DOS, Mac, etc.) which has always been 8-bit.

EUUG> In other countries, such
EUUG> as the Netherlands, you mostly see ASCII.  There are some new
EUUG> international standards based on 8-bit characters (the ISO
EUUG> 8859/1/2 Latin character sets and the ISO 6937/2 Videotex
EUUG> standard) which includes both ASCII and the various national
EUUG> characters, but it will take years, if not decades, for these
EUUG> new offcial standards to become industry standards and for 7-bit
EUUG> equipment to completely lose its importance.

Again correct, it _took_ years (not decades) for 8-bit character sets
to become dominating outside the PC world.  Bigraphs might have
allowed some people to delay the transition to 8-bit character sets a
few years, had they been available in 1989.

Does anyone actually have numbers for how much software development is
done using the national variants of EBCDIC or ISO-646 now?

Olaf> Just to make the readability point again, I've used ISO 8859
Olaf> Latin-1 (surely your systems supports that) to show what the
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:-)

Olaf> example in the ARM, page 371 looks like in DIN 66 003 (German
Olaf> national set):


 int main(int argc, char* argv      )

  if (argc<1        *argv   1   =='   0') return 0;
  printf("Hello, %s   n", argv   1   );


Olaf> with trigraphs:

 int main(int argc, char* argv??(??))
 ??<
  if (argc<1 ??!??! *argv??(1??)=='??/0') return 0;
  printf("Hello, %s??/n", argv??(1??));
 ??>

Olaf> and with bigraphs where possible:

 int main(int argc, char* argv<::>)
 <%
  if (argc<1 or *argv<:1:>=='??/0') return 0;
  printf("Hello, %s??/n", argv<:1:>);
 %>

I prefer the first.  In that example, _I_ will have to learn a new
weird notation, but if someone else reads it using ASCII-capable
equipment it will look like normal C++.  The second example doesn't
add anything in terms of readability, but at least it can easily be
transfered into normal C++.  In the third example you are stuck with a
piece of code that is unreadable to most C++ programmers.

In article <CuB8GB.960@cwi.nl>, olaf@cwi.nl (Olaf Weber) writes:

> ... in their article in EUUG Notices (Vol 9, No 2 Summer 1989, pp
> 15-18) Simonsen and Stroustrup write:

For the record, the article's title is "A European Representation for
ISO C".  The history of the proposal for C++ can be traced through the
ANSI updates in older issues of the C++ Report [3(2), 3(6), 4(1)].
The final version of the proposal was reached in June 1991, and it
seems to have been accepted at that time.  Neither the SGI C++
compiler on our systems (Cfront 3.0.1 derived, dated 02/03/92), nor
g++ 2.6.0 implement bigraphs.  Is there a compiler that does?

-- Olaf Weber

In article <KANZE.94Aug10184342@slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
|> |>  ASCII.  There are some new international standards based on
|> |>  8-bit characters (the ISO 8859/1/2 Latin character sets and
|> |>  the ISO 6937/2 Videotex standard) which includes both ASCII
|> |>  and the various national characters, but it will take years,
|> |>  if not decades, for these new offcial standards to become
|> |>  industry standards and for 7-bit equipment to completely lose
|> |>  its importance.
|>
|> I think that amongst people actually developing programs, ISO 8859 (or
|> the IBM PC code) is already the standard.  Things happen fast in our
|> world, and it has been years since the quoted article appeared.

Indeed so, the standard X11r4 fonts are all ISO 8859.
Since X11 is now up to r6, I think that, combined with PC's
makes ISO 8859 one of the most predominant chracter sets today.

[Yep, I thought so, 8859/Latin 1 contains all of 7-bit ASCII as a
subset - with it you can have all of the letters with diacritics
*and* have the C/C++ special characters].

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.

In article <CuB8GB.960@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:

|> No doubt you'd call them prejudiced, but in their article in EUUG
|> Notices (Vol 9, No 2 Summer 1989, pp 15-18) Simonsen and Stroustrup
                               ^^^^
|> write:

In 1989, I would have fought dearly for digraphs.  Today...

|>  In many countries in Europe, South America and Africa the
|>  national character set standard is a version of the ISO
|>  646-1983 international standard for 7-bit character sets.
|>  ASCII (ANSI X3.4-1968) is the national version of ISO 646 in
|>  the USA.  It is the impression of the authors that ASCII and
|>  the national standard competes bravely from country to country
|>  for being the national industry standard.  Also, on IBM
|>  mainframes there are national EBCDIC implementations very
|>  close in character repetoire to the formal national standards.
|>  In some areas, such a Scandinavia, the national character sets
|>  are predominant both the in the 7-bit and the EBCDIC world.
|>  In other countries, such as the Netherlands, you mostly see
|>  ASCII.  There are some new international standards based on
|>  8-bit characters (the ISO 8859/1/2 Latin character sets and
|>  the ISO 6937/2 Videotex standard) which includes both ASCII
|>  and the various national characters, but it will take years,
|>  if not decades, for these new offcial standards to become
|>  industry standards and for 7-bit equipment to completely lose
|>  its importance.

I think that amongst people actually developing programs, ISO 8859 (or
the IBM PC code) is already the standard.  Things happen fast in our
world, and it has been years since the quoted article appeared.

|> Just to make the readability point again, I've used ISO 8859 Latin-1
|> (surely your systems supports that) to show what the example in the
|> ARM, page 371 looks like in DIN 66 003 (German national set):

|>  int main(int argc, char* argv      )
|>
|>   if (argc<1        *argv   1   =='   0') return 0;
|>   printf("Hello, %s   n", argv   1   );
|>

|> with trigraphs:

|>  int main(int argc, char* argv??(??))
|>  ??<
|>   if (argc<1 ??!??! *argv??(1??)=='??/0') return 0;
|>   printf("Hello, %s??/n", argv??(1??));
|>  ??>

|> and with bigraphs where possible:

|>  int main(int argc, char* argv<::>)
|>  <%
|>   if (argc<1 or *argv<:1:>=='??/0') return 0;
|>   printf("Hello, %s??/n", argv<:1:>);
|>  %>

|> Feel free to comment on the relative readability of these.

Having developped C for several years using the first, I find it by
far the most readable:-).

Actually, of course, none are the least bit readable, but the human
being, being flexible, can accomadate himself to anything.  I
accomadated myself to the first because at the time, there was no
alternative.

Just to make the issue clear.  I am a very strong proponent of
internationalization.  (I think my .sig should make clear why.)  Ten
years ago, I would have given almost anything to have digraphs.
(Instead, we got trigraphs:-(.)  Today, frankly, I don't care.  What I
really need is an iostreams which can handle positional arguments, as
in the X/Open extension to printf?  (Just a pet peeve, this.)
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <rfgCu5qur.8Er@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
> In article <CtwLv2.E54@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:
>> In article <rfgCttp3t.1rs@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:

>>> I can give you countless examples of features of the language that appear
>>> to be throughly unnecessary...
>>> References [...] Operator overloading [...]

>> These two do of course belong together, as you cannot get decent
>> syntax for overloaded operators without reference types [...]
>> You'd have to introduce lots of littel "wrappers" for the operators
>> of the built-in types, and hope the compiler does inline them.

> So?  So what?  Do you have a problem with that?

Yes, I have a problem with having to write those wrappers for built-in
types.  Besides, they'd be much like the `bool' type, everyone would
roll their own, and all would be slightly different, and possibly
incompatible.

> Would it really have bothered you if the language had been defined
> such that all standard conforming implementations had been required
> to pre-define things like `plus(int,int)' and `plus(double,double)'
> in addition to the corresponding built-in operators??  If so, why?

This sounds like a much better idea, although the cost in namespace
pollution seems to be fairly high.  Given that we have operator
overloading in C++, I wouldn't mind having
 int operator+(int, int);
 double operator+(double, double);
and so on as predefined functions, the address of which can be taken.

> (Note that if such things *had* been required of the implementations,
> they could have been referenced from within templates.)

Exactly.

-- Olaf Weber

In article <rfgCu5ryA.90G@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:

> In article <CtwLv2.E54@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:

>>> Then there's the ultimate example of ``design by INTERNATIONAL committee''
>>> in this era of PC (political correctness) where the entire planet has to
>>> bend over backwards just to prove that we're not prejudiced against lazy
>>> left-handed Latvians.  I'm speaking (of course) about digraphs.  Aren't
>>> you just so relieved to know that left-handed Latvians won't be forced to
>>> occasionally use their right-hands to hit certain keys (or to hit three
>>> keys rather than two) when typing C++ programs?  I sure am.

>> The point here wasn't writability, but readability: trigraphs didn't
>> solve that at all.  And the problem that digraphs are supposed to
>> solve doesn't exist for "lazy left-handed Latvians" only, but also
>> (among others) in France, Germany, Spain, Portugal, Italy, Hungary,
>> Denmark, Finland, Norway, and Sweden.

> Not that I question your opinions with regard who who wanted and/or demanded
> these ...explitive deleted... diagraphs, but just to make sure that the
> record's straight before going any further, can I ask a couple of quick
> questions?

> What country are you from... i.e. what does the `.nl' standard for in
> your E-mail address?

I'm a Dutchman writing from The Netherlands.

> What country actually proposed diagraphs?

Do countries make proposals?  I always though they were made by
members, who might (but need not) be the national representative of a
country.

AFIK the proposal for the introduction of the unspeakable bigraphs was
made by Keld Simonsen and Bjarne Stroustrup, both Danes.

> (I'm sure that the answers to these two questions will be as different as
> Botswana and Bolivia, but I just want to verify that before responding
> further.)

The point being?

> Oh yes, and before I forget.  I do have just one other small question...

> Since you have made a point of stressing ``readability'' (as the motivation
> for diagraphs), I'm curious...  What percentage of the world's total popu-
> lation of CRT screens are currently unable to display the characters which
> C++ diagraphs act as replacements for?

Since a CRT will display whatever the signal it is fed dictates, 100%
should be able to display those characters.  More interesting is the
number of systems using 7-bit national character sets, such as ASCII.
I include ASCII here because its failure to handle accents properly is
a bad (IMHO) as the failure of most other ISO 646 variants to provide
`[', `]', `{', `}', `\', and `|'.  A lack of accents is especially
irksome when names containing them have to be handled.

I've occasionally seen people wonder why languages desinged in Europe
tend to use keywords where langauges designed in the USA use symbols.
The answer should be obvious now: such symbols are often unavailable
on the keyboards that have to be used to type programs.

An interesting approach to this problem can be found in ALGOL 68,
which was designed when keypunches and 6-bit characters were still
common.  Rather than mandating a character set, there is a recommended
way of "typing" the language, and a recommended way of typesetting the
language, where the latter is very rich in symbols, and the former
tries to get by with a few different characters as possible.

> I don't expect that you have an exact number handy, so any
> reasonably accurate estimate from any reliable and unbiased source
> will do just fine.

No doubt you'd call them prejudiced, but in their article in EUUG
Notices (Vol 9, No 2 Summer 1989, pp 15-18) Simonsen and Stroustrup
write:

 In many countries in Europe, South America and Africa the
 national character set standard is a version of the ISO
 646-1983 international standard for 7-bit character sets.
 ASCII (ANSI X3.4-1968) is the national version of ISO 646 in
 the USA.  It is the impression of the authors that ASCII and
 the national standard competes bravely from country to country
 for being the national industry standard.  Also, on IBM
 mainframes there are national EBCDIC implementations very
 close in character repetoire to the formal national standards.
 In some areas, such a Scandinavia, the national character sets
 are predominant both the in the 7-bit and the EBCDIC world.
 In other countries, such as the Netherlands, you mostly see
 ASCII.  There are some new international standards based on
 8-bit characters (the ISO 8859/1/2 Latin character sets and
 the ISO 6937/2 Videotex standard) which includes both ASCII
 and the various national characters, but it will take years,
 if not decades, for these new offcial standards to become
 industry standards and for 7-bit equipment to completely lose
 its importance.

Accented characters are rare in Dutch, and words that differ in an
accent only virtually absent, so our adoption of ASCII was fairly
painless, except if your name contains accents (and a fair number do).

Just to make the readability point again, I've used ISO 8859 Latin-1
(surely your systems supports that) to show what the example in the
ARM, page 371 looks like in DIN 66 003 (German national set):

 int main(int argc, char* argv      )

  if (argc<1        *argv   1   =='   0') return 0;
  printf("Hello, %s   n", argv   1   );


with trigraphs:

 int main(int argc, char* argv??(??))
 ??<
  if (argc<1 ??!??! *argv??(1??)=='??/0') return 0;
  printf("Hello, %s??/n", argv??(1??));
 ??>

and with bigraphs where possible:

 int main(int argc, char* argv<::>)
 <%
  if (argc<1 or *argv<:1:>=='??/0') return 0;
  printf("Hello, %s??/n", argv<:1:>);
 %>

Feel free to comment on the relative readability of these.

By the way, do you disagree with the introduction of `not' and
`not_eq' for `!' and `!='?  These were added because some EBCDIC
variants lack the exclamation mark.

-- Olaf Weber

In article <31lver$bu7@hermes.synopsys.com> jbuck@synopsys.com (Joe Buck) writes:
|This function conforms to ANSI C as long as it is never called with an
|argument that postruct foos to a const struct foo.  If it's called with a
|postruct fooer to a non-const struct foo it's perfectly legal.  This means
|that compilers cannot assume that a function that takes a pointer to
|const struct won't change the struct, meaning that it can't save fields in
|callee-save registers.  This limits the optimization that compilers can do
|across function calls that take const pointers or references.

Limits but does not eliminate.  A not-uncommon counter-example, would
be a pointer to const that the optimizing compiler *knows* points to
a const struct because, for example, the struct was init'ed in local
scope.  Then the compiler knows that the struct's member cannot be
legally modified by the function call, and could, for instance, cache
some member values in register across function call.

In article <DAG.94Aug1151451@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:
>>>>>> "RG" == Ronald F Guilmette <rfg@netcom.com> writes:
>
>RG> Operator overloading is just another shorhand notation `hack'.
>RG> .... but it doesn't really give you anything that you
>RG> couldn't already do with function calls, and it doesn't have a
>RG> damn thing to do with object oriented programming.
>
>The assuption seems to be that the goal of every programmer should be
>OOPification, and that all other styles are useless.  I won't buy that.

Nope.  The assumption is that mere shorthand notations make a language
*look* powerful (to the great masses of weekend hackers) while actually
doing very little to improve the lot of those engaged in large-scale
professional software engineering efforts.

In C++, namespaces are an example of something which was an attempt to
improve things significantly for large scale software engineering.  (Some
folks have written me to say that namespaces didn't quite do all they should
have in this regard, but that's besides the point here).  In contrast,
operator overloading only provides a cutsey shorthand notation for something
we could have done already (with functions) anyway... and there is a case
to be made that the resulting code would have been more maintainable (and
thus, in a sense `better engineered') if we had all just been forced to
use functions anyway.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CtvIxw.8ut@world.std.com> tob@world.std.com writes:
>However, I wanted to point out that I have made a good-faith attempt to
>find some substance in Ron's claims, that:
>
>        C++ features are often added to appease programmers at compiler
>        developers' expense, in a cost-benefit ratio tilted extremely
>        far toward the programmers, with little appreciation for cost to
>        developers, and on the whole, blindly.
>
>        (In my own words but I think it accurately captures the thought.

Almost, but not quite.  I would put it slightly differently:

 C++ features are often added to appease programmers at *programmer's*
 expense.

For an explanation of how this could be, I refer you to my other postings
in which I attempted to explain one of the fundamental laws of economics...
i.e. the TANSTAAFL law.

>... The examples I got were unconvincing...

To you perhaps.

> I trust their flaws are obvious to most.

If there *were* flaws in my arguments (regardless the relative uselessness
of certain unnecessary baggage in C++) which were obvious to most, then
these obvious flaws were apparently missed by the several people who wrote
me private E-mail, thanking me for making the points I've made.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CtwLv2.E54@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:
>In article <rfgCttp3t.1rs@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> I can give you countless examples of features of the language that appear
>> to be throughly unnecessary...
>> References [...] Operator overloading [...]
>
>These two do of course belong together, as you cannot get decent
>syntax for overloaded operators without reference types (or lots of
>special rules).  Is operator overloading itself worth the trouble?
>Try writing a template that works effiently with both the built-in
>types and user-defined types given that neither references nor
>operator overloading are available.  You'd have to introduce lots of
>littel "wrappers" for the operators of the built-in types, and hope
>the compiler does inline them.

So?  So what?  Do you have a problem with that?  Would it really have
bothered you if the language had been defined such that all standard
conforming implementations had been required to pre-define things like
`plus(int,int)' and `plus(double,double)' in addition to the correspon-
ding built-in operators??  If so, why?

(Note that if such things *had* been required of the implementations,
they could have been referenced from within templates.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CtwLv2.E54@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:
>
>> Then there's the ultimate example of ``design by INTERNATIONAL committee''
>> in this era of PC (political correctness) where the entire planet has to
>> bend over backwards just to prove that we're not prejudiced against lazy
>> left-handed Latvians.  I'm speaking (of course) about digraphs.  Aren't
>> you just so relieved to know that left-handed Latvians won't be forced to
>> occasionally use their right-hands to hit certain keys (or to hit three
>> keys rather than two) when typing C++ programs?  I sure am.
>
>The point here wasn't writability, but readability: trigraphs didn't
>solve that at all.  And the problem that digraphs are supposed to
>solve doesn't exist for "lazy left-handed Latvians" only, but also
>(among others) in France, Germany, Spain, Portugal, Italy, Hungary,
>Denmark, Finland, Norway, and Sweden.

Not that I question your opinions with regard who who wanted and/or demanded
these ...explitive deleted... diagraphs, but just to make sure that the
record's straight before going any further, can I ask a couple of quick
questions?

What country are you from... i.e. what does the `.nl' standard for in
your E-mail address?

What country actually proposed diagraphs?

(I'm sure that the answers to these two questions will be as different as
Botswana and Bolivia, but I just want to verify that before responding
further.)

Oh yes, and before I forget.  I do have just one other small question...

Since you have made a point of stressing ``readability'' (as the motivation
for diagraphs), I'm curious...  What percentage of the world's total popu-
lation of CRT screens are currently unable to display the characters which
C++ diagraphs act as replacements for?  I don't expect that you have an
exact number handy, so any reasonably accurate estimate from any reliable
and unbiased source will do just fine.

>Why do Americans so often
>insist on imposing their provincialisms on the rest of the world?

Well, that's an easy one.  It's because we are all evil bigoted bruts who
are not satisfied with having the largest, most successful, most productive,
and (above all) most PRAGMATIC capitalist economy in the world.  That's
just not good enough for us.  As a matter of fact, it is a well know
national policy goal of the United States (and all of its citizens) to
totally and selfishly squash all diversity (... well... at least all of
the diversity that's different from our own home-grown diversity) in all
other countries of the world.  When making technical decisions, or evaluating
technical alternatives and cost/benefit ratios on technical projects, we
Americans never let little things like pragmatism or common sense get in
our way.  We always try to make these choices based upon whatever will
be maximally harmful to people in little countries.

We really should be ashamed of ourselves.  I just can't understand why
we're not.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <KANZE.94Aug2194919@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald
>F. Guilmette) writes:
>
>|> I can give you countless examples of features of the language that appear
>|> to be throughly unnecessary (usually just involving shorthand notations
>|> for things that could already be done in other ways anyway), that have
>|> little (if anything) to do with object-oriented programming, and for
>|> which all of the language rules (let alone the actual implementations
>|> of all those rules) have yet to even be fully worked out.
>
>|> Humm.... where to start?  There are so many things that it's difficult to
>|> choose.
>
>And you started out so well, Ron.
>
>I basically agree with the first paragraph of Ron's, quoted above,
>although I think I would have expressed it in somewhat more diplomatic
>terms (and in this case, I think the diplomatic terms are probably
>closer to the reality of what went on in the committee).  But I find I
>must disagree with most of Ron's examples.
>
>To begin with, most of the examples, with the exception of operator
>overloading, are *small* things, easy to specify and easy to implement...

James, if you think that references and reference types are `easy' (in any
sense of the word) then you've obviously missed one hell of a lot of lengthy
discussions in the committee regarding the rules relating to references.

My understanding is that it's only been quite recently (after four previous
years of work) that the committee finally decided that there's no such thing
as an expression having a reference type... and there's still plenty more
clarifications needed with regard to reference types.

>On the other hand, Ron, why didn't you mention the two *big*
>extensions: RTTI and namespaces.  These are anything but trivial to
>implement, and to judge from the discussions in the core working
>group, anything but trivial to define.

I didn't mention RTTI because I got tired of listing things.

I didn't mention namespaces because *that* is one feature which holds the
potential (at least) of actually providing support for software engineering
on the grand scale.  It is certainly more than just a shorthand notation
for something else.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <JASON.94Aug1172500@deneb.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>
>> In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
>>> provide some new functionality that we couldn't already get via casting away
>>> `const'?  If so, nobody's told me about it.
>
>>  Sure it does. It allows const objects to be put in ROM.
>
>It would seem to me that it only adds the possibility of storing part of an
>object in readonly memory, and part in read-write; why does the existence
>of mutable change the status of, say, C structs?  Couldn't
>
>struct A {
>  int i;
>  int j;
>};
>
>const A a = { 1, 2 };
>
>go into ROM/shared text in any case?

 The ARM says something like "classes with
constructors cant be put in ROM". The reason is:
people put caches in their objects, and cast away
const to write to the cache of a const object.
The ARM blesses this practice.

 Now we have "mutable" the caches can be
declared and we can (and have) banned writing to
non-mutable parts of objects created by const declarations.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In a recent article rfg@netcom.com (Ronald F. Guilmette) writes:

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Overloading [][]--end the confusion once and for all!
>Date: Sun, 7 Aug 1994 07:40:47 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: offsetof(class,member)?
>Date: Sun, 7 Aug 1994 08:01:39 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: after
>Date: Sun, 7 Aug 1994 08:15:54 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Prefix versus postfix operator overrides
>Date: Sun, 7 Aug 1994 08:48:50 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Yet Another suggestion:  readonly
>Date: Sun, 7 Aug 1994 08:52:31 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Prefix versus postfix operator overrides
>Date: Sun, 7 Aug 1994 09:02:29 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: after
>Date: Sun, 7 Aug 1994 09:04:40 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Prefix versus postfix operator overrides
>Date: Sun, 7 Aug 1994 09:11:15 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Prefix versus postfix operator overrides
>Date: Sun, 7 Aug 1994 09:34:57 GMT

>From: rfg@netcom.com (Ronald F. Guilmette)
>Subject: Re: Prefix versus postfix operator overrides
>Date: Sun, 7 Aug 1994 09:44:40 GMT

All of in favor of renaming this the "Ronald F. Guilmette Memorial
Newsgroup" say "aye".

garry

--
Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California

In article <rfgCu5sEG.9EM@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

|> >I basically agree with the first paragraph of Ron's, quoted above,
|> >although I think I would have expressed it in somewhat more diplomatic
|> >terms (and in this case, I think the diplomatic terms are probably
|> >closer to the reality of what went on in the committee).  But I find I
|> >must disagree with most of Ron's examples.
|> >
|> >To begin with, most of the examples, with the exception of operator
|> >overloading, are *small* things, easy to specify and easy to implement...

|> James, if you think that references and reference types are `easy' (in any
|> sense of the word) then you've obviously missed one hell of a lot of lengthy
|> discussions in the committee regarding the rules relating to references.

|> My understanding is that it's only been quite recently (after four previous
|> years of work) that the committee finally decided that there's no such thing
|> as an expression having a reference type... and there's still plenty more
|> clarifications needed with regard to reference types.

I agree, they aren't easy, and I should have put them in with operator
overloading.  These two are really part of existing C++ practice;
they've been there from the start.  I don't think that there is any
way that the standards committee could even consider dropping them.
(After all, that would break much of *my* code.)
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

>>>>> "RG" == Ronald F Guilmette <rfg@netcom.com> writes:

RG> Operator overloading is just another shorhand notation `hack'.
RG> .... but it doesn't really give you anything that you
RG> couldn't already do with function calls, and it doesn't have a
RG> damn thing to do with object oriented programming.

The assuption seems to be that the goal of every programmer should be
OOPification, and that all other styles are useless.  I won't buy that.

[Other ramblings deleted.]

RG> I could go on and on, but quite frankly, I'm starting to not feel
RG> very well.

Share the feeling of us who occasionally read your postings.  Frankly
speaking Ron, I think you went overboard this time.

     -- Dag

In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
>provide some new functionality that we couldn't already get via casting away
>`const'?  If so, nobody's told me about it.

 Sure it does. It allows const objects to be put in ROM.
Previously only scalars were romable.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <rfgCttp3t.1rs@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) write:
|> More recent examples of pointless additions to the language (brought to
|> you by the committee) include such things as wchar_t and bool as built-in
|> types.  These types have already been available to C programmers for
|> quite a number of years... but not as built-in types.

I'm sorry, but this change *does* make a significant addition:
overloading function calls on these types (which is really a
necessity).

Sure they have been used in C without being built-in, but *C*
dosen't have function overloading, so the difference is trivial.
In C++, the difference between built-in and not is non-trivial.

|> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
|> provide some new functionality that we couldn't already get via casting away
|> `const'?  If so, nobody's told me about it.

Yes - the ability to *eliminate* this hideous hack.

Casting away const is a blecherous, sickening coding style.
Some real, *structured* alternative is necessary.  This allows
const to really mean what it says.  One important aspect here is that
it allows the decisions about const`ness to be made at the 'design'
level, not the 'implementation' level.  This allows more organized,
better documented, more easily checkable, code.

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.

In light of the personal abuse, sarcasm, and will-to-misunderstand in
the above message, I am not quoting any part of it.

However, I wanted to point out that I have made a good-faith attempt to
find some substance in Ron's claims, that:

        C++ features are often added to appease programmers at compiler
        developers' expense, in a cost-benefit ratio tilted extremely
        far toward the programmers, with little appreciation for cost to
        developers, and on the whole, blindly.

        (In my own words but I think it accurately captures the thought.
        At any rate, I'm not making this point by sarcasm, I'm
        describing this as reasonably as I can.)

I invited him to give an example of this, having seen none. The examples
I got were unconvincing. I trust their flaws are obvious to most. I will
not dignify the concomitant personal abuse with a reply.

My conclusion: the position described above is false.

BTW, I value internationalization.

        Tom

--
finger me for how Tehomega is coming along (at tob@world.std.com)
Author of The Burning Tower (from TomBreton@delphi.com) (weekly in
rec.games.frp.archives)

>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

> In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
>> provide some new functionality that we couldn't already get via casting away
>> `const'?  If so, nobody's told me about it.

>  Sure it does. It allows const objects to be put in ROM.

It would seem to me that it only adds the possibility of storing part of an
object in readonly memory, and part in read-write; why does the existence
of mutable change the status of, say, C structs?  Couldn't

struct A {
  int i;
  int j;
};

const A a = { 1, 2 };

go into ROM/shared text in any case?

Jason

In article <rfgCttp3t.1rs@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:

> I can give you countless examples of features of the language that appear
> to be throughly unnecessary (usually just involving shorthand notations
> for things that could already be done in other ways anyway), that have
> little (if anything) to do with object-oriented programming, and for
> which all of the language rules (let alone the actual implementations
> of all those rules) have yet to even be fully worked out.

> Humm.... where to start?  There are so many things that it's difficult to
> choose.

> I guess I could start way back before the standardization committee even
> got into the business of adding features.

> References [...] Operator overloading [...]

These two do of course belong together, as you cannot get decent
syntax for overloaded operators without reference types (or lots of
special rules).  Is operator overloading itself worth the trouble?
Try writing a template that works effiently with both the built-in
types and user-defined types given that neither references nor
operator overloading are available.  You'd have to introduce lots of
littel "wrappers" for the operators of the built-in types, and hope
the compiler does inline them.

> More recent examples of pointless additions to the language (brought to
> you by the committee) include such things as wchar_t and bool as built-in
> types.  [...]

How do you correctly do:
 wchar_t * wcs = L"...";
 cout << wcs;
if `wchar_t' is neither a built-in type (breaking headers) nor a class
(also breaking headers)?

I think a boolean type was a good idea, even if I'm not completely
convinced that its current incarnation is the best we could have.  And
again we have the problem that for a boolean type to act "as expected"
it _has_ to be a built-in type.

> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
> provide some new functionality that we couldn't already get via casting away
> `const'?  If so, nobody's told me about it.

Yes, in fact it does provide extra functionality: on systems where
constants are in read-only memory, objects with mutable members can be
put into writeable storage.  Programs that failed on such a system
(because casting away const from a constant didn't work) can be made
to work now.

> Then there's the ultimate example of ``design by INTERNATIONAL committee''
> in this era of PC (political correctness) where the entire planet has to
> bend over backwards just to prove that we're not prejudiced against lazy
> left-handed Latvians.  I'm speaking (of course) about digraphs.  Aren't
> you just so relieved to know that left-handed Latvians won't be forced to
> occasionally use their right-hands to hit certain keys (or to hit three
> keys rather than two) when typing C++ programs?  I sure am.

The point here wasn't writability, but readability: trigraphs didn't
solve that at all.  And the problem that digraphs are supposed to
solve doesn't exist for "lazy left-handed Latvians" only, but also
(among others) in France, Germany, Spain, Portugal, Italy, Hungary,
Denmark, Finland, Norway, and Sweden.  Why do Americans so often
insist on imposing their provincialisms on the rest of the world?

> I could go on and on, but quite frankly, I'm starting to not feel very
> well.

In spite of the comments above, I do sympathise with your feelings in
this matter.  Writing software while its specifications are still in
flux isn't very pleasant at the best of times, let alone when you're
betting the company's future on it.

> I'll be happy to provide many many more examples if those are [not]
> enough for you to chew on.

Feel free.

-- Olaf Weber

In article <JASON.94Aug1172500@deneb.cygnus.com> jason@cygnus.com
(Jason Merrill) writes:

|> >>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

|> > In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|> >> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
|> >> provide some new functionality that we couldn't already get via casting away
|> >> `const'?  If so, nobody's told me about it.

|> >  Sure it does. It allows const objects to be put in ROM.

|> It would seem to me that it only adds the possibility of storing part of an
|> object in readonly memory, and part in read-write; why does the existence
|> of mutable change the status of, say, C structs?  Couldn't

|> struct A {
|>   int i;
|>   int j;
|> };

|> const A a = { 1, 2 };

|> go into ROM/shared text in any case?

Yes, because it didn't have a constructor.  But:

 class complex
 {
 public :
     complex( double real , double imag )
         :   r( real ) , i( imag )  {}
     //  ...
 } ;

couldn't, since the results of casting away const would be defined.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

|> >> This is what I mean when I say that the committee has tended to PRETEND
|> >> to coddle end-users (some of whom have rather strange ideas about what
|> >> should go into a well-designed language).  The committee has tended to
|> >> say `Yes, you can have this.' and `Yes, you can have that.', but where
|> >> are the implementations of all these things?

|> >Care to give an example?

|> I can give you countless examples of features of the language that appear
|> to be throughly unnecessary (usually just involving shorthand notations
|> for things that could already be done in other ways anyway), that have
|> little (if anything) to do with object-oriented programming, and for
|> which all of the language rules (let alone the actual implementations
|> of all those rules) have yet to even be fully worked out.

|> Humm.... where to start?  There are so many things that it's difficult to
|> choose.

And you started out so well, Ron.

I basically agree with the first paragraph of Ron's, quoted above,
although I think I would have expressed it in somewhat more diplomatic
terms (and in this case, I think the diplomatic terms are probably
closer to the reality of what went on in the committee).  But I find I
must disagree with most of Ron's examples.

To begin with, most of the examples, with the exception of operator
overloading, are *small* things, easy to specify and easy to
implement.  In sum, less than than the what the C standards committee
did to K&R C.  So no big deal.

On the other hand, Ron, why didn't you mention the two *big*
extensions: RTTI and namespaces.  These are anything but trivial to
implement, and to judge from the discussions in the core working
group, anything but trivial to define.

In addition, neither of them really do the job one would expect.
Namespaces don't begin to solve the problem of the library vendor who
has "#define list" in his header files.  (Quality library vendors like
Rogue Wave and Booch have already solved this problem, without
namespaces.)  A real solution would require modules.  But that would,
in turn, delay the standard more than could be tolerated.

Similarly, the real use of RTTI is for persistency and
transportability.  Regretfully, the current proposal doesn't go far
enough to really be of much help here, perhaps because of a real lack
of existing practice.

On the other hand, both proposals *do* go far enough to create real
problems in the core language (type system, name lookup, etc.), and
thus, to create a significant delay in the standard.

My own position is that we should probably have saved these proposals
for a future version of the standard (when there would have been more
time to do them right), and gotten the current version out quicker
without them.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

rfg@netcom.com (Ronald F. Guilmette) writes:
> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
> provide some new functionality that we couldn't already get via casting away
> `const'?  If so, nobody's told me about it.

Casting away const?  Yuk.  That is an abomination which "mutable" has
finally freed us of.

John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>>  Sure it does. It allows const objects to be put in ROM.

jason@cygnus.com (Jason Merrill) writes:
>It would seem to me that it only adds the possibility of storing part of an
>object in readonly memory, and part in read-write; why does the existence
>of mutable change the status of, say, C structs?  Couldn't

struct A {
  int i;
  int j;
};

const A a = { 1, 2 };

>go into ROM/shared text in any case?

Yes, because there is no constructor or destructor.  However, under the
ARM rules, if A had a constructor or a destructor, "const" was to be
understood as truly "logical" -- "Humpty Dumpty const", as Jim Adcock used
to say, from Alice in Wonderland: "const means exactly what I want it to
mean, neither more nor less".  Folks advocated casting away const with
wild abandon to implement things like caches to store values returned by
const methods, etc.  Given this, it wasn't possible to store objects in
ROM, in general.  The "mutable" proposal, in addition to introducing the
mutable keyword (for writable data members in const objects, permitting
a mixed read-write object as Jason suggests), also made the effect of
writing to a const member that is not mutable undefined, permitting it
to go into ROM.  Previously it was required to work, so class objects
with constructors or destructors weren't really const.

Unfortunately, there's a limit to how far we can go because of some
problems with const in ANSI C.  Consider

void bad_neighbor(const struct foo * c_ptr) {
 struct foo * ptr = (struct foo *) c_ptr;
 ptr->some_field = 0;
}

This function conforms to ANSI C as long as it is never called with an
argument that postruct foos to a const struct foo.  If it's called with a
postruct fooer to a non-const struct foo it's perfectly legal.  This means
that compilers cannot assume that a function that takes a pointer to
const struct won't change the struct, meaning that it can't save fields in
callee-save registers.  This limits the optimization that compilers can do
across function calls that take const pointers or references.

At least with mutable, it's no longer required to use "cast away const",
which means that compiler vendors could implement an optional flag like
-fconst-means-const, which would treat casting away const as a hard error
and which would assume for the purposes of optimization that all code
respects const.




--
-- Joe Buck  <jbuck@synopsys.com>
Posting from but not speaking for Synopsys, Inc.
***** Stamp out junk e-mail spamming!  If someone sends you a junk e-mail
***** ad just because you posted in comp.foo, boycott their company.

olaf@cwi.nl (Olaf Weber) writes:
>> More recent examples of pointless additions to the language (brought to
>> you by the committee) include such things as wchar_t and bool as built-in
>> types.  [...]
>
>How do you correctly do:
> wchar_t * wcs = L"...";
> cout << wcs;
>if `wchar_t' is neither a built-in type (breaking headers) nor a class
>(also breaking headers)?

While I disagree with Ron's general thesis, I agree that wchar_t was a
mistake.  All the other things ending in _t are typedefs, and having it
be a typedef in C but a builtin in C++ seems wrong to me.  I would have
solved the problem by introducing "long char".  Look, ma, no new keywords!

This, I think, was a mistake on the part of the ANSI C committee: they
could have done it the same way so that the value of L"..." would be a
portable builtin type.
--
-- Joe Buck  <jbuck@synopsys.com>
Posting from but not speaking for Synopsys, Inc.
***** Stamp out junk e-mail spamming!  If someone sends you a junk e-mail
***** ad just because you posted in comp.foo, boycott their company.

In article <9408011929.AA15352@tdat.ElSegundoCA.NCR.COM> swf@ElSegundoCA.NCR.COM writes:
>In article <rfgCttp3t.1rs@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) write:
>|> More recent examples of pointless additions to the language (brought to
>|> you by the committee) include such things as wchar_t and bool as built-in
>|> types.  These types have already been available to C programmers for
>|> quite a number of years... but not as built-in types.
>
>I'm sorry, but this change *does* make a significant addition:
>overloading function calls on these types (which is really a
>necessity).
>
>Sure they have been used in C without being built-in, but *C*
>dosen't have function overloading, so the difference is trivial.
>In C++, the difference between built-in and not is non-trivial.

Hummm... Lemme see now.  Overloading based upon enum types is in the working
paper, and has been for SEVERAL revisions.  (Heck!  Some people have even
implemented it.)

So if `bool' and `wchar_t' had just been made into enum types, then you
would have been able to overload based upon them, yes?  So what's the
problem?  (Oh, and by the way, an enum type `bool' was already available
in quite a few existing header files.)

>|> Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
>|> provide some new functionality that we couldn't already get via casting away
>|> `const'?  If so, nobody's told me about it.
>
>Yes - the ability to *eliminate* this hideous hack.
>
>Casting away const is a blecherous, sickening coding style.

My, my.  It's really nice to know that people who are (and have been) in
favor of all of these innumerable additions to the language (many of
which, as I've already said, are totally unjustified) are so... well...
dispasionate and coldly reasonable in the way that they form their
opinions. :-) :-)

Hideous?  Blecherous?  Sickening?  My you do get emotional over such
small things as casts, don't you?

>Some real, *structured* alternative is necessary.

Because you say so?  Or was there something I missed?  Were you really
unable to do your job in a reasonable period of time back when you had
to cast away const?  (Actally, that era is NOT yet even in the past for
the majority of us.  Many compilers don't implement `mutable' to this
day.  But we seem to be surviving anyway.)

>This allows
>const to really mean what it says.  One important aspect here is that
>it allows the decisions about const`ness to be made at the 'design'
>level, not the 'implementation' level.  This allows more organized,
>better documented, more easily checkable, code.

You forgot Motherhood, Apple Pie, and Family Values(tm).

Get serious.  If you have any hard empirical data (which seems to be the
one thing that all of the proponents of all of these whiz-bang new language
features always seem to lack) which either proves or even tends to strongly
support the view that the world is better off with `mutable' (or that every-
thing goes better with Coke(tm)) then please lay it on us.  Elsewise your
claims have about as much scientific validity as if I made that claim that
oil spills are really Good for America.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CtvCzo.79q@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
>>provide some new functionality that we couldn't already get via casting away
>>`const'?  If so, nobody's told me about it.
>
> Sure it does. It allows const objects to be put in ROM.
>Previously only scalars were romable.

Are you just making a claim John, or can you provide a concrete example
(using actual C++ code)?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <31lvob$c35@hermes.synopsys.com>, jbuck@synopsys.com (Joe Buck) writes:

> While I disagree with Ron's general thesis, I agree that wchar_t was a
> mistake.  All the other things ending in _t are typedefs, and having it
> be a typedef in C but a builtin in C++ seems wrong to me.  I would have
> solved the problem by introducing "long char".  Look, ma, no new keywords!

I like `long char' much better too.  The point I tried to make was
that `wchar_t' must be a built-in type, not that it is named correctly.

> This, I think, was a mistake on the part of the ANSI C committee: they
> could have done it the same way so that the value of L"..." would be a
> portable builtin type.

It is indeed extremely odd that the L'..' and L"..." support was added
for the benefit of a typedef'd "type".  I really don't undertand why
`long char' wasn't introduced instead.

Of course, the C++ committee could just introduce it by itself, and
then we could just use `typedef long char wchar_t;' in C++ headers if
`wchar_t' is needed.

-- Olaf Weber

In article <rfgCty8q5.EKy@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

|> In article <CtvCzo.79q@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
|> >In article <rfgCttp3t.1rs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|> >>Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
|> >>provide some new functionality that we couldn't already get via casting away
|> >>`const'?  If so, nobody's told me about it.

|> > Sure it does. It allows const objects to be put in ROM.
|> >Previously only scalars were romable.

|> Are you just making a claim John, or can you provide a concrete example
|> (using actual C++ code)?

John's statement isn't 100% correct.  Previously, only objects without
constructors could be put into ROM; now, only objects that contain no
mutable fields can be put into ROM.

A typical case where this will be a big win (supposing the usual
definitions for class complex, with constructor and operator* inline):

 complex const  i( 0 , 1 ) ;

 complex
 rotate90( complex const& in )
 {
     return in * i ;
 }

Under the previous rules, the compiler *must* read the values in i and
do all of the multiplications, since someone, somewhere, could have
cast const away and modified i (a legal and defined operation under
the previous rules).

Under the new rules, the compiler is free to use the values in the
initializer of i, and optimize out the multiplications by 0 and 1
(i.e.: all of the multiplications).

Similarly, if I declare a table of const complex values, the compiler
is free to put them in write protected memory.  (Believe it or not,
some embedded, ROM based systems do use complex.  And because they are
typically time critical, they may want to replace some of the more
expensive functions, like the trig functions, with look-up tables.)

So much for the gains.  (The fact that you can do without casting away
const in a few cases is a negligible gain, and in my opinion, while
nice, would not be enough to justify the extension in itself.)  It
definitly helps in a few specific cases which, while perhaps not
overly frequent, do occur.  So what does it cost us?  (I'll let the
compiler implementers answer this one.)
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

jason@cygnus.com (Jason Merrill) writes:

>>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>
>>  [mutable] allows const objects to be put in ROM.
>
>It would seem to me that it only adds the possibility of storing part of an
>object in readonly memory, and part in read-write; why does the existence
>of mutable change the status of, say, C structs?

Before `mutable' existed, cast-away-const was allowed even if the
object was defined using `const', so const objects couldn't be put in
ROM.  Cast-away-const *had* to be allowed, since there was no other way
of doing it.  When `mutable' was introduced, cast-away-const was
disallowed (given undefined behaviour) in the case where the object was
defined using `const', so that compilers could place const object in
ROM.  Without `mutable', this change could not have been made.

(Or at least, that's my impression of what happened.)
--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <CtM9Do.BIw@world.std.com> tob@world.std.com writes:
>rfg@netcom.com (Ronald F. Guilmette) writes:
>> I have a very different view.
>>
>> As one who is familiar with both using and implementing compilers (and
>> as who who has observed the committe's work over several years) it is
>
>Much as I hate to toss credentials around in lieu of thought...

Clever innuendo there. (Have you considered entering politics?)

Much as I hate to even respond to such blatantly retorical comments, allow
me to point out that I was merely indicating that I'm at least minimally
*qualified* to comment on this ongoing debate between end-users and compiler
implementors, because I have been on both sides of the fence.  (Of course
if I had wanted to drag out my actual ``credentials'', I would have bored
you with a list of titles and degrees, but I agree that such things are
not relevant to informed and dispassionate debate.)

Now, if we can get back to the subject...

>> This is what I mean when I say that the committee has tended to PRETEND
>> to coddle end-users (some of whom have rather strange ideas about what
>> should go into a well-designed language).  The committee has tended to
>> say `Yes, you can have this.' and `Yes, you can have that.', but where
>> are the implementations of all these things?
>
>Care to give an example?

I can give you countless examples of features of the language that appear
to be throughly unnecessary (usually just involving shorthand notations
for things that could already be done in other ways anyway), that have
little (if anything) to do with object-oriented programming, and for
which all of the language rules (let alone the actual implementations
of all those rules) have yet to even be fully worked out.

Humm.... where to start?  There are so many things that it's difficult to
choose.

I guess I could start way back before the standardization committee even
got into the business of adding features.

References types have added an enormous amount of complexity to the
language, for very little gain.  All the same stuff can be done with
`const' qualified pointers.  The only differences are that with pointers,
you have to write dereferences explicitly.  (Big deal!  This proves that
some folks will even whine about having to write a few extra unary *'s!)

Operator overloading is just another shorhand notation `hack'.  Sure, it
maybe makes a few numerical types feel oh so comfy (just like slipping
behind the wheel of a Cadillac El Dorado with leather seats) but it doesn't
really give you anything that you couldn't already do with function calls,
and it doesn't have a damn thing to do with object oriented programming.
(Of course type-conversion operators, and their associated implicit con-
versions are the absolutely worse thing done in this area.  They lull
innocent C++ programmers into writing code which is maximally incompre-
hensible, even to the most astute and seasoned C++ programmers.)

More recent examples of pointless additions to the language (brought to
you by the committee) include such things as wchar_t and bool as built-in
types.  These types have already been available to C programmers for
quite a number of years... but not as built-in types.  These seem to
represent examples of the motto ``If it ain't broke, fix it.''  C pro-
grammers were not complaining about these types, so naturally, the C++
committee felt compelled to change their status to built-in types
(thereby rendering just about everyone's existing standard header files
incompatible with the *new* C++ language overnight).

Then there's `mutable'.  Maybe I'm just ignorant about this.  Did `mutable'
provide some new functionality that we couldn't already get via casting away
`const'?  If so, nobody's told me about it.

Then there's the ultimate example of ``design by INTERNATIONAL committee''
in this era of PC (political correctness) where the entire planet has to
bend over backwards just to prove that we're not prejudiced against lazy
left-handed Latvians.  I'm speaking (of course) about digraphs.  Aren't
you just so relieved to know that left-handed Latvians won't be forced to
occasionally use their right-hands to hit certain keys (or to hit three
keys rather than two) when typing C++ programs?  I sure am.

I could go on and on, but quite frankly, I'm starting to not feel very
well.

>What specifically has the committee done (or "pretended to do") where
>you feel it should have let the users make do with the existing
>language?

See above.  I'll be happy to provide many many more examples if those
are enough for you to chew on.

>BTW, I've written a compiler myself. I'm not going to be told that it's
>breathtakingly hard, because it's not. It's not even my main job, but I
>was surprised how easy it was.

Ummmm... and that was a commercial quality C++ compiler, yes?

>Sure, "C++ is bigger and more complex than your dinky little compiler",
>you may argue. I know that. I'm scaling to account for that, and it's
>still my distinct impression that I'm hearing enormous exaggeration of
>the difficulties. I add tougher stuff to bigger designs, and frankly I
>get impatient hearing how difficult it's supposed to be.

Yea.  Ya know, you're probably right.  The fact that the people who are
actually trying to make a living builing and selling C++ compilers say
that it's incredibly hard is probably just due to their tendency to
indulge in self-agrandizement.  You should just slap together your own
C++ compiler, and show them up for what they really are.  Shall we check
back with you, say, about the middle of next month?  (Surely you'll have
it done by then, yes? :-)

Oh yea!  And don't forget to supply a complete C++ ``standard library''
(including all of the iostreams stuff, a string class, locale class,
time class, the Standard Template Library, etc., etc., etc.).

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

rfg@netcom.com (Ronald F. Guilmette) writes:
> I have a very different view.
>
> As one who is familiar with both using and implementing compilers (and
> as who who has observed the committe's work over several years) it is

Much as I hate to toss credentials around in lieu of thought, I have all
3 also. (Unless you mean some formal observer relationship with the
committee)


> my opinion that the committee tends to PRETEND to coddle end-users (by
> giving them every new feature they seem to express an interest in...
> at least in the written drafts of the standard, if not in any actual
> implementations) regardless of the difficulty or complexity of accurately
> specifying, implementing, or testing these additional features.
>       [...]
> This is what I mean when I say that the committee has tended to PRETEND
> to coddle end-users (some of whom have rather strange ideas about what
> should go into a well-designed language).  The committee has tended to
> say `Yes, you can have this.' and `Yes, you can have that.', but where
> are the implementations of all these things?

Care to give an example?

I have seen dozens of worthy suggestions come through this group. (Along
with hundreds of ignorant proposals that were instantly shot down) (And
of course Adcock's dot operator which was in a category by itself }:) ).
Over the years I have seen a grand total of zero features that I would
consider whims incorporated into the standard, or even go very far. I
have seen many ideas with great cost/benefit ratios go begging.

What specifically has the committee done (or "pretended to do") where
you feel it should have let the users make do with the existing
language?


> P.S.  My comments here BY NO MEANS apply to the entire committee.

Nor do mine. In fact, they may not neccessarily apply to any member, but
to the process. In any case, they apply to the committee's output.

BTW, I've written a compiler myself. I'm not going to be told that it's
breathtakingly hard, because it's not. It's not even my main job, but I
was surprised how easy it was.

Sure, "C++ is bigger and more complex than your dinky little compiler",
you may argue. I know that. I'm scaling to account for that, and it's
still my distinct impression that I'm hearing enormous exaggeration of
the difficulties. I add tougher stuff to bigger designs, and frankly I
get impatient hearing how difficult it's supposed to be.

        Tom

In article <rfgCtLBzL.DBo@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>fact, the implementors (and representatives from compiler vendors) on
>the committee... i.e. the people who actually have a detailed under-
>standing of how tough it is to implement (and *test*) all this stuff
>have, in general, been very responsible in recognizing the *actual*
>costs (both to themselves and to end-users) of each new addition to
>the language.  It's all those *other* folks who *know* that they'll never
>have to do any of the painful, slow, and laborious work to implement
>and test any of this stuff that always seem to insist on having just
>one more feature... and then just one more after that, etc.  (And as
>bad luck would have it, these non-implementors heavily outnumber the
>real implementors on the committee. :-(

 I should point out that as a _user_ of the language C++,
I'd rather a few professional implementors slave over getting
their implementations of powerful features right than force
many times the number of programmers -- not all of whom
are brilliant software engineers -- to use the hacks and tricks
for which C is famous to get around deficiencies in the language.

 So there are two sides to the coin: it is not only
vendors that have to make a profit but programmers too.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <CtD0GD.D3D@world.std.com> tob@world.std.com writes:
>
>I do think the committee often coddles compiler developers...

I have a very different view.

As one who is familiar with both using and implementing compilers (and
as who who has observed the committe's work over several years) it is
my opinion that the committee tends to PRETEND to coddle end-users (by
giving them every new feature they seem to express an interest in...
at least in the written drafts of the standard, if not in any actual
implementations) regardless of the difficulty or complexity of accurately
specifying, implementing, or testing these additional features. The net
result of this is (of course) that the language has continually been a
moving target for both implementors AND end-users (since well before
the language standardization had even begun), that no two compilers
will agree about the validity of (let alone the possible meaning of)
any sizable non-trivial program, and that actual RELIABLE full-blown
implementations of the entire language will not be seen by anyone for
many many years hence.

This is what I mean when I say that the committee has tended to PRETEND
to coddle end-users (some of whom have rather strange ideas about what
should go into a well-designed language).  The committee has tended to
say `Yes, you can have this.' and `Yes, you can have that.', but where
are the implementations of all these things?  Answer:  Somewhere off in
the future.  It's a bit like the government's Social Security scam.
Yes, we can make believe that you are going to get something for nothing
today.  (Of course, someone will have to pay for it eventually; probably
your kids.)  But if you really want really want to cling to this fantasy
that you are going to get all of these great goodies immediately (can
you say `Instant gratification?') and also FOR FREE... well... we're
only too happy to help you maintain your fantasy.  (That's politics for
you.  The greatest delusion for the greatest number... or, to put it
another way, you can fool most of the people most of the time.)

P.S.  My comments here BY NO MEANS apply to the entire committee.  In
fact, the implementors (and representatives from compiler vendors) on
the committee... i.e. the people who actually have a detailed under-
standing of how tough it is to implement (and *test*) all this stuff
have, in general, been very responsible in recognizing the *actual*
costs (both to themselves and to end-users) of each new addition to
the language.  It's all those *other* folks who *know* that they'll never
have to do any of the painful, slow, and laborious work to implement
and test any of this stuff that always seem to insist on having just
one more feature... and then just one more after that, etc.  (And as
bad luck would have it, these non-implementors heavily outnumber the
real implementors on the committee. :-(

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

Can anyone explain to me why the following notation wasn't adopted
to distinguish prefix and postfix operator overrides :

classx classx::operator++(); // For postfix operator override.
classx classx::++operator();    // For prefix operator override.

// As opposed to what is now standard syntax for this:

classx classx::operator++(int); // For postfix operator override.
classx classx::operator++();    // For prefix operator override.


I don't see how the former notation would present a problem
to a c++ compiler.  It should be unambiguously recognizable by
a parser and I think it's more intuitive.

Thanks.

---
Pat Brans                        pbrans@netds.netx.com
NetExpress
1953 Gallows Road, Suite 300
Vienna, Virginia 22182
(703) 749-2207

pbrans@netxcom.netx.com (Pat Brans) asks:
> Can anyone explain to me why the following notation wasn't adopted
> to distinguish prefix and postfix operator overrides :
>
> classx classx::operator++();    // For postfix operator override.
> classx classx::++operator();    // For prefix operator override.
>
> // As opposed to what is now standard syntax for this:
>
> classx classx::operator++(int); // For postfix operator override.
> classx classx::operator++();    // For prefix operator override.

Because with the standard syntax, the compiler can just watch for the
word "operator" as an identifier and act on the funny syntax after that.
The syntax is only changed in a localized way.

If the "++" can come first, then every time you see "++" where it might
possibly be declared, you have to go looking for "operator". (In
addition to normal processing)


I do think the committee often coddles compiler developers, but in this
case there seems little benefit in doing otherwise.

FWIW, I'd just as soon see no distinction between the pre- and post-
uses, since I strongly recommend not writing in a way where it makes any
difference. I won't harangue against that style here, but I don't think
it is the language's responsibility to enable it.

        Tom

--
finger me for how Tehomega is coming along (at tob@world.std.com)
Author of The Burning Tower (from TomBreton@delphi.com) (weekly in
rec.games.frp.archives)