Re: [boost] Re: Review : format2, yet another 'printf class'

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-07-02 06:09:05

> Given that there is a "common practice" extension of C's printf to support $
> for positional arguments (as in the "%2$s" form), which is currently
> included (and which I'd like to see stay), it's not clear what the best way
> of addressing this might be. Pick an alternative character? "#" - for
> "number" (ie, argument number) might do, but does it clash with other usage?
> How does that square with the incompatibility with existing practice?

I'm not even sure I understood the issue right.
Format should not require the users to type '$' in order to use the
library, but can internally have '$' in its source, can it ?

if Yes :
what I can do is leave printf directives as is, with %5$s supported,
but add a note somewhere that '$' can be replaced by '#' in format
strings with no difference in the effects, for those that can not (or dont
want to) have '$' in their code files. it does not bring any parsing
difficulty at all.
It should be all right like this, I hope.

if No:
I can even use a 'universal character' notation for '$' in the format
implementation, if '$' really should not appear anywhere.
well, it would still appear in the docs, though..
And I guess very few compilers support this notation right now, so it is
rather a solution for the long term, so we can tolerate '$' in format's
sources the time being..

I place some importance in providing support for printf directives, even
if you need to use a specific mode, as currently designed with 'pformat'
vs  'format'.
so I would very reluctantly leave away the support of '$' in '%5$s'..

 > But I do thing there's a need for a cleaner "convert to string" operation.
> At the very least, a non-member str() function seems notationally cleaner -
>
>     str(format("%.20s") % my_string)

adding this function is on my todo list.
Even if not very different (still a pair of parenthesis), it is already a bit nicer.

> As an alternative (not a particularly good one, IMHO...) would be some form
> of magic "convert to string" manipulator - something like
>
>     format("%.20s") % my_string % to_str

Yes, we can define a class format_manip and define
string operator%(format& , format_manip&)

I think it would be chosen by the compiler
(rather than operator%(format&, T&)   )
without ambiguity.

But I too find  it  ugly..

> But the need for the extra brackets and dot notation in
>
>     (format(%.20s") % my_string).str()
>
> make it look irredeemably ugly to me.

that's sure.
I'll add the str function.

by the way, why  must we avoid defining format::operator string()  ?
it makes the nicest syntax for conversion, of course..

-- 
Sam