[GSoC] coerce (previously construe_cast)
Hi, Some time ago I've announced construe_cast as a library which builds upon boost.spirit to create a cast-like operator aiming to provide an alternative to lexical_cast providing greater speed and flexibility. It has since been renamed to boost.coerce (it's the last rename, I promise) and it has found its way to the boost sandbox where development will continue. For the original email I'd like to point you to http://boost.2283326.n4.nabble.com/construe-cast-call-for-interest-and-feedb.... Due to an internship I haven't been able to get much done on this project lately. I would still very much like to see this through and because of this I would like to propose this as a GSoC project. There is quite a bit to be done to get this to the level expected from a potential boost library, however I believe I can get it in a state where it can be reviewed within the timespan set for the GSoC. The request for feedback stands, and please be expecting my proposal! Regards, Jeroen Habraken
Due to an internship I haven't been able to get much done on this project lately. I would still very much like to see this through and because of this I would like to propose this as a GSoC project. There is quite a bit to be done to get this to the level expected from a potential boost library, however I believe I can get it in a state where it can be reviewed within the timespan set for the GSoC.
The request for feedback stands, and please be expecting my proposal!
This seems like a very reasonable GSOC project assuming that somebody is willing to act as a mentor. Out of curiosity, have you thought about how the compile-time benefits of this library will interact with user-defined literals (a C++0x feature). I'm not saying that there is some kind of relationship. I just suspect that there might be some overlapping use cases. If you're going to submit a proposal, I think it would be worthwhile to add some discussion to this affect. Andrew
Due to an internship I haven't been able to get much done on this project lately. I would still very much like to see this through and because of this I would like to propose this as a GSoC project. There is quite a bit to be done to get this to the level expected from a potential boost library, however I believe I can get it in a state where it can be reviewed within the timespan set for the GSoC.
The request for feedback stands, and please be expecting my proposal!
This seems like a very reasonable GSOC project assuming that somebody is willing to act as a mentor.
I'd be willing to mentor this one (and frankly, I'd prefer to mentor this over the other project I said I would).
Out of curiosity, have you thought about how the compile-time benefits of this library will interact with user-defined literals (a C++0x feature). I'm not saying that there is some kind of relationship. I just suspect that there might be some overlapping use cases. If you're going to submit a proposal, I think it would be worthwhile to add some discussion to this affect.
Agreed. Regards Hartmut --------------- http://boost-spirit.com
On 4 April 2011 19:05, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Due to an internship I haven't been able to get much done on this project lately. I would still very much like to see this through and because of this I would like to propose this as a GSoC project. There is quite a bit to be done to get this to the level expected from a potential boost library, however I believe I can get it in a state where it can be reviewed within the timespan set for the GSoC.
The request for feedback stands, and please be expecting my proposal!
This seems like a very reasonable GSOC project assuming that somebody is willing to act as a mentor.
I'd be willing to mentor this one (and frankly, I'd prefer to mentor this over the other project I said I would).
Out of curiosity, have you thought about how the compile-time benefits of this library will interact with user-defined literals (a C++0x feature). I'm not saying that there is some kind of relationship. I just suspect that there might be some overlapping use cases. If you're going to submit a proposal, I think it would be worthwhile to add some discussion to this affect.
Agreed.
Regards Hartmut --------------- http://boost-spirit.com
Apparently some people misinterpreted my initial email and thought I would like someone else to finish this. That's absolutely not the case, this is something I would like to take on myself (which is possible since I'm a student). Regards, Jeroen
On 4/4/2011 6:11 AM, Jeroen Habraken wrote:
Hi,
Some time ago I've announced construe_cast as a library which builds upon boost.spirit to create a cast-like operator aiming to provide an alternative to lexical_cast providing greater speed and flexibility. It has since been renamed to boost.coerce (it's the last rename, I promise) and it has found its way to the boost sandbox where development will continue. For the original email I'd like to point you to http://boost.2283326.n4.nabble.com/construe-cast-call-for-interest-and-feedb....
On 09/10/2010 13:50, Mathias Gaunard wrote:
On 09/10/2010 13:42, PB wrote:
Rather than introducing another casting method, could lexical_cast be reworked internally to build upon Spirit? That way previous investments in lexical_cast will just work faster with no changes, Also, I won't need to stop and think which one I should be using.
The problem is that lexical_cast is a bit different since it takes into account C++ locales.
I think the important question is the following:
Do we care about C++ locales support in lexical_cast? Are people fine scrapping lexical_cast and have construe_cast take its name?
I like the idea of being able to use Spirit for lexical_cast despite the compile-time hit. Ideally, I'd like to be able to enable it with a preprocessor option rather than replacing lexical_cast outright or refactoring to use a different API. The preprocessor option could choose between the pure streams lexical_cast, lexical_cast with C runtime optimizations (good runtime performance, no compile-time hit), and lexical_cast with Spirit optimization (best runtime performance, but surely this would be a nasty compile-time hit when using lexical_cast across tens/hundreds of TUs!?) I for one don't much care about the locale support in lexical_cast. But since others probably do, would it be possible to use the optimized calls only when the locale is set to the default (with trivial runtime overhead)? The same check would apply to lexical_cast optimizations using the C runtime strtol/strtod as well. Thanks, -Matt
participants (4)
-
Andrew Sutton -
Hartmut Kaiser -
Jeroen Habraken -
Matthew Chambers