"Helmut Zeisel" <helmut.zeisel@vai.at> wrote in message
news:3B70DF76.3200B7D8@vai.at...
> Has it ever been discussed whether operator "." should be
> supported for built-in types?
>
> Then it would be easier to write template algorithms
> that work on built-in types and user defined types:
>
> template<typename T> void some_algorithm(T& x)
> {
> ...
>   fct(x,...); // here I would like to write x.fct(...)
> ...
> }

I thout some time ago about the new feature, which I called "open methods".
Their definition could be:

template <class T>
int T::invert()
{ return ~*this; }

> I would prefer to have a member function fct
> whenever possible
> because member functions make code structure clearer,
> can be virtual,
> and can access private members.

These private members for the builtin types are the same sense
as for any already defined type (read it: NONE). But the argument
about being virtual is worth thinking about. The template can use
the method of a "type" and some types can have it defined
externally with the "open method" feature, while some other
as the method, which can be virtual.

> I cannot use members only because
> the algorithm should also work on built-in types
> (and on other types where I must not change the interface).

But there is a way to solve this problem without using any new features.
You can define a template function with an appropriate header,
which depending on the template parameter will either do something
directly on the type, or call a method of this type, probably virtual.

> Additionally to some generic f (which I have to write anyway),
> currently every user of the algorithm has to write trivial
> specializations
>
> template<> void fct(X& x,...)
> {
>   x.fct();
> }
>

Bad example. The more often used techniq is to call a method from a
function.

> This is at least burdensome
> and can interfere with namespaces in a not yet completely understood
> way,
> as we know from std::swap.
Many STL types have defined the 'swap' method.

> My suggestion would be to extend the meaning of the operator "."
> using the following semantics:
>
> 1) If x.f(...) is already defined, treat it the same way as now.
> 2) Otherwise the compiler currently will give a diagnosis.
>    Instead of that diagnosis, the compiler should try to interpret
> x.f(...)
>    as f(x,...).
>    If a match (according to the current meaning of f(x,...) ) is found,
>    accept this one, otherwise give a diagnosis.

I think the "open methods" feature is more general, because affects
both '.' and '->' operators. The rules I have thought some time ago
for the open methods are as following:

1. Open method you define in a way as shown.
2. The open method is used from appropriate namespace
3. You can call it for every type (let's call it value_type) being known as
a type name.
4. The open method is choosen ONLY if there is no method
with the same header defined for value_type
5. All rules about the language conventions (e.g. access rights) for the
open
method are the same as for the external function
6. Using any member of value_type requires usage of 'this'.

I don't know if this proposition is worth implementing, because we have
functions.
For now, the open methods feature is tried in the case, when now it's a
syntax error.

--
Regards,

((
 )) ektor


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

Has it ever been discussed whether operator "." should be
supported for built-in types?

Then it would be easier to write template algorithms
that work on built-in types and user defined types:

template<typename T> void some_algorithm(T& x)
{
...
  fct(x,...); // here I would like to write x.fct(...)
...
}

I would prefer to have a member function fct
whenever possible
because member functions make code structure clearer,
can be virtual,
and can access private members.

I cannot use members only because
the algorithm should also work on built-in types
(and on other types where I must not change the interface).

Additionally to some generic f (which I have to write anyway),
currently every user of the algorithm has to write trivial
specializations

template<> void fct(X& x,...)
{
  x.fct();
}

for the used types.

This is at least burdensome
and can interfere with namespaces in a not yet completely understood
way,
as we know from std::swap.

My suggestion would be to extend the meaning of the operator "."
using the following semantics:

1) If x.f(...) is already defined, treat it the same way as now.
2) Otherwise the compiler currently will give a diagnosis.
   Instead of that diagnosis, the compiler should try to interpret
x.f(...)
   as f(x,...).
   If a match (according to the current meaning of f(x,...) ) is found,
   accept this one, otherwise give a diagnosis.

For uniformity, one could also
extend the meaning of x->f(...) in an analogous way to
(*x).f(...) and/or  f(*x,...).

IMHO, this would be in the spirit of C++
to treat built-in types and user-defined types uniformly,
and would make life easier for template library writers.

What dou you think about it?

Helmut



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