Hi, I am wondering, what is the status of the Boost.Conversion library? On the Review Schedule page, it indicates that a review had taken place in August 2011 and the results of the review are "pending". Does anyone when the results will be forthcoming? Thanks, Nate
Le 22/06/12 08:10, Nathan Ridge a écrit :
Hi,
I am wondering, what is the status of the Boost.Conversion library? Hi,
are you interested on the library? the review status?
On the Review Schedule page, it indicates that a review had taken place in August 2011 and the results of the review are "pending".
Does anyone when the results will be forthcoming?
Gordon will send the review status soon. Best, Vicente
Hi,
I am wondering, what is the status of the Boost.Conversion library? Hi,
are you interested on the library? the review status?
I am interested in the library. At the moment I am particularly interested in the ptime <--> chrono conversions (there isn't functionality for that elsewhere in Boost, is there?), but the library as a whole seems interesting and useful. By the way, I have a question about the ptime <--> chrono conversions. In this stackoverflow question [1], the implementation of these conversions is suggested as a way to implement ptime <--> std::chrono conversions, and Howard Hinnant points out in a comment to the accepted answer that this implementation silently returns incorrect results if the clock's epoch is not the same as ptime's. I am wondering, is your implementation susceptible to this problem, or can you somehow assume more about the epoch of a boost::chrono clock than you could about the epoch of an std::chrono clock? In case your implementation does have this problem, Howard also suggests a solution in another comment. Regards, Nate [1] http://stackoverflow.com/questions/4910373/interoperability-between-boostdat...
Hi Nathan, On Jun 22, 2012, at 9:34 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
I am wondering, what is the status of the Boost.Conversion library?
are you interested on the library? the review status?
I am interested in the library.
I am sorry it has taken such a ridiculously long time to file a report. I don't think it's any secret that the library is rejected, the core problem being that there is no universal conversion domain, so a mechanism relying on template specialization and overloaded functions was found to be unworkable.
At the moment I am particularly interested in the ptime <--> chrono conversions (there isn't functionality for that elsewhere in Boost, is there?), but the library as a whole seems interesting and useful.
I agree that the idea of the library is interesting and useful. I suggest that Vicente might publish these individual conversion routines as plain old functions (or functors) in the Chrono source, while we wait for some acceptable general-purpose framework to plug them into for a nice generic interface. Cheers, Gordon
2012/6/28 Gordon Woodhull <gordon@woodhull.com>
Hi Nathan,
On Jun 22, 2012, at 9:34 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
I am wondering, what is the status of the Boost.Conversion library?
are you interested on the library? the review status?
I am interested in the library.
I am sorry it has taken such a ridiculously long time to file a report.
I don't think it's any secret that the library is rejected, the core problem being that there is no universal conversion domain, so a mechanism relying on template specialization and overloaded functions was found to be unworkable.
At the moment I am particularly interested in the ptime <--> chrono conversions (there isn't functionality for that elsewhere in Boost, is there?), but the library as a whole seems interesting and useful.
I agree that the idea of the library is interesting and useful.
I suggest that Vicente might publish these individual conversion routines as plain old functions (or functors) in the Chrono source, while we wait for some acceptable general-purpose framework to plug them into for a nice generic interface.
+1. Kris
Le 28/06/12 12:52, Krzysztof Czainski a écrit :
2012/6/28 Gordon Woodhull<gordon@woodhull.com>
Hi Nathan,
On Jun 22, 2012, at 9:34 PM, Nathan Ridge<zeratul976@hotmail.com> wrote:
I am wondering, what is the status of the Boost.Conversion library? are you interested on the library? the review status? I am interested in the library. I am sorry it has taken such a ridiculously long time to file a report.
I don't think it's any secret that the library is rejected, the core problem being that there is no universal conversion domain, so a mechanism relying on template specialization and overloaded functions was found to be unworkable.
At the moment I am particularly interested in the ptime<--> chrono conversions (there isn't functionality for that elsewhere in Boost, is there?), but the library as a whole seems interesting and useful. I agree that the idea of the library is interesting and useful.
I suggest that Vicente might publish these individual conversion routines as plain old functions (or functors) in the Chrono source, while we wait for some acceptable general-purpose framework to plug them into for a nice generic interface.
+1. Kris
Hi, I would prefer to avoid a dependency from Boost.Chrono to Boost.DateTime. The conversions are not too difficult. You could adapt them for your own application avoiding any hole I could have in my first implementation ;-) Best, Vicente
On Jun 28, 2012, at 7:20 AM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I would prefer to avoid a dependency from Boost.Chrono to Boost.DateTime.
Understood. Boost.Conversion has/had a nice directory structure to put these things in. But for the sake of argument, what is the difference between an optional header dependency between Chrono and DateTime, and an optional header dependency from Conversion to both libraries? Is your objection because Chrono is mostly standard? A few reviewers said they'd rather see individual libraries implement their own conversions rather than putting them all in Conversion. Cheers, Gordon
Le 29/06/12 02:16, Gordon Woodhull a écrit :
On Jun 28, 2012, at 7:20 AM, "Vicente J. Botet Escriba"<vicente.botet@wanadoo.fr> wrote:
I would prefer to avoid a dependency from Boost.Chrono to Boost.DateTime. Understood. Boost.Conversion has/had a nice directory structure to put these things in.
But for the sake of argument, what is the difference between an optional header dependency between Chrono and DateTime, and an optional header dependency from Conversion to both libraries? Is your objection because Chrono is mostly standard? Yes and not. Boost.Chrono contains already features that are not standard (e.g. Boost.Chrono/IO/Rounding). and I pretend to add more (e.g. Boost.Chrono/Stopwatches). Of course if a conversion was added it should not be included as a member of the duration or time_point classes as I try to maintain them close to the standard, so a non member functions are needed. I don't know a good name for these non members functions conversions. Has someone considered to add these conversions to Boost.DateTime?
A few reviewers said they'd rather see individual libraries implement their own conversions rather than putting them all in Conversion.
I'm not against adding these conversions as a sub-library of Boost.Chrono (eg. Boost.Chrono/Conversions) if the Boost community reach a consensus on the interface and someone takes care of the authoring and maintenance of this sub-library. Has someone considered to add these conversions to Boost.DateTime? HTH, Vicente
participants (4)
-
Gordon Woodhull -
Krzysztof Czainski -
Nathan Ridge -
Vicente J. Botet Escriba