In article <KRISS.93Feb25131327@roll.ibp.fr> grosjean@masi.ibp.fr writes:
|One last thing : extending a language is not ever adding exception.
|It can be removing exceptions too.

I would argue that removing exceptional cases in general represents
a desirable *reduction* in a language.  All things being equal,
having to memorize a bunch of unusual special case exceptions
makes a language much harder to learn.

In article <1993Feb23.191535.18628@medtron.medtronic.com> jb8285@medtronic.COM writes:

.......
>
>What we need is higher productivity and higher quality, not the
>opposite.  In my opinion, C++ is beginning to approach a level of
>complexity where the addition of rules and exceptions will cause it to
>be a poorer language, not a richer one.  Remember that code is read
>many more times than it is written.  If coding constructs are
>difficult to understand by a reviewer, then the resultant system will
>contain defects.  The idea is to keep the syntax simple and to
>minimize the exceptions -- not the other direction.
>

I couldn't agree more.
--------------
Raphael Mankin   Nil taurus excretum

erc@netcom.com (Eric Smith) writes:

>In article <1lrendINNem3@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>>I agree with you that discriminated unions would be helpful, and
>>unions as they exist could be improved. But we already have too many
>>rules, and too many exceptions to those rules.

>Having too many is no reason not to want more.  Each rule and exception
>adds something desirable to the language.  In a few decades, when it has
>many thousands of rules and exception, it might be a much better language
>than it is now.  It might be easier to learn too, with online hypertext
>help, intelligent syntax checkers and idiom analyzers, etc.

And there will be the time where you need to major in artificial
languages before even venturing a line of code...

All amendments to the language were made in order to add something
which was felt to be really missing, in such a way as to minimally
impact programs not employing that features.

Other rules were added so that the compiler would rather do the
thing felt to be right, than the thing its rules implied.
Many thousands of rules and exceptions are not a thing to be desired,
each new thing has to be carefully weighed, and put in only if the
added complexity has very significant advantages.

A proper language designer will find each change a pain in the neck.
It is like getting involved in a surgery: you have to carefully weigh
the consequences, before doing that which human sense would
normally prohibit you to do, and once while you are at it, do
it in a way that you need not touch there again soon.
--
 David Kastrup        dak@messua.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, W-5100 Aachen, Germany

In article <1993Feb17.010025.21788@netcom.com> erc@netcom.com (Eric Smith) writes:
>In article <1lrendINNem3@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>>I agree with you that discriminated unions would be helpful, and
>>unions as they exist could be improved. But we already have too many
>>rules, and too many exceptions to those rules.
>
>But the real reason to stop adding to it, at least for a while, is so we
>can get a published standard, and try to convince the compiler vendors to
>follow it.


 However the biggest obstacle to a published standard
involves basic (fundamental) issues. While these issues are being
resolved, it should be possible to add well thought out extensions
without any time being lost.


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------

I seem to have missed the beginning of this thread....  I hope I'm not
quoting this too far out of context.

>In article <1993Feb16.123243.5380@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>>No object of a class with a constructor or destructor or user-defined
>>>assignment operator can be a member of a union.  (ARM 9.5)
>
>> That makes great problems for the discriminated
>>union idiom and argues for a proper compiler supported contruct.
>>But the case of a union in a class should not suffer this
>>restriction provided exactly one union component is initialised:
> ...
>>Could this extension be allowed?

Actually, I wouldn't call this an extension; it's actually a relaxation of
the rules.  But I don't see any reason why a union could't have a single
member with a constructor, and it's a feature I'd like to see.  Why don't
you write it up?

On the other hand, I think the rule about destructors is correct.  In
general, one can't be sure what the contents of a union will be when an
object is destroyed, so the prohibition on destructors is reasonable.

The part I don't understand is why there should be a restriction on user-
defined assignment operators.  Can anyone explain why this would be the
case?  Off hand, I can't see how that would be a problem....

--
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
...
: But the case of a union in a class should not suffer this
: restriction provided exactly one union component is initialised:
:
:  class X {
:   union {
:    Y y;
:    Z z;
:   };
:   X(const Y& yy) : y(yy) {}
:   X(const Z& zz) : z(zz) {}
:  };
:
: Could this extension be allowed?

No.
What would happen if you build X containing a Y, and then
assign to the 'z' field? Would it have to magically divine that
a destructor for yy was to be called, and the assignment to 'z'
implemented as a copy constructor?

Perhaps if it were a const union it might be safe.

What I *could* use is a limited-inheritance class: one that
has a fixed list of other classes inheriting from it. Then
you could overallocate storage to it so that the largest of
its derived classes fit. Then you could embed it into
larger data structures without an extra indirection.

The real cost of the extra indirection is not lookup time,
which is negligible, but dynamic storage allocation time.
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

In article <dak.729959716@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>Many thousands of rules and exceptions are not a thing to be desired,
>each new thing has to be carefully weighed, and put in only if the
>added complexity has very significant advantages.

Many thousands of carefully weighed rules and exceptions, each having
very significant advantages, and the programmer can learn them easily
with the assistance of a very sophistictated help system.

Many thousands of rules and exceptions are not a thing to be desired,
if added recklessly.  But nobody suggested that.

Assuming the goal of programming language development is to have computers
program themselves eventually, perhaps in the 22nd century, what happens
between now and then?  Do programming languages gradually evolve towards
that goal?  If so, it would seem that the programming languages would
gradually get more sophisticated, and that the programmers would gradually
come to rely more and more on assistance from the computer to help them
understand what they are doing.

In article <1993Feb18.185618.19080@vedge.com>, hendrik@vedge.com (Hendrik Boom) writes:
> What I *could* use is a limited-inheritance class: one that
> has a fixed list of other classes inheriting from it. Then
> you could overallocate storage to it so that the largest of
> its derived classes fit. Then you could embed it into
> larger data structures without an extra indirection.

I don't quite understand this; what type is the member of the larger data
structure going to be?  How is the constructor going to specify which of
the derived classes are to actually occupy the overallocated storage?

Perhaps a better approach would be for the compiler to optimize calls to
'new' in cases where the constructor calls 'new' to initialize member
variables.  It could make one call to the allocator, then call the
constructors in the proper order.  (This only applies, of course, if the
new operator has not been overridden by any of the classes involved.)

--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com

These opinions and statements are my own and do not reflect the opinions or
positions of Harris Corporation.
---------------------------------------------------------------------------
I don't know if my memory is as good as it used to be or not -- I can't
remember how good it used to be!
---------------------------------------------------------------------------

In article <1993Feb19.032357.843@netcom.com> erc@netcom.com (Eric Smith) writes:
>
>Assuming the goal of programming language development is to have computers
>program themselves eventually, perhaps in the 22nd century, what happens

 Computers already program themselves. Thats what compilers are for :-)


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------

Eric Smith (erc@netcom.com) wrote:
> Assuming the goal of programming language development is to have computers
> program themselves eventually, ...

Oh, no! I'll be out of a job!

> Many thousands of carefully weighed rules and exceptions, each having
> very significant advantages, and the programmer can learn them easily
> with the assistance of a very sophistictated help system.

Let's try to keep the human being in the picture here.  Regardless of
help systems, sophisticated or not, humans have a limited tolerance of
complexity.  There are things that can be done to help us handle
complexity, but eventually human performance begins to break down,
with the result of low productivity and low quality.

What we need is higher productivity and higher quality, not the
opposite.  In my opinion, C++ is beginning to approach a level of
complexity where the addition of rules and exceptions will cause it to
be a poorer language, not a richer one.  Remember that code is read
many more times than it is written.  If coding constructs are
difficult to understand by a reviewer, then the resultant system will
contain defects.  The idea is to keep the syntax simple and to
minimize the exceptions -- not the other direction.

--
"The comments and opinions expressed above are mine and do not necessarily
represent the official position or views of Medtronic, Inc."
Jeffrey R. Brown
Internet: jeffrey.brown@medtronic.com             Voice: 1-612-574-4698
UUCP:     uunet!medtron!jb8285                    FAX:   1-612-574-6150

In article <1993Feb23.191535.18628@medtron.medtronic.com> jb8285@medtronic.COM (Jeffrey R. Brown) writes:

>   Let's try to keep the human being in the picture here.  Regardless of
>   help systems, sophisticated or not, humans have a limited tolerance of
>   complexity.  There are things that can be done to help us handle
>   complexity, but eventually human performance begins to break down,
>   with the result of low productivity and low quality.

>   What we need is higher productivity and higher quality, not the
>   opposite.  In my opinion, C++ is beginning to approach a level of
>   complexity where the addition of rules and exceptions will cause it to
>   be a poorer language, not a richer one.  Remember that code is read
>   many more times than it is written.  If coding constructs are
>   difficult to understand by a reviewer, then the resultant system will
>   contain defects.  The idea is to keep the syntax simple and to
>   minimize the exceptions -- not the other direction.

I feel that *missing* rules won't make programs simpler.

In article <1993Feb15.182138.9521@taumet.com> steve@taumet.com (Steve Clamage) writes:
>
>No object of a class with a constructor or destructor or user-defined
>assignment operator can be a member of a union.  (ARM 9.5)
>

 That makes great problems for the discriminated
union idiom and argues for a proper compiler supported contruct.
But the case of a union in a class should not suffer this
restriction provided exactly one union component is initialised:

 class X {
  union {
   Y y;
   Z z;
  };
  X(const Y& yy) : y(yy) {}
  X(const Z& zz) : z(zz) {}
 };

Could this extension be allowed?

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------

In article <1993Feb16.123243.5380@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>>No object of a class with a constructor or destructor or user-defined
>>assignment operator can be a member of a union.  (ARM 9.5)

> That makes great problems for the discriminated
>union idiom and argues for a proper compiler supported contruct.
>But the case of a union in a class should not suffer this
>restriction provided exactly one union component is initialised:
 ...
>Could this extension be allowed?

I agree with you that discriminated unions would be helpful, and
unions as they exist could be improved. But we already have too many
rules, and too many exceptions to those rules.

daniel

In article <1lrendINNem3@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>I agree with you that discriminated unions would be helpful, and
>unions as they exist could be improved. But we already have too many
>rules, and too many exceptions to those rules.

Having too many is no reason not to want more.  Each rule and exception
adds something desirable to the language.  In a few decades, when it has
many thousands of rules and exception, it might be a much better language
than it is now.  It might be easier to learn too, with online hypertext
help, intelligent syntax checkers and idiom analyzers, etc.

But the real reason to stop adding to it, at least for a while, is so we
can get a published standard, and try to convince the compiler vendors to
follow it.  Right now compiler vendors use the word "standard" very loosely,
such as saying their C++ compiler is standard when what they really mean is
that is is compatible with standard C and has some extensions to make it
look like C++.  Also there are some software development groups choosing
not to use C++ because it isn't yet standardized.