🚀 go-pugleaf

Is operator.() banned from the standards discussion?

Such a creature would sure be nice to have, given the STL 
containers. Suppose that you have a list<string>, and lots of 
code looking like

  typedef list<string> stringlist;
  /* ....... */
  for (stringlist::iterator i = l.begin(); i != l.end(); i++)
	(*i).append(".");

Then you decide that you want to put something else into the 
list. If you decide not to derive from string (e.g. using a smart 
pointer instead), there is no alternative to rewriting all the 
functions refering to type stringlist.

The only way to retain flexibility now, as far as I can see, is 
to refrain from using constructs like (*i).function(), using 
smart pointer imitating wrappers and (*i)->function() 
consequently instead. But this is kind of messy...

Ideally, operator.() should allow you to have all the things 
inheritance allows you to have, except for storage. I.e. a class 
with operator.() should behave just as its "base class", but be 
allowed to override suitable functions.

Why isn't this possible? What's the catch?

Dan Holmsand
dan@et.se
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]