[prev in list] [next in list] [prev in thread] [next in thread]
List: boost
Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Andrey Semashev <andrey.semashev () gmail ! com>
Date: 2009-02-28 18:26:23
Message-ID: 49A981CF.70509 () gmail ! com
[Download RAW message or body]
Emil Dotchevski wrote:
>>> Now, the user of uuid.hpp can also #include "boost/convert.hpp" when
>>> making calls to convert. This could provide generic overloads that
>>> support common conversion options, which would bind only if uuid.hpp
>>> doesn't provide overloads itself (which would obviously be more
>>> specialized and the overload resolution will prefer them over the
>>> convert.hpp generics.)
>> I can't imagine how the generic convert.hpp could provide support for
>> additional conversion options for user::uuid.
>
> Additional conversion options that are specific to converting
> user::uuid to string shouldn't be a concern for the generic convert
> framework. The caller can pass such additional arguments if user::uuid
> provides overloads that take them; if not then the caller will get a
> compile error, which is also appropriate.
I think that'll make too many of these overloads, with an added
confusion on the user's side, who has to remember the order of these
options in the overloads. I certainly like named arguments more.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic