>>>>> "Alain" == Alain MINIUSSI <miniussi@labri.u-bordeaux.fr> writes:
 <<munch>>
    Alain> Of course g++ is not written in g++ (all the people I known
    Alain> who have tried to develop something "important" in g++
    Alain> have: - decided to return to C, - decided to switch to ml,
    Alain> - comited suicide (well, not yet but he is really
    Alain> depressed...)  - are looking for another compiler)

You left out:
 - Are continuing to use g++ 2.5.8 to solve real-world problems.
 - Are using the hacked #pragma stuff to use class templates all
   *over* the place without incurring code bloat.
 - Are delivering on zillions of UNIX platforms with a recompile.

 <<munch>>
    Alain> Alain

Don't slam g++ man!
--
Bill Burcham        billb@sunquest.sunquest.com  "You're only as good
602.570.2840 Office     4801 East Broadway        as your last System"
602.570.2099 FAX       Tucson, AZ 85711 3610

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>rfg@netcom.com (Ronald F. Guilmette) writes:
>|tmb@idiap.ch writes:
>|>C++ compiler writing is already a nightmare.  And the Ellis and
>|>Detlefs proposal is not all that hard to implement.
>|
>|_Everthing_ is `easy' as long as you are not the schmuck who has to
>|implement it.
>
>Language design should be oriented towards the user, not the
>implementor.  If the implementor doesn't "like" implementing GC, too
>bad for him: he should change jobs.
>
>What matters to the user is what the cost and the benefit of a
>potential new language feature is.  In the case of the Ellis and
>Detlefs proposal, the cost is low and the benefit is considerable.

As you yourself wrote, C++ compiler writing is already a nightmare.
Increasing the implementation difficulty has a very high cost.  The
result is low-quality implementations.  As a user, I would certainly
like to have garbage collection.  But having a high-quality
implementation of the rest of the language is more important to me.

You are right that language design should be oriented towards the
user.  But keeping implementation difficulty as low as possible is
essential to satisfy user demands for reliable, efficient, high-quality
implementations on a wide variety of platforms.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <JASON.94Sep27152354@deneb.cygnus.com>, jason@cygnus.com (Jason Merrill) writes:
|> >>>>> James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> writes:
|>
|> Assuming, of course, that the compiler is written in C++.  g++, for one,
|> isn't.  Are there any others?

Of course g++ is not written in g++ (all the people I known who have tried
to develop something "important" in g++ have:
   - decided to return to C,
   - decided to switch to ml,
   - comited suicide (well, not yet but he is really depressed...)
   - are looking for another compiler)

|> > Apparently the implementors don't agree with me.  I wonder if there is
|> > any relationship between this and the particularly low quality of most
|> > available compilers.
|>
|> "this"?  etc..|>
|> I think that the low quality of most available compilers is due primarily
|> to the complexity and fluidity of the language.

It's due primarily to the fact that the people who produce these compilers
should learn how to code.

|> When the rules change
|> every few months, sometimes the repercussions don't quite get propagated to
|> the dark corners of the compiler.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I see that you agree with me...

|> Jason

Alain

>>>>> Alain MINIUSSI <miniussi@labri.u-bordeaux.fr> writes:

> Of course g++ is not written in g++ (all the people I known who have tried
> to develop something "important" in g++ have:
>    - decided to return to C,
>    - decided to switch to ml,
>    - comited suicide (well, not yet but he is really depressed...)
>    - are looking for another compiler)

And I could give you plenty of examples of people who are developing
"important" code with g++, and paying my salary into the bargain.  At least
I think they consider the code to be important, since it's how they make
their own salaries.

> |> I think that the low quality of most available compilers is due primarily
> |> to the complexity and fluidity of the language.

> It's due primarily to the fact that the people who produce these compilers
> should learn how to code.

Hmm.  C++ compilers are buggy, perhaps more buggy than the industry norm
for software.  Ergo, programmers working on C++ compilers are less
proficient than the industry norm.  No, I don't think that works.

In any case, this discussion is not really relevant to comp.std.c++, so
I've directed followups to comp.lang.c++ alone.

Jason

Alain MINIUSSI (miniussi@labri.u-bordeaux.fr) wrote:
[ talking about g++ and the people who programed it ]
: It's due primarily to the fact that the people who produce these compilers
: should learn how to code.

 I wanted to throw in my little voice here. Since some time, I've been
 studying the g++ compiler. That's already 1 point, you *CAN* if you
 like.

 Secondly, it isn't trivial, as is with any program that exists for years
 (pre ANSI era) already and that has started as a compiler that should
 be able to implement any language on any machine (I know, what you are
 thinking now...); though, I find the principle behind the gcc/g++/...
 compiler (tree structures, RTL, ...) a very flexible (and again, therefore
 *NOT* trivial) approach. Given some more docs on the frontend of the
 compiler design (then what exists already) and enough study of the source
 should be enough to implement what you need, within reason.

 In short, thank God for gcc/g++. If you don't like them, don't use
 them.

 Stef

--
Steven Buytaert

WORK buytaert@imec.be
HOME buytaert@innet.be

 'Imagination is more important than knowledge.'
   (A. Einstein)

Hi there,
In article <36c5vn$9b8@serveur.cribx1.u-bordeaux.fr>,
Alain MINIUSSI <miniussi@labri.u-bordeaux.fr> wrote:
>In article <JASON.94Sep27152354@deneb.cygnus.com>, jason@cygnus.com (Jason Merrill) writes:
>|> >>>>> James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> writes:
>|>
>|> Assuming, of course, that the compiler is written in C++.  g++, for one,
>|> isn't.  Are there any others?
>
>Of course g++ is not written in g++ (all the people I known who have tried
>to develop something "important" in g++ have:
>   - decided to return to C,
>   - decided to switch to ml,
>   - comited suicide (well, not yet but he is really depressed...)
>   - are looking for another compiler)

Talk about flame bait.

Anyone developing a commercial project without commercial support for their
development environment is an idiot.  The firm I work for has been
successfully using g++ since november last year, but rather than wait for
the latest FSF release, we purchased support and we get bug fixes from guys
like Jason typically within three to five days.  Try getting support like
that from Sun, HP, et. al.

BTW. I'm glad your sample space of all consists of just one person :-)  It's
good to see the experience base used to make those ridiculous judgements.

>
>|> > Apparently the implementors don't agree with me.  I wonder if there is
>|> > any relationship between this and the particularly low quality of most
>|> > available compilers.
>|>
>|> "this"?  etc..|>
>|> I think that the low quality of most available compilers is due primarily
>|> to the complexity and fluidity of the language.
>
>It's due primarily to the fact that the people who produce these compilers
>should learn how to code.

Oh get a grip Alain.  Writing compilers is not an easy task, especially when
the goal posts keep shifting.


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 <1994Oct3.110638.12211@imec.be>, buytaert@imec.be (Steven Buytaert) writes:
|> Alain MINIUSSI (miniussi@labri.u-bordeaux.fr) wrote:
|> [ talking about g++ and the people who programed it ]
really ? I don't remember my entire posting but I don't think that it
was specific to g++.
|> : It's due primarily to the fact that the people who produce these compilers
|> : should learn how to code.
It sounds really hard... I mean without the context.

|>  I wanted to throw in my little voice here. Since some time, I've been
|>  studying the g++ compiler. That's already 1 point, you *CAN* if you
|>  like.
well, I don't.
the last time I've been studying the g++ compiler, it was for a bug in template
(version 2.4.5 or something like that) it was... special. But the other parts
seems ok.
|>  Secondly, it isn't trivial, as is with any program that exists for years
|>  (pre ANSI era) already and that has started as a compiler that should
|>  be able to implement any language on any machine (I know, what you are
|>  thinking now...); though, I find the principle behind the gcc/g++/...
|>  compiler (tree structures, RTL, ...) a very flexible (and again, therefore
|>  *NOT* trivial) approach.
I didn't make any critics concerning this approach.

|>  Given some more docs on the frontend of the
|>  compiler design (then what exists already) and enough study of the source
|>  should be enough to implement what you need, within reason.
and what do I do when the next version comes ?

|>  In short, thank God for gcc/g++. If you don't like them, don't use
|>  them.
first, I'm an atheist and I thank who I like.
Secondly, I didn't blame gnu for the "quality" of their compilers (by quality I mean
things like efficiency of generated code, speed etc...) since a) it's not
so bad (specialy the efficiency) b) for the price...
and I like the C compiler too, the problem is that they lie when they say
that g++ is able to compile C++ code (and that the reputation of C++ suffer
from that).

Anyway, I think you should reread 1) my previous new 2) the news I was
responding to. I was irritated by the statement that "good software are
difficult to program" (try to adapt this statement to anything else than
software, it's very fun) and "it take time to propagate the changes to the
dark corners of the compiler" (one of the main concerns of OOP is that...
forget it).

|>  Stef
|>
|> --
|> Steven Buytaert
|>
|> WORK buytaert@imec.be
|> HOME buytaert@innet.be
|>
|>  'Imagination is more important than knowledge.'
|>    (A. Einstein)

--
------------------------------------------------------------------------------
Alain Miniussi                       |
(avec le "i" avant le "u")           |   For every complex problem, there
e-mail: miniussi@labri.u-bordeaux.fr |   is a solution that is simple, neat,
tel : 56 84 69 16                    |   and wrong.
LaBRI, Univ. BORDEAUX I              |
351, cours de la Liberation          |                    -- H. L. Mencken
FRANCE                               |
------------------------------------------------------------------------------

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

|> >>>>> James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> writes:

|> > Of course, the other difference is who pays: the implementor or the
|> > user.  As Ron has pointed out before, if the implementor pays, in the
|> > end, so does the user.  But in this case, both get back more than they
|> > pay (since the implementor will be a user in his next release).  I
|> > think that if I were an implementor, I would implement something along
|> > the lines of the Safe C++ proposal, even if no one wanted it, just to
|> > be able to use is myself in the implementation, and thus reduce my
|> > costs.

|> Assuming, of course, that the compiler is written in C++.  g++, for one,
|> isn't.  Are there any others?

I wasn't particularly targetting g++.  They are not the only C++
compiler with serious quality problems.  (They may be the only one
which recognizes that they have a problem, and since recognition is
the first step to finding a solution...)

|> > Apparently the implementors don't agree with me.  I wonder if there is
|> > any relationship between this and the particularly low quality of most
|> > available compilers.

|> "this"?  The availability of GC, you mean?  The gcc implementation uses a
|> happy medium between manual and automatic garbage collection; dynamically
|> allocated things go onto different heaps ("obstacks"), which are cleared as
|> a whole when they are no longer pertinent.  So when a function has been
|> compiled, everything it created is tossed (except, perhaps, for what is
|> necessary to inline it later on).  As a consequence, memory management in
|> gcc is fairly simple and error-resistant.  Not to suggest that there isn't
|> room for improvement; gcc is a notorious memory hog, but I don't think that
|> leaks are causing that.

I don't think that memory leaks, per se, are a problem for a compiler.
Quite frankly, so what if you loose a couple of kilobytes.  As soon as
the module is compiled, the compiler quits, and *all* of its resourses
are returned to the system.

My remark was meant in a more general sense, and really referred more
to attitude, than to any specific technical proposal.  A proposal is
made to make C++ in some way safer, and compiler implementors simply
ignore it.  Can I conclude from that that the implementors don't care
about safe code, and that this attitude carries over in the way the
write their compilers?

And I really should have added a smiley, since the comment had nothing
to do with the technical merits of the proposal being discussed (and
everything to do with my frustrations over compiler errors).

|> I think that the low quality of most available compilers is due primarily
|> to the complexity and fluidity of the language.  When the rules change
|> every few months, sometimes the repercussions don't quite get propagated to
|> the dark corners of the compiler.

I will agree that this certainly doesn't help things.  And I realize
that this poses a dilemma for the compiler implementor; clean up the
compiler generally, or add the new features.  Since one of these is
highly visible, and the user doesn't immediately see the other
(especially since you don't want to admit in ad copy that your
compiler seriously needed a clean-up), we know which one gets chosen.
--
James Kanze      Tel.: (+33) 88 14 49 00     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 <CHRISTEN.94Sep23135752@declet.das> christen@declet.das (Jon Christensen) writes:
|In article <TMB.94Sep23155815@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|
|> Well, some of these problems would go away with some of the extensions
|> I mentioned above.  For example, many kinds of constructors,
|> assignment operators, and destructors would not be for most code under
|> the Ellis and Detlefs' safe C++ proposal.
|
|Now that Ellis and Detleft's "Safe C++" has been bandied around for
|a couple days, I'm curious to find out more about it.  Does anyone
|know of any online papers, tech-reports, etc.?

Try parcftp.xerox.com in pub/ellis/gc.

    Thomas.

In article <CwLLyM.KDK@cunews.carleton.ca> dfs@doe.carleton.ca (David F. Skoll) writes:
|True.  However, IMO, a radical change is needed to clean up the language.
|It's just my opinion, of course.  Implementing GC in the face of unions
|while maintaining C linkage (no run-time type identification for the
|unions, for example) is a daunting task, unless you're willing to settle
|for a conservative collector.

Well, read Ellis and Detlefs' paper.  Roughly, the idea is to have two
separate "heaps" or classes of pointers, one supporting the unsafe,
old-style semantics, the other allowing only safe constructs.  Related
ideas exist in Modula-3 and in a number of other languages and
implementations.

This approach also addresses the concerns of users who really want
to do all their storage management themselves with the traditional
malloc-like behavior.

    Thomas.

In article <DAG.94Sep23203034@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

|>>>>> "TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:
|
|TMB> lack of garbage collection means that all users have to
|TMB> face issues such as temporaries, ...
|TMB> in the presence of GC, these would be something
|TMB> most people wouldn't have to think about
|
|So you would suggest garbage collecting compiler-generated
|temporaries?  I don't think I have seen that suggested before.
|
|It seems like a radical change to me, in particular as the user has no
|control over when temporaries are generated, and hence no control over
|when the garbage collector will be needed.

No, I'm not suggesting that whether temporaries are garbage collected
or not is left up to the compiler.  Compiler-generated temporaries
should (probably) continue to be handled in exactly the same way
that they have always been handled.

But with garbage collection, you can adopt programming styles in which
something like temporaries or data structures associated with
temporaries are deallocated by the garbage collector.  No additional
language constructs are needed.  Such programming styles are simply
not used today because they would invariably lead to memory leaks.

    Thomas.

In article <TMB.94Sep23155815@arolla.idiap.ch> tmb@idiap.ch writes:
>
>C++ compiler writing is already a nightmare.  And the Ellis and
>Detlefs proposal is not all that hard to implement.

I'm going to keep repeating this as long as people here keep giving me
valid excuses to do so.

_Everthing_ is `easy' as long as you are not the schmuck who has to
implement it.

--

-- 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 <TMB.94Sep24235720@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>   But with garbage collection, you can adopt programming styles in which
>   something like temporaries or data structures associated with
>   temporaries are deallocated by the garbage collector.  No additional
>   language constructs are needed.  Such programming styles are simply
>   not used today because they would invariably lead to memory leaks.

There have been a discussion in comp.lang.eiffel (which have
a GC) about object finalization (ie: destructor).

it appears that it is impossible to maintain a strong
destructor-is-desallocation-of-ressource semantic
with a GC.

the problem is that when an object is "unsused", there are
also many other object "unused" including it's own ressources
that it should manually close-then-deallocate. as the order is unpredictable,
a destructor cannot work on objects outside itself ...

perhaps is there solution in a kind of sort as a direct
acyclic graph...

but what if tere are loops ? who musbe destructed first...
it is acommon fact that a ressource own a pointer on
it's holder... evidently the holder must be destroyed
first, but a GC cannot guess who is the holder...

so a GC make destructor semantic impossible
to ensure. And, IMO destructor semantic (finalization) is
essential, and on of the best feature of C++.

moreover there are problem when you want to  destroy explicitly
an object a a given time.
-Either you do it when asked, and you can fail
-or you do it when you want, and it is done later ...


as a summary I'll say the GC manage memory, but not objects.

who has optimistics ideas ?  GC would be fantastic, but not
at the price of killing finalization !

:(

--
=======
Alain Coetmeur, Informatique-CDC R&D dept.
coetmeur@icdc.fr

In article <rfgCwpHx3.2Jz@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|In article <TMB.94Sep23155815@arolla.idiap.ch> tmb@idiap.ch writes:
|>C++ compiler writing is already a nightmare.  And the Ellis and
|>Detlefs proposal is not all that hard to implement.
|
|I'm going to keep repeating this as long as people here keep giving me
|valid excuses to do so.
|
|_Everthing_ is `easy' as long as you are not the schmuck who has to
|implement it.

Language design should be oriented towards the user, not the
implementor.  If the implementor doesn't "like" implementing GC, too
bad for him: he should change jobs.

What matters to the user is what the cost and the benefit of a
potential new language feature is.  In the case of the Ellis and
Detlefs proposal, the cost is low and the benefit is considerable.

    Thomas.

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

|> In article <TMB.94Sep26214307@arolla.idiap.ch> tmb@idiap.ch writes:

|> >What matters to the user is what the cost and the benefit of a
|> >potential new language feature is.  In the case of the Ellis and
|> >Detlefs proposal, the cost is low and the benefit is considerable.

|> _Everthing_ is `easy' as long as you are not the schmuck who has to
|> implement it.

But I'm the schmuck you has to implement programs in a language
without the Ellis and Detlefs proposal:-).

Everything in the language can be viewed as a cost trade-off.  I
believe that in this case, the cost of not implementing the Ellis and
Detlefs proposal may easily be a magnitude higher than the cost of
implementing it.

Of course, the other difference is who pays: the implementor or the
user.  As Ron has pointed out before, if the implementor pays, in the
end, so does the user.  But in this case, both get back more than they
pay (since the implementor will be a user in his next release).  I
think that if I were an implementor, I would implement something along
the lines of the Safe C++ proposal, even if no one wanted it, just to
be able to use is myself in the implementation, and thus reduce my
costs.

Apparently the implementors don't agree with me.  I wonder if there is
any relationship between this and the particularly low quality of most
available compilers.

In article <COETMEUR.94Sep26160233@moon.icdc.fr>, coetmeur@icdc.fr (Alain Coetmeur) writes:
>...
> as a summary I'll say the GC manage memory, but not objects.
>
> who has optimistics ideas ?  GC would be fantastic, but not
> at the price of killing finalization !

The GC seems to be a object lifetime manager, it collects the
garbage objects away at some time.

The questions is do we want to transfer the object lifetime
management from the progammer to the language responsibility ?

--
-- <A HREF="http://www.lut.fi/~hevi/">The Page</A> --

>>>>> James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> writes:

> Of course, the other difference is who pays: the implementor or the
> user.  As Ron has pointed out before, if the implementor pays, in the
> end, so does the user.  But in this case, both get back more than they
> pay (since the implementor will be a user in his next release).  I
> think that if I were an implementor, I would implement something along
> the lines of the Safe C++ proposal, even if no one wanted it, just to
> be able to use is myself in the implementation, and thus reduce my
> costs.

