|
Boost : |
From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-23 14:19:41
From: Samuel Krempp [SMTP:krempp_at_[hidden]]
>
> a)
> format("%3, %1 %2-th try") % 40.23 %manip(hex) % 50 % "toto"];
This certainly correlates well, but "manip(hex)" looks like an ordinary
function call (not that "glue" was any better).
> b) operator* for manips, and % for arguments :
> format("%3, %1 %2-th try") % 40.23 * hex % 50 % "toto"];
This is too easy to miss, and what about the following?
int i(0);
format("%3, %1 %2-th try") % 40.23 * i * hex % 50 % "toto";
> c)
> format("%3, %1 %2-th try") [40.23] (hex) [50] ["toto"];
>
> If there were no manipulator stuff, a) would be my favorite.
> but c) is the only approach that still looks good with manipulators.
> but apparently everybody favors a).
Try deviating from the printf-like notation in the format string since this
isn't allowing for any printf-like functionality:
format("[3], [1] [2]-th try")[40.23](hex)[50]["toto"];
The [] pairs match in the format string as well as in the "parameters list,"
you always have delimiters on either side of the positional parameter, so
you don't need %n versus %{n}, and you get the syntactical difference
between values and manipulators.
This format offers a couple of valuable things. First, as someone pointed
out in another post, putting parentheses around manipulators allows the eye
to downgrade their importance in reading the expression. Second, we are
accustomed to subscripting operations being chained like this, whereas we
aren't accustomed to seeing chains of modulus operations. (I don't think of
this as subscripting any more than I think of << and >> as bit shifting
operations when working with streams. I just see the concatenation of
multiple subscripts as ordinary, and thus more comfortable.)
> Well, maybe I should not care too much about passing manipulators, as
> this should not be used very frequently anyway..
I wouldn't presume that at this time.
Rob
Susquehanna International Group, LLP
http://www.sig.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk