TITLE: Use for operator comma ?


PROBLEM: rcromw1@umbc.edu (Ray Cromwell)

  I recently read "The Design and Evolution of C++" and in one
section, Bjarne says that he allowed operator,() to be overloaded for
orthogonality reasons but that he really didn't see a use for it. I
agreed at the time (couldn't see its use), but now I think I do see a
neat application - easily construction of lists. Has anyone tried
something like this?

List operator,(X&, X&);
List& operator,(List&, X&);
List& operator,(X&, List&);
List& operator,(List&, List&);

...

List foo = X(...), X(...), X(...), ..., X(...);

For instance, a simple application would be X = String class. Then, one
could initialize a list with the following syntax.

(imagine that "one" represents String("one") )

List numbers = "one", "two", "three", "four", ..., "ten";

or, for more Perl/Lisp like declaration

List numbers = ("one", "two", "three");

  This seems very economical as the alternative I have used
is:

List numbers;
numbers.push("one");
numbers.push("two");
numbers.push("three");

   What I want to know is, will this work?


RESPONSE: kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425), 12 Sept 94

If done correctly, yes.  I did it once to try it out, but have
abandonned it (at least in this context) as being to exoteric, and
resulting in code that is too difficult for a reader to understand.

To make it work, you need three things:

1. a copy constructor for List.  If this is going to be called, it
should be efficient, so I would recommend some sort of reference
counting scheme.

2. Two global functions:
    List& operator,( List& list , String const& elem ) ;
and
    List operator,( String const& first , String const& elem ) ;

The reason for the second is that this is a built-in operator (but
returning String) if you don't define it.  The second makes a new
list, and adds both strings to it.

Note that the second returns a copy of the new list, whereas the first
simply returns a reference to the list.  This will only work under the
new lifetime of temporary rules; watch out for versions of g++ before
2.6.0.  (This is not a g++ bug; they cannot be blamed for not
forseeing a later decision by the standards committee.)

[...]