Assuming, of course, that the compiler is written in C++.  g++, for one,
isn't.  Are there any others?

> Apparently the implementors don't agree with me.  I wonder if there is
> any relationship between this and the particularly low quality of most
> available compilers.

"this"?  The availability of GC, you mean?  The gcc implementation uses a
happy medium between manual and automatic garbage collection; dynamically
allocated things go onto different heaps ("obstacks"), which are cleared as
a whole when they are no longer pertinent.  So when a function has been
compiled, everything it created is tossed (except, perhaps, for what is
necessary to inline it later on).  As a consequence, memory management in
gcc is fairly simple and error-resistant.  Not to suggest that there isn't
room for improvement; gcc is a notorious memory hog, but I don't think that
leaks are causing that.

I think that the low quality of most available compilers is due primarily
to the complexity and fluidity of the language.  When the rules change
every few months, sometimes the repercussions don't quite get propagated to
the dark corners of the compiler.

Jason

In article <TMB.94Sep26214307@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <rfgCwpHx3.2Jz@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>|In article <TMB.94Sep23155815@arolla.idiap.ch> tmb@idiap.ch writes:
>|>C++ compiler writing is already a nightmare.  And the Ellis and
>|>Detlefs proposal is not all that hard to implement.
>|
>|I'm going to keep repeating this as long as people here keep giving me
>|valid excuses to do so.
>|
>|_Everthing_ is `easy' as long as you are not the schmuck who has to
>|implement it.
>
>Language design should be oriented towards the user, not the
>implementor.  If the implementor doesn't "like" implementing GC, too
>bad for him: he should change jobs.

This is a wonderful example of the kinds of absurd conclusions reached
by those who perfer to look at issues from only one side, and who view
everything as being strictly black or white.

Here is another one:

 "Laws should be wriiten so as to maximize freedom for the citizen."

 "Therefore, murder should be legal, as should yelling fire in a
 crowded theater."

I trust that _intelligent_ readers of this newsgroup will realize the
absurdity of such deductions, and that they will also realize that part
of the reason that we users do not now have in our possesion languages and
compilers which are infinitely powerful is because it would take infinitely
long to write, debug, and document such things, and they would be infinitely
expensive when delivered, so we couldn't afford them anyway.

Reality may be onerous on occasion, but neither gravity nor the fundamental
and immutable laws of economics can be merely wished away.  Constraints _do_
exist, and we all live within them whether we like it or not.

>What matters to the user is what the cost and the benefit of a
>potential new language feature is.  In the case of the Ellis and
>Detlefs proposal, the cost is low and the benefit is considerable.

_Everthing_ is `easy' as long as you are not the schmuck who has to
implement it.

--

-- 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 <CwJE3w.Ezo@cunews.carleton.ca> dfs@doe.carleton.ca (David F. Skoll) writes:
|The biggest problem (as I see it) with C++ is its schizophrenic desire
|to be a new language on the one hand, and largely compatible with C on
|the other hand.  I believe that it's time to drop compatibility with C
|to clean up the language.  For example, changing C++ arrays to more
|than the C concept would help a lot.  Getting rid of unions would
|vastly simplify the implementation of a garbage collector (and unions
|aren't really needed when inheritance is available.)

But there is no reason to throw the baby out with the bathwater.  We
can migrate gradually to these new constructs.  For example, we don't
have to get rid of C-style arrays just to have safe arrays.  They can
live side-by-side.  Likewise, we don't have to get rid of C-style
unions to support garbage collection.

|When I mentioned "special rules", I refer to the ARM -- for example,
|see the table on page 306, which defines 15 types of constructors,
|destructors, conversion functions, operator functions, friend
|functions and other member functions, and describes whether or not
|they are inherited, can be virtual, can have a return type, can be a
|member or friend and are generated by default.  This, IMO, is
|egregious.  It's terrible to force software developers to remember or
|refer to this table.  There must be a cleaner way.

Well, some of these problems would go away with some of the extensions
I mentioned above.  For example, many kinds of constructors,
assignment operators, and destructors would not be for most code under
the Ellis and Detlefs' safe C++ proposal.

|Well, maybe.  I've written a fairly large system in Lisp, and am
|writing one in C++.  There's no doubt that C++ is more efficient than
|Lisp in terms of run-time, but I have grave doubts that it's more
|efficient in programmer-time.

I agree: C++ is probably not more efficient in terms of programmer
time.

|Absolutely.  One of my gripes with C++ is the amount of detail.  The
|ARM describes a baroque language with thousands of minutiae which
|certainly bedevil someone learning the language (and, I'd bet,
|experienced programmers too.)

By making the language more regular through extensions, most people
won't have to remember most of those features.

|>  -- lack of garbage collection means that all users
|>     have to face issues such as temporaries, constructor/
|>     destructor semantics, etc.; in the presence of GC,
|>     these would be something most people wouldn't have to
|>     think about
|
|Yes, but in the effort to maintain backward-compatibility, all of
|these things would still have to be available, making compiler-writing
|a bit of a nightmare.

C++ compiler writing is already a nightmare.  And the Ellis and
Detlefs proposal is not all that hard to implement.

|> Anther area in which C++ is a real mess is in templates.
|
|Yes.  For my project, I have made the heretical decision not to use
|templates at all.

Well, it depends on what performance tradeoffs you are able to make
for your application.  But for some applications, templates are
indispensable, messy as they are.

    THomas.

In article <TMB.94Sep23155815@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

> Well, some of these problems would go away with some of the extensions
> I mentioned above.  For example, many kinds of constructors,
> assignment operators, and destructors would not be for most code under
> the Ellis and Detlefs' safe C++ proposal.

Now that Ellis and Detleft's "Safe C++" has been bandied around for
a couple days, I'm curious to find out more about it.  Does anyone
know of any online papers, tech-reports, etc.?

thanks in advance,
--
Jon Christensen
christen@das.harvard.edu

>>>>> "TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:

TMB> lack of garbage collection means that all users have to
TMB> face issues such as temporaries, ...
TMB> in the presence of GC, these would be something
TMB> most people wouldn't have to think about

So you would suggest garbage collecting compiler-generated
temporaries?  I don't think I have seen that suggested before.

It seems like a radical change to me, in particular as the user has no
control over when temporaries are generated, and hence no control over
when the garbage collector will be needed.

      -- Dag

In article <TMB.94Sep23155815@arolla.idiap.ch>, Thomas M. Breuel
(tmb@arolla.idiap.ch) wrote:

> In article <CwJE3w.Ezo@cunews.carleton.ca> dfs@doe.carleton.ca
(David F. Skoll) writes:

DFS> The biggest problem (as I see it) with C++ is its schizophrenic desire
DFS> to be a new language on the one hand, and largely compatible with C on
DFS> the other hand. [... snip ...]

TMB> But there is no reason to throw the baby out with the bathwater.  We
TMB> can migrate gradually to these new constructs.  For example, we don't
TMB> have to get rid of C-style arrays just to have safe arrays.  They can
TMB> live side-by-side.  Likewise, we don't have to get rid of C-style
TMB> unions to support garbage collection.

True.  However, IMO, a radical change is needed to clean up the language.
It's just my opinion, of course.  Implementing GC in the face of unions
while maintaining C linkage (no run-time type identification for the
unions, for example) is a daunting task, unless you're willing to settle
for a conservative collector.

DFS> When I mentioned "special rules", I refer to the ARM -- for example,
DFS> see the table on page 306, [... snip ...]
DFS> It's terrible to force software developers to remember or
DFS> refer to this table.  There must be a cleaner way.

> Well, some of these problems would go away with some of the extensions
> I mentioned above.

I have never yet seen a language (or any other piece of software) get
simpler with the passing of time. :-)

--
David F. Skoll
<a HREF="http://www.doe.carleton.ca/students/skoll/">
Click here for my home page</a> "Query two pi" on typewriter.

Mr. Skoll is obviously not thinking about C++ in the right way.

