----- Original Message -----

Hi Marek,

Am Friday, 1. August 2014, 12:50:11 schrieb Curdeius Curdeius:

...

Hi all,

I have created a pull request building on top of Erik's proposal. It adds missing zebi and yobi prefixes as defined by IEC. I have also added tests for these prefixes. The only thing is that zebi (2^70) and yobi (2*80) are too large for *long long int*, so I test them with boost::multiprecision::int128_t.

Link to PR: https://github.com/boostorg/units/pull/6

Description: I have added zebi and yobi IEC prefixes and corresponding tests for completeness taking Erik's pull request as a base.

I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some?

Good point. As I recall, I held off on doc because I could not figure out where unit-specific docs actually lived. In fact I couldn't find doc for any of the existing units, it was all more general description of how the library worked. Is there an established place for information unit doc to live?

And there is not need to prefix the commit message with "[Boost] [Units]", the context is clear :-)

...

I am not sure if creating a new PR is a good solution or if there is any way to add a commit directly to the existing one. If you know a better way, I would appreciate any information.

As far as I know, that it okay. I've been able to pull both commits to my working copy without problems.

Yours,

Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Congratulations Jürgen! Let me know what can I improve on [0] to get the pull-request merged. Best of luck, Gonzalo [0] https://github.com/boostorg/units/pull/1 On Fri, Aug 22, 2014 at 5:27 PM, Steven Watanabe wrote:

AMDG

On 08/22/2014 08:55 AM, Erik Erlandson wrote:

...

----- Original Message -----

...

I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some?

Good point. As I recall, I held off on doc because I could not figure

out where unit-specific docs actually lived. In fact I couldn't find doc for any of the existing units, it was all more general description of how the library worked. Is there an established place for information unit doc to live?

...

I think there's a list of units in the reference. You could create a table near that listing all the prefixes.

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Wed, Aug 27, 2014 at 12:21 PM, Jürgen Hunold wrote:

- Documentation: - (Examples)

I'll add a small section to the documentation with an constexpr example. The (automatically generated?) API reference documentation already includes the BOOST_CONSTEXPR in the data-types member functions which should be self-explanatory. I'll ping you when I update the PR and we can discuss there how to improve the documentation further but basically either you can use Boost.Units in constant expressions or you can't.

- Tests

I have some unit-tests but removed them because I wasn't able to enable them only for compilers with constexpr support (otherwise they will fail to compile). Boost.Build/Boost.Test documentation wasn't very helpful in this regard. I just went through Boost.Array develop branch and found: https://github.com/boostorg/array/blob/develop/test/array_constexpr.cpp Should I implement the constexpr tests in a similar manner or do anything differently?

And I'd like a snappy sentence to add to the release notes.

I'll add "Boost.Units has gained constexpr support." to the commit message.

- The patch also changes unrelated whitespace like line-endings, removes empty lines and changes wrapping. This should go into a separate pull request if necessary. - The patch also removes some code blocks currently commented out. This should be done in a separate request, too.

I was just following the boy scout rule but will revert them. I won't create a new pull-request with these but I since navigating the code in a 80char terminal was a bit unpleasant I would be happy if you consider some of them in the future. Bests, Gonzalo