Re: [boost] [lexical_cast] A suggestion
That's not my concern. My concern is that I don't think lexical_cast is a particularly good interface for its main uses, which could be thought of as "to-string" and "from-string."
Dave, I am not sure what you see wrong with lexical_cast interface. Could you elaborate? I am not using lexical_cast (due to throw, no default value and the def.ctor requirement). So, I still keep using the analog I wrote a while back and well before I ever heard of lexical_cast. Even though I wrote it independently, the interface happened to be very close: namespace aux { namespace string { template<class Type> std::string from (Type const&); template<class Type, class String> bool is (String const&) throw(); template<class Type, class String> Type to (String const&); template<class Type, class String> Type to (String const&, Type const&); } } That is, string str = aux::string::from(-1); int i1 = aux::string::to<int>(str); // throw int i2 = aux::string::to<int>(str, -1); // no throw As you can see it is pretty close to lexical_cast.
... I just don't think lexical_cast is the interface we need for most convenient string conversions.
It might be the case. However, I do not see any other practical suggestions that we could act on. Therefore, in the end we end up with nothing at all... again. That's been dragging for far too long.
... Maybe so, but I don't think lexical_cast is all that well-designed for convenience to begin with, and tacking on little convenience features isn't likely to yield a very clean interface.
I am not that concerned about the internal design as it can be worked on and improved without rush behind the interface. If it is the interface that is the issue, then let's look at it. Any suggestions? So far, I do not see people arguing against that proposed "extension" offering anything practical in return. That is not constructive as people end up with nothing at all. I am not counting the <optional> suggestion as it seems as an overkill and it still has the default-constructability requirement. Thanks, Vladimir.
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
That's not my concern. My concern is that I don't think lexical_cast is a particularly good interface for its main uses, which could be thought of as "to-string" and "from-string."
Dave, I am not sure what you see wrong with lexical_cast interface. Could you elaborate? I am not using lexical_cast (due to throw, no default value and the def.ctor requirement). So, I still keep using the analog I wrote a while back and well before I ever heard of lexical_cast. Even though I wrote it independently, the interface happened to be very close:
namespace aux { namespace string { template<class Type> std::string from (Type const&); template<class Type, class String> bool is (String const&) throw(); template<class Type, class String> Type to (String const&); template<class Type, class String> Type to (String const&, Type const&); } }
I rather like it.
That is,
string str = aux::string::from(-1); int i1 = aux::string::to<int>(str); // throw int i2 = aux::string::to<int>(str, -1); // no throw
As you can see it is pretty close to lexical_cast.
Yeah, well it doesn't ever make you type "<string>." But also, it isn't trying to be lexical_cast. lexical_cast takes one type's lexical representation and tries to interpret that as another type. That's a very odd kind of semantics that just happens to line up with something very useful when one of the types is a string. I've never heard of anyone using lexical_cast when one of the types was something else. Have you?
... I just don't think lexical_cast is the interface we need for most convenient string conversions.
It might be the case. However, I do not see any other practical suggestions that we could act on. Therefore, in the end we end up with nothing at all... again. That's been dragging for far too long.
Let's start with something like your interface. Propose a utility library. Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space.
Maybe so, but I don't think lexical_cast is all that well-designed for convenience to begin with, and tacking on little convenience features isn't likely to yield a very clean interface.
I am not that concerned about the internal design
I said "interface," not "implementation."
as it can be worked on and improved without rush behind the interface. If it is the interface that is the issue, then let's look at it. Any suggestions? So far, I do not see people arguing against that proposed "extension" offering anything practical in return. That is not constructive as people end up with nothing at all.
I am not counting the <optional> suggestion as it seems as an overkill
I think that's kinda twisted. lexical_cast is already _huge_ compared to optional, since it drags in iostreams. Optional is a very basic component.
and it still has the default-constructability requirement.
Actually it doesn't. optional<T> is always default constructible as empty, and even if T isn't default constructible you could always define istream& operator>>(istream&, optional<T>&) for some particular T. Have you proposed some way to do away with default constructibility somehow? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
... Yeah, well it doesn't ever make you type "<string>." But also, it isn't trying to be lexical_cast. lexical_cast takes one type's lexical representation and tries to interpret that as another type. That's a very odd kind of semantics that just happens to line up with something very useful when one of the types is a string. I've never heard of anyone using lexical_cast when one of the types was something else. Have you?
Yes, I readily admit that the idea indeed looked very odd when I looked at the implementation... then I thought that smarter-than-me people looked into it and gave their approval. Still, you are right mentioning that I never had any inclanation to use lexical_cast<> beyond to/from-string conversions.
... I just don't think lexical_cast is the interface we need for most convenient string conversions.
It might be the case. However, I do not see any other practical suggestions that we could act on. Therefore, in the end we end up with
nothing at all... again. That's been dragging for far too long.
Let's start with something like your interface. Propose a utility library. Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space.
OK, I'll investigate.
...
I am not counting the <optional> suggestion as it seems as an overkill
I think that's kinda twisted. lexical_cast is already _huge_ compared to optional, since it drags in iostreams. Optional is a very basic component.
I am not sure I can agree it is twisted. From the user point of view lexical_cast is very straightforward. By throwing <optional> into the mix you immediately increase overall complexity and the entry level.
and it still has the default-constructability requirement.
Actually it doesn't. optional<T> is always default constructible as empty, and even if T isn't default constructible you could always define
istream& operator>>(istream&, optional<T>&)
for some particular T.
At the moment I cannot have another look at optional. When I looked at it before, I saw it needed/expected T::T() somewhere to compile. I'll try it again when I get a chance.
Have you proposed some way to do away with default constructibility somehow?
Foo default_foo; Foo foo = lexical_cast(str, default_foo); (or whatever instead of lexical_cast) has no Foo::Foo() requirement. Best, V.
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
Have you proposed some way to do away with default constructibility somehow?
Foo default_foo; Foo foo = lexical_cast(str, default_foo);
(or whatever instead of lexical_cast) has no Foo::Foo() requirement.
and... how is lexical_cast going to come up with an object into which it can stream? Is it going to use default_foo? In that case, what if streaming fails partway through? Are you assuming copyability? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Foo default_foo; Foo foo = lexical_cast(str, default_foo);
(or whatever instead of lexical_cast) has no Foo::Foo() requirement.
and... how is lexical_cast going to come up with an object into which it can stream? Is it going to use default_foo? In that case, what if streaming fails partway through? Are you assuming copyability?
Yes, the copy-constructability requirement is still there. Currently lexicac_cast does if(interpreter << arg) { Target result; // DEFAULT-CONSTRUCTED if (interpreter >> result) return result; } throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return Target(); // DEFAULT-CONSTRUCTED For the proposed "extended" interface I imagined something as simple/minimal as if(interpreter << arg) { Target result(failure_value); // COPY-CONSTRUCTED if (interpreter >> result) return result; } return failure_value; // COPY-CONSTRUCTED The likely reason I got so hooked up on extending lexical_cast (rather than branching off) is that it already implements 95% of what I need/do. With lexical_cast submitted for TR2 I had an impression that it was the preferred interface we should be utilizing rather than branching off on our own. Now I get the feeling that people are suggesting/implying we should leave lexical_cast behind as an interesting-but-not-quite-successful experiment (which I somewhat agree with) and start fresh free of its shackles. V.
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
Now I get the feeling that people are suggesting/implying we should leave lexical_cast behind as an interesting-but-not-quite-successful experiment (which I somewhat agree with) and start fresh free of its shackles.
That's just my opinion. And of course, I could be wrong ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
Now I get the feeling that people are suggesting/implying we should leave lexical_cast behind as an interesting-but-not-quite-successful experiment (which I somewhat agree with) and start fresh free of its shackles.
That's just my opinion. And of course, I could be wrong ;-)
As someone who originally supported Vladimir's original suggestion, I would say that I agree with the idea of a fresh start.
David Abrahams wrote:
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
Now I get the feeling that people are suggesting/implying we should leave lexical_cast behind as an interesting-but-not-quite-successful experiment (which I somewhat agree with) and start fresh free of its shackles.
That's just my opinion. And of course, I could be wrong ;-)
As someone who originally supported Vladimir's original suggestion, I would say that I agree with the idea of a fresh start.
I understand. However, I feel uneasy about the easy we are planning to brush lexical_cast off. That must be very disheartening for Kevlin (the author) and Alex (Nasonov, the maintainer). Primarily for Alex as I feel he's been putting quite an effort into it lately. Even though I *might* be leaning towards a fresh start from the technical point of view, it does not feel right morally. Even from purely technical point of view I feel Alex'd be best qualified to make the move as I feel it'll be largely lexical_cast implementation (at least initially) under a different/better/stricter interface. Alex, are you there? How do feel about it? Could you do it? As you can see your effort won't be in vain and already there is quite a support for your effort. I really want you to spearhead the effort. V.
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
David Abrahams wrote:
on Sun Feb 08 2009, Vladimir.Batov-AT-wrsa.com.au wrote:
Now I get the feeling that people are suggesting/implying we should leave lexical_cast behind as an interesting-but-not-quite-successful experiment (which I somewhat agree with) and start fresh free of its shackles.
That's just my opinion. And of course, I could be wrong ;-)
As someone who originally supported Vladimir's original suggestion, I would say that I agree with the idea of a fresh start.
I understand. However, I feel uneasy about the easy we are planning to brush lexical_cast off. That must be very disheartening for Kevlin (the author) and Alex (Nasonov, the maintainer). Primarily for Alex as I feel he's been putting quite an effort into it lately.
I'm not suggesting it be "brushed off," I'm just saying that whatever it's intended to be, it isn't the tool that the many people who want nothrow this-or-that are asking for. I don't believe any good can come from an outraged user community trying to get the author and maintainer to make it into something they don't believe it should be. lexical_cast should remain consistent with the vision of its author and maintainer. If many people need something else, they should have it. Then lexical_cast can gain or lose users on its own merits. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
<Vladimir.Batov <at> wrsa.com.au> writes:
Alex, are you there? How do feel about it? Could you do it? As you can see your effort won't be in vain and already there is quite a support for your effort. I really want you to spearhead the effort.
Sorry guys, My little boy is more important than all other things in the world. I will come back to this discussion later. PS NHS (National Health Services) stuff start counting days from day 0. So, a day when a baby was born is day 0. Not all babys become programmers, though ;) Alex
participants (4)
-
Alexander Nasonov -
David Abrahams -
Deane Yang -
Vladimir.Batov＠wrsa.com.au