[GSoC] coerce (previously construe_cast)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[GSoC] coerce (previously construe_cast)

Jeroen Habraken
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-feedback-td2967275.html.

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] coerce (previously construe_cast)

Andrew Sutton-3
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] coerce (previously construe_cast)

Hartmut Kaiser
> > 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] coerce (previously construe_cast)

Jeroen Habraken
On 4 April 2011 19:05, Hartmut Kaiser <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] coerce (previously construe_cast)

Chambers, Matthew
In reply to this post by Jeroen Habraken
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-feedback-td2967275.html.


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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost