horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
> In article <1991Jul24.021726.557@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
> >
> >Now MY pet peeve is the multiple meanings of the "static" keyword.
>
> So I am not alone in the world after all with this one!

 I want to join the club...

>
> 3. To declare variables shared in a class, use shared.
>
>    class X
>    {   shared int i;
>        // ...
>    };
>
>    Sorry, I have no suggestion how to call static member functions.

 Why not indicate their "sharedness" the same way as for
 "constness" and "volatileness"?

 class X
 {   shared int i;
     void f() shared;  // X::f() only uses shared members.
 };

 -- Johan

--
-----------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden     |
| Email: jbn@lulea.telesoft.se; Voice: (+46) 92075471; Fax: (+46) 92075490  |
-----------------------------------------------------------------------------

In article <1991Jul24.021726.557@agate.berkeley.edu>, jbuck@forney.berkeley.edu (Joe Buck) writes:
> In article <1991Jul23.205711.13311@trantor.harris-atd.com> mvm@jedi.UUCP (Matt Mahoney) writes:
> >Instead of adding features to C++ until it's crushed under its own weight,
> >lets think about what we can remove.  We could do away with:
> >
> >* Multiple inheritence

> Vanilla multiple inheritance is not a problem.  The feature that
> grossly complicates the language is virtual base classes.  These
> are extraordinarily ugly and aren't worth the benefit they provide.

I expect that we'll see a lot more uses once templates and nested
classes come into wide use.  There's a distinction we have yet to start
making between those types that implement semantics for general use and
those that help to implement the semantics of another type.  When we
get templates, we'll start to use existing templates and we'll probably
graduate in a year or two to making fairly heavy use of the combination
in prepackaged type libraries--and both MI and virtual MI will probably
come into their own about then ...

> Tom Cargill (sp?) gave an excellent argument in a resent "Computing
> Systems" that multiple inheritance is almost never needed ...

    ... Tom Cargill not withstanding.  MI
is especially useful when we need to combine capabilities that occur
in different domains and that should be coded in their natural domains,
e.g. a Window (GUI domain) that is also an Error-Notifiable (programming
or application domain) combined to form an Error-Window.  Note that the
goal of this MI is not code sharing, but allowing the objects of one type
to respond to the member function calls of both types.

> >* The iostream library (use stdio.h)

> This is something you don't pay for if you don't use, so I don't see
> why you care if it's there or not.  You're free to use stdio.

True enough, but it would be nice if we got a greater return on our
investment for using  stream s.  Extra `handles' for providing formatting
information and making it available to user-defined types when they do I/O
would help.  Templates for manipulators (on the way, I believe ...) are
also mouth-waterin'.

> >* The "class" keyword (use "struct")
>
> Oh, come on.  This hardly complicates the language.

I agree, it's the silly suggestion of the week.

> >* Pointers to members
>
> Instead of having pointers to members, C++ would have been better
> with closures.

Both are needed, as far as I can see.  Perhaps we can get closures on the
cheap with a couple of templates?

> >* Friends
>
> Sometimes you need a friend, and they don't complicate the language.

Well ... they DO complicate the language, but I agree that they are
needed when you need semantics in one type more complicated than one type
can provide, or when the semantics of two types are intertwined.   And
there are good reasons for such intertwining, as when you want to provide
access to a type ONLY through another type.  (For example, a database-access-
descriptor for access to a database ...)

> >* Overloading "new"
>
> Would you want to go back to the kludgey assignment-to-this stuff
> that was needed in 1.2?  overloading new is much better.

Agreed.  This is the shortsighted suggestion of the month.  (If anything,
there are one or two subtleties that the current scheme lacks ...)

> >* Default arguments
>
> It is true that default arguments are unnecessary fluff.

Weeeelll ... yes, overloads can do the job.  But they do allow you to
write one function declaration/definition instead of two, and they may
keep a large class definition a bit shorter.  Moreover, when you see

 foo( int i, const char* cp = "" )

you know that one function handles both; if you have

 foo( int i ) { return foo( i, "" ); };
 foo( int i, const char* cp )
 {
  . . .

and you see the second definition/declaration but miss the first, you
won't realize that the functions share implementation.  It's a small
reason, but the mainatinability seems to pay off.

--

 (This man's opinions are his own.)
 From mole-end    Mark Terribile

>In article <1991Jul23.205711.13311@trantor.harris-atd.com>, mvm@jedi.harris-atd.com (Matt Mahoney) writes:

[complaining about a ton of features slowing C++ compilers down.]

-- I am only aware of a couple features in C++ that really slow compilers
down.  There's the problem within class declarations that things can
be used before declared, thus generally requiring an extra pass over class
declarations.  There's the problem with macro definitions in header
files, preventing a general solution to precompiled headers.  [If
you do this and this and this, and don't do this, that, or the other
thing, and run the compiler with such-and-such flag, then you can
precompile headers that might work in such-and-such a situation.]
Same preprocessor problems mucks up interpreters and incremental compilations.
Also, there are problems with the syntax in a few situations requiring
indefinite look-ahead.  So, its mainly a few poorly designed features
that slow down compilations -- not the ton of new features in general.

Instead of adding features to C++ until it's crushed under its own weight,
lets think about what we can remove.  We could do away with:

* Multiple inheritence
* The iostream library (use stdio.h)
* The "class" keyword (use "struct")
* Pointers to members
* Friends
* Overloading "new"
* Default arguments
* etc...

Yes, I know it will break code, but do we really want another Ada?
Features seem harmless, but once added, are added forever.  Compared with
C, C++ compilers are slower, are less portable, have more bugs, and are
more expensive.  Don't let C++ die of featuritis!

I welcome all flames.

--------------------------------
Matt Mahoney, mvm@epg.harris.com
#include <disclaimer.h>  // Or <disclaimer.hpp>, <iodisclaimer.h>, ARGGH!!!

In article <1991Jul23.205711.13311@trantor.harris-atd.com> mvm@jedi.UUCP (Matt Mahoney) writes:
>Instead of adding features to C++ until it's crushed under its own weight,
>lets think about what we can remove.  We could do away with:
>
>* Multiple inheritence

Vanilla multiple inheritance is not a problem.  The feature that
grossly complicates the language is virtual base classes.  These
are extraordinarily ugly and aren't worth the benefit they provide.

Tom Cargill (sp?) gave an excellent argument in a resent "Computing
Systems" that multiple inheritance is almost never needed and can
almost always be eliminated, but I've occasionally found "simple
multiple inheritance" (i.e. no virtual base classes) useful and
wouldn't want to lose it.

>* The iostream library (use stdio.h)

This is something you don't pay for if you don't use, so I don't see
why you care if it's there or not.  You're free to use stdio.

>* The "class" keyword (use "struct")

Oh, come on.  This hardly complicates the language.

>* Pointers to members

Instead of having pointers to members, C++ would have been better
with closures.

>* Friends

Sometimes you need a friend, and they don't complicate the language.

>* Overloading "new"

Would you want to go back to the kludgey assignment-to-this stuff
that was needed in 1.2?  overloading new is much better.

>* Default arguments

It is true that default arguments are unnecessary fluff.

>Yes, I know it will break code, but do we really want another Ada?
>Features seem harmless, but once added, are added forever.  Compared with
>C, C++ compilers are slower, are less portable, have more bugs, and are
>more expensive.  Don't let C++ die of featuritis!

You could eliminate most of the bugs from many C++ compilers simply
by getting rid of virtual base classes -- they are the easiest way
to get either g++ or cfront to core dump.

But it's too late now to do significant feature removal.

Now MY pet peeve is the multiple meanings of the "static" keyword.
A different keyword should have been chosen to indicate that a member
belongs to a class rather than to an individual object.  I find
that beginners repeatedly do

// in the .h file

class Bar;

class Foo {
 ...

 static Bar bletch;
};

// in the .cc file

static Bar Foo::bletch;

And why shouldn't they?  Why should the same keyword mean two radically
different things?  Of course, Foo::bletch will now be inaccessible outside
its file, because that's what "static" means in that position.  C had
two incompatible meanings of "static" and C++ added a third.  Too late
now, I suppose.

--
--
Joe Buck
jbuck@galileo.berkeley.edu  {uunet,ucbvax}!galileo.berkeley.edu!jbuck

In article <1991Jul23.205711.13311@trantor.harris-atd.com>, mvm@jedi.harris-atd.com (Matt Mahoney) writes:
|> Instead of adding features to C++ until it's crushed under its own weight,
|> lets think about what we can remove.  We could do away with:
|>
|> * Multiple inheritence

Can be usefull sometimes, we had a few cases where MI supplied the
most elegant and efficient solution.

|> * The iostream library (use stdio.h)

The iostream library is faster than stdio's printf.  In most of the
case the version of the overloaded operator << can be determined at
compile time while printf has to scan the line character per
character to determine which output facility for the given parameter
should be called.

|> * The "class" keyword (use "struct")

Agree.

|> * Pointers to members

They are seldom usefull.

|> * Friends

Usefull when you want to supply services (methods) to only a subset
of the classes.

|> * Overloading "new"

Very usefull to do memory management.

|> * Default arguments

Agree, use an inline overloaded method which supply the parameter to
the other one.

|> * etc...
|>
|> Yes, I know it will break code, but do we really want another Ada?
|> Features seem harmless, but once added, are added forever.  Compared with
|> C, C++ compilers are slower, are less portable, have more bugs, and are
|> more expensive.  Don't let C++ die of featuritis!
|>
|> I welcome all flames.
|>
|> --------------------------------
|> Matt Mahoney, mvm@epg.harris.com
|> #include <disclaimer.h>  // Or <disclaimer.hpp>, <iodisclaimer.h>, ARGGH!!!

--
Steve Juneau                            Recherches Bell-Northern Ltee
                                        3, Place du Commerce
phone: (514) 765-8246                   Verdun, Quebec, Canada
fax:   (514) 876-3681                   H3E 1H6

email: bnrmtl!stevej@larry.mcrcim.mcgill.edu

In comp.std.c++, mvm@jedi.harris-atd.com (Matt Mahoney) writes:

> Instead of adding features to C++ until it's crushed under its own weight,
> lets think about what we can remove.  We could do away with:

> * Multiple inheritence
> * The iostream library (use stdio.h)
> * The "class" keyword (use "struct")
> * Pointers to members
> * Friends
> * Overloading "new"
> * Default arguments
> * etc...

Gasp! A minimalist on comp.std.c++. Be still, my beating heart!  :-) :-)

But seriously, why don't you just stick to ANSI C?  After all, a few
macros should help you "simulate" inheritance, and then you can get rid
of "public", "private", etc., too. And once you start in with a machete,
who knows where you can end up?

ok, not so serious .. :-)
-----
Shankar Unni                                   E-Mail:
HP India Software Operation, Bangalore       Internet: shankar@india.hp.com
Phone : +91-812-261254 x417                      UUCP: ...!hplabs!hpda!shankar

In article <1991Jul24.021726.557@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>
>Now MY pet peeve is the multiple meanings of the "static" keyword.

So I am not alone in the world after all with this one!

Indeed, here is my suggestion.

1. To declare variables private to a module, use private, not static. (Static
   must of course still be allowed for compatibility with older dialects, like
   BCPL.)
 private int x = 0;
   N.B. It is unfortunate that public visibility of global data in modules is
   the default, and this suggestion doesn't resolve that.

2. To declare variables static in a block, keep on using static.
   main()
   {   static int a[100000];
       // ...
   }

3. To declare variables shared in a class, use shared.

   class X
   {   shared int i;
       // ...
   };

   Sorry, I have no suggestion how to call static member functions.
   I realize that "shared" introduces yet another keyword, and it will break
   code containing such lines as typedef int (*shared)();. Ok, then use
   "until". Clearly, this can be unambiguously parsed.

Cay


>A different keyword should have been chosen to indicate that a member
>belongs to a class rather than to an individual object.  I find
>that beginners repeatedly do
>
>// in the .h file
>
>class Bar;
>
>class Foo {
> ...
>
> static Bar bletch;
>};
>
>// in the .cc file
>
>static Bar Foo::bletch;
>
>And why shouldn't they?  Why should the same keyword mean two radically
>different things?  Of course, Foo::bletch will now be inaccessible outside
>its file, because that's what "static" means in that position.  C had
>two incompatible meanings of "static" and C++ added a third.  Too late
>now, I suppose.
>
>--
>--
>Joe Buck
>jbuck@galileo.berkeley.edu  {uunet,ucbvax}!galileo.berkeley.edu!jbuck