Actually this raises the question about what a “header only” library really is. When it gets included in multiple modules, it looks like the compiler/linker consolidates functions with the same type signature - thus conflicting with most persons idea of what “header only” should actually mean. Food for thought.
It also raises the issue of “head only” libraries and “code bloat”. By making sure everything is inline we are contributing to code bloat. This really should/could be addressed with making “inline” INLINE and defining it according to what kind output we want to produce (ie. executable, static library, shared library, etc.). But of course that changes the API - another can of worms.
* Converted Windows ends of line to UNIX.
Text files in git must have UNIX ends of lines, to be converted to Windows
EOLs on checkout, as required by git settings on the user's system.
* Removed executable permission from header.
corrections in cpp promotion
added make_safe_literal
separated integers from other types
dropped example91
updated CMakeLists.txt and Jamfile.v2 accordingly
improved support for safe_literals
corrected errors in less_than and equal which were failing to detect possible runtime failures.
simplified pseudo partial specialization for checked_result_operations
Turns out that these changes should also better position us to handle other underlying types - but we're not there yet.
Added example for composition with other types - example boost rational and boost multi precision
Added performance test using boost multi precision
Many other small corrections
Making way for checked_float, checked_money, etc
a) factoring checked into checked_integer etc.
b) moved some tests from test_z to official tests
c) added test_rational which tests interoperability with boost::rational
d) moved safe_range to safe_integer_range
before this change, it would get instantiated by is_convertible<T, safe<U>> for any type T which created a syntax error.
This problem appears with using rational<safe<int>> but passes tests now.
Switched casting operators back to implicit. Having it explicit makes it safe types more unwieldy to use and breaks some examples.
