Re: [boost] [http] Design ideas for a request router

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.

http://www.boost.org/doc/libs/1_60_0/libs/format/doc/format.html

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 
meaning.

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.