[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