A post from 2009 and it's 2013 and this isn't implemented yet. It's such a simple feature to add so we can create proxy objects. James Kanze made the perfect argument for it already and it creates absolutely no issues in the standard and is essentially identical to the -> operator. Not having it is far more limiting and confusing for programmers when the intention is to create a seamless proxy object.

Do the actual C++ people who add things to the standard read these? I know Stroustrup wrote about it since googling returns this: http://www.stroustrup.com/bs_faq2.html#overload-dot
It seems like the idea just keeps getting overlooked when there are no downsides to putting it in.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello. Next c++0x standard's going to be great!! But I wonder why
operator. isn't still overloadable. I think it should
be, as all other operators because it helps to function forwarding. I
think of some use cases, and it would be useful for value-based
programming.
I think that operator. should return a reference to an object. This
way, you can use some wrapper classes which should be transparent to
the user, like this one:

template <class T>
class flyweight {
private:
     T * t;
public:

    ...
       T & operator.() { return *t; }

};

This way, you can use this, for example as a string. The only problem
I didn't find a solution for is that if flyweight itself has any
function, it will be hidden. Anyway, there are workarounds, like
implementing another class which can query flyweight for its state, or
use free functions. I think it would be a useful feature for things
like
For example, it would also be a good idea for copy_on_write<T> (like
adobe's asl one) types. And there are
much more use cases, such as reference wrappers, value-based
polymorphic objects... and the list goes on.


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

On Jan 16, 10:46 pm, german diago <germandi...@gmail.com> wrote:
> Hello. Next c++0x standard's going to be great!! But I wonder why
> operator. isn't still overloadable.

Because still no one has come up with a syntax that
1) makes sense
2) allows access to the proxied object's members
3) allows access to the proxy object's members
4) doesn't confuse the hell out of programmers as to which of the
above happens in any given expression.


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

german diago wrote:
>
> Hello. Next c++0x standard's going to be great!! But I wonder why
> operator. isn't still overloadable.

   The comma has weird syntax in C/C++.  The operator precedence
is different in

       f(a,b)

and

       f[a,b]

for example.

                               John Nagle


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

On 16 jan, 22:46, german diago <germandi...@gmail.com> wrote:

> I think that operator. should return a reference to an object.
> [...]
>        T & operator.() { return *t; }

I personally find this much more useful:

         template<typename F>
         auto operator.(F&& f) -> decltype(f(*t)) { return f(*t); }

Since it would actually be usable with boost::variant, for example.
It's much more powerful.
If we had polymorphic lambdas, it could easily be expressed in terms
of these.


> The only problem
> I didn't find a solution for is that if flyweight itself has any
> function, it will be hidden.

Well, the solution would be that a type overloading operator. cannot
have any member variable or function public or protected, outside of
constructors, destructors, and operators.
Within the member functions, t would reference the private member, but
this->t would invoke the overloaded operator.


> For example, it would also be a good idea for copy_on_write<T> (like
> adobe's asl one) types. And there are
> much more use cases, such as reference wrappers, value-based
> polymorphic objects... and the list goes on.

There is no denial it would be very useful, of course.


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

On Jan 17, 10:32 pm, John Nagle <na...@animats.com> wrote:
>    The comma has weird syntax in C/C++.  The operator precedence
> is different in
>
>        f(a,b)
>
> and
>
>        f[a,b]
>
> for example.
>
>                                John Nagle

0/2: german diago was asking about period, not comma, and comma is in
fact overloadable (and would be called in the second but not the first
example.


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

german diago wrote:

> I wonder why
> operator. isn't still overloadable.

Mostly for the reasons wasti.redl listed.

> I think it should
> be, as all other operators because it helps to function forwarding.

The . operator is sort of the base case of operator overloading.  It's
the one truth we hold to be self-evident.

> I
> think of some use cases, and it would be useful for value-based
> programming.

Hm, not sure about that.  Feel free to show some use cases.  If
nothing else, it'll be a fun exercise to try providing alternative
solutions, and maybe I'll learn (or realize) something. :)

> I think that operator. should return a reference to an object. This
> way, you can use some wrapper classes which should be transparent to
> the user, like this one:
>
> template <class T>
> class flyweight {
> private:
>     T * t;
> public:
>
>    ...
>       T & operator.() { return *t; }
>
> };
>
> This way, you can use this, for example as a string.

1. It doesn't account for non-member operations on T.  Given:

       struct foo_type { };

       template<class T>
       void print(T t) {
               std::cout << "template\n";
       }

       void print(foo_type foo) {
               std::cout << "overload\n";
       }

       foo_type const foo;
       flyweight<foo_type> const fly;

The following calls do different things:

       print(foo);
       print(fly);

2. Any change to any instance of flyweight<foo> will immediately be
reflected by any previously made copies of it.  Those are pointer
semantics, not value semantics, so operator. would be horribly
misleading.  Maybe you could work around that by making t immutable.

3. The ownership of *t is unclear.  Who allocates, and who deletes?
You could make all flyweights:

       a. point into an externally owned table
       b. noncopyable
       c. reference-counted
       d. copy-on-write
       e. move-on-copy

Option a is called "internment," and is used by Java for flyweight
Strings (which are also immutable).  Option b is used by
boost::scoped_ptr, and c shared_ptr.  Option d is used by many
existing string implementations, and e is used by std::auto_ptr.

Options a, b, and c work for pointer types because it's understood
that copied pointers point to the same object; the ownership is
irrelevant from the PoV of generic code that just works with the
pointer.  The same would not be true of proxy types like your
hypothetical flyweights.

Option d works for strings that effectively implement flyweight,
because they're not just thin wrappers.  They directly provide
string-related functions to the client.  T differs from one library
version to the next, so overloading operator. would just expose an
implementation detail that is better hidden.

Option e has proven so confusing that auto_ptr is now deprecated.  The
replacement has "smooth moves:"
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=400

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

Mathias Gaunard wrote:
>
> On 16 jan, 22:46, german diago <germandi...@gmail.com> wrote:
>
>> I think that operator. should return a reference to an object.

> There is no denial it would be very useful, of course.

"No denial?"  I find the guarantee that . means . pretty useful.  What
would operator. buy you over operator->, btw?  All I've seen so far is
"slightly better proxying."

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

On Jan 18, 3:40 am, wasti.r...@gmx.net wrote:
> On Jan 16, 10:46 pm, german diago <germandi...@gmail.com> wrote:

> > Hello. Next c++0x standard's going to be great!! But I
> > wonder why operator. isn't still overloadable.

The main reason is purely political.  The person who made the
original proposal had a very undiplomatic way of promoting it,
which in turn put many committee members off it.

> Because still no one has come up with a syntax that
> 1) makes sense

How's that?  The whole point of operator overloading is that the
syntax is indistinguishable from the built-in operator.

> 2) allows access to the proxied object's members

I don't understand this one either.  The whole purpose of
overloading operator.() is to provide access to the proxied
object's members.

> 3) allows access to the proxy object's members

In member functions, just refering to them works.  Normally,
a proxy object's members are only referred to in member
functions---proxies don't usually have named member functions,
only overloaded operators, which get called explicitly.  But of
course, should the need arrive, there's always ->.

> 4) doesn't confuse the hell out of programmers as to which of
> the above happens in any given expression.

What's confusing the hell out of programmers is the fact that
they have to use -> when accessing members of a class type via a
proxy.

There's no logical reason why you can't overload the dot
operator.  And it would be exceedingly useful.  For political
reasons, however, it isn't likely to happen.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


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

John Nagle wrote:
> german diago wrote:
>>
>> Hello. Next c++0x standard's going to be great!! But I wonder why
>> operator. isn't still overloadable.
>
>   The comma has weird syntax in C/C++.  The operator precedence
> is different in
>
>       f(a,b)
I cannot see a comma operator in that expression (only a comma punctuator)
>
> and
>
>       f[a,b]
>

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

On 18 jan, 20:59, Jeff Schwab <j...@schwabcenter.com> wrote:

> "No denial?"  I find the guarantee that . means . pretty useful.  What
> would operator. buy you over operator->, btw?  All I've seen so far is
> "slightly better proxying."

I perfectly agree with you that those proposals that offer a operator.
overloading that is virtually the same as the current operator->
overloading are not very useful.
Yet there is a demand for them.

What I offer is to satisfy that demand, but not only that: do
something more powerful than just recopy what operator-> does.
It's not just proxying, you could give it any meaning you'd like to
eventually.

It would be incredible to be able to do something like that:

struct foo { int baz() { return 0; } };
struct bar { int baz() { return 1; } };

variant<foo, bar> v = foo();
int a = v.baz(); // or v->baz()

Which, of course, simple forwarding ala operator-> cannot do.
The operator. I offered would provide a real way to overload the name
that is provided and not just forward it. I think I've read somewhere
that Bjarne Stroustrup, for example, didn't like operator. overloading
because he didn't see how you could overload a name, which is what
operator. really receives, along with arguments.
However, passing a polymorphic function object (I mean parametric
polymorphism here) kinda is.

A call to
obj.member(arg1, arg2, ..., argN);
would be equivalent to
obj.operator.([&](o) { return o.member(arg1, arg2, ..., argN); });
assuming polymorphic lambdas (which we don't have, but the syntax
should be explicit enough)

The function object can also be decorated to provide compile-time
reflection information about what name is being called, to allow more
fancy usages, such as converting the name to a string to do some
lookup in a database or whatever. But that can be added later.


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