Scott Johnson <sj_nospam@nospam.aracnet.com> writes:

>Mirek Fidler wrote:
>>
>> Hoshi Takanori wrote:
>>
>> > I believe that "inherited" should be in the standard because it is
>> > one of the most pricipal idioms in object-oriented programming to
>> > call a member function of the direct base class.
>>
>>     So do I. Well, you can fake it by:
>>
>> class Alfa : public Beta {
>>     typedef Beta inherited;
>> };
>
>Another problem:  What happens if a class doesn't inherit anything?  If
>the class inherits multiple base classes?
>
>Java has the luxury of all classes having exactly one base class (except
>of course for Object), thus Java's "super" keyword makes sense there.
>In C++, this ain't the case.  It would be a major headache if a class
>uses "inherited", and then gets a second base class (and all uses of
>inherited thus fail.)

But that is *exactly* why a built-in language construct would be better
than the typedef work-around!  The typedef work-around can't handle
multiple inheritence, whereas with a built-in language construct
the compiler could use ordinary ambiguity resolution.

This topic has been discussed (to death) several times before on this
newsgroup.  If you're interested in this topic, I suggest you read those
old threads with DejaNews...

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Mirek Fidler wrote:
>
> Hoshi Takanori wrote:
>
> > In article <344a9862.0@hades.ndirect.co.uk> "lg"
> > <lg@mail.ndirect.co.uk> writes:
> >
> > > In "The Design and Evolution of C++" Bjarne Stroustrup uses the
> > inherited::
> > > keyword extension proposal as a textbook example of an unnecessary
> > addition.
> >
> > I believe that "inherited" should be in the standard because it is
> > one of the most pricipal idioms in object-oriented programming to
> > call a member function of the direct base class.
>
>     So do I. Well, you can fake it by:
>
> class Alfa : public Beta {
>     typedef Beta inherited;
> };

Another problem:  What happens if a class doesn't inherit anything?  If
the class inherits multiple base classes?

Java has the luxury of all classes having exactly one base class (except
of course for Object), thus Java's "super" keyword makes sense there.
In C++, this ain't the case.  It would be a major headache if a class
uses "inherited", and then gets a second base class (and all uses of
inherited thus fail.)



Scott
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> class A {
>     ...
> };
>
> typedef A B_inherited;
> class A : public B_inherited {
>     typedef B_inherited inherited;
>     ...
> };
>
> typedef A C_inherited;
> class A : public C_inherited {
>     typedef C_inherited inherited;
>     ...
> };
>
> now each classes base class is only defined in one place - so you
> cannot get
> into trouble.

  I believe you could manage it such a way, but it seems to me to be as
cryptic and verbose as removing 'virtual' keyword a replaceit by
pointers-to-function memebers...

Mirek
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <344a9862.0@hades.ndirect.co.uk> "lg" <lg@mail.ndirect.co.uk> writes:

> In "The Design and Evolution of C++" Bjarne Stroustrup uses the inherited::
> keyword extension proposal as a textbook example of an unnecessary addition.

I believe that "inherited" should be in the standard because it is
one of the most pricipal idioms in object-oriented programming to
call a member function of the direct base class.

> OK. This is only a warning not an error. But I really like clean compiles.
> What does it mean? How can I get rid of it?

Well, M$VC++ has a pragma to supress the specific warnings.  Try:

    #pragma warning (disable : 4097)

hoshi
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

lg wrote:
>
> In "The Design and Evolution of C++" Bjarne Stroustrup uses the inherited::
> keyword extension proposal as a textbook example of an unnecessary addition.
> He suggests that
> class derived : public ancestor {
> typedef ancestor inherited;
> ....
> }
> would work as well.
> I have been using inherited this way with BC++.
> Unfortunately, the same idiom on the Microsoft compiler gives me the
> following warning:

The following code compiles w/o warning on Visual C++ 5.0:

struct Base {
  int value;
};

struct Derived : public Base {
  typedef Base inherited;
  int another;
};

so I'm not sure what the problem is.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 20 Oct 97 12:52:32 GMT, aGriffiths@ma.ccngroup.com (Alan Griffiths)
wrote:

>Sadly the standard does not disallow diagnostics for correct code.

I think "sadly" is the wrong word. I would have said "happily". :-)

You can write dangerous code that does not violate any language rule.
Examples: Assigning a double value to a char variable without a cast.
Creating a class with virtual functions but no virtual destructor.

Some frequent typographical errors result in valid code, like writing
while(x=y) instead of while(x==y).

An implementation is allowed to warn about the legal (but
questionable) code. Maybe you don't want to get the warnings. Maybe
the compiler warns about too many things. You can take those issues up
with the vendor. I don't think the standard should disallow the
warnings.

>Would it be feasible to mandate that diagnostics be catagorised ...

I think such attempts constrain implementations too much and stifle
innovation. Given all the other variables among platforms and
implementations, I don't see much benefit for users.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Gerard Weatherby wrote in message <344BFF16.64C@alum.mit.edu>...
in reply to my report of Visual C++ 5.0 warnings over the inherited typedef
>
>The following code compiles w/o warning on Visual C++ 5.0:
>
>struct Base {
> int value;
>};
>
>struct Derived : public Base {
> typedef Base inherited;
> int another;
>};
>

The warning comes when one actually tries to use the inherited keyword. Add
a function to struct:
struct Base {
 int value;
};

struct Derived : public Base {
     typedef Base inherited;
    void test() {inherited::value = 3;}        // added
};

warning C4097: typedef-name 'inherited' used as synonym for class-name
'Derived::Base'

of course, normally one would use inherited:: for calling inherited virtual
functions.
I am not so much interested in getting rid of the warning as understanding
what it means.
Leo
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

lg wrote in message <344a9862.0@hades.ndirect.co.uk>...
...
>Unfortunately, the same idiom on the Microsoft compiler gives me the
>following warning:
>
>warning C4097: typedef-name 'inherited' used as synonym for class-name
>'TLElementDraw::TLObjectDraw'
>which is explained in the help file as:
>
>"typedef-name 'identifier1' used as synonym for class-name 'identifier2'

Can you give a concrete example?  If it's the same as the method used below,
I think I see what's going on.

...
>typedef struct _T
>{
>    int i;
>} T;

This idiom is unnecessary and undesirable in C++.  It's also not strictly
legal, since identifiers beginning with "_" ar reserved to the
implementation.  You should say:

struct T { int i; };

In C++, you can then use T without the "struct" keyword, just as you would
the typedef name.

If the code needs to be shared with C, look at alternative ways to handle
the typedef to make things clean for C.  If you must keep a similar approach
to the above, at least use identifiers like "T_", which are legal, rather
than the illegal "_T".

>struct U : T
>{
>    int j;
>};               // warning

What it's warning you about here is that you've used a typedef name as if it
were a clss name.  It's a warning because it's depending on T being a
typedef for a class rather than something else.  The code will work fine,
but it's not necessarily the best practice.  Given that you're assuming
knowledge of the structure anyway, you might as well refer to the dummy
identifer.

>struct V : _T
>{
>    int j;
>};               // OK"

I assume you're using private inheritance and structs for the sake of
brevity, and not because you do this in your code, yes?  Containment is
usually better than private inheritance (though private inheritance
definitely has its uses), and structs should be avoided whenever possible.

--
----------------------------------------------------------------------------
Brad Daniels                  |  Was mich nicht umbringt macht mich hungrig.
Mission Critical Software     |   - Otto Nietzche
Standard disclaimers apply    |     (Friedrich's corpulent brother)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hoshi Takanori wrote:

> In article <344a9862.0@hades.ndirect.co.uk> "lg"
> <lg@mail.ndirect.co.uk> writes:
>
> > In "The Design and Evolution of C++" Bjarne Stroustrup uses the
> inherited::
> > keyword extension proposal as a textbook example of an unnecessary
> addition.
>
> I believe that "inherited" should be in the standard because it is
> one of the most pricipal idioms in object-oriented programming to
> call a member function of the direct base class.

    So do I. Well, you can fake it by:

class Alfa : public Beta {
    typedef Beta inherited;
};

    But often you need to make some changes in class hierarchy, e.g.
insert some class beetween Alfa and Beta:

class SomeClass : public Beta {
.....
......
class Alfa : public SomeClass {
......
};

    At this moment, if you forget to change typedef too (and it is not
unlikely), you can get into troubles...

Mirek
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

How about this then...

class A {
    ...
};

typedef A B_inherited;
class A : public B_inherited {
    typedef B_inherited inherited;
    ...
};

typedef A C_inherited;
class A : public C_inherited {
    typedef C_inherited inherited;
    ...
};

now each classes base class is only defined in one place - so you cannot get
into trouble.

Another way, of course is

class A {
    ...
};

#define B_inherited A
class A : public B_inherited {
    typedef B_inherited inherited;
    ...
};

#define C_inherited A
class A : public C_inherited {
    typedef C_inherited inherited;
    ...
};

Neither of these removes the informational warning about using a typedef
where a class name is more usual.  But they do make the code safer if/when
class hierarchies change.

Roger


Mirek Fidler wrote in message <344CE9DB.CE1655D@cslab.felk.cvut.cz>...
>Hoshi Takanori wrote:
>> In article <344a9862.0@hades.ndirect.co.uk> "lg"
>> <lg@mail.ndirect.co.uk> writes:
>> > In "The Design and Evolution of C++" Bjarne Stroustrup uses the
>> inherited::
>> > keyword extension proposal as a textbook example of an unnecessary
>> addition.
>> I believe that "inherited" should be in the standard because it is
>> one of the most pricipal idioms in object-oriented programming to
>> call a member function of the direct base class.
>    So do I. Well, you can fake it by:
>class Alfa : public Beta {
>    typedef Beta inherited;
>};
>    But often you need to make some changes in class hierarchy, e.g.
>insert some class beetween Alfa and Beta:
>class SomeClass : public Beta {
>.....
>......
>class Alfa : public SomeClass {
>......
>};
>    At this moment, if you forget to change typedef too (and it is not
>unlikely), you can get into troubles...
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In "The Design and Evolution of C++" Bjarne Stroustrup uses the inherited::
keyword extension proposal as a textbook example of an unnecessary addition.
He suggests that
class derived : public ancestor {
typedef ancestor inherited;
....
}
would work as well.
I have been using inherited this way with BC++.
Unfortunately, the same idiom on the Microsoft compiler gives me the
following warning:

warning C4097: typedef-name 'inherited' used as synonym for class-name
'TLElementDraw::TLObjectDraw'
which is explained in the help file as:

"typedef-name 'identifier1' used as synonym for class-name 'identifier2'

A typedef name which names a class is itself a class name. However, only a
class declared without a tag can be named. In the following line of code the
typedef name P is promoted to class name but Q is not.


typedef struct { int member; } P, Q;
Q remains a normal typedef name and a synonym for the class.
The following example causes this warning:


typedef struct _T
{
    int i;
} T;
struct U : T
{
    int j;
};               // warning
struct V : _T
{
    int j;
};               // OK"


OK. This is only a warning not an error. But I really like clean compiles.
What does it mean? How can I get rid of it?
typedef class ancestor inherited; doesn't work any better.
What I have always wanted to do is to turn on all the warnings the compilers
tell me and modify the code until they disappear. Compiler warnings IMHO are
there to point out possible sources of error or misunderstandings between
the compiler's interpretation of the code and yours ;->. Unnecessary and
unremovable warning are therefore a real pain. I hope this is not one of
them.
(P.S. the standard library includes at this warning level also provide lots
of warnings inside those headers on clean code :-<)

Llew
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article: <344a9862.0@hades.ndirect.co.uk>  "lg" <lg@mail.ndirect.co.uk> writes:
> Unfortunately, the same idiom on the Microsoft compiler gives me the
> following warning:
>
> warning C4097: typedef-name 'inherited' used as synonym for class-name
> 'TLElementDraw::TLObjectDraw'
> which is explained in the help file as:

Sadly the standard does not disallow diagnostics for correct code.

> OK. This is only a warning not an error. But I really like clean compiles.
> What does it mean? How can I get rid of it?
> typedef class ancestor inherited; doesn't work any better.
> What I have always wanted to do is to turn on all the warnings the compilers
> tell me and modify the code until they disappear. Compiler warnings IMHO are
> there to point out possible sources of error or misunderstandings between
> the compiler's interpretation of the code and yours ;->. Unnecessary and
> unremovable warning are therefore a real pain. I hope this is not one of
> them.
> (P.S. the standard library includes at this warning level also provide lots
> of warnings inside those headers on clean code :-<)

I agree with your intent.  But this is a "quality of implementation"
issue not a language standards one.

FWIW I have a "kitchen sink" header that disables the erronious diagnostics
from MSVC and those that relate to implementation deficiencies (e.g.
the warning that template instantiations have names too long for the
debugger).

Also I either wrap MS headers to disable the diagnostics they generate
or (in extreme cases - like plauger's standard library) take copies under
source control and fix them.

None of this would be necessary in a high quality implementation, but
MS only aim at "good enough to sell".

(Trying to get back on the standards track...)

Would it be feasible to mandate that diagnostics be catagorised as:

 1  violation of language standard
 2  use of undefined behaviour [where detected]
 3  use of implementation defined behaviour
 4  exeeding implementation limits
 5  use of implementation specific extensions
 6  syntax flagged as possible error

And that items in the latter two catagories are easily distinguished
from the others.
__
Alan Griffiths              | Senior Systems Consultant, Experian (Formerly CCN)
alan.griffiths@experian.com (agriffiths@ma.ccngroup.com, Tel. +44 115 934 4517)
(ACCU C++ SIG organiser     | <http://www.accu.org/> alan@octopull.demon.co.uk)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]