speaking of typename (see Scott Meyers' post
http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/8eb68b18da1e93ad/24685e19275ff9e6#24685e19275ff9e6)

I always thought typename should be used to forward declare a
class/struct:

ie

class Foo;

//...

class Foo
{
//...
};

should be

typename Foo;

//...

class Foo
{
//...
};

so that the forward declaration need not know whether Foo is a class or
struct or whatever.  (And so that if Foo changes from a struct to a
class, etc, then the header where Foo if foward-declared doesn't need
to change, and less code needs to recompile, etc)

Any thoughts?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony wrote:

> speaking of typename (see Scott Meyers' post
> http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/8eb68b18da1e93ad/24685e19275ff9e6#24685e19275ff9e6)
>
> I always thought typename should be used to forward declare a
> class/struct:
>
> ie
>
> class Foo;
>
> //...
>
> class Foo
> {
> //...
> };
>
> should be
>
> typename Foo;
>
> //...
>
> class Foo
> {
> //...
> };
>
> so that the forward declaration need not know whether Foo is a class or
> struct or whatever.

But we want to know if it's a class or not (and we don't care if
the class is introduced with the "struct" keyword).

Right now, it's legal to write

   class Foo; // forward declaration
   struct Foo {}; // defined here

and we don't want to allow

   typename a;
   typename b;
   typedef int a;
   typedef struct {} b;

> (And so that if Foo changes from a struct to a
> class, etc, then the header where Foo if foward-declared doesn't need
> to change, and less code needs to recompile, etc)
>
> Any thoughts?

That's already legal today, though MSVC++6 is still widespread and
has trouble with it.

-- James

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1107216492.557057.308370@c13g2000cwb.googlegroups.com>, Tony
<gottlobfrege@gmail.com> writes
>I always thought typename should be used to forward declare a
>class/struct:

But a class/struct name isn't any old type name. It specifically isn't
an enum or a typedef name for a fundamental type or a derivative name
such as a T* or a T&
>
>ie
>
>class Foo;
>
>//...
>
>class Foo
>{
>//...
>};
>
>should be
>
>typename Foo;
>
>//...
>
>class Foo
>{
>//...
>};
>
>so that the forward declaration need not know whether Foo is a class or
>struct or whatever.  (And so that if Foo changes from a struct to a
>class, etc, then the header where Foo if foward-declared doesn't need
>to change, and less code needs to recompile, etc)

However it is not supposed to matter which keyword you use to (forward)
declare a class/struct name. The ways in which you can use a
user-defined type without a visible definition do not have any reliance
on whether the type is declared as a struct or a class.

Compilers that treat such declarations as different are, AFAIK, not
conforming.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> and we don't want to allow

>   typename a;
>   typename b;
>   typedef int a;
>   typedef struct {} b;
don't we?  I've been wondering if maybe we do.  Why not?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony wrote:
>> and we don't want to allow
>
>>   typename a;
>>   typename b;
>>   typedef int a;
>>   typedef struct {} b;
> don't we?  I've been wondering if maybe we do.  Why not?

On word-addressable machines, byte pointers differ in representation,
and sometimes size, from word pointers.  Since the language allows the
definition of functions that receive and pass around pointers to
incomplete types, it must be possible to tell what kind of pointer
representation will be used even for a pointer to an incomplete type.
Hence the lack of provision for forward declarations of type aliases.

Arguably it ought to be possible to use a word pointer for a class
type that is word-aligned, which can't be known if it is incomplete,
but the possibility of circular references in class definitions makes
forward declarations essential.  So by convention pointer-to-class
types are represented as byte pointers.  At least, they were in C
implementations; I don't know that there are any C++ implementations
on word-addressable machines.

--
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony wrote:
> speaking of typename (see Scott Meyers' post
>
http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/8eb68b18da1e93ad/24685e19275ff9e6#24685e19275ff9e6)

> I always thought typename should be used to forward declare a
> class/struct:

> ie

> class Foo;

> //...

> class Foo
> {
> //...
> };

> should be

> typename Foo;

> //...

> class Foo
> {
> //...
> };

Forward declarations only work if the compiler knows that it is
a class.  So using the class, struct or union keyword seems more
appropriate to me.

> so that the forward declaration need not know whether Foo is a
> class or struct or whatever.

It needs to know that Foo is a class.

> (And so that if Foo changes from a struct to a class, etc,
> then the header where Foo if foward-declared doesn't need to
> change, and less code needs to recompile, etc)

Foo can't change from a struct to a class; a struct is just a
specialized form of a class, and the forward declaration doesn't
commit on the form.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning Ben Hutchings,

Ben Hutchings schrieb:

>On word-addressable machines, byte pointers differ in representation,
>and sometimes size, from word pointers.  Since the language allows the
>definition of functions that receive and pass around pointers to
>incomplete types, it must be possible to tell what kind of pointer
>representation will be used even for a pointer to an incomplete type.
>Hence the lack of provision for forward declarations of type aliases.
>
>Arguably it ought to be possible to use a word pointer for a class
>type that is word-aligned, which can't be known if it is incomplete,
>but the possibility of circular references in class definitions makes
>forward declarations essential.  So by convention pointer-to-class
>types are represented as byte pointers.  At least, they were in C
>implementations; I don't know that there are any C++ implementations
>on word-addressable machines.
>

I don't think, that the pointer size indeterminancy is the cruzial point
here. Interestingly the language
allows something like

class B;
typedef void (B::* PMV)() ;
PMV var = 0;

although at the point of definition of var it is unknown, whether var
might point to a virtual member
function or not or whether class B itself has virtual base classes. So
the compiler has the same
problem here to be unaware of possible targets of var and usually must
assume the worst case.

Greetings from Bremen,

Daniel

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ben Hutchings wrote:
> Tony wrote:
> >> and we don't want to allow

> >>   typename a;
> >>   typename b;
> >>   typedef int a;
> >>   typedef struct {} b;
> > don't we?  I've been wondering if maybe we do.  Why not?

> On word-addressable machines, byte pointers differ in
> representation, and sometimes size, from word pointers.  Since
> the language allows the definition of functions that receive
> and pass around pointers to incomplete types, it must be
> possible to tell what kind of pointer representation will be
> used even for a pointer to an incomplete type.  Hence the lack
> of provision for forward declarations of type aliases.

> Arguably it ought to be possible to use a word pointer for a
> class type that is word-aligned, which can't be known if it is
> incomplete, but the possibility of circular references in
> class definitions makes forward declarations essential.  So by
> convention pointer-to-class types are represented as byte
> pointers.  At least, they were in C implementations; I don't
> know that there are any C++ implementations on
> word-addressable machines.

The convention I'm familiar with is that pointer-to-class types
(and pointer-to-struct types in C) were represented by word
pointers.  This meant, of course, that classes had to be word
aligned, and potentially padded, but typically, byte addressing
was significantly slower than word addressing, and only used
when absolutely necessary.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ben Hutchings wrote:
> Tony wrote:
> >> and we don't want to allow

> >>   typename a;
> >>   typename b;
> >>   typedef int a;
> >>   typedef struct {} b;
> > don't we?  I've been wondering if maybe we do.  Why not?

> On word-addressable machines, byte pointers differ in
> representation, and sometimes size, from word pointers.  Since
> the language allows the definition of functions that receive
> and pass around pointers to incomplete types, it must be
> possible to tell what kind of pointer representation will be
> used even for a pointer to an incomplete type.  Hence the lack
> of provision for forward declarations of type aliases.

> Arguably it ought to be possible to use a word pointer for a
> class type that is word-aligned, which can't be known if it is
> incomplete, but the possibility of circular references in
> class definitions makes forward declarations essential.  So by
> convention pointer-to-class types are represented as byte
> pointers.  At least, they were in C implementations; I don't
> know that there are any C++ implementations on
> word-addressable machines.

The convention I'm familiar with is that pointer-to-class types
(and pointer-to-struct types in C) were represented by word
pointers.  This meant, of course, that classes had to be word
aligned, and potentially padded, but typically, byte addressing
was significantly slower than word addressing, and only used
when absolutely necessary.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 10 Feb 2005 13:17:05 CST, kanze@gabi-soft.fr wrote:

> Ben Hutchings wrote:
> > Tony wrote:
<snip>
> > On word-addressable machines, byte pointers differ in
> > representation, and sometimes size, from word pointers.  <snip>
> > Arguably it ought to be possible to use a word pointer for a
> > class type that is word-aligned, which can't be known if it is
> > incomplete, but the possibility of circular references in
> > class definitions makes forward declarations essential.  So by
> > convention pointer-to-class types are represented as byte
> > pointers.  At least, they were in C implementations; I don't
> > know that there are any C++ implementations on
> > word-addressable machines.
>
> The convention I'm familiar with is that pointer-to-class types
> (and pointer-to-struct types in C) were represented by word
> pointers.  This meant, of course, that classes had to be word
> aligned, and potentially padded, but typically, byte addressing
> was significantly slower than word addressing, and only used
> when absolutely necessary.

The Tandem^WCompaq^WHP NonStop 1 (aka original) had different (16-bit)
word and byte pointers/addressing; it did not have a C implementation,
but was carried forward as a subset of the TNS 2 architecture and one
memory model of the C implementation thereon, still supported in
emulation on the successor TNS/R. That model does indeed use word
pointers for structs (and unions) and aligns and pads to a word
(2-byte) boundary. Byte access was not as far as I recall slower on
real TNS CPUs, and is probably slightly faster on the current
emulation -- at least it requires slightly fewer instructions, since
the underlying hardware is now byte, though with modern CPUs time (and
speed) is no longer such a simple function of instructions. It is
however limited to the lower 32KW of small model's 64KW data space
which is sufficient for normal variables but not for some "system"
data that is used by the runtime and/or other languages particularly
Tandem's own (semi-legacy) SIL TAL, and which one might reasonably
want to access in another SIL C.

The TNS-mode C++ implementation does not support small model at all --
though as it is (still!) cfront+C based I think it technically could.
They probably judged, I think rightly, that no one would really need
C++ for programs that could be fit in rather less than 64KB data and
(originally) 64KW code, and as they already needed to deal with
16/32-bit data in TNS mode it wasn't worth the additional complexity.

(The "native" C and C++ on new systems are both flat-byte 32-bit.)

- David.Thompson1 at worldnet.att.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]