On Tue, Feb 17, 2009 at 11:55 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Tuesday, February 17, 2009 2:51 PM Emil Dotchevski wrote:
On Tue, Feb 17, 2009 at 11:43 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Tuesday, February 17, 2009 2:39 PM Emil Dotchevski wrote:
My question is, what is the motivation for the convert function? What's the use case for it that doesn't work with to_string/from_string?
That was my suggestion to account for both conversion directions and eliminate "string" from the name, thus opening the interface to other conversions.
An interface that converts anything to anything else is a separate issue, and requires a separate discussion.
If we concentrate on converting from and to string, I think that two families of functions, to_string and from_string is the most logical approach. When I want a string, I know that I want a string and at that time I don't care about any other conversions. I can't think of a use case when I might want a string but might also want something else.
The arguments, whether function or template, would specify the conversion to apply. For example, to_string<int>(s) could also be written as convert<int>(s). (Both can be rearranged to take two arguments and return a bool, for example, so the point is merely to eliminate directionality and "string" from the name.)
I don't buy this. In general, converting to_string requires formatting specifiers, etc. If the semantics of convert() are that it can convert anything to anything, it needs a way to configure the conversion, and I don't see how all this can be crammed into a single practical interface for all types (and even if that's possible, it's outside of the scope of this discussion IMO.) I'd much rather treat to_string and from_string not as synonyms of convert(), but as two independent interfaces (meaning, two separate HPP files: to_string.hpp and from_string.hpp) each designed for its specific task. These two conversions are important enough to justify this special attention. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode