Topic: class namespaces (N1420): What is the current status?


Author: "Thorsten Ottosen" <nesotto@cs.auc.dk>
Date: Sat, 1 Jan 2005 12:56:02 CST
Raw View

<Nicola.Musatti@ObjectWay.it> wrote in message
news:1103711703.043110.236140@f14g2000cwb.googlegroups.com...
| Hallo,
| I was about to post an informal proposal on class templates, but I
| found that Carl Daniel has already put exactly the same proposal before
| the committee almost two years ago.
|
| So, what is the current status of Carl's proposal?

we haven't discussed it yet, but I hope we get to it in norway.

| By the way, I think there's one aspect that isn't considered in paper
| N1420, namely how to handle return types that are defined within the
| class, e.g.
|
| template <typename T> class C {
| public:
| typedef int R;
| R f();
| };
|
| Normally I'd write something like
|
| typename C<T>::R C<T>::f() { return 42; }
|
| Within Carl's proposal it is not clear what should be done; one idea is
| to regard the class name without template parameters as naming the
| current specializazion, as is already the case within the class's
| scope. Thus one would write:
|
| template <typename T> namespace class C {
| typename C::R f() { return 42; }
| }
|
| An alternative would be to allow a plain 'R' to implicitly refer to
| C<T>::R, but I regard this as an undesirable potential source of
| ambiguities.

ok. why?

-Thorsten


---
[ 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: Nicola.Musatti@ObjectWay.it
Date: Mon, 3 Jan 2005 11:33:55 CST
Raw View
Thorsten Ottosen wrote:
> <Nicola.Musatti@ObjectWay.it> wrote in message
> news:1103711703.043110.236140@f14g2000cwb.googlegroups.com...
[...]
> | An alternative would be to allow a plain 'R' to implicitly refer to
> | C<T>::R, but I regard this as an undesirable potential source of
> | ambiguities.
>
> ok. why?

Consider the present syntax; if I write

template <typename T>
R C<T>::f() { return 42; }

R as a return type can never refer to C<T>::R . With the proposed
syntax if I write

template <typename T> namespace class C {
R f() { return 42; }
}

It is not obvious whether R refers to C<T>::R or to another R. Making R
refer by default to C<T>::R would make it necessary to qualify a type
hidden by R.

When all's said and done a decision should be made on whether name
lookup in class namespaces works exactly as within class definitions or
whether it should be preferable that they keep as close as possible to
the current syntax.

Cheers,
Nicola Musatti

---
[ 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: "Thorsten Ottosen" <nesotto@cs.auc.dk>
Date: Mon, 3 Jan 2005 14:47:17 CST
Raw View
<Nicola.Musatti@ObjectWay.it> wrote in message
news:1104746855.029601.159670@z14g2000cwz.googlegroups.com...
|
| Thorsten Ottosen wrote:
| > <Nicola.Musatti@ObjectWay.it> wrote in message
| > news:1103711703.043110.236140@f14g2000cwb.googlegroups.com...
| [...]
| > | An alternative would be to allow a plain 'R' to implicitly refer to
| > | C<T>::R, but I regard this as an undesirable potential source of
| > | ambiguities.
| >
| > ok. why?
|
| Consider the present syntax; if I write
|
| template <typename T>
| R C<T>::f() { return 42; }
|
| R as a return type can never refer to C<T>::R . With the proposed
| syntax if I write
|
| template <typename T> namespace class C {
| R f() { return 42; }
| }
|
| It is not obvious whether R refers to C<T>::R or to another R.

well, I would say it should always refer to C<T>::R if that name is availble.

| Making R
| refer by default to C<T>::R would make it necessary to qualify a type
| hidden by R.

yes, :.R or something.

| When all's said and done a decision should be made on whether name
| lookup in class namespaces works exactly as within class definitions or
| whether it should be preferable that they keep as close as possible to
| the current syntax.

Going away from the current syntax would be
most natural IMO since the whole idea of the proposal is
to make it easy to write the definition.

-Thorsten


---
[ 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: AlbertoBarbati@libero.it (Alberto Barbati)
Date: Tue, 4 Jan 2005 16:47:47 GMT
Raw View
Thorsten Ottosen wrote:
> <Nicola.Musatti@ObjectWay.it> wrote in message
> news:1104746855.029601.159670@z14g2000cwz.googlegroups.com...
> |
> | Consider the present syntax; if I write
> |
> | template <typename T>
> | R C<T>::f() { return 42; }
> |
> | R as a return type can never refer to C<T>::R . With the proposed
> | syntax if I write
> |
> | template <typename T> namespace class C {
> | R f() { return 42; }
> | }
> |
> | It is not obvious whether R refers to C<T>::R or to another R.
>
> well, I would say it should always refer to C<T>::R if that name is availble.
>

In order to let unqualified R refer to C<T>::R we need to effectively
make *every* unqualified name inside the class namespace dependent, to
be bound at the point of instantiation. Name binding even would be
deferred also for names that should be bound (in the programmer's
intent) at the point of declaration. That would be a big deviation from
the current syntax where unqualified names (with notable exceptions for
function names) are always non-dependent, and the programmer must make
an active effort either by adding qualification of by using "this->" to
make the name dependent.

On a side note, having unqualified names dependent would potentially
require the usage of the "typename" keyword in a lot of unintuitive places:

template <typename T>
R C<T>::f()  // R is non-dependent and is bound at PoD, no typename
{ return 42; }

template <typename T> namespace class C {
   typename R f() // R is dependent, is bound at PoI so you need typename
   { return 42; } // even if the intent is to refer to ::R
}

IMHO, unqualified R should be bound at PoD and thus can *never* refer to
C<T>::R. To refer to C<T>::R you must write C::R, prefixed by the
typename keyword (if R is a type name, of course).

Alberto

---
[ 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: Nicola.Musatti@ObjectWay.it
Date: Wed, 22 Dec 2004 17:41:32 CST
Raw View
Hallo,
I was about to post an informal proposal on class templates, but I
found that Carl Daniel has already put exactly the same proposal before
the committee almost two years ago.

So, what is the current status of Carl's proposal?

By the way, I think there's one aspect that isn't considered in paper
N1420, namely how to handle return types that are defined within the
class, e.g.

template <typename T> class C {
public:
typedef int R;
R f();
};

Normally I'd write something like

typename C<T>::R C<T>::f() { return 42; }

Within Carl's proposal it is not clear what should be done; one idea is
to regard the class name without template parameters as naming the
current specializazion, as is already the case within the class's
scope. Thus one would write:

template <typename T> namespace class C {
typename C::R f() { return 42; }
}

An alternative would be to allow a plain 'R' to implicitly refer to
C<T>::R, but I regard this as an undesirable potential source of
ambiguities.

Cheers,
Nicola Musatti

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