- Boost - lists.boost.org

[iostreams] compression tests
by Vladimir Prus 28 Nov '06

28 Nov '06

The iostreams compression tests fail on VC7.1 (RudbekAssociates-V2): http://tinyurl.com/y4vngt the error message suggest that the iostreams library is either not built, or built with a wrong name, or something. I would appreciate if somebody look at those. Also, Victor, can you provide the values of iostream-related environment variables? Thanks, Volodya

1 0

Request for review: scope_exit
by Tom Brinkman 28 Nov '06

28 Nov '06

Alexander, Your library has been added to the review queue. Either Ronald or myself will be in touch to make further arrangements about the review schedule. Thank You.

1 0

[test] prg_exec_fail2.cpp
by Vladimir Prus 28 Nov '06

28 Nov '06

The prg_exec_fail2 test fails for OSL-V2: http://tinyurl.com/y3gj8p It looks like the test assumes that division by zero is detected, and it's not. Gennadiy, Doug, do you have any ideas what's going on? Thanks, Volodya

1 1

Function Types Accepted - November 28, 2006
by Tom Brinkman 28 Nov '06

28 Nov '06

Function Types Review Managers Summary Tom Brinkman Accepted The library has matured much between reviews. It is my conclusion that the documentation, the examples, the test suite, and the library's interface all meet the requirements to be accepted as Boost library. My own experience with the library was good. I compiled all the examples, read the documentation and have become familiar with the design. However, I did have some compiling issues with two out of three of my linux machines. I fear that this library may face some compatiblity issues with some of the lessor supported platforms The reason for the relatively low review count is that this library is for library "authors" and not for "end users". The low review count is not a concern and does not reflect on the quality of this library, While these are not issues required for acceptance, I do think that this library should eventually be merged with the "type traits" library. I'll leave that up to Tobias and others to make the final determination of how to make that happen, or if it is even practical. Clearly, there does appear to be some redundancy between the "type traits" library and the "function types" library ("tags"). I would encourage Tobias to get in contact with maintainers of those libraries and flush that issue out. It is my opinion that the "Function Types" library has met or exceeded all of the conditions set by the "Full-Review" conducted by John Maddock last year and should be accepted into boost. Congratulations and thanks to Tobias for his "Function Types" library; I'm looking forward to seeing it in a future version of boost. ----Download---- http://tinyurl.com/qaf5f ----Author---- Tobias Schwinger ----Review Dates---- June 2005 - Full Review November 2006 - Mini Review ----Review Manager(s)---- John Maddock (Full Review) Tom Brinkman (Mini Review) ----Full Review ---- 2005-Jun-6 to 2005-June-16 Accepted int Boost, subject to a mini-review. ----Mini-Review---- 2006 November 6 - 2006 November 17 Accepted into Boost

1 0

[math] [cw-9.4] common_factor_test
by Vladimir Prus 28 Nov '06

28 Nov '06

The failure at: http://tinyurl.com/y27tlc looks like problem with the test itself. Anybody's in position to fix it? I think the same operator<< was causing problems for other compilers and John has a patch, but I have no idea if this patch will apply to cw-9.4. If we exclude stale (Nov 22) test failures that are fixed since, those borland, 6.5, 7.0 and cw-9.4 are four remaining failures of the math library, it would be great to see them go away. Thanks, Volodya

2 1

BOOST_ALL_NO_LIB
by Vladimir Prus 28 Nov '06

28 Nov '06

Pardon my nit-picking, but I fail to see the relation between BOOST_ALL_NO_LIB spelling and autolinking -- which is exactly what this macro controls. Perhaps this macro has some extra semantics, but I can't find any, except for auto-linking, in separate_compilation.html, nor in library's config.hpp files. Wouldn't it be better if the macro was named BOOST_ALL_NO_AUTOLINK? Thanks, Volodya

2 1

[math] common_factor_test
by Vladimir Prus 28 Nov '06

28 Nov '06

The test fails on metacomm-v2 for msvc-6.5, 7.0 and for borland: http://tinyurl.com/y6otrh http://tinyurl.com/ynz9z3 http://tinyurl.com/yxlcv7 The borland and 6.5 failures seem to be related to compiler problems that trigger *on the test itself*, so it might be possible to revive the test. The 7.0 failures is something deeper inside the math library. Is somebody in position to look at those? Thanks, Volodya

3 6

Re: [boost] New getting started guide
by Sohail Somani 28 Nov '06

28 Nov '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Martin > Knoblauch Revuelta > I have no idea what this is all about, but I got to compile, link and > run the example so... :-) > > I had a little problem with the libraries: I installed them in > /usr/local/lib (deafult location, isn't it?), but the system didn't > find them at runtime. I had to append /usr/local/lib to > /etc/ld.so.conf, and then run ldconfig. I decided to do so after > reading: > http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.html Maybe dll-path(?)/rpath should be encouraged?

2 1

Re: [boost] [function_types]
by Steven Watanabe 27 Nov '06

27 Nov '06

AMDG Sorry for taking so long to reply. Tobias Schwinger wrote: > I don't see it this way: a function is a compound type and the mpl sequence contains the component types. They are ordered left to right which seems pretty common, too. > OK. I understand now. I had this kind of thing in mind: function_type< mpl::push_front< result_type<F>::type, mpl::push_front<parameter_types<F>::type, int>::type >::type >::type The outer push_front doesn't express the intent of the code clearly. The mpl sequence is fine if it is just going to be created on the spot like: function_type<mpl::vector<int, bool, char> >::type For these cases what you have is as good as anything. > I'm not sure I understand you correctly, here. To do what? Eliminate > the tags? ... I suppose I should have been more clear. The thing I object to is tag<...> not the individual tags. I don't see any way out of using a type to represent the calling convention anyway. >> > Neither >> > one is completely satisfactory. >> > 1. >> > template<class R, class Args, class Option1, class Option2, class Option3> >> > struct function_type : >> > original_function_type<typename mpl::push_front<Args, R>::type, >> > tag<Option1, Option2, Option3> > {}; >> > 2. >> > template<class ReturnTypeAndArgsAndTagsRolledIntoASingleType> >> > struct function_type : ... {}; >> > ... If so, I can't see any "tag elimination"... ... Both alternatives > even seem to increase the presence of tags in the interface ... I > considered the first alternative when redesigning the library, but I > chose the current design because it doesn't redundantly introduce lots > of rarely needed template parameters. >> > >> > What about is_same<calling_convention<F>::type, fastcall_cc>? >> > ... Same here: The return type of that metafunction would be a tag > again, wouldn't it? Maybe I just lost track because of a missing > sentence or something like that. Regards, Tobias Suppose I want to change a function's calling convention. function_type<components<int(...)>, tag<components<int(...)>, stdcall_cc> >::type This is awkward even if the function to be modified is simple. If on the other hand it is needed for a computed function type where typedef is impossible e.g. a function declaration.... I believe this is one of the reasons MPL chose to pass containers to algorithms instead of iterator pairs. Now, about actually removing tags. How often are the cv tags likely to be used? They are redundant since for member functions this information is already available in the first parameter. If they are not a very common thing to need, I would propose simply removing them from the interface. If you stick to the MPL sequence representation, what about adding the variable argument list onto the end? function_type<mpl::vector<int, int, varargs> >::type that way it looks more like the actual function type. In Christ, Steven Watanabe

2 1

[inspect] Contents in XML <legalnotice> sections not checked for L & C issues?
by Andreas Huber 27 Nov '06

27 Nov '06

Hi Rene It seems that the <legalnotice> sections in Boostbook xml files are not checked for L & C issues. Is there any chance that such a feature could be added to the inspect tool before 1.34 goes out? That would surely uncover many more L & C problems. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 8