In article <CwJE3w.Ezo@cunews.carleton.ca> dfs@doe.carleton.ca (David F. Skoll) writes:
>
>When I mentioned "special rules", I refer to the ARM -- for example,
>see the table on page 306, which defines 15 types of constructors,
>destructors, conversion functions, operator functions, friend
>functions and other member functions, and describes whether or not
>they are inherited, can be virtual, can have a return type, can be a
>member or friend and are generated by default.  This, IMO, is
>egregious.  It's terrible to force software developers to remember or
>refer to this table...

Think of it as job security.  If you can memorize all these details,
you'll have a job as a C++ programmer for life.

>... There's no doubt that C++ is more efficient than
>Lisp in terms of run-time, but I have grave doubts that it's more
>efficient in programmer-time...

Think of it as job security.

>... One of my gripes with C++ is the amount of detail.  The
>ARM describes a baroque language with thousands of minutiae which
>certainly bedevil someone learning the language (and, I'd bet,
>experienced programmers too.)

Think of it as job security.

>... but in the effort to maintain backward-compatibility, all of
>these things would still have to be available, making compiler-writing
>a bit of a nightmare...

Think of it as job security... for implementors!

:-)

--

-- 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 <CwHwFL.G4t@cunews.carleton.ca> dfs@doe.carleton.ca (David F. Skoll) writes:
|In article <TMB.94Sep21202456@arolla.idiap.ch>, Thomas M. Breuel
|(tmb@arolla.idiap.ch) wrote:
|
|> In fact,
|> many people (including some on the ANSI committee, apparently) are
|> hoping that additional functionality will become de-facto
|> standardized, like
|
|>  -- garbage collection
|>  -- threads and tasking
|>  -- runtime error checking
|>  -- closures [with dynamic extent]
|>  -- dynamic typing (not just type identification)
|>  -- signatures
|>  -- sound replacements for cpp functionality
|
|This will make C++ change from an unruly proliferating hack stuck
|awkwardly on top of C into an absolutely incomprehensible tangle of
|messy syntax and special rules.

No, it will make C++ into a language that's easier to use and cheaper
to develop code in.  It will make C++ less of a "proliferating hack"
and less "awkward".

The only of these extensions that requires new syntax and new rules is
replacements for cpp functionality.  The others don't require new
syntax or new rules (well, OK, signatures require one keyword with
syntax like "sizeof"); they either can be implemented completely with
a library-like interface (GC, threads, dynamic typing, runtime error
checking) or they simply relax a haphazard constraint on current
syntax (nested function definitions).  In fact, such features are
already in use in a number of implementations.  Several of them have
been proposed by Stroustrup himself.

|If you want GC, closures, dynamic
|typing, etc, why not use Lisp or Scheme or some other language
|designed for it from the start?

C++ is a language that encourages efficient implementations and is
backwards compatible and highly interoperable.  Those are features
that neither Lisp nor Scheme offer.  Those are properties won't be
affected at all by the above additions.

Also, the devil is in the detail.  C++ dynamic typing and C++ closures
aren't anything like Lisp or Scheme dynamic typing.  Signatures are a
style of programming that doesn't even exist in most other statically
OOLs.

In fact, the incomprehensible tangle that C++ already is is
due in part to the absence of some of these features.  Adding
them considerably simplifies the language for most users:

 -- lack of garbage collection means that all users
    have to face issues such as temporaries, constructor/
    destructor semantics, etc.; in the presence of GC,
    these would be something most people wouldn't have to
    think about

 -- lack of signatures implies the need for MI with
    all its complications in implementation and semantics;
    with signatures, MI could be ignored by most users
    and might eventually even become obsolete (replaced
    by a simple multiple implementation inheritance scheme)

 -- lack of dynamic typing makes binary I/O unsafe and
    cumbersome ("dynamic typing" in C++ also mean determining
    object structure statically in templates with no
    associated runtime overhead)

 -- lack of closures makes it necessary to abstract
    implementation via cursor classes; cursor classes
    require the class author to make the state of an
    iteration explicit, and they are not even particularly
    easy to use

 -- lack of sound cpp-like constructs makes developing
    better programming support tools really difficult
    (and if you want messy semantics, you can't get
    any "better" than a mix of cpp and C++)

 -- lack of garbage collection makes exceptions much
    more difficult to use in practice

Anther area in which C++ is a real mess is in templates.  I'm not sure
whether there is a good way of fixing that, though.  The problems seem
mainly related to the way overloading is resolved for type parameters,
and to the bizarre scoping rules for class scope.  Unfortunately, the
choices that C++ made here seem rather deeply ingrained with the general
approach C++ has to doing things.

So rather than rejecting these features just by their names and their
association with Lisp, I suggest you evaluate these issues carefully
and from a technical point of view; there have been several papers
describing the extensions--look them up and make specific criticism.
In fact, even among many people that opposed the inclusion of the
above features in the standard, many of them seem to agree that they
are fundamentally useful and important.  Standards committees rarely
make choices only based on technical merit.

    Thomas.

In article <TMB.94Sep22103818@arolla.idiap.ch>, Thomas M. Breuel
(tmb@arolla.idiap.ch) wrote:

> In article <CwHwFL.G4t@cunews.carleton.ca> dfs@doe.carleton.ca
(David F. Skoll) writes:

[T. Breuel]
> |>  -- garbage collection
> |>  -- threads and tasking
> |>  -- runtime error checking
> |>  -- closures [with dynamic extent]
> |>  -- dynamic typing (not just type identification)
> |>  -- signatures
> |>  -- sound replacements for cpp functionality

[D. Skoll]
> |This will make C++ change from an unruly proliferating hack stuck
> |awkwardly on top of C into an absolutely incomprehensible tangle of
> |messy syntax and special rules.

[T. Breuel]
> No, it will make C++ into a language that's easier to use and cheaper
> to develop code in.  It will make C++ less of a "proliferating hack"
> and less "awkward".

The biggest problem (as I see it) with C++ is its schizophrenic desire
to be a new language on the one hand, and largely compatible with C on
the other hand.  I believe that it's time to drop compatibility with C
to clean up the language.  For example, changing C++ arrays to more
than the C concept would help a lot.  Getting rid of unions would
vastly simplify the implementation of a garbage collector (and unions
aren't really needed when inheritance is available.)

> The only of these extensions that requires new syntax and new rules is
> replacements for cpp functionality.

When I mentioned "special rules", I refer to the ARM -- for example,
see the table on page 306, which defines 15 types of constructors,
destructors, conversion functions, operator functions, friend
functions and other member functions, and describes whether or not
they are inherited, can be virtual, can have a return type, can be a
member or friend and are generated by default.  This, IMO, is
egregious.  It's terrible to force software developers to remember or
refer to this table.  There must be a cleaner way.

[...]

> |If you want GC, closures, dynamic
> |typing, etc, why not use Lisp or Scheme or some other language
> |designed for it from the start?

> C++ is a language that encourages efficient implementations and is
> backwards compatible and highly interoperable.  Those are features
> that neither Lisp nor Scheme offer.  Those are properties won't be
> affected at all by the above additions.

Well, maybe.  I've written a fairly large system in Lisp, and am
writing one in C++.  There's no doubt that C++ is more efficient than
Lisp in terms of run-time, but I have grave doubts that it's more
efficient in programmer-time.  (Our application was not really
runtime-critical; that heavily influenced the choice of Lisp.)

> Also, the devil is in the detail.  C++ dynamic typing and C++ closures
> aren't anything like Lisp or Scheme dynamic typing.

Absolutely.  One of my gripes with C++ is the amount of detail.  The
ARM describes a baroque language with thousands of minutiae which
certainly bedevil someone learning the language (and, I'd bet,
experienced programmers too.)  The meaning of the word "static", for
example, already abused in C, is abused even further in C++.  It can
mean a variable with file scope, a static variable with function scope,
or a member shared among all instances of a class.

>  -- lack of garbage collection means that all users
>     have to face issues such as temporaries, constructor/
>     destructor semantics, etc.; in the presence of GC,
>     these would be something most people wouldn't have to
>     think about

Yes, but in the effort to maintain backward-compatibility, all of
these things would still have to be available, making compiler-writing
a bit of a nightmare.  Also, my experience is that when a language
provides something, people will use it, even if it may be inadvisable.
So these old issues won't go away.

[...]

> Anther area in which C++ is a real mess is in templates.

Yes.  For my project, I have made the heretical decision not to use
templates at all.  All my objects are rooted in a single object, and
the resulting object system is very similar to SmallTalk's system.
Objects have IsA() methods, effectively giving RTTI.  They all know
how to write and read themselves to and from a stream.  The root
object is a garbage-collected class, so the only special action needed
is to wrap automatic pointers in special smart pointers that add and
remove themselves from the rootset as required.  I don't use multiple
inheritance or virtual base classes, which allows reasonably safe
downcasting when combined with IsA().  While this may be restricting,
possibly inefficient, and definitely against the C++ style, it is very
portable (since no weird or new C++ constructs are used), it matches
our application better, and I'm used to it. :-)

--
David F. Skoll
<a HREF="http://www.doe.carleton.ca/students/skoll/">
Click here for my home page</a> "Query two pi" on typewriter.