Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
On Wed, 2011-03-30 at 18:16 +0300, Matthew Chambers wrote:
Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for string->number and number->string (template specializations using strtol/strtod; or optionally using the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) would be nice too [...] Which reminds me - lexical_cast error messages are not very informative[...]
Agreed. This should be added as well[...]
-Matt
Added some optimizations for casts to integral types ( you can see them in tickets #5417 and #5350). Did not used strtol/strtod (it will be hard to implement tags/ios flags if we`ll use them, hard to detect overflows), did not used spirit library (it`s too big, includes too many files, and looks like it`s API changes often). Alexander Nasonov wrote:
Stewart, Robert wrote:
Not true. You and others will benefit from the patches. First, they can be applied manually to local Boost installations, even if they aren't part of a Boost release. Second, others, with commit permission, can apply the patches even without an active maintainer if they are sufficiently comfortable with doing so (and there's enough noise to get their attention). Besides, you could volunteer to be the maintainer!
No objections from me (the current maintaier). I don't have time for this any more.
Alex
If there will be no active maintainer, I`d like to have at least commit permissions to lexical_cast library (if nobody has objections). I`ve got some ideas on implementing tags/ios flags and there are some more possible optimizations for float types and locales usage. So, is there any volunteers to be the maintainer? - Antony
On 4 Apr 2011, at 21:19, Antony Polukhin wrote:
If there will be no active maintainer, I`d like to have at least commit permissions to lexical_cast library (if nobody has objections). I`ve got some ideas on implementing tags/ios flags and there are some more possible optimizations for float types and locales usage.
If you are making modifications, there really needs to be someone who keeps an eye on the test results and bug reports to make sure nothing is broken. If you want to make some changes anyway,why not also be the maintainer? :) Chris
Antony Polukhin <antoshkka <at> gmail.com> writes: ... Added some optimizations for casts to integral types ( you can see them in tickets #5417 and #5350). Did not used strtol/strtod (it will be hard to implement tags/ios flags if we`ll use them, hard to detect overflows), did not used spirit library (it`s too big, includes too many files, and looks like it`s API changes often).
Various limitations of and extension requests to the existing lexical_cast persistently (and understandably) keep popping up on this list. Quite some time back now I myself was requesting a few features added to it and thought it'd be relatively straightforward. Back then I was explained by Kevlin Henney (the lexical_cast author) and Alexander Nasonov (the current maintainer) that the requested features were spilling over the original lexical_cast design concept and, essentially, lexical_cast was closed for extension business (or so I understood). That resulted in lengthy discussions (search for [convert] in archives) where to go and how to proceed and in the end the decision has been made to essentially branch off or to break free or to start fresh (whatever one's preference might be) and now there has been the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc. Regards, Vladimir.
Message du 07/04/11 00:49 De : "Vladimir Batov" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
Antony Polukhin gmail.com> writes: ... Added some optimizations for casts to integral types ( you can see them in tickets #5417 and #5350). Did not used strtol/strtod (it will be hard to implement tags/ios flags if we`ll use them, hard to detect overflows), did not used spirit library (it`s too big, includes too many files, and looks like it`s API changes often).
Various limitations of and extension requests to the existing lexical_cast persistently (and understandably) keep popping up on this list. Quite some time back now I myself was requesting a few features added to it and thought it'd be relatively straightforward. Back then I was explained by Kevlin Henney (the lexical_cast author) and Alexander Nasonov (the current maintainer) that the requested features were spilling over the original lexical_cast design concept and, essentially, lexical_cast was closed for extension business (or so I understood). That resulted in lengthy discussions (search for [convert] in archives) where to go and how to proceed and in the end the decision has been made to essentially branch off or to break free or to start fresh (whatever one's preference might be) and now there has been the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc.
It will be great to have a performance comparison between your library and lexical cast (with a without the proposed modifications) as one of the major concerns of your library were to provide an interface that performs better than lexical_cast. Maybe Antony can provide the program he used to make the comparison before and after the patch Best, Vicente
----- Original Message ----- From: "Vicente BOTET" <vicente.botet@wanadoo.fr>
... the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc.
It will be great to have a performance comparison between your library and lexical cast (with a without the proposed modifications) as one of the major concerns of your library were to provide an interface that performs better than lexical_cast.
As I understand the main goal of the Convert library was to provide richer interface (or so I understood). Namely, to support configurable throwing behavior, locale, formatting and ability to extend if/when needed. Therefore, quite a bit of effort was put into working out the framework, the interface. In that light at this stage I feel that trying to address performance in Convert would be somewhat premature. Consequently, I do not expect the Convert library to do to/from-string conversions any better or worse than lexical_cast as at present Convert uses the same std::stream-based engine for those conversions. Having said that I do believe that performance needs to be addressed at some point and I am currently leaning towards deploying Spirit facilities to do that. If anyone has better suggestions, implementations, I do not see anything stopping them from incorporating those improvements into Convert. Obviously, before we go ahead doing that we have to find out if that library has any future to begin with. Best, V.
2011/4/7 Vladimir Batov <vbatov@people.net.au>:
----- Original Message ----- From: "Vicente BOTET" <vicente.botet@wanadoo.fr>
... the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc.
It will be great to have a performance comparison between your library and lexical cast (with a without the proposed modifications) as one of the major concerns of your library were to provide an interface that performs better than lexical_cast.
As I understand the main goal of the Convert library was to provide richer interface (or so I understood). Namely, to support configurable throwing behavior, locale, formatting and ability to extend if/when needed. Therefore, quite a bit of effort was put into working out the framework, the interface. In that light at this stage I feel that trying to address performance in Convert would be somewhat premature.
Agreed. But a lot of libraries (even in boost) use lexical_cast. And performance improvemnts will be appreciated. Patches only add performance, and there can be done some more improvements (for float types conversion). So the quiestion with applying patches is still open.
----- Original Message ----- From: "Antony Polukhin" <antoshkka@gmail.com> ... But a lot of libraries (even in boost) use lexical_cast. And performance improvemnts will be appreciated. Patches only add performance, and there can be done some more improvements (for float types conversion). So the quiestion with applying patches is still open.
By no means I tried to suggest abandoning/ignoring lexical_cast. I am sure it'll stick around for quite some time no matter what. I only tried to raise your awareness of the fact that similar requests/suggestions/attempts have been made in the past and for a number of reasons the overwhelming view on this list was that it was better to leave lexical_cast as-is and to start fresh. That said, Boost libraries do use lexical_cast and I am sure would benefit from any improvements in it. Just be prepared that those improvements might be limited to the under-the-hood implementation and that the interface (my biggest gripe) improvements might be ruled out. That was my (and people before me) experience anyway. V.
Message du 07/04/11 11:23 De : "Vladimir Batov" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 isquite older than in trunk
----- Original Message ----- From: "Vicente BOTET"
... the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc.
It will be great to have a performance comparison between your library and lexical cast (with a without the proposed modifications) as one of the major concerns of your library were to provide an interface that performs better than lexical_cast.
As I understand the main goal of the Convert library was to provide richer interface (or so I understood). Namely, to support configurable throwing behavior, locale, formatting and ability to extend if/when needed. Therefore, quite a bit of effort was put into working out the framework, the interface. In that light at this stage I feel that trying to address performance in Convert would be somewhat premature. Consequently, I do not expect the Convert library to do to/from-string conversions any better or worse than lexical_cast as at present Convert uses the same std::stream-based engine for those conversions. Having said that I do believe that performance needs to be addressed at some point and I am currently leaning towards deploying Spirit facilities to do that. If anyone has better suggestions, implementations, I do not see anything stopping them from incorporating those improvements into Convert. Obviously, before we go ahead doing that we have to find out if that library has any future to begin with.
I replied to your post because you were suggesting the PO to see your library. As the PO was proposing performance improvements on lexical cast I thought that maybe your library could already provide what the PO was expecting. Unfortunatelly for PO it seems it is not the case. Best, Vicente
Hi, On 7 April 2011 11:19, Vladimir Batov <vbatov@people.net.au> wrote:
----- Original Message ----- From: "Vicente BOTET" <vicente.botet@wanadoo.fr>
... the Convert proposal sitting in the queue and getting ready for the review this month. I'd suggest anyone interested in additional lexical_cast features to have a look the the proposal if it already satisfies your needs. If not, then it's most definitely open for improvements/extensions/ideas/etc.
It will be great to have a performance comparison between your library and lexical cast (with a without the proposed modifications) as one of the major concerns of your library were to provide an interface that performs better than lexical_cast.
As I understand the main goal of the Convert library was to provide richer interface (or so I understood). Namely, to support configurable throwing behavior, locale, formatting and ability to extend if/when needed. Therefore, quite a bit of effort was put into working out the framework, the interface. In that light at this stage I feel that trying to address performance in Convert would be somewhat premature. Consequently, I do not expect the Convert library to do to/from-string conversions any better or worse than lexical_cast as at present Convert uses the same std::stream-based engine for those conversions. Having said that I do believe that performance needs to be addressed at some point and I am currently leaning towards deploying Spirit facilities to do that. If anyone has better suggestions, implementations, I do not see anything stopping them from incorporating those improvements into Convert. Obviously, before we go ahead doing that we have to find out if that library has any future to begin with.
Best, V.
You've hit the nail on the head there I think. The lexical_cast author has always maintained a policy of not extending the library with extra features. However, this seems like the way forward to me and all the new features that convert has can be added to lexical_cast. Some have even been added and proposed as patches, but they weren't accepted due to this aforementioned policy. Now that this is no longer a problem I believe we should be extending lexical_cast instead of adding another library, especially since deprecating lexical_cast is not an option. I'm working on a library which is taking the spirit road you mentioned; it's called coerce and can be found in the boost sandbox. It still has some rough edges but I've proposed a GSoC project to fix this, see http://boost.2283326.n4.nabble.com/GSoC-coerce-previously-construe-cast-td34.... This I believe to be a completely different approach whilst the convert library seems to be reimplementing lexical_cast instead of fixing it. Regards, Jeroen
----- Original Message ----- From: "Jeroen Habraken" <vexocide@gmail.com> ... ... they weren't accepted due to this aforementioned policy. Now that this is no longer a problem I believe we should be extending lexical_cast instead of adding another library, especially since deprecating lexical_cast is not an option.
If the situation with regard to lexical_cast has changed so dramatically, then I am certainly not aware of it. Would you mind elaborating how you've come to the conclusion that lexical_cast is now open for improvements? By "improvements" I mean chiefly interface extensions as without fallback value, configurable throwing behavior, locale, formatting, etc. lexical_cast has very limited application.
I'm working on a library which is taking the spirit road you mentioned; it's called coerce and can be found in the boost sandbox. It still has some rough edges but I've proposed a GSoC project to fix this, see http://boost.2283326.n4.nabble.com/GSoC-coerce-previously-construe-cast-td34.... This I believe to be a completely different approach whilst the convert library seems to be reimplementing lexical_cast instead of fixing it.
Here we need to separate and constantly keep in mind the fact that there are always two sides to every coin. In case of development they are interface and implementation. If one needs to manage resources and to minimize the effort to achieve certain result (rather than simply enjoying the process of writing code), then interface and implementation need to be addressed separately and interface has to come first. With interface worked out and *some* implementation one can ship the product and start gathering feedback while improving underlying implementation (say, performance-wise). That's the road I've taken with Convert. The major effort so far went in to Convert interface. Consequently, I have to disagree that "convert library seems to be reimplementing lexical_cast". I am well out of my rebel years when I simply wanted to reimplement something existing just because the "new" one would be "mine" and a notch faster. Convert provides considerably richer interface (IMHO of course) and that considerably widens Convert applicability compared to lexical_cast. Granted, currently under-the-hood Convert still uses stream-based engine for some conversions. However, it was not a result of underlying design but a pragmatic decision to start testing the concept quicker. Does it perform its best performance-wise? Hardly. However, it rolls the product out to the potential users (now I seem to sound like a manager ;-) ) many of which mind you are not so performance-minded. Now I'd be very happy for you to step in and to apply your "completely different approach" to the implementation within the boundaries of the agreed interface. Here I am in agreement with Hartmut Kaiser and others that Spirit would be a worthy conversion engine (where applicable). Can you propose/incorporate your work for/into Convert? I am not saying Convert is better than what you've done so far. What I am saying is that together we'll achieve more and logistically Convert just happens to be further along that acceptance road. If you want, you can have all the kudos and laurels and whatever... I did not want to write that Convert in the first place anyway... I was hoping someone else would extend lexical_cast to make it useful/usable *for* me ;-) So, what do you say? V.
On 8 April 2011 01:52, Vladimir Batov <vbatov@people.net.au> wrote:
----- Original Message ----- From: "Jeroen Habraken" <vexocide@gmail.com> ... ... they weren't accepted due to this aforementioned policy. Now that this is no longer a problem I believe we should be extending lexical_cast instead of adding another library, especially since deprecating lexical_cast is not an option.
If the situation with regard to lexical_cast has changed so dramatically, then I am certainly not aware of it. Would you mind elaborating how you've come to the conclusion that lexical_cast is now open for improvements? By "improvements" I mean chiefly interface extensions as without fallback value, configurable throwing behavior, locale, formatting, etc. lexical_cast has very limited application.
Since the library is without a maintainer I believe if someone steps up it can be taken forward. The features you mention would certainly be nice to have.
I'm working on a library which is taking the spirit road you mentioned; it's called coerce and can be found in the boost sandbox. It still has some rough edges but I've proposed a GSoC project to fix this, see http://boost.2283326.n4.nabble.com/GSoC-coerce-previously-construe-cast-td34.... This I believe to be a completely different approach whilst the convert library seems to be reimplementing lexical_cast instead of fixing it.
Here we need to separate and constantly keep in mind the fact that there are always two sides to every coin. In case of development they are interface and implementation. If one needs to manage resources and to minimize the effort to achieve certain result (rather than simply enjoying the process of writing code), then interface and implementation need to be addressed separately and interface has to come first. With interface worked out and *some* implementation one can ship the product and start gathering feedback while improving underlying implementation (say, performance-wise).
That's the road I've taken with Convert. The major effort so far went in to Convert interface. Consequently, I have to disagree that "convert library seems to be reimplementing lexical_cast". I am well out of my rebel years when I simply wanted to reimplement something existing just because the "new" one would be "mine" and a notch faster. Convert provides considerably richer interface (IMHO of course) and that considerably widens Convert applicability compared to lexical_cast. Granted, currently under-the-hood Convert still uses stream-based engine for some conversions. However, it was not a result of underlying design but a pragmatic decision to start testing the concept quicker. Does it perform its best performance-wise? Hardly. However, it rolls the product out to the potential users (now I seem to sound like a manager ;-) ) many of which mind you are not so performance-minded. Now I'd be very happy for you to step in and to apply your "completely different approach" to the implementation within the boundaries of the agreed interface. Here I am in agreement with Hartmut Kaiser and others that Spirit would be a worthy conversion engine (where applicable). Can you propose/incorporate your work for/into Convert? I am not saying Convert is better than what you've done so far. What I am saying is that together we'll achieve more and logistically Convert just happens to be further along that acceptance road. If you want, you can have all the kudos and laurels and whatever... I did not want to write that Convert in the first place anyway... I was hoping someone else would extend lexical_cast to make it useful/usable *for* me ;-)
So, what do you say?
Your library does have richer interface but will inevitable implement parts that are already in lexical_cast when sticking to the stream-based implementation. I consider this undesirable since it is unlikely that lexical_cast will be deprecated once your library is added. Considering the merging of the two libraries, I believe it to be a bad idea. This is only useful if both implementation return exactly the same results for each function which, considering locale etc., is simply impossible. If you wish to only have a spirit based implementation it makes no sense to incorporate my code into convert either.
V.
Jeroen
participants (5)
-
Antony Polukhin -
Christopher Jefferson -
Jeroen Habraken -
Vicente BOTET -
Vladimir Batov