In article mq0@f111.iassf.easams.com.au, rjl@f111.iassf.easams.com.au (Rohan LENARD) writes:
>In article <3oq7h3$1ao@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
>:Rohan LENARD (rjl@f111.iassf.easams.com.au) wrote:
>:|> What drivel.  You never have to consider namespaces unless you want to use
>:|> them.   All the standard namespaces are automatically available with no
>:|> change to present use.
>:
>:The implementor cannot avoid namespaces.  It is not some little feature
>:that you add to a corner of your compiler.  It affects name lookup and
>:scope, which is one of the more fundamental aspects of the language.
>
>That wasn't what I was saying.  For the average Joe on the street they don't
>need to consider namespaces much at all.  For the compiler implementer sure,
>it is a difficult task.

My friend, have you actually *read* all the arcane name lookup rules that
govern namespaces?  If, as seems likely, library vendors start wrapping their
code in namespaces, *all* C++ programmers will be compelled to wrestle with
those rules.

The namespace rules--in their subtlety and complexity--have an eerie
resemblance to the multiple-inheritance name lookup rules.  As everyone
must know, the majority of C++ texts advise people to *stay away* from
MI, because there are just too many complexities for the *typical*
programmer to master.

I fear namespaces (particularly using-directives) are the next MI.

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com The opinions I express are no one's but mine!

In article <3oq7h3$1ao@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
:Rohan LENARD (rjl@f111.iassf.easams.com.au) wrote:
:|> What drivel.  You never have to consider namespaces unless you want to use
:|> them.   All the standard namespaces are automatically available with no
:|> change to present use.
:
:The implementor cannot avoid namespaces.  It is not some little feature
:that you add to a corner of your compiler.  It affects name lookup and
:scope, which is one of the more fundamental aspects of the language.

That wasn't what I was saying.  For the average Joe on the street they don't
need to consider namespaces much at all.  For the compiler implementer sure,
it is a difficult task.

Rohan
--
----------------------------------------------------------------------------
rjl@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...

In article <3oq2t2$mo@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
>|> >|> Vaguely related... what it the schedule for "reviews"? E.g., how long
>|> >|> after the first standard can we expect the "first review"?
>|> >|> Shall we wait 13 years? (I'm thinking about Fortran 77->90 :)
>|> >
>|> Hmmm... I did not express my question well. I really meant something
>|> like this: Once the standard is accepted (and my understanding is
>|> that it's unlikely to have major differences from the current draft),
>|> how long will we have to wait to have a chance at some "changes"
>|> (like the addition of restricted pointers or a similar feature)?
>
>I think the requirement is that a standard be reviewed at least every
>ten years.
>
>In practice, my copy of the C standard is copyright 1990.  The C
>standards committee is currently in the final stages of a new version.
                                  ^^^^^^^^^^^^^^^^^^^

This is absolutely untrue, false, wrong, bogus.

The C standardization commitee (SC22/WG14) is just now _beginning_ the
process of creating a revision of the C standard.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

|> >|> Vaguely related... what it the schedule for "reviews"? E.g., how long
|> >|> after the first standard can we expect the "first review"?
|> >|> Shall we wait 13 years? (I'm thinking about Fortran 77->90 :)
|> >
|> Hmmm... I did not express my question well. I really meant something
|> like this: Once the standard is accepted (and my understanding is
|> that it's unlikely to have major differences from the current draft),
|> how long will we have to wait to have a chance at some "changes"
|> (like the addition of restricted pointers or a similar feature)?

I think the requirement is that a standard be reviewed at least every
ten years.

In practice, my copy of the C standard is copyright 1990.  The C
standards committee is currently in the final stages of a new version.
For Fortran, we have standards dated 1966, 1977 and 1990.  (Fortran's
last revision got kicked around a lot before being accepted.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Rohan LENARD (rjl@f111.iassf.easams.com.au) wrote:
|> In article <3o8ld5$oma@offas_dike.sbil.co.uk>,
|> Marc Shepherd <shepherd@debussy.sbi.com> wrote:
|> :In article IAv@ucc.su.OZ.AU, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> :I'm concerned about namespaces ("opposed" would be too strong a word)
|> :for a different reason--lack of sufficient prior art.

|> So Ada 83 doesn't count as prior art then ?

In this context, no.  Ada 83 doesn't implement separate compilation by
inclusion of a textual copy of the declarations, and so faces a
completely different (and, I think, easier) set of problems.  Ada 83 had
`namespaces' from the start, and the entire language was designed with
them in mind.  This is considerably different from trying to wed them
into an existing language with a minimum of changes.

|> :I include myself in this category: all I know about namespaces is what
|> :I've read.  However, I *do* know that large extensions often engender
|> :complications and side effects that are not evident until they have
|> :enjoyed widespread production use: witness the number of changes to
|> :the overload resolution rules over the years, for example.

|> Any large scale project needs namespaces.  It is one of the better things
|> added.  Given a choice of rtti and namespaces, I'd be surprised if many
|> people working on large scale development went for RTTI.

I agree with the relative importance.  But I've worked on large
projects, both in C and C++, and we somehow managed to make it work
without namespaces.

Large scale projects need some form of naming discipline.  Namespaces
are a tool to facilitate this naming discipline.  They are not a miracle
solution which will replace project organization and discipline.

The question is not whether namespaces are a Good Thing.  I think
everyone agrees that they are.  The question is (or rather, was), are
they worth the cost.  And the answer is largely a question of opinion:
how much will they cost, and how much are they really worth.

The large scale projects I've worked on have all had (or gotten) enough
naming discipline for them to work.  The mechanisms are there, even if
they are somewhat awkward, and we know how to use them and to make them
work.  From my point of view, the single most important thing is to get
stable and reliable compilers.  To do this, we need a stable language
definition.

So any delays namespaces occasion costs heavily in my weighting, and the
benifits from namespaces are limited (since we have other solutions
which work anyway, and the discipline necessary to use them is already
there).

|> :I make a distinction, by the way, for RTTI.  The effects of RTTI on
|> :the language are, I think, relatively localized.  So, even if the design
|> :turns out to be a total botch (unlikely, but it could happen), there
|> :will be little adverse impact, except that perhaps people won't use
|> :the feature.  By contrast, I don't think you can avoid namespaces.

|> What drivel.  You never have to consider namespaces unless you want to use
|> them.   All the standard namespaces are automatically available with no
|> change to present use.

The implementor cannot avoid namespaces.  It is not some little feature
that you add to a corner of your compiler.  It affects name lookup and
scope, which is one of the more fundamental aspects of the language.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

>>>>> Rohan LENARD <rjl@f111.iassf.easams.com.au> writes:

> The GNU C++ compiler will support namespaces in release 2.7 (the next
> release).

No, it won't.  At least not in 2.7.0; the syntax has been added, but the
semantics have not (unless someone added it while I wasn't looking).

Jason

In article <3obtvf$t23@f111.iassf.easams.com.au>,
Rohan LENARD <rjl@f111.iassf.easams.com.au> wrote:

>The GNU C++ compiler will support namespaces in release 2.7 (the next
>release).  Hopefully it will be made available for general use very
>soon.

This isn't quite right.  The compiler will do something with
namespaces, but it doesn't yet `do' namespaces.  It will parse
namespaces 100%, but that doesn't mean they work 100% yet.

If I had to attach a percent, I would say 2%.

In article t23@f111.iassf.easams.com.au, rjl@f111.iassf.easams.com.au (Rohan LENARD) writes:
>In article <3o8ld5$oma@offas_dike.sbil.co.uk>,
>Marc Shepherd <shepherd@debussy.sbi.com> wrote:
>:I'm concerned about namespaces ("opposed" would be too strong a word)
>:for a different reason--lack of sufficient prior art.
>:
>So Ada 83 doesn't count as prior art then ?

No, Ada 83 does not count.  A programming language is not merely a shopping
bag of features.  The success of the language depends on how those features
work *together*.  Since so many aspects of C++ are different from Ada, you
cannot infer that an Ada feature will work the same when plopped into C++
(or vice versa, for that matter).

Remember, C++ has a feature called "templates," which is loosely similar to
an Ada feature called "generics."  Nevertheless, the specification of templates
has evolved considerably since it was first widely disseminated in the ARM,
in 1990.  There is a wide gap between the basic concept of templates, and the
very detailed rules of specifically how templates interact with all the other
features of the language.

Luckily, we've had five years' experience with the concept.  Templates are
now supported (to at least some degree) in all the major compilers, and plenty
of commercial work has been done.  Much of the evolution in the template
specification--from the ARM (1990) to the draft WP (1995) is based on
real-world experience.

My concern is that we don't have that kind of experience with namespaces
yet, and that it is therefore too soon to be standardizing them.  (What would
the Templates clause of the WP look like, if we had as little production
experience with templates today as we have with namespaces?)

>
>:At this stage of the game, most of the people who express an opinion
>:about namespaces have never used them in a program.  There are simply
>:too few compilers out there that support namespaces.  I would bet
>:that most people (perhaps even some *committee* members) know namespaces
>:only on paper.
>
>The GNU C++ compiler will support namespaces in release 2.7 (the next release).
>Hopefully it will be made available for general use very soon.

Yes, I know that.  Borland's next release will have them too.  But, that
doesn't change the fact that most of the "standardizing" work will have been
done without the benefit of actually using the feature (or anything remotely
like it) in a real C++ compiler.  By the time GNU's and Borland's next releases
come out, the WP will be nearly set in cement.

>
>Any large scale project needs namespaces.  It is one of the better things
>added.

Oh yeah?  We work on some fairly large projects here, and the lack of
namespaces is like a fly buzzing around in the summer: occasionally a
minor nuisance, but nothing seriously disruptive.

>Given a choice of rtti and namespaces, I'd be surprised if many
>people working on large scale development went for RTTI.

Most projects I've seen standardize on a virtual function called "ClassName"
(or something like it) and put it in all their classes.  Or, they use a
proprietary scheme inspired by their library vendor.  This is an area where
the committee wisely stepped in and standardized existing practice.

>
>:
>:I make a distinction, by the way, for RTTI.  The effects of RTTI on
>:the language are, I think, relatively localized.  So, even if the design
>:turns out to be a total botch (unlikely, but it could happen), there
>:will be little adverse impact, except that perhaps people won't use
>:the feature.  By contrast, I don't think you can avoid namespaces.
>
>What drivel.  You never have to consider namespaces unless you want to use
>them.   All the standard namespaces are automatically available with no
>change to present use.

What drivel.  Everyone becomes a user of namespaces, because all of the
standard library is in namespace 'std'.  I understand the committee *still*
is arguing over how to make the name lookup rules work, and this will
affect *everyone*.

Namespaces have a pervasive impact on the language.  They add considerable
complexity to the standard and any reference manual derived from it.  The
jury is still out on whether the value added is commensurate with that
complexity.

There is a very real possibility that namespaces will be another Multiple
Inheritance--required to be in every compiler, but generally shunned by
users who are afraid of being bitten by the nuances.

--
Marc Shepherd
Salomon Brothers Inc
mshepherd@mhfl.sbi.com
<std_disclaimer.h>

In article <3o8ld5$oma@offas_dike.sbil.co.uk>,
Marc Shepherd <shepherd@debussy.sbi.com> wrote:
>In article IAv@ucc.su.OZ.AU, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>>>> I personally opposed namespaces and RTTI (and still think it was a mistake
>>>> to include them)
>>
>> I supported both.
>>
>> I also agree with James :-)
>>
>> How is this? To me, these features were worth the
>>time, for James having a less featured Standard sooner was
>>more important. I think this is a legitimate personal
>>and political difference of stance -- one which can
>>only be resolved by discussion, acceptance of the legitimacy
>>of differing viewpoints, and acceptance of the procedure used
>>to resolve such differences -- voting.
>
>I'm concerned about namespaces ("opposed" would be too strong a word)
>for a different reason--lack of sufficient prior art.

 yes, I agree.

>At this stage of the game, most of the people who express an opinion
>about namespaces have never used them in a program.  There are simply
>too few compilers out there that support namespaces.  I would bet
>that most people (perhaps even some *committee* members) know namespaces
>only on paper.

 True. I personally _have_ used them -- but the compiler
I use has not implemented them fully and does not conform to the
specifications.

>I include myself in this category: all I know about namespaces is what
>I've read.  However, I *do* know that large extensions often engender
>complications and side effects that are not evident until they have
>enjoyed widespread production use: witness the number of changes to
>the overload resolution rules over the years, for example.

 True. Its a risk that was taken because NOT approving
namespaces would have left us without _any_ way to
partition the nameset of large systems.

>The problem is, once namespaces are incorporated in the standard, fixing
>a mistake will be extremely difficult.

 I agree, and I think the system we have is not as good
as it should be. In particular I'd rather have seen an inheritance
based model, and I think the using directive ought to be non-transitive.

>I make a distinction, by the way, for RTTI.  The effects of RTTI on
>the language are, I think, relatively localized.

 I'm not at all sure this is correct -- the typeid operator
has some interesting problems.

>By contrast, namespaces are a creation out of thin air.

 No, they were created out of very think air -- there
was a lot of discussion.

>This is not
>to say that they don't address a legitimate need--only that there is
>little real-world C++ experience with anything at all resembling namespaces.

>So, I am concerned.  Perhaps James Kanze shares this same concern as well.
>I'd be curious to here more counter-arguments.

 I agree with your concern. So the thing to do is look
at the specifications and say what you think could be done to
improve them.

 The committee wants to hear your opinon, but there is
little point being "worried": try as best as is possible without
a working implementation to discover if namespaces are
done right.


--
        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 <KANZE.95Apr27143517@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> <snip>
|>
|> Similarly, the only legitimate uses for RTTI which I see involve
|> persistency and transportability.

I beg to differ. I have found RTTI (or more specifically dynamic_cast)
extremely useful when dealing with parallel hierarchies. I have also
used it to test for cases that could be handled with a fast specialized
method instead of the slower general one. I have had to cast from a
virtual base.

It might be that none of these uses were really unavoidable, using
maybe an alternate design. But you don't always have the choice, or
the possibility to redesign the system when such needs arise.

As a consequence I had to *fake* it, like many. I got enraged ;-)
on reading in D&E (p 320) ``... having done that, I was satisfied
that I knew how to add RTTI should it ever become necessary -- and
removed the feature''. This is indeed my main gripe about C++, that
built-in RTTI makes its way so slowly in compilers, since the concept
was apparently well understood long ago.

IMHO, persistency and transportability are system-level issues and I
can wait till the right solutions are available. But dynamic_cast is
more of an everyday need.

--chris@etca.fr

In article <KANZE.95May2165903@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>In article <3nu6kb$a59@usenet.rpi.edu> vandevod@avs.cs.rpi.edu (David
>Vandevoorde) writes:
>
>|> In article <KANZE.95Apr27143517@slsvhdt.lts.sel.alcatel.de>,
>|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
[ The issue at hand is the usefulness of RTTI as currently proposed
  and its cost in terms of standardization effort and implementation.
  James argues that the usefulness is far from demonstrably commen-
  surate with the costs. As James pointed out, the issue is now
  mostly of historical interest. But interesting nevertheless :-) ]
>
>There is more to RTTI than just `dynamic_cast'.  Most of the problems

Ineed. But I only consider 'RTTI' that what can not be (reasonably) be
resolved at compile time. For example,

 class A {}; { A a; typeid(a); }

is not 'RTTI'.

>center about typeid.  For example, is `const' or reference part of the
>typeid?  (Const is part of the type, for example, in function
>overloading.)  There is, of course, nothing unsolvable in all of this.

Good point.

>It just takes added time to specify.  Time that, IMHO, would have been
>better spent on the core language.

I guess I severely underestimate the time-constant for such decisions.
[... snip somment about namespaces ...]
>
>|> >Similarly, the only legitimate uses for RTTI which I see involve
>|> >persistency and transportability.  But the current proposals do not
>|> >offer much help in this regard.  (Taligent did try to strengthen the
>
>|> I think it does help for persistency (although it is not "sufficient",
>|> it simplifies the task considerably). Transportability seems another
>|> issue altogether though (I'm thinking more about XDR-like issues;
>|> maybe I misunderstand your point here).
>
>If the persistent objects are read and written from the same
>processes, it is possible to use typeid to identify them.  In
>practice, however, I suspect that this is *not* a good thing.  Should
>my persistent objects become unreadable because my compiler vendor
>goes bankrupt.  For that matter, should using persistent objects lock
>me into a single vendor.

Another good point, but it seems to me that your requirements would
require a 'coding standard' which is probably beyond the scope of
a 'language standard'. Your (or rather: our :) concerns should
probably be addresses through other standard-like means (like API's).
I'm thinking of conventional character-strings returned by the
type_info::name() member.
>
>In the case of transportability (in my mind, sending objects over a
>network), it is almost certain that reader and writer will at some
>time be different, since in all probability, they will be running on
>different hardware platforms.  And obviously, identifying the type of
>incoming data is only a small part of the problem.

Well, again. I feel this can (or rather: should) not be handled by
the language. Providing a "hook" for transportation standards
however is useful (and I think that's what is provided in the
current draft).
>
>I think that there is much potential for RTTI with regards to both of
>these fields.  But there is not really enough existing practice to
>know exactly what is needed.  (As an example of what is needed, I
>suspect, but cannot prove, that in the case of transportability, what
>is required is structural type equivalence, and not name equivalence.)

Yes, structural equivalence would be nice. Still, structureen coding
for transportation purposes should not be specified by a standard that
is meant to be applied to a diversity of computing environments.

Maybe a implementation-dependent member "structure" could have been
added to type_info... (of course, a vendor can still add it, but it
would be nice to have at least a standard hook).
[ ... snipped some more comments ...]
>
>|> Vaguely related... what it the schedule for "reviews"? E.g., how long
>|> after the first standard can we expect the "first review"?
>|> Shall we wait 13 years? (I'm thinking about Fortran 77->90 :)
>
Hmmm... I did not express my question well. I really meant something
like this: Once the standard is accepted (and my understanding is
that it's unlikely to have major differences from the current draft),
how long will we have to wait to have a chance at some "changes"
(like the addition of restricted pointers or a similar feature)?
>--
>James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
>GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
>Conseils en informatique industrielle --
>                              -- Beratung in industrieller Datenverarbeitung
 Daveed

P.S.: I will reply to your e-mail response as soon as convenient (sorry).

In article <3o8ld5$oma@offas_dike.sbil.co.uk>,
Marc Shepherd <shepherd@debussy.sbi.com> wrote:
:In article IAv@ucc.su.OZ.AU, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
:>In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>,
:>Sam Fenster <fenster@ground.cs.columbia.edu> wrote:
:>>kanze@us-es.sel.de (James Kanze) writes:
:>>> I personally opposed namespaces and RTTI (and still think it was a mistake
:>>> to include them)
:>>
:>>Why?
:>
:> I supported both.
:>
:> I also agree with James :-)
:>
:> How is this? To me, these features were worth the
:>time, for James having a less featured Standard sooner was
:>more important. I think this is a legitimate personal
:>and political difference of stance -- one which can
:>only be resolved by discussion, acceptance of the legitimacy
:>of differing viewpoints, and acceptance of the procedure used
:>to resolve such differences -- voting.
:
:I'm concerned about namespaces ("opposed" would be too strong a word)
:for a different reason--lack of sufficient prior art.
:
So Ada 83 doesn't count as prior art then ?

:At this stage of the game, most of the people who express an opinion
:about namespaces have never used them in a program.  There are simply
:too few compilers out there that support namespaces.  I would bet
:that most people (perhaps even some *committee* members) know namespaces
:only on paper.

The GNU C++ compiler will support namespaces in release 2.7 (the next release).
Hopefully it will be made available for general use very soon.

:
:I include myself in this category: all I know about namespaces is what
:I've read.  However, I *do* know that large extensions often engender
:complications and side effects that are not evident until they have
:enjoyed widespread production use: witness the number of changes to
:the overload resolution rules over the years, for example.

Any large scale project needs namespaces.  It is one of the better things
added.  Given a choice of rtti and namespaces, I'd be surprised if many
people working on large scale development went for RTTI.

:
:I make a distinction, by the way, for RTTI.  The effects of RTTI on
:the language are, I think, relatively localized.  So, even if the design
:turns out to be a total botch (unlikely, but it could happen), there
:will be little adverse impact, except that perhaps people won't use
:the feature.  By contrast, I don't think you can avoid namespaces.

What drivel.  You never have to consider namespaces unless you want to use
them.   All the standard namespaces are automatically available with no
change to present use.


Regards,
 Rohan
--
----------------------------------------------------------------------------
rjl@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...

In article IAv@ucc.su.OZ.AU, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>,
>Sam Fenster <fenster@ground.cs.columbia.edu> wrote:
>>kanze@us-es.sel.de (James Kanze) writes:
>>> I personally opposed namespaces and RTTI (and still think it was a mistake
>>> to include them)
>>
>>Why?
>
> I supported both.
>
> I also agree with James :-)
>
> How is this? To me, these features were worth the
>time, for James having a less featured Standard sooner was
>more important. I think this is a legitimate personal
>and political difference of stance -- one which can
>only be resolved by discussion, acceptance of the legitimacy
>of differing viewpoints, and acceptance of the procedure used
>to resolve such differences -- voting.

I'm concerned about namespaces ("opposed" would be too strong a word)
for a different reason--lack of sufficient prior art.

At this stage of the game, most of the people who express an opinion
about namespaces have never used them in a program.  There are simply
too few compilers out there that support namespaces.  I would bet
that most people (perhaps even some *committee* members) know namespaces
only on paper.

I include myself in this category: all I know about namespaces is what
I've read.  However, I *do* know that large extensions often engender
complications and side effects that are not evident until they have
enjoyed widespread production use: witness the number of changes to
the overload resolution rules over the years, for example.

The problem is, once namespaces are incorporated in the standard, fixing
a mistake will be extremely difficult.  The same could be argued, of
course, about *any* extension, but no extension in this standard has
such a large impact on the language with so little real-world experience
to support it.

I make a distinction, by the way, for RTTI.  The effects of RTTI on
the language are, I think, relatively localized.  So, even if the design
turns out to be a total botch (unlikely, but it could happen), there
will be little adverse impact, except that perhaps people won't use
the feature.  By contrast, I don't think you can avoid namespaces.

Also, many vendors had already started incorporating proprietary RTTI
schemes into their implementations--this was a real problem to which
disparate solutions were beginning to emerge.  In my view, the committee
acted wisely here in crafting a portable solution.

By contrast, namespaces are a creation out of thin air.  This is not
to say that they don't address a legitimate need--only that there is
little real-world C++ experience with anything at all resembling namespaces.

So, I am concerned.  Perhaps James Kanze shares this same concern as well.
I'd be curious to here more counter-arguments.


---
Marc Shepherd
Salomon Brothers Inc
mshepherd@mhfl.sbi.com  The opinions I express are no one's but mine!

In article <3nu6kb$a59@usenet.rpi.edu> vandevod@avs.cs.rpi.edu (David
Vandevoorde) writes:

|> In article <KANZE.95Apr27143517@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
|> >In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>
|> >fenster@ground.cs.columbia.edu (Sam Fenster) writes:
|> >
|> >|> kanze@us-es.sel.de (James Kanze) writes:
|> >|> > I personally opposed namespaces and RTTI (and still think it was a mistake
|> >|> > to include them)
|> >
|> >|> Why?
|> >
|> >Because they are both extremely complex extensions (as opposed to
|> >something like mutable), which will cause (have caused?) noticeable
|> >delays in the standard.  In both cases, because of time constraints,
|> >they only partially solve the problem they are attempting to solve.

|> I agree with the fact that namespaces add some complexity to the
|> language and make many previously "intuitive" rules much less
|> "intuitive".

|> I fail to see what is so hard about RTTI however. My feeling was
|> that the implementation of RTTI essentially reduced to the provision
|> of one (or a few) "standard virtual functions" to every class that
|> already has at least one programmer-defined virtual function.
|> Although the RTTI functionality as currently proposed could
|> probably be emulated to a large extend by the programmer, I find
|> its canned availability rather useful.

There is more to RTTI than just `dynamic_cast'.  Most of the problems
center about typeid.  For example, is `const' or reference part of the
typeid?  (Const is part of the type, for example, in function
overloading.)  There is, of course, nothing unsolvable in all of this.
It just takes added time to specify.  Time that, IMHO, would have been
better spent on the core language.

|> >Namespaces do not do anything with regards to macros, for example.  I
|> >believe that some sort of module system is needed, but there is no
|> >obvious concensus as to what.  While I believe that a concensus could
|> >be found, it most certainly cannot be found without an unacceptable
|> >delay in the standard.  My own personal point of view would have been
|> >to simply put the solution off until the first review of the standard
|> >(at which time we might have a better idea of what is actually
|> >wanted).

|> All of this seems quite right, unfortunately... :-(

|> >Similarly, the only legitimate uses for RTTI which I see involve
|> >persistency and transportability.  But the current proposals do not
|> >offer much help in this regard.  (Taligent did try to strengthen the

|> I think it does help for persistency (although it is not "sufficient",
|> it simplifies the task considerably). Transportability seems another
|> issue altogether though (I'm thinking more about XDR-like issues;
|> maybe I misunderstand your point here).

If the persistent objects are read and written from the same
processes, it is possible to use typeid to identify them.  In
practice, however, I suspect that this is *not* a good thing.  Should
my persistent objects become unreadable because my compiler vendor
goes bankrupt.  For that matter, should using persistent objects lock
me into a single vendor.

In the case of transportability (in my mind, sending objects over a
network), it is almost certain that reader and writer will at some
time be different, since in all probability, they will be running on
different hardware platforms.  And obviously, identifying the type of
incoming data is only a small part of the problem.

I think that there is much potential for RTTI with regards to both of
these fields.  But there is not really enough existing practice to
know exactly what is needed.  (As an example of what is needed, I
suspect, but cannot prove, that in the case of transportability, what
is required is structural type equivalence, and not name equivalence.)

|> >standard to offer some help; I don't think anything actually came of
|> >their proposal, though, mainly because some people had jumped the gun
|> >and already had implementations which would be broken.)  Again, the
|> >question could be addressed in the first review, but in this case, I
|> >am not really convinced that we would be able to find concensus even
|> >then.

|> Vaguely related... what it the schedule for "reviews"? E.g., how long
|> after the first standard can we expect the "first review"?
|> Shall we wait 13 years? (I'm thinking about Fortran 77->90 :)

Any day now.

And in case anyone misunderstands.  The above presentation is for
historical interest only.  I feel that it would have been preferable
to have not included namespaces and RTTI in the standard.  They have
been included, however, and I do not see where anything would be
gained by removing them at this late date.  (Both of them *do* offer
something.  I personally don't think that they were worth the cost,
but the cost has largely been paid already.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>,
Sam Fenster <fenster@ground.cs.columbia.edu> wrote:
>kanze@us-es.sel.de (James Kanze) writes:
>> I personally opposed namespaces and RTTI (and still think it was a mistake
>> to include them)
>
>Why?

 I supported both.

 I also agree with James :-)

 How is this? To me, these features were worth the
time, for James having a less featured Standard sooner was
more important. I think this is a legitimate personal
and political difference of stance -- one which can
only be resolved by discussion, acceptance of the legitimacy
of differing viewpoints, and acceptance of the procedure used
to resolve such differences -- voting.

 It is also a difficult matter of judgement  of both
technical issues and requirements. I'm not at all sure
I was right, even given differing needs of Australia.
Time may tell.


--
        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

>James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

>>Similarly, the only legitimate uses for RTTI which I see involve
>>persistency and transportability.

Although I agree that RTTI has a restriced set of legitimate uses in
an OO environment,  I think the domain of such uses is larger than you
admit to above.

One nagging, yet legitimate, problem that is very difficult to solve
without RTTI, and which has nothing to do with persistence or
tranportability, is the crossing of dual hierarchies.  A dual
hierarchy is formed when two inheritance hierarchies mirror each other
in some way.  I have often used the example of the Vehicle hierarchy
which mirrors the Operator hierarchy.  Without RTTI, it is very
difficult to create the needed communication between the classes in
such hierarchies.  Moreover RTTI, when used in such cases, does not
harm the object structure at all.




--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

In article <KANZE.95Apr25123206@slsvhdt.us-es.sel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@us-es.sel.de> wrote:
>The actual ANSI incorporation makes no mention of any specific
>extensions (but does mandate us to consider extensions in general);...
>
>This said, of course, all of the above really isn't that relevant.
>Extensions (in general) *were* mandated...

OK.  I'll bite.  By whom?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

In article <KANZE.95Apr27143517@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>
>fenster@ground.cs.columbia.edu (Sam Fenster) writes:
>
>|> kanze@us-es.sel.de (James Kanze) writes:
>|> > I personally opposed namespaces and RTTI (and still think it was a mistake
>|> > to include them)
>
>|> Why?
>
>Because they are both extremely complex extensions (as opposed to
>something like mutable), which will cause (have caused?) noticeable
>delays in the standard.  In both cases, because of time constraints,
>they only partially solve the problem they are attempting to solve.

I agree with the fact that namespaces add some complexity to the
language and make many previously "intuitive" rules much less
"intuitive".

I fail to see what is so hard about RTTI however. My feeling was
that the implementation of RTTI essentially reduced to the provision
of one (or a few) "standard virtual functions" to every class that
already has at least one programmer-defined virtual function.
Although the RTTI functionality as currently proposed could
probably be emulated to a large extend by the programmer, I find
its canned availability rather useful.
>
>Namespaces do not do anything with regards to macros, for example.  I
>believe that some sort of module system is needed, but there is no
>obvious concensus as to what.  While I believe that a concensus could
>be found, it most certainly cannot be found without an unacceptable
>delay in the standard.  My own personal point of view would have been
>to simply put the solution off until the first review of the standard
>(at which time we might have a better idea of what is actually
>wanted).

All of this seems quite right, unfortunately... :-(

>Similarly, the only legitimate uses for RTTI which I see involve
>persistency and transportability.  But the current proposals do not
>offer much help in this regard.  (Taligent did try to strengthen the

I think it does help for persistency (although it is not "sufficient",
it simplifies the task considerably). Transportability seems another
issue altogether though (I'm thinking more about XDR-like issues;
maybe I misunderstand your point here).

>standard to offer some help; I don't think anything actually came of
>their proposal, though, mainly because some people had jumped the gun
>and already had implementations which would be broken.)  Again, the
>question could be addressed in the first review, but in this case, I
>am not really convinced that we would be able to find concensus even
>then.

Vaguely related... what it the schedule for "reviews"? E.g., how long
after the first standard can we expect the "first review"?
Shall we wait 13 years? (I'm thinking about Fortran 77->90 :)
>
[... snipped some comments ...]
>--
>James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
>GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
>Conseils en informatique industrielle --
>                              -- Beratung in industrieller Datenverarbeitung

 Daveed

kanze@us-es.sel.de (James Kanze) writes:
> I personally opposed namespaces and RTTI (and still think it was a mistake
> to include them)

Why?

In article <FENSTER.95Apr25150624@ground.cs.columbia.edu>
fenster@ground.cs.columbia.edu (Sam Fenster) writes:

|> kanze@us-es.sel.de (James Kanze) writes:
|> > I personally opposed namespaces and RTTI (and still think it was a mistake
|> > to include them)

|> Why?

Because they are both extremely complex extensions (as opposed to
something like mutable), which will cause (have caused?) noticeable
delays in the standard.  In both cases, because of time constraints,
they only partially solve the problem they are attempting to solve.

Namespaces do not do anything with regards to macros, for example.  I
believe that some sort of module system is needed, but there is no
obvious concensus as to what.  While I believe that a concensus could
be found, it most certainly cannot be found without an unacceptable
delay in the standard.  My own personal point of view would have been
to simply put the solution off until the first review of the standard
(at which time we might have a better idea of what is actually
wanted).

Similarly, the only legitimate uses for RTTI which I see involve
persistency and transportability.  But the current proposals do not
offer much help in this regard.  (Taligent did try to strengthen the
standard to offer some help; I don't think anything actually came of
their proposal, though, mainly because some people had jumped the gun
and already had implementations which would be broken.)  Again, the
question could be addressed in the first review, but in this case, I
am not really convinced that we would be able to find concensus even
then.

It is interesting to note that a significant amount of time in the
core group has been spent recently on problems brought up by these
extensions (particularly namespaces, which modify name look-up rules
and operator overloading).  This is precisely what I was afraid would
happen.

Finally, I would like to stress the fact that these are my opinions,
and that it is perfectly possible for people to have a different
opinion without being idiots, or out to get me.  Also, that I have
been able to present these opinions without any hinderance to the
standards committee.  I believe I was fairly listened to, and that my
point of view was considered.  (I normally would consider this
paragraph obvious, and unnecessary, but given the tone of certain
recent postings, it probably should be said.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <D7CGLy.Dwu@research.att.com> ark@research.att.com (Andrew
Koenig) writes:

|> In article <KANZE.95Apr20171822@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> > As a specific example, I believe Mr. Joyner advocates garbage
|> > collection.  In addition, garbage collection was actually one of the
|> > `mandated' extensions when the committee was formed.

|> I don't believe so.  I think the `mandated' extensions were
|> templates and exception handling.

This point has actually intregued me for a long time.  So I actually
read all of the literature I got when I first joined the ANSI
committee.

The actual ANSI incorporation makes no mention of any specific
extensions (but does mandate us to consider extensions in general); it
would seem that we are left to our own discression.  In all of the
correspondence preceding this incorporation, however, I could find no
place where templates and exceptions were mentioned without garbage
collection also being mentioned.  (These are mostly letters from HP,
motivating the formation of a committee.)  So, IMHO, if one can
justifiably speak of `mandated' extensions, garbage collection is
among them.

This said, of course, all of the above really isn't that relevant.
Extensions (in general) *were* mandated, and while, for example, I
personally opposed namespaces and RTTI (and still think it was a
mistake to include them), I certainly do not think that the committee
overstepped our mandate in including them.  I would also oppose any
suggestion that the committee was in any way `manipulated', or had
anything forced down its throat.  Or that there is any lack of
competence/intellegence/responsibility.  Intelligent people will
differ on specific issues, and if anything, the committee leaned over
backwards to allow us disenters to be heard.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <D7CGLy.Dwu@research.att.com>, ark@research.att.com says...
>
>In article <KANZE.95Apr20171822@slsvhdt.us-es.sel.de> kanze@us-es.sel.de
(James Kanze US/E
>SC 60/3/141 #40763) writes:
>
>> As a specific example, I believe Mr. Joyner advocates garbage
>> collection.  In addition, garbage collection was actually one of the
>> `mandated' extensions when the committee was formed.
>
>I don't believe so.  I think the `mandated' extensions were
>templates and exception handling.
>--
>                                --Andrew Koenig
>                                  ark@research.att.com

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Does anyone know for sure?
Do we assume that AT&T knows all?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology,
Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd.
#100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL
60563
East End, Tortola  |____|___\   1-708-505-5801
1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12
<-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the
OuterNet_|

In article <KANZE.95Apr20171822@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:

> As a specific example, I believe Mr. Joyner advocates garbage
> collection.  In addition, garbage collection was actually one of the
> `mandated' extensions when the committee was formed.

I don't believe so.  I think the `mandated' extensions were
templates and exception handling.
--
    --Andrew Koenig
      ark@research.att.com

>>>>> "JF" == Jim Fleming <jim.fleming@bytes.com> writes:

    JF> In article <D7ALzp.G28@meteor.sbi.com>, shepherd@debussy.sbi.com
    JF> says...
    >>  It will, if Mr. Joyner chooses to submit it.  Why he would do so is
    >> beyond me; why should he waste his (presumably valuable) time
    >> contributing to the standardization of a language he seems to so
    >> thoroughly detest?

    JF> So you really only want public comments from people that think the
    JF> language is great and the end-all-be-all. If this is the case then
    JF> someone from ISO and ANSI should post such a position.

That is not what he said, now is it?  The reason that it would seem
pointless to include Mr Joyner's infamous commentary is that it is not at
all constructive.  It in no way would help the comittee in formulating a
standard.  Second, for those who think the language is beyond hope, why
should they even *care* what is in the standard?

    JF> Unfortunately, after several months we still have not
    JF> been able to determine who is on these committees, much less who is
    JF> in charge of them. We do get the occassional clue but nothing
    JF> compared to the type of disclosure that one would expect from a
    JF> group trying to "use" our American National Standards Institute
    JF> process for their purposes.

I have no idea why you seem to think that the ANSI C++ comittee is
secret just because no one feels like posting the membership list
on this newsgroup.  If you really want to find out, why don't you
just write ANSI and ask them to send you a member list?  Really now,
I could very well make the argument that there is a conspiracy to keep
the names of members of congress secret because no one is willing to
post the congressional roster.  If I did so, you would probably consider
me nuts.  For my own part, I don't really care who is on the comittee.
They can all be members of the trilateral comission for all I care.

- Chris
--
Christopher Barber        cbarber@bbn.com        http://guava.bbn.com/~cbarber

In article <3n4f2p$3qg@News1.mcs.com>,
Jim Fleming <jim.fleming@bytes.com> wrote:
:In article <D7ALzp.G28@meteor.sbi.com>, shepherd@debussy.sbi.com says...
:>
:>In article 6uj@News1.mcs.com, jim.fleming@bytes.com (Jim Fleming) writes:
:>>
:>>I assume that Ian's famous "C++ Critique" will be part of the public
:>>comments submitted to the ANSI Committee working on the C++ standard.
:>>
:>
:>It will, if Mr. Joyner chooses to submit it.  Why he would do so is
:>beyond me; why should he waste his (presumably valuable) time contributing
:>to the standardization of a language he seems to so thoroughly detest?
:
:>Marc Shepherd
:>mshepherd@mhfl.sbi.com
:>
:
:So you really only want public comments from people that think the
:language is great and the end-all-be-all.

I think you misunderstood Mr. Shepherd's response (big surprise there).
He didn't say that the committee only wanted public comments from people
that think the language is great and the end-all-be-all.  He said that
Mr. Joyner probably wouldn't submit them.  Such a statement makes no
inference to people from which comments are desired.

:If this is the case then
:someone from ISO and ANSI should post such a position. Unfortunately,
:after several months we still have not been able to determine who
:is on these committees, much less who is in charge of them.

Actually how to obtain the list of committee members has been disclosed at
least twice in this forum alone.  Apparently, no one cares about obtaining
this list, including you.

:We do get the occassional clue

I consider "write ANSI" more than a simple clue.

:but nothing compared to the type of
:disclosure that one would expect from a group trying to "use" our
:American National Standards Institute process for their purposes.

And don't forget the obligatory baseless inference required in each of your
posts.

--
Stephen Gevers
sg3235@shelob.sbc.com

In article <D7ALzp.G28@meteor.sbi.com> shepherd@debussy.sbi.com (Marc
Shepherd) writes:

|> In article 6uj@News1.mcs.com, jim.fleming@bytes.com (Jim Fleming) writes:
|> >
|> >I assume that Ian's famous "C++ Critique" will be part of the public
|> >comments submitted to the ANSI Committee working on the C++ standard.
|> >

|> It will, if Mr. Joyner chooses to submit it.  Why he would do so is
|> beyond me; why should he waste his (presumably valuable) time contributing
|> to the standardization of a language he seems to so thoroughly detest?

Actually, Mr. Joyner's paper per se is probably not relevant to the
standardization effort, as his discussions are more on the lines of
which language should I use (and the standards committee is not
mandated to turn C++ into Ada, even supposing it wanted to).

Some of his specific points, on the other hand, do suggest that the
standard could be different.  I would expect to see some of these
appearing (in a different form) in the public comments.  Of course,
since most of them are already known to the committee members, and
have already been thoroughly discussed within the committee, I don't
think they will result in much change.

As a specific example, I believe Mr. Joyner advocates garbage
collection.  In addition, garbage collection was actually one of the
`mandated' extensions when the committee was formed.  I would be very
surprised if no one made a public comment to the effect that C++
should have garbage collection.  In fact, of course, the question has
been discussed within the committee (before I was a member).  And the
response to the public comment will almost certainly be a summary of
the committee's conclusions.  (Basically, at the time when such an
extension was still possible, there wasn't any concrete proposal.  And
when the Ellis/Detleff garbage collection became available, it was,
practically speaking, too late.  Although I am an ardent supporter of
garbage collection, in this particular case, I do not see how the
committee could have done anything else.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

jim.fleming@bytes.com (Jim Fleming) writes:

>In article <D7ALzp.G28@meteor.sbi.com>, shepherd@debussy.sbi.com says...
>>
>>In article 6uj@News1.mcs.com, jim.fleming@bytes.com (Jim Fleming) writes:
>>>
>>>I assume that Ian's famous "C++ Critique" will be part of the public
>>>comments submitted to the ANSI Committee working on the C++ standard.
>>>
>>
>>It will, if Mr. Joyner chooses to submit it.  Why he would do so is
>>beyond me; why should he waste his (presumably valuable) time contributing
>>to the standardization of a language he seems to so thoroughly detest?

>>Marc Shepherd
>>mshepherd@mhfl.sbi.com
>>

>So you really only want public comments from people that think the
>language is great and the end-all-be-all. If this is the case then
>someone from ISO and ANSI should post such a position. Unfortunately,
>after several months we still have not been able to determine who
>is on these committees, much less who is in charge of them. We do
>get the occassional clue but nothing compared to the type of
>disclosure that one would expect from a group trying to "use" our
>American National Standards Institute process for their purposes.

- For how long are we to put up with these things?
-
- Sincerely yours,
- Maj. Gen. James C. Fleming, (Mrs.)

Geez, what score did you get on your SAT verbal test?  A three?
Marc didn't say that ISO wasn't interested in Joyner's comments,
he said that Joyner probably wasn't interested in the ISO.

What are you going to accuse the ISO/ANSI committee of next?
Abusing cats and little children?

--
    ciao,
    milo
================================================================
    John DiCamillo                         Fiery the Angels Fell
    milod@netcom.com       Deep thunder rode around their shores

In article <D7ALzp.G28@meteor.sbi.com>, shepherd@debussy.sbi.com says...
>
>In article 6uj@News1.mcs.com, jim.fleming@bytes.com (Jim Fleming) writes:
>>
>>I assume that Ian's famous "C++ Critique" will be part of the public
>>comments submitted to the ANSI Committee working on the C++ standard.
>>
>
>It will, if Mr. Joyner chooses to submit it.  Why he would do so is
>beyond me; why should he waste his (presumably valuable) time contributing
>to the standardization of a language he seems to so thoroughly detest?

>Marc Shepherd
>mshepherd@mhfl.sbi.com
>

So you really only want public comments from people that think the
language is great and the end-all-be-all. If this is the case then
someone from ISO and ANSI should post such a position. Unfortunately,
after several months we still have not been able to determine who
is on these committees, much less who is in charge of them. We do
get the occassional clue but nothing compared to the type of
disclosure that one would expect from a group trying to "use" our
American National Standards Institute process for their purposes.


--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd. #100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article 6uj@News1.mcs.com, jim.fleming@bytes.com (Jim Fleming) writes:
>
>I assume that Ian's famous "C++ Critique" will be part of the public
>comments submitted to the ANSI Committee working on the C++ standard.
>

It will, if Mr. Joyner chooses to submit it.  Why he would do so is
beyond me; why should he waste his (presumably valuable) time contributing
to the standardization of a language he seems to so thoroughly detest?


--
Marc Shepherd
mshepherd@mhfl.sbi.com

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I assume that Ian's famous "C++ Critique" will be part of the public
comments submitted to the ANSI Committee working on the C++ standard.

Here are some additonal public comments...JF

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
In article <D6urBF.ECG@syacus.acus.oz.au>, ian@syacus.acus.oz.au says...
>
>Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
>
>>> There's actually no need to change the syntax, only
>>> enhance the semantics:
>>>
>>>      Foo *p;
>>>      Blarg **q;
>>>
>>>      p->thing = 42;  /* means (*p).thing = 42 */
>>>      q->stuff = 17;  /* means (**q).stuff = 17 */
>>>
>>> and even
>>>
>>>      p.thing = 42;   /* means (*p).thing = 42 */
>>>
>>> The compiler can always figure out what you mean!
>
>>In which case you might as well just make it...
>
>>   p.thing = 42;  and
>>       q.stuff = 17;
>
>>That's where Wirth's gone, after all.
>
>Exactly the point I make in the C++ Critique. There is no reason to have
>separate '->' and '.' operators, because the compiler can easily figure
>it out. However, you need to consider why the '->' and '.' lead to
programs
>being unmaintanable. What happens if you change Foo *p to just Foo p?
>Well if you only accessed members by a single '.' operator, no problems,
>just recompile. But if you distinguish '->' and '.', then you must
>go and change all the '->' accesses to this object to '.' manually.
>Real tedious bookkeeping stuff, when I should have a compiler do all
>this for me. That's what compilers are for...
>--
>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

--
Jim Fleming            /|\      Unir Corporation       Unir Technology,
Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd.
#100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL
60563
East End, Tortola  |____|___\   1-708-505-5801
1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12
<-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the
OuterNet_|