The first barrier to compiling templates is in understanding how
well the language has been worded to map references to symbols
in a template scope to unique declarations in the AST.

I will provide an example:

    struct S {

        static S *sptr;

        S *operator ->(void)
        {
            return sptr;
        }

        int member;

    };

    template<class T>
    int
    foo(T &t)
    {
        return t->member;
    }

    S s;

    int i = foo(s); // works

Under the current language rules for operator ->, a usage of that
operator
always implies a class member access(3.4.5).

However, if one were to make -> a binary operator which would accept
two arguments[i.e. a->b would result in operator ->(a, b)], then
it would give rise to the following predicament:

    int member;

    template<class T>
    int
    foo(T &t)
    {
        return t->member; // it could also mean : "operator -
>(t&, ::member)"
    }

My question is : does the standard explicitly word itself so as to
disallow ambiguity wrt references to symbol?

If no, then this would be the first reason why we may not
be able to compile templates.

Sincerely.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

parthaspanda22@gmail.com ha scritto:
>
> Under the current language rules for operator ->, a usage of that
> operator
> always implies a class member access(3.4.5).
>
> However, if one were to make -> a binary operator which would accept
> two arguments[i.e. a->b would result in operator ->(a, b)], then
> it would give rise to the following predicament:

operator-> can not be overloaded in that way. Please refer to 13.5.6:
"operator-> shall be a non-static member function taking no parameters"
and "an expression x->m is interpreted as (x.operator->())->m".

operator-> can not be a binary operator because the right hand side is
always a name (of a member) and never an expression.

>     int member;
>
>     template<class T>
>     int
>     foo(T &t)
>     {
>         return t->member; // it could also mean : "operator -
>> (t&, ::member)"
>     }
>
> My question is : does the standard explicitly word itself so as to
> disallow ambiguity wrt references to symbol?

The question is pointless, because t->member can never be interpreted
that way.

> If no, then this would be the first reason why we may not
> be able to compile templates.

Actually that would be one more reason why operator-> can not be binary.

HTH,

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> parthaspanda22@gmail.com ha scritto:
>> Under the current language rules for operator ->, a usage of that
>> operator
>> always implies a class member access(3.4.5).
>>
>> However, if one were to make -> a binary operator which would accept
>> two arguments[i.e. a->b would result in operator ->(a, b)], then
>> it would give rise to the following predicament:
>
> operator-> can not be overloaded in that way. Please refer to 13.5.6:
> "operator-> shall be a non-static member function taking no parameters"
> and "an expression x->m is interpreted as (x.operator->())->m".

I think he knows that, his question boils down to why that is the case.
I.e. what was the motivation for disallowing global definition of
operator ->?
>
> operator-> can not be a binary operator because the right hand side is
> always a name (of a member) and never an expression.

Clearly -> _is_ a binary operator as it takes two arguments :-). OTOH it
clearly needs to be an in class definition because overloads need to be
specific to a type. The second argument (as you say) has to be a member
name and not an expression and has to be evaluated at compile time.

Remember that the builtin version of operator -> is equivalent to
dereferencing the pointer and then using dot. I.e.: x->y is equivalent
to (*x).y and we do not (yet) allow overloading of operator .

There is another (desirable) feature of operator -> in that the
evaluation is recursive with the requirement that we eventually obtain a
pointer on the lefthand side.

All-in-all operator -> is very different from most operators but the
rules were drafted to support smart-pointer types. Indeed it is
fortuitous that C actually introduced -> even though it was (for C) pure
syntactic sugar.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Do any of the C++ compilers compile templates into ASTs
or does the standard say (without actually doing so)
that templates are meant to be pre-processed?

Sincerely.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Nov 15, 7:15 pm, parthaspand...@gmail.com wrote:
> Do any of the C++ compilers compile templates into ASTs
> or does the standard say (without actually doing so)
> that templates are meant to be pre-processed?

I think only EDG compiles them into ASTs.
The others simply instantiates them.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

>
> Remember that the builtin version of operator -> is equivalent to
> dereferencing the pointer and then using dot. I.e.: x->y is equivalent
> to (*x).y and we do not (yet) allow overloading of operator .
>
> There is another (desirable) feature of operator -> in that the
> evaluation is recursive with the requirement that we eventually obtain a
> pointer on the lefthand side.
>
> All-in-all operator -> is very different from most operators but the
> rules were drafted to support smart-pointer types. Indeed it is
> fortuitous that C actually introduced -> even though it was (for C) pure
> syntactic sugar.

How come the same properties don't extend to ->*? Currently, it's
impossible to overload it for a smart pointer, because doing so would
require returning a member function, which is forbidden under the
standard (I don't have a copy on me, but I remember the only valid
thing to do with a function resulting from a .* or ->* is to call it).
An overload would could be easily accomplished if it was permitted to
return this value from the operator call, or if we could reproduce the
inherent translation applied to operator ->*

Actually, you might be able to overload it with a very well-crafted
template function combined with a functional struct,(especially given
the new metaprogramming abilities in 0x), but that would require a lot
of work to get perfect, especially if it needs to be functional for
both pointers to functions and objects.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]