Boost logo

Boost :

Subject: Re: [boost] [http] Design ideas for a request router
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-03-22 20:11:28

On 22/03/2016 09:49, Vinícius dos Santos Oliveira wrote:
> 2016-03-20 19:06 GMT-03:00 Uisleandro <uisleandro_at_[hidden]>:
>> 4. This implementation considers "%i", "%d" and "%f" as the same, which
>> means that they will be placed in group,
> I don't like the use of printf-style formatters.
> For one, you have to learn these letter and they're useless anyway (C++ has
> the necessary machinery to detect the used type).
> Another reason to avoid them is the
> easy-to-misuse/lack-of-planned-extensibility/unsafety they tend to acquire
> as they evolve. Besides the type, you might need formatting options and
> using printf this is text you put between the '%' sign and the type letter.
> Expressions start to get long and confuse and it's hard to tell when they
> end. It's way easier to use something like Python's {} where you know where
> are the beginning/end points (even if you have several formatting options).
> Another issue is localization, but it may be less important in this domain.
> Printf style formatting doesn't allow you to reorder arguments, which is
> very important in localization where different languages may use the
> arguments in different order.

This encourages a clean syntax by default, although it does have
printf-based underpinnings as well.

>> "%%" (which means all the characters from the current position) are
>> placed separately;

This sort of thing is usually treated as an escape for an actual % in
the resulting string; it seems like a bad idea to give this a different

It also seems like a bad idea to use % in general in the context of URL
strings, as this already has a defined (hex escape) meaning. While
granted it would be rare to use unusual characters that require escapes
in API-style endpoint addresses, there's no particular reason that
someone should be prevented from doing so due to overloaded meanings.

Boost list run by bdawes at, gregod at, cpdaniel at, john at