Re: [boost] Release of 1.30.2 imminent
Fernando Cacciola wrote:
> Recently, Jens Maurer changed the guard at function scope
> from:
>
> #ifndef __GNUC__
> to
> #ifndef BOOST_NO_STDC_NAMESPACE
>
> and honestly, I didn't looked much at it as I should.
>
> BOOST_NO_STDC_NAMESPACE is documented to relate to C names,
> but swap is a C++ name so I don't think such macro
> should be used here.
The CVS change of optional.hpp:1.10 is definitely incorrect,
because STDC_NAMESPACE refers to C names, not C++ names.
Sorry.
However, just reverting the patch will make gcc-3.3
non-functional, because std::swap(int,int) (for example)
is not going to be found.
I've checked in a better fix to the main branch. optional_test.cpp
now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux.
Please test on other platforms and (optionally) transport
the fix to the 1.30.0 CVS branch.
Jens Maurer
RCS file: /cvsroot/boost/boost/boost/optional.hpp,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- optional.hpp14 Mar 2003 12:56:01 - 1.9
+++ optional.hpp9 Jul 2003 23:13:40 - 1.10
@@ -296,7 +296,8 @@
}
else if ( !!x && !!y )
{
-#ifndef __GNUC__
+#ifndef BOOST_NO_STDC_NAMESPACE
+// allow for Koenig lookup
using std::swap ;
#endif
swap(*x,*y);
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review Results: fixed-point decimal library
The library has been reviewed by a number of boost contributors,
including Paul Bristow, Ilya Buchkin, Fernando Cacciola, Daryle
Walker and others. Thanks for your effort!
Taking the review comments into considerations, the library
will not be accepted into boost at its present state.
Here's a short summary of what I believe are the most
outstanding issues, but each review comment should be taken
into account individually for a rework.
- The documentation needs serious overhaul in both presentation
and content. Words such as "precision" and "scale" should be
defined, not all readers are experts in the domain. Specific
technical requirements on the abstract type to be defined should
be layed out ("financial applications" is not enough), and
sound reasoning in the forest of alternatives should be provided.
A comparison of the design to other programming languages or
numerics standards is appreciated. Detailed semantics of each of
the functions should be given, possibly similar in layout as the
description of the standard library in the C++ standard. The
discussion of the internal implementation should be moved to the
very end to not distract readers from the interface.
- The design should be reviewed. What happens with overflow?
Financial people may want overflow signalled instead of
silently eaten and producing wrong results. What happens with
intermediate loss of precision? A number type is very
surprising if its +,* operations are non-commutative.
For a relatively simple value-based numerical type, inability
to serve as a value type for STL containers is not acceptable.
Providing a multitude of maths operators for various alien
types such as int, double, and string instead of conversion
or explicit constructors requires detailed reasoning to
support the added complexity.
On the positive side, boost::numeric has been agreed as the
namespace for the library, and fixed_decimal appears to be
a good name given the very interesting idea of standardized
floating-point decimal numbers. Plus, the rounding control
appears really ingenious syntax-wise.
Nonetheless, thanks to Bill Seymour for bringing forward this
library. Some boost readers wishing to code financial
applications may now better understand the issues involved.
Personally, I'm looking forward to a IEEE-conforming
decimal floating-point library.
Jens Maurer, Review Manager
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Interest in selected_real?
Daniel Spangenberg wrote: > template > class selected_real; > template > class selected_int; > typedef selected_int<9> MyInt; Those class templates may be of use for some people. However, until we get typedef templates into the C++ core language, there appears to be no way to defer the implementation of the type to, say, a plain "int". This can be fixed by making the selected_XXX classes template metafunctions that happen to return the correct type. Usage: typedef selected(9)::type MyInt . Compare that with boost/integer.hpp where we have uint_t::least and uint_t::fast . Of course, if you compile on a platform that can't fulfill your precision/range desires, you should get a compile-time error. namespace boost::numeric is your friend. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review: fixed-point decimal library
Bill Seymour wrote: > - A second, which instantiates all the output-related templates, > writes some interesting values like numeric_limits::min() > and tests the correct operations of the I/O manipulators and > rounding modes (as arguments to operator<<), locales, and narrow > and wide streams. > - A third which instantiates all the input-related templates and > does the same kind of tests except that the user will have to > enter some ad hoc values. What about a single program that writes to stringstreams, reads the data back in (instantiates everything) and compares the values prior and after the I/O? > For the second and third test programs, because locale strings > are implementation-specific, they'd be entered as command-line > arguments. I'm thinking about automated testing, so I'd rather have a longish #ifdef list at the top of the program to deal with the implementation-specifics than some funny command-line parameters. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Warnings about derivation without explicit access controlspecified
Daniel Frey wrote:
> I saw a lot of new regression runs on various platforms.
Some of those are mine (HP-UX, IRIX, Solaris).
> One obvious
> question: Should we remove the outdated runs?
First, my setup is not completely cronjob-automated, so my runs
may become outdated. Second, my runs use different compilers
or different compiler versions than the tests already there.
> Now for the real reason of this message: One compiler (the SGI MIPSpro)
> complains (with a warning) about:
>
> cc-1234 CC: WARNING File = /net/cci/maurer/boost/libs/utility/operators_test.cpp,
> Line = 52
> Access control is not specified ("private" by default).
>
> : boost::operators >
>
> The question is: Should we, for the sake of portability, support this
> warning by requesting an explicit access control specifier whenever we
> derive?
Since only some Unix compilers give a warning there, and we may be able
to turn off the warning by command-line flags, people shouldn't probably
be made to change their habits. For me, it's obvious that private
derivation is the default here.
Do we want to add the command-line flag to turn off the warning?
> PS: Would it make sense to have a "boost bug bashing week" or something
> to fix some more bugs/regressions? Or do we wait for users to complain
> and provide fixes?
The libraries itself are relatively bug-free, but there are plenty of
portability problems with some compilers. For the HP-UX, IRIX, and DEC
compilers in the versions I have access to, it's probably a waste of time
to try and fix problems, unless it's obvious what to do, because the
compilers have relatively old front-ends with plenty of non-conformance
issues.
Jens Maurer
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams wrote: > That's really odd. > > Everything works perfectly on my machine with gcc-3.2 and CWPro8.3 > except for a numeric_traits_test failure with gcc-3.2 and that has no > relation to iterator_adaptors. I can't believe it. Very strange. I've just removed libs/utility and re-"cvs update"d it. I'm reading (for example) libs/utility/transform_iterator_example.cpp which contains: typedef boost::transform_iterator_generator::type doubling_iterator; And this is gone for good, I thought. So this should fail the compile. If it doesn't, for you, then either the XML post-processing is doing something wrong, or the dependency checking of bjam isn't doing its job. May I suggest that you remove (for example) (ALL_LOCATE_TARGET)/status/bin/transform_iterator_example.test and try re-running the regression tests? If this shows a different result, you may want to clean ALL_LOCATE_TARGET completely. :-) Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams wrote: > In what sense? If a C++ source file includes a header (even > indirectly) and the header changes, the source file should be > recompiled. No recompilation is neccessary just because an > application links to a built library whose sources include a header > file that changed. That's right, I was misled by the fact that boost/iterator/* was checked in on Monday, but I started to see regression test failures only yesterday. Further investigation showed that libraries include boost/iterator_adaptors.hpp, and that file was changed to use boost/iterator/* only yesterday. Sorry for the confusion. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New iterator adaptors and bjam builds
David Abrahams wrote: > What problems are you having with the utility lib? I don't see any. Looking at my Linux regression test results, there's plenty of lines with "utility" in the first column and *_iterator_example in the second, which says "Fail" for all the compilers. Those are probably examples from the iterator adaptors library. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] New iterator adaptors and bjam builds
The new iterator adaptors appear to have been checked in to the main boost CVS. The boost build setup appears not to take header-file dependencies between libraries into account. Therefore, in order to produce a valid test run for publication, you should completely remove all binaries etc. (ALL_LOCATE_TARGET) from the previous run so that everything is regenerated. The following libraries are now broken and should be fixed: - filesystem - graph - multi_array - random_demo - signals - tokenizer - utility The boost documentation appears to still be out-of-date. David Abrahams gave these documentation links in his contribution to this list date 29 April 2003: http://boost-consulting.com/writing/facade-and-adaptor.html http://boost-consulting.com/writing/new-iter-concepts.html Just a general heads-up. (I decline any involvement with iterator adaptors.) Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Formal Review: fixed-point decimal library
The formal review of Bill Seymour's fixed-point decimal library runs 11 July to 21 July 2003 with myself serving as review manager. The library provides a class boost::fixdec::decimal that represents a fixed-point number. Unlike "double" or other floating-point representations, a fixed-point number has a fixed number of decimal digits. Together with explicit rounding control, this prevents surprise from rounding errors, for example in financial applications. The library is available in the boost files section at http://groups.yahoo.com/group/boost/files/fixdecv22.zip The library has been successfully compiled on MSVC. (There should be an update shortly that allows compilation with como and gcc 3.3, presumably named fixdecv23.zip.) When submitting reviews, please state explicitly whether or not you think that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. Jens Maurer, Review Manager ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comeau toolset configuration for Unix/Linux?
Martin Wille wrote: > I have a como-gcc toolset here that does the job for me. > It wrote it using como-win32 as starting point. I could > add it to the cvs if you want to. It likely can be improved. Is that for como on Win32 or for Unix? Hm... We shouldn't add too many toolsets for basically the same thing. Either we unify all of como (as has been done for gcc), or at least we have como-win32 (Win32 only) and como (the Unix-like rest). Differences in backend C compiler should be easy to handle in one unified file. Please send me your file privately and I'll see what I can do. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comeau toolset configuration for Unix/Linux?
It appears that the current tools/build/como-tools.jam is not usable on Unix. For example, the linker action causes "REM" lines to be passed to the Unix shell, which does not work. It looks to me that como-win32-tools.jam contains the Win32 configuration now, so I'd like to completely redo como-tools.jam for use on Unix/Linux. Ideas? Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Updated Boost.Random to TR proposal
I've updated the current Boost.Random CVS to the interface contained in the C++ library TR proposal: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html The boost documentation has not yet been updated, I hope to be able to do that later this week. Reading the TR proposal should give you a sufficient idea. There have been various suggestions for changes from C++ committee members, so additional (but minor) interface changes may happen after the October 2003 meeting. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] N1398: Proposal for adding random numbers to the standardlibrary
Jens Maurer wrote: > > I've checked in my paper N1398 to libs/random/wg21-proposal.html > This will be in the post-Santa Cruz mailing of the ISO C++ > committee and will form the basis for discussion at the next > meeting in Oxford, England. > > Thanks to all who offered comments and suggestions. I forgot: The modifications to Boost.Random so that it is compatible with the specification are not yet checked in, since the structure of the end-user interface has been changed slightly. How should I proceed? Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] N1398: Proposal for adding random numbers to the standardlibrary
I've checked in my paper N1398 to libs/random/wg21-proposal.html This will be in the post-Santa Cruz mailing of the ISO C++ committee and will form the basis for discussion at the next meeting in Oxford, England. Thanks to all who offered comments and suggestions. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
