Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-06-02 09:27:51

Gavin Lambert wrote
> On 26/05/2014 02:59, quoth Thijs (M.A.) van den Berg:
>> The value of convert to me seems to be more in the context of
>> generic programming for a wide range of types with a uniform
>> interface than for a simple interface for specific types for
>> which there are already simple & standard alternatives.
> 
> This comment in the context of strings made me think of stateful 
> converters.  I haven't really looked at the proposed library too 
> closely, but is it supported/expected to have mutable converters?
> 
> An example of this in another conversion library was one that provided 
> for conversion from std::wstring to const char *.  This was handled by 
> having a local instance of a "context" object (possibly analogous to the 
> converter) that internally stored any memory allocated during the course 
> of the conversion, such that the returned pointer remained valid as long 
> as the context object was in scope, and no memory was leaked.
> 
> Furthermore, the way the templates were defined made it a compile error 
> to try to perform that type of conversion without supplying a context 
> object (whereas converting from std::wstring to std::string could be 
> done with or without one, as it did not require intermediate storage).
> 
> The same context object could be used in multiple conversions and each 
> would be kept distinct (so no conflicts between returned pointers), but 
> all freed at the end.

Gavin, my humble apologies for answering your post/question that late.
Somehow I managed to miss it in the avalanche. Now that I am re-reading the
threads, I've come across your post and it made me very excited. You are
describing IMO a quite interesting/tricky conversion case that the proposed
design (with external converters passed in) handles seemingly with ease. In
the proposed design converters are created/configured independently from
actual conversion. So, they can store configuration/state. Say,
std::sstream-based converter remembers hex/dec/oct/uppercase/locale
settings, etc. In the case of std::wstring -> "char const*" that might be as
follows:

char buf[...];
my_converter cnv;

optional<char const*> res = convert<char const*>(from, cnv(buf));

Above "cnv(buf)" takes "buf" and uses it during conversion and returns
pointer to it if successful. Does it sound like the case you describe?
Admittedly, that would not probably my deployment choice but to me it seems
to demonstrate the flexibility/adaptability of the design.

--
View this message in context: http://boost.2283326.n4.nabble.com/review-Convert-library-tp4662821p4663246.html
Sent from the Boost - Dev mailing list archive at Nabble.com.