[boost] Is that parsing right? (was: Re: Just say no to arbitrary operators (was: Re: boost::format rant))

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-04-25 01:04:08

On Wednesday, April 23, 2003, at 10:45 AM, Giovanni Bajo wrote:

> Daryle Walker <dwalker07_at_[hidden]> wrote:
>
[Peter Dimov said]
>>> Very appealing... but doesn't work, for me, at least.
>>>
>>> "%1% %3%" % 5 % 6 % 7; // should yield "5 7"
>
>> The first part of that expression would be like:
>> 	whatever operator %( char const *p1, int p2 );
>
> I think you misread what Peter was trying to say. He was implying 
> that, without a format class, you can't keep track of how many 
> formatting items you have applied to your string, so you can't skip 
> the '6' in the above example. My answer was to modify the input string 
> by decrementing the positions within the string every time, until they 
> reach zero and get formatted.
>
>> I don't think Giovanni's expected "char const [N]"-to-std::string
>> conversion will occur, killing his idea.  (Also, the function 
>> prototype I gave above isn't legal since you can't overload operators 
>> without at least one user-defined operand type.  This is probably the 
>> cause of Peter's errors.)
>
> The conversion to string does occur, I tried it in real code, you just 
> need a string context:
>
> void Foo(std::string m)
> {  cout << m; }
>
> Foo("This %s work - %u" % "does" % 123)
>
> It does not work in contexts not explicitally asking for a string, 
> like stream.operator<<() (which I believe it's a template). My guess 
> was that you could fix it by providing a global operator<<(ostream&, 
> string) which would simply call ostream.operator<<(), but I never 
> tried it.

Isn't your example _also_ a non-explicit desire for a string?  I 
thought the parsing was:

1.	determine the exact form of
        whatever1 operator %("This %s work - %u", "does");

2.	determine the exact form of
        whatever2 operator %( temp_from_part_1, 123 );

3.	determine the exact form of
        Foo( temp_from_part_2 );

For part [3], the compiler has to consider if "Foo" is a function, 
function object, or a type.  Then the compiler searches for potential 
functions, operator(), or constructors, with at most one conversion 
from "whatever2" to the argument type.

For your idea to work, doesn't the compiler have to consider what 
happens in part [3] when computing parts [1] and [2]?  The compiler has 
to fadangle the results of [1] knowing it needs a "std::string" for 
your part [3] to work.  I thought the compiler can't do that kind of 
lookahead.  Your compiler may actually be smart enough to do that, but 
wouldn't that be a bug, since it would be incompatible with compilers 
that can't do that lookahead?

Daryle