[modularization] Extracting lexical_cast from conversion
Conversion depends on Math and Range due to lexical_cast.
/math/ http://www.pdimov.com/tmp/report-6d1f271/math.html
|
On 06/06/2014 18:08, Vicente J. Botet Escriba wrote:
Conversion depends on Math and Range due to lexical_cast.
/math/ http://www.pdimov.com/tmp/report-6d1f271/math.html
|
| * from |
| |
| * from |
| /range/ http://www.pdimov.com/tmp/report-6d1f271/range.html
|
| * from |
| |Extracting LexicalCast allows to break these cycle|s
Conversion -> Math -> Conversion -> Range -> Conversion
Best, Vicente
P.S. This dependencies have been introduced lately while trying to make the implementation more efficient.
And it's sensible to reuse that code rather than reinvent the wheel. I'm open to the idea of some sort of "Math core" lib, even though it's likely to suffer feature creep, but provided - and this is going to be the controversial bit - that tests and docs remain in the "one true Math lib". In other words it's just a small module containing some headers, with links to the Math lib for docs and tests. John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 06 June 2014 18:26 To: boost@lists.boost.org Subject: Re: [boost] [modularization] Extracting lexical_cast from conversion
On 06/06/2014 18:08, Vicente J. Botet Escriba wrote:
Conversion depends on Math and Range due to lexical_cast.
|Extracting LexicalCast allows to break these cycle|s
Conversion -> Math -> Conversion -> Range -> Conversion
Best, Vicente
P.S. This dependencies have been introduced lately while trying to make the implementation more efficient.
And it's sensible to reuse that code rather than reinvent the wheel.
I'm open to the idea of some sort of "Math core" lib, even though it's likely to suffer feature creep, but provided - and this is going to be the controversial bit - that tests and docs remain in the "one true Math lib". In other words it's just a small module containing some headers, with links to the Math lib for docs and tests.
I'm concerned at the documentation implications of this too! :-) But links to the "one true Math docs" could also be provided? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
John Maddock wrote:
I'm open to the idea of some sort of "Math core" lib, even though it's likely to suffer feature creep, ...
It seems to me that the fpclassify.hpp/sign.hpp functions, that correspond to the "Classification macros" section of C99, are "core" enough to stand apart from the rest of the Math library. We could have a "float" module, the analog of the "integer" module, but for the built-in floating point types, which would be the natural place for those functions.
but provided - and this is going to be the controversial bit - that tests and docs remain in the "one true Math lib". In other words it's just a small module containing some headers, with links to the Math lib for docs and tests.
No opinion on that one. It's just a handful of functions anyway. Pretty much anything will work.
2014-06-06 21:08 GMT+04:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:
Conversion depends on Math and Range due to lexical_cast.
/math/ http://www.pdimov.com/tmp/report-6d1f271/math.html
|
| * from |
| |
| * from |
| /range/ http://www.pdimov.com/tmp/report-6d1f271/range.html
|
| * from |
| |Extracting LexicalCast allows to break these cycle|s
Conversion -> Math -> Conversion -> Range -> Conversion
I'd rather solve it in other way: Lexical_cast uses some common functions from Math (changesign, sign...). May be it would be better to move those to some separate library... Lexical_cast uses only iterator_range from Range library. iterator_range is a widely used class, FWIW it would be better to move it to some sublibrary (Core?) Anyway, I'm OK with moving lexical cast into a separate library. -- Best regards, Antony Polukhin
participants (5)
-
Antony Polukhin -
John Maddock -
Paul A. Bristow -
Peter Dimov -
Vicente J. Botet Escriba