Boost logo

Boost :

Subject: Re: [boost] Variadic append for std::string
From: Olaf van der Spek (ml_at_[hidden])
Date: 2017-01-16 03:54:34


On Sun, Jan 15, 2017 at 9:42 PM, Damien Buhl <damien.buhl_at_[hidden]> wrote:

> On 15/01/2017 14:39, Christof Donat wrote:
> > We were talking about performance here. Therefore I tried to come up
> > with a syntax, that can be implemented without virtual function calls
> > as much as possible and avoids parsing format strings. Also that
> > syntax should allow for creating the result in one go, in order to
> > avoid unnecessary reallocations. Keeping that in mind, I think, my
> > proposal is not the worst possible, though, of course, someone might
> > come up with a better one.
> >
> Yes sorry I've been distracted by the discussion about formatting,
> because indeed your API idea looks like a good choice when it come to
> the initial problem of this discussion : appending / concatenating.
> While users might find more intuitive a variadic concat(...) api.
>
> But to close the ellipsis about formatting : with something like Abel
> Sincovick's snprintf in principle you only pay for the parsing at
> compile-time and at runtime you have your string formatted with no/less
> dynamic allocation.
>

http://abel.web.elte.hu/mpllibs/safe_printf/snprintf.html

It appears to only do checking at compile-time and then forwards to
sprintf..

>
> > Libraries like boost::format have their strengths, when simply
> > concatenating information does not fit the needs. E.g. for
> > internationalized text output. I like boost::format a lot, but speed
> > actually is not its focus.
> I personally uses boost::format alot, but I think boost::format would be
> easier and shorter to use if it would be callable with an `std::string
> snprintf(format_str, args...)`. And it would be awesome that format_str
> would be, if already known at compile time handled with Metaparse.
> Sorry for getting off-topic. :D
>

Can't boost::format be updated to a variadic variant?

-- 
Olaf

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk