Topic: Forward Declarations


Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Wed, 7 Apr 2010 15:17:18 CST
Raw View
On 7 Apr., 19:20, REH <spamj...@stny.rr.com> wrote:
> Will the next standard address the difficulty of forward declaring
> types that aren't simple classes or structs, such as typedefs or
> classes instantiated from templates?  I mean, it would be nice to
> simple do this:
>
> typedef X;

Not really.

> Or, this:
>
> class X;

This is already valid, but works only for class types.

> without having to know the details for X (e.g., whether or not it was
> instantiated from a template or what that template looked like).

No, this will not be supported. The only relevant new forward
declaration is that of enumeration types with fixed underlying
type (which is named a "opaque-enum-declaration"), e.g.

enum MyEnum : int;

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: REH <spamjunk@stny.rr.com>
Date: Thu, 8 Apr 2010 00:23:56 CST
Raw View
On Apr 7, 5:17 pm, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
wrote:
> This is already valid, but works only for class types.
>
> > without having to know the details for X (e.g., whether or not it was
> > instantiated from a template or what that template looked like).
>
> No, this will not be supported. The only relevant new forward
> declaration is that of enumeration types with fixed underlying
> type (which is named a "opaque-enum-declaration"), e.g.
>

Thanks.

Just to be clear (in case anyone else responds): all I am saying is
that it would be nice to just say:

class X;

regardless of whether X is a class, a typedef of a class, or an
instantiation of class template.

Thanks,

REH


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: =3D?ISO-8859-1?Q?Daniel_Kr=3DFCgler?=3D <daniel.kruegler@googlemail.c=.om>
Date: Thu, 8 Apr 2010 12:59:06 CST
Raw View
On Apr 8, 8:23 am, REH <spamj...@stny.rr.com> wrote:
> On Apr 7, 5:17 pm, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
> wrote:
>
> > This is already valid, but works only for class types.
>
> > > without having to know the details for X (e.g., whether or not it was
> > > instantiated from a template or what that template looked like).
>
> > No, this will not be supported. The only relevant new forward
> > declaration is that of enumeration types with fixed underlying
> > type (which is named a "opaque-enum-declaration"), e.g.
>
> Thanks.
>
> Just to be clear (in case anyone else responds): all I am saying is
> that it would be nice to just say:
>
> class X;
>
> regardless of whether X is a class, a typedef of a class, or an
> instantiation of class template.

But declaring

class X;

has already a specific meaning, so in either case if you want a more
general forward declaration style this should be something as you
suggested before

typedef X;

or so. The question is, what you want to realize with this. If X can
be *any* type, there are a lot some constructions that may not
work. If I have

class X;

today, I can rely on the fact that I can also define

X* p;

Now consider a much more general forwarding like

typedef X;

If X can be *any* type, the above pointer definition is not
guaranteed to be well-formed. Consider:

class X;
typedef X& XR;
XR* p; // Error: No Pointer to references!

Assume now that you had declared:

typedef XR;

This means that we cannot support

XR* p;

because - depending on the actual type of
XR, this may not be a supported construction.

Now assume that from this lesson we conclude
that only non-reference types can be forwarded
in this way. This is still insufficient, because e.g.
of linkage issues. Declaring

extern "C" {
 class X;
}

does always work, but declaring

extern "C" {
 template<class T> struct X;
}

or

template<class T> struct X;

extern "C" {
 template<> struct X<int>;
}

is ill-formed, because a template specialization cannot
have C linkage. This means again that we cannot
guarantee that

extern "C" {
 typedef X;
}

will be well-formed, if it turns out that X is a specialization of
a class template.

The example of /opaque-enum declarations/ is another
example: As you see, your perfect general forwarding style
is also not supported here, because you need to specify an
underlying type. The reason is similar as the pointer
problem described above for references, because a compiler
may not produce meaningful code for definitions like

enum E;
E* pe; // Which pointer representation?

with the absence of this information.

Concluding, there are several subtle problems to solve before
being able to provide this feature and in the end we need to
ask what the advantage of this additional specification
overhead is.

HTH & Greetings from Bremen,

Daniel Kr=FCgler



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Colin <google@icemx.net>
Date: Thu, 8 Apr 2010 18:26:45 CST
Raw View
On Apr 8, 8:23 am, REH <spamj...@stny.rr.com> wrote:
>
> Just to be clear (in case anyone else responds): all I am saying is
> that it would be nice to just say:
>
> class X;
>
> regardless of whether X is a class, a typedef of a class, or an
> instantiation of class template.

A couple of days ago, in a post titled "Small Ideas for Future C++" I
suggested

typename X;

to forward-declare something without saying what it is, but as
Daniel's replies show, it doesn't seem to be quite as simple as we
would hope...

...although I'd guess it to be a reasonably wide-spread issue (both
the "unable to forward-declare typedefs" and the uniform declaration
syntax for arbitrary things).

Ciao, Colin


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: REH <spamjunk@stny.rr.com>
Date: Fri, 9 Apr 2010 11:57:39 CST
Raw View
On Apr 8, 2:59 pm, =?ISO-8859-1?Q?Daniel_Kr=FCgler?=
<daniel.krueg...@googlemail.c=.om> wrote:
> But declaring
>
> class X;
>
> has already a specific meaning,

Yes, but regardless of how classes are ultimately defined, their
pointer types all share the same representation. So, I don't see the
harm in expanding its meaning.

>so in either case if you want a more
> general forward declaration style this should be something as you
> suggested before
>
> typedef X;
>
> or so.

My phrasing could have been better. I didn't mean to suggest this for
all types. I meant it only for structs and classes. Since different
pointer types may have different representations, this would not be
feasibility in the general case.

REH


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Yechezkel Mett <ymett.on.usenet@gmail.com>
Date: Mon, 12 Apr 2010 12:07:57 CST
Raw View
On Apr 9, 8:57 pm, REH <spamj...@stny.rr.com> wrote:
> On Apr 8, 2:59 pm, =?ISO-8859-1?Q?Daniel_Kr=FCgler?=
>
> <daniel.krueg...@googlemail.c=.om> wrote:
> > But declaring
>
> > class X;
>
> > has already a specific meaning,
...
> My phrasing could have been better. I didn't mean to suggest this for
> all types. I meant it only for structs and classes. Since different
> pointer types may have different representations, this would not be
> feasibility in the general case.

It's already available for structs and classes.

class X;

struct X {};

is legal. (Although I did come across a bug in MSVC with certain
combinations, giving me a linker error.)

Yechezkel Mett


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Yechezkel Mett <ymett.on.usenet@gmail.com>
Date: Tue, 13 Apr 2010 17:53:36 CST
Raw View
On Apr 12, 9:07 pm, Yechezkel Mett <ymett.on.use...@gmail.com> wrote:
> On Apr 9, 8:57 pm, REH <spamj...@stny.rr.com> wrote:
>
> > On Apr 8, 2:59 pm, =?ISO-8859-1?Q?Daniel_Kr=FCgler?=
>
> > <daniel.krueg...@googlemail.c=.om> wrote:
> > > But declaring
>
> > > class X;
>
> > > has already a specific meaning,
> ...
> > My phrasing could have been better. I didn't mean to suggest this for
> > all types. I meant it only for structs and classes. Since different
> > pointer types may have different representations, this would not be
> > feasibility in the general case.
>
> It's already available for structs and classes.
>
> class X;
>
> struct X {};
>
> is legal. (Although I did come across a bug in MSVC with certain
> combinations, giving me a linker error.)

I see I missed the point. You want to forward declare typedefs. The
problem with that is that typedefs have no linkage, so there'd be no
way to know which class the typedef refers to.

Consider:

// a.hpp
class A {};
typedef A T;

// b.hpp
class B {};
typedef B T;

// c.cpp
typedef T;
void f(T*);

What type will f take?

Now if you suggest giving typedefs linkage (aside from backward
compatibility issues) consider the following:

// a.cpp
class A {};
typedef A T;

// b.cpp
typedef T;
void f(T*);

// c.cpp
class A;
void f(A*);

The two declarations of f are the same function. But it's going to
take a smart linker to work that out, and traditionally C++ has not
expected that kind of intelligence from a linker.

Yechezkel Mett


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Miles Bader <miles@gnu.org>
Date: Tue, 13 Apr 2010 18:31:37 CST
Raw View
Yechezkel Mett <ymett.on.usenet@gmail.com> writes:
>> My phrasing could have been better. I didn't mean to suggest this for
>> all types. I meant it only for structs and classes. Since different
>> pointer types may have different representations, this would not be
>> feasibility in the general case.
>
> It's already available for structs and classes.
> class X;
> struct X {};
>
> is legal.

The case I've come across, was where I have:

  a.h:
    class A { int field };
  b.h:
    class A;   // we're just using a pointer to A
    class B { A *ptr; };
  c.c:
    #include "a.h"
    #include "b.h"

and then A later gets changed to a typedef of a template
instantiation, but is essentially pretty much the same class as the
old non-template definition:

  a.h:
    template<typename T> class GeneralA { T field; };
    typedef GeneralA<int> A;
  b.h:
    class A;   // we're just using a pointer to A
    class B { A *ptr; };
  c.c:
    #include "a.h"
    #include "b.h"

... which of course doesn't compile, even though A hasn't "really"
changed.

This can usually be worked around, but it's kind of annoying that
it's necessary to do so (in a real program, just adding an include
of "a.h" to "b.h" can in some cases end up causing circular-include
issues etc)...

-Miles

--
Yo mama's so fat when she gets on an elevator it HAS to go down.

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: REH <spamjunk@stny.rr.com>
Date: Wed, 7 Apr 2010 11:20:33 CST
Raw View
Will the next standard address the difficulty of forward declaring
types that aren't simple classes or structs, such as typedefs or
classes instantiated from templates?  I mean, it would be nice to
simple do this:

typedef X;

Or, this:

class X;

without having to know the details for X (e.g., whether or not it was
instantiated from a template or what that template looked like).

REH

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Stephen Clamage <stephen.clamage@sun.com>
Date: Sat, 13 Apr 2002 23:43:28 GMT
Raw View
On Wed, 10 Apr 2002 16:22:56 GMT, Vincent Finn
<1@2.com.cos.agilent.com> wrote:

>On a similar note
>it would be nice to be able to forward declare nested classes too !
>

You cannot forward declare a member of a class because it woud allow
anyone to add to or hijack members of a class without modifying the
class definition. It also makes code maintainance more difficult. A
declaration should appear in only one place.

Put the class definition in a header and include the header when you
need to know more about the class than just its name.
---
Steve Clamage, stephen.clamage@sun.com

---
[ 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                       ]





Author: "nmtop40" <neil@nmtop40.homechoice.co.uk>
Date: Tue, 9 Apr 2002 22:58:33 GMT
Raw View
There are 2 forward declarations I would like to see "legalised" which are
not at present.
Plus there is something else I would like to see made legal.

Firstly, the problem with a typedef. It would be nice if you could forwardly
declare something
that is actually a typedef. For example:

class std::string;

// then stuff that uses string

This is illegal because std::string is not actually a class but a typedef of
std::basic_string< char >;
(Ok, if you don't like that, let us use typename)

I would also like to see it made legal to show a class's inheritance as a
forward declaration. For
example:

class A : public SomeBase;

You would, of course, subsequently get an error (possibly a link-error?) if
A were not actually
derived from SomeBase.

Finally, it would be nice to allow . (or ->) to access class typedefs. Eg:

std::vector< X > myVect;
myVect.iterator it;

This can look a lot tidier, and surely it would be easy for compilers.




---
[ 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                       ]





Author: Herb Sutter <hsutter@acm.org>
Date: Wed, 10 Apr 2002 07:36:53 GMT
Raw View
On Tue,  9 Apr 2002 22:58:33 GMT, "nmtop40" <neil@nmtop40.homechoice.co.uk>
wrote:
>Firstly, the problem with a typedef. It would be nice if you could forwardly
>declare something that is actually a typedef. For example:
>
>class std::string;
>
>// then stuff that uses string
>
>This is illegal because std::string is not actually a class but a typedef of
>std::basic_string< char >;

Forward declarations of typedefs are a fairly commonly-requested feature and
may get added to C++0x if there's enough support.

>I would also like to see it made legal to show a class's inheritance as a
>forward declaration. For example:
>
>class A : public SomeBase;
>
>You would, of course, subsequently get an error (possibly a link-error?) if
>A were not actually derived from SomeBase.

What's the benefit that makes you want to do this? Can you show a motivating
example?

>Finally, it would be nice to allow . (or ->) to access class typedefs. Eg:
>
>std::vector< X > myVect;
>myVect.iterator it;
>
>This can look a lot tidier, and surely it would be easy for compilers.

Also on the wish-list for C++0x, and if there's enough support, then
maybe...

Herb

---
Herb Sutter (www.gotw.ca)

Secretary, ISO WG21/ANSI J16 (C++) standards committee   (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal                 (www.gotw.ca/cuj)
C++ community program manager, Microsoft           (www.gotw.ca/microsoft)

---
[ 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                       ]





Author: Vincent Finn <1@2.com.cos.agilent.com>
Date: Wed, 10 Apr 2002 16:22:56 GMT
Raw View
On a similar note
it would be nice to be able to forward declare nested classes too !

nmtop40 wrote:

> There are 2 forward declarations I would like to see "legalised" which are
> not at present.
> Plus there is something else I would like to see made legal.
>
> Firstly, the problem with a typedef. It would be nice if you could forwardly
> declare something
> that is actually a typedef. For example:
>
> class std::string;
>
> // then stuff that uses string
>
> This is illegal because std::string is not actually a class but a typedef of
> std::basic_string< char >;
> (Ok, if you don't like that, let us use typename)
>
> I would also like to see it made legal to show a class's inheritance as a
> forward declaration. For
> example:
>
> class A : public SomeBase;
>
> You would, of course, subsequently get an error (possibly a link-error?) if
> A were not actually
> derived from SomeBase.
>
> Finally, it would be nice to allow . (or ->) to access class typedefs. Eg:
>
> std::vector< X > myVect;
> myVect.iterator it;
>
> This can look a lot tidier, and surely it would be easy for compilers.
>
> ---
> [ 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                       ]

---
[ 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                       ]





Author: brangdon@cix.co.uk (Dave Harris)
Date: Wed, 10 Apr 2002 20:28:53 GMT
Raw View
hsutter@acm.org (Herb Sutter) wrote (abridged):
> Forward declarations of typedefs are a fairly commonly-requested
> feature and may get added to C++0x if there's enough support.

Really? Is there some notion of how to deal with overloading? Eg:

    typedef A myspace::A;
    typedef B myspace::B;

    void proc( A & ) {}
    void proc( B & ) {};

    void test( A &a ) {
        proc( a );
    }

Would this compile? What if A and B turn out to be the same type?

    namespace myspace {
        typedef int A;
        typedef A B;  // A and B are actually the same type!
    }

It seems that proc( int & ) is defined twice.

Couldn't the original problem also be addressed by requiring std::string
be a class. In other words, instead of:

    class std::string;
    // ...

    namespace std {
        typedef basic_string<char> string;
    }

it could be:

    namespace std {
        class string;
    }

    namespace std {
        struct string : private basic_string<char> {
            using basic_string<char>::begin;
            using basic_string<char>::end;
            //... etc
        }
    }

(Or use delegation if you don't like private inheritance... C++ could do
with improvement in this area anyway, but that's a separate discussion.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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                       ]





Author: Steve Clamage <clamage@eng.sun.com>
Date: Wed, 10 Apr 2002 22:19:27 GMT
Raw View
On Tue, 9 Apr 2002, nmtop40 wrote:
>
> There are 2 forward declarations I would like to see "legalised" which are
> not at present.
> Plus there is something else I would like to see made legal.
>
> Firstly, the problem with a typedef. It would be nice if you could forwardly
> declare something
> that is actually a typedef. For example:
>
> class std::string;
>
> // then stuff that uses string
>
> This is illegal because std::string is not actually a class but a typedef of
> std::basic_string< char >;
> (Ok, if you don't like that, let us use typename)

The problem with that is how the compiler will implement typesafe
linkage. Typedefs don't have linkage, and do not introduce a new type.

Given in one file
 typename std::string;
 void foo(std::string&);
 void bar(std::string& s) { foo(s); }
and in another file
 #include <string>
 void foo(std::basic_string< char,
     std::char_traits<char>,
     std::allocator<char> >& s)  { ... }
how does the implementation tell that the call to foo in the
first file is satisfied by the definition in the second file?

More generally, suppose you have in one file
 struct A { ... };
 typedef A Type;
 int hoo(Type* t) { ... }

and in another file
 struct B { ... };
 typedef B Type;
 int hoo(Type* t) { ... }

Now in a third file you have
 typename Type;
 int hoo(Type* t);
 int horton(Type* p)
 {
     return hoo(p);
 }

Which, if either, of the hoo functions should be called?  Notice
that the compiler does not need to know anything about Type to
generate the code to call hoo, but it cannot know which hoo to call.
(That is, not in C++.  You'd need fully dynamic type determination.)

If you disallow the call to hoo, of what use is the incomplete
declaration for Type?

>
> I would also like to see it made legal to show a class's inheritance as a
> forward declaration. For
> example:
>
> class A : public SomeBase;

And what problem does this solve?  You still can't do anything
more with type A than use A* and A& in the same limited contexts
as if you wrote only
 class A;

>
> Finally, it would be nice to allow . (or ->) to access class typedefs. Eg:
>
> std::vector< X > myVect;
> myVect.iterator it;
>
> This can look a lot tidier, and surely it would be easy for compilers.

You can currently use typedefs to make the code tidy.
 typedef std::vector<X> MyVectType;
 typedef myVectType::iterator MyVectIterator;

 MyVectType myVect;
 MyVectIterator it;

Your suggestion actually does complicate things for compilers.
It is currently quite difficult to determine whether a
statement is a declaration or an expression. Allowing this
syntax makes it a little harder.
 myobj.memb[ix]->memb2.iterator it;
Right up to the "iterator", this thing looks like an expression.

Admittedly, compilers already need indefinite lookahead to
distinguish declarations from expressions. If you propose to make
it even more difficult, I think we need a compelling benefit for
C++ users in exchange.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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                       ]





Author: Michiel.Salters@cmg.nl (Michiel Salters)
Date: Thu, 11 Apr 2002 12:34:49 GMT
Raw View
Steve Clamage <clamage@eng.sun.com> wrote in message news:<Pine.SOL.4.33.0204101430510.16096-100000@taumet>...
> On Tue, 9 Apr 2002, nmtop40 wrote:

> > ... it would be nice to allow . (or ->) to access class typedefs. Eg:
> >
> > std::vector< X > myVect;
> > myVect.iterator it;
> >
> > This can look a lot tidier, and surely it would be easy for compilers.
>
> You can currently use typedefs to make the code tidy.
>  typedef std::vector<X> MyVectType;
>  typedef myVectType::iterator MyVectIterator;
>
>  MyVectType myVect;
>  MyVectIterator it;
>
> Your suggestion actually does complicate things for compilers.
> It is currently quite difficult to determine whether a
> statement is a declaration or an expression. Allowing this
> syntax makes it a little harder.
>  myobj.memb[ix]->memb2.iterator it;
> Right up to the "iterator", this thing looks like an expression.

Does it help if the :: symbol was used ? E.g.
myobj.memb[ix]->memb2::iterator it;

Of course, up to the :: the thing still looks like an an expression,
which is only one token earlier. But that's pretty much the point of
the construct.

I guess the problem is a parsing thing; the compiler must be able to
pass that expression to  template<class T> T::iterator f(T)  so it must
be capable of getting to the iterator given the expression.

NB. With typeof() there's less need for this construct so I don't
think this is a high-priority issue.

Regards,
Michiel Salters

---
[ 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                       ]





Author: xleobx@qmailcomq.com
Date: Thu, 11 Apr 2002 15:29:46 GMT
Raw View
Steve Clamage <clamage@eng.sun.com> wrote:

> Your suggestion actually does complicate things for compilers.
> It is currently quite difficult to determine whether a
> statement is a declaration or an expression. Allowing this
> syntax makes it a little harder.
>  myobj.memb[ix]->memb2.iterator it;
> Right up to the "iterator", this thing looks like an expression.

Why not
typename myobj.memb[ix]->memb2.iterator it;
then?

Requiring "typename" in such declarations will not break any existing code.

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