I'm a student of the ANSI/ISO standard for C++, not an expert. I don't
understand a coding convention used in the BGL. Maybe you can help
me understand.

Let's focus on Boost's adjacency_list class. As with other BGL classes,
it nests type definitions in a manner like the following:

[1] template <class X, class Y, class Z>
[2] class adjacency_list:
        public adj_list_gen<adjacency_list<X, Y, Z> Y, X, Z>::type
[3] {  typedef adjacency_list self;
[4]     typedef typename
            detail::adj_list_gen<self, Y, X, Z>::type Base;
    ...}

My understanding is that adjacency_list in [3] denotes something that is
not a type. Otherwise, the standard mandates the use of "typename."

So, what is adjacency_list in [3]? The member typedef  must refer to an
adjacency_list declared in the namespace enclosing this class (i.e.,
boost).
But the only boost::adjacency_list is the one under definition in this temp-
lated class. My understanding is that when this typedef is first processed
by the compiler, adjacency_list is treated as a member variable that has
not yet been defined. When the entire definition of the class has been
seen, the member variable self is made known throughout the definition of
class adjacency_list as another name for adjacency_list::adjacency_list.
But how has adjacency_list::adjacency_list been defined?

I suspect the answer  has to do with the semantic  relationship between
adjacency_list<X, Y, Z> in [2] and adjacency_list in [3]. BGL defines the
first arg to the class adj_list_gen to be of class Graph. Does [2]
explicitly
resolve the typedef in [3] somehow?

Finally, g++ compiles adjacency_list just fine. IBM's VAC++ compiler
complains as follows:

    "The templated argument boost::adjacency_list::self does not
      match the template parameter class Graph."

So, what is self in [3] and [4]? Since self (aka boost::adjacency_list and
boost::adjacency_list::adjacency_list) fails to "refer to the same
declaration
in its context and when re-evaluated in the completed scope" of the class
under construction, doesn't this violate subclause 3.6.6 of the standard?

Please tell me what I'm missing.


--Gary

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Gary Coen" <coens@attglobal.net> schrieb im Newsbeitrag
news:3A648A8D.80706@attglobal.net...
> I'm a student of the ANSI/ISO standard for C++, not an expert. I don't
> understand a coding convention used in the BGL. Maybe you can help
> me understand.
>
> Let's focus on Boost's adjacency_list class. As with other BGL classes,
> it nests type definitions in a manner like the following:
>
> [1] template <class X, class Y, class Z>
> [2] class adjacency_list:
>         public adj_list_gen<adjacency_list<X, Y, Z> Y, X, Z>::type
> [3] {  typedef adjacency_list self;
equivalent to:
    typedef adjacency_list<X, Y, Z> self;

> [4]     typedef typename
>             detail::adj_list_gen<self, Y, X, Z>::type Base;
equivalent to:
    typedef detail::adj_list_gen<adjacency_list<X, Y, Z> Y, X, Z>::type
Base;

>     ...}
>
> My understanding is that adjacency_list in [3] denotes something that is
> not a type. Otherwise, the standard mandates the use of "typename."
No. The standard mandates typename if some name cannot ambiguously be
determined to be a type name. In the case of detail::adj_list_gen, the
compiler might not know what detail is and thus has no clue about
detail::adj_list_gen. In the case of adjacency_list it knows that it is a
type name (the name of the class the declaration resides in). Note that the
class name is part of the scope of the class the class name refers to.

sm



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gary Coen wrote:

First off I can't find any way to parse "3.3.6" that would lead to something
appropriate to this subject.

>
> I'm a student of the ANSI/ISO standard for C++, not an expert. I don't
> understand a coding convention used in the BGL. Maybe you can help
> me understand.
>
> Let's focus on Boost's adjacency_list class. As with other BGL classes,
> it nests type definitions in a manner like the following:
>
> [1] template <class X, class Y, class Z>
> [2] class adjacency_list:
>         public adj_list_gen<adjacency_list<X, Y, Z> Y, X, Z>::type
> [3] {  typedef adjacency_list self;
> [4]     typedef typename
>             detail::adj_list_gen<self, Y, X, Z>::type Base;
>     ...}
>
> My understanding is that adjacency_list in [3] denotes something that is
> not a type. Otherwise, the standard mandates the use of "typename."

The use of adjacency_list here is KNOWN to be a type name.  This name
is resolved as a type name without the necessity of referring to typename.

> So, what is adjacency_list in [3]? The member typedef  must refer to an
> adjacency_list declared in the namespace enclosing this class (i.e.,
> boost).

It refers to a the class being defined.  As soon as the class name is
seen the name is inserted in the scope.  It's the same as it would be with
a regular class.  Read the beginning of 14.6 again.

>
> Finally, g++ compiles adjacency_list just fine. IBM's VAC++ compiler
> complains as follows:
>
>     "The templated argument boost::adjacency_list::self does not
>       match the template parameter class Graph."
>

Where did "Graph" come from?

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie wrote:

> Gary Coen wrote:
>
> First off I can't find any way to parse "3.3.6" that would lead to something appropriate to this subject.
>
>> Let's focus on Boost's adjacency_list class. As with other BGL classes,
>> it nests type definitions in a manner like the following:
>>
>> [1] template <class X, class Y, class Z>
>> [2] class adjacency_list:
>>         public adj_list_gen<adjacency_list<X, Y, Z> Y, X, Z>::type
>> [3] {  typedef adjacency_list self;
>> [4]     typedef typename
>>             detail::adj_list_gen<self, Y, X, Z>::type Base;
>>     ...}
>
[snip]

>> Finally, g++ compiles adjacency_list just fine. IBM's VAC++ compiler
>> complains as follows:
>>
>>     "The templated argument boost::adjacency_list::self does not
>>       match the template parameter class Graph."
>
> Where did "Graph" come from?

BGL defines the 1st arg to the templated class adj_list_gen to be a
Graph object (see [2]).

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]