- Boost - lists.boost.org

[program_options] Patch for Tru64/cxx65
by Markus Schöpflin 06 Jun '05

06 Jun '05

Attached patch fixes the last failure on Tru64. (See http://tinyurl.com/dfslr) Ok to commit? Markus Index: parsers_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/test/parsers_test.cpp,v retrieving revision 1.12 diff -u -w -r1.12 parsers_test.cpp --- parsers_test.cpp 27 Apr 2005 07:02:39 -0000 1.12 +++ parsers_test.cpp 17 May 2005 10:12:16 -0000 @@ -126,7 +126,13 @@ // Regression test: check that '0' as style is interpreted as // 'default_style' vector<option> a4 = - parse_command_line(5, cmdline3_, desc, 0, additional_parser).options; + parse_command_line(5, +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) + static_cast<char const * const *>(cmdline3_), +#else + cmdline3_, +#endif + desc, 0, additional_parser).options; BOOST_CHECK_EQUAL(a4.size(), 4u); check_value(a4[0], "foo", "4");

3 5

Re: [boost] Re: Boost Array Initialization Technique
by brangdon＠cix.compulink.co.uk 06 Jun '05

06 Jun '05

In-Reply-To: <005501c566b3$1fc76eb0$2b792518@heronnest> cdiggins(a)videotron.ca (christopher diggins) wrote (abridged): > > I strongly disagree. Forcing initialization makes code that is not > > useful for high performance numerical processing. When we declare a > > container of 1000000 elements, we don't want to waste time > > initializing each, unless we want to. > > I think the best solution in this case is to use an alternative > "collection" for numerical processing. Using a class intended as > general purpose array for numerical processing I think would not be a > good idea. I doubt we need a whole class. A special argument might do, to let us choose: boost::array<int,1000> b( boost::uninitialised ); boost::array<int,1000> b( boost::initialised ); The question for me is what the default should be. And in my view, the default should be safe rather than fast. ---- For what it's worth, I think auto variables, std::complex and even std::vector should be the same: initialised by default but with uninitialised available as an option. And since this is now a language change, perhaps "boost::initialised" should be spelt "?" for brevity. int x; // x == 0. int y = ?; // y is uninitialised. int *px = new int; // *px == 0. int *py = new int( ? ) // *py is uninitialised. vector<int> vx( 100 ); // vx.front() is 0. vector<int> vy( 100, ? ); Vectors are complicated in that their elements currently need to be copyable. Either the standard needs to specify when they are copied, so that eg vy is OK as long as the vector is not resized; or else it could make initialisation implementation-defined in the ? case. Then on most platforms, vector<int> would not need initialisation but vector<double> would. User code would not be able to tell the difference. Basically, initialising with ? is telling the implementation that the user will always write to the variable before reading it. The implementation exploits that knowledge as best it can. -- Dave Harris, Nottingham, UK.

4 3

Boost Build Env Checker (was RE: [boost] Re: Customer Friendlier Boost Installation)
by Brian Braatz 06 Jun '05

06 Jun '05

David- Some thoughts below (sorry for taking a bit to come back on this one. I have been contemplating) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, May 31, 2005 7:08 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Customer Friendlier Boost Installation > > "Brian Braatz" <brianb(a)rmtg.com> writes: > > > HAVING said that here is the suggestion, reformed: > > > > Boostenvcheck.exe become s a program which LISTS the dependencies for > > your configuration. > > Can you show an example of what that output might look like? I don't even > have a clear idea of what you mean by "dependencies" or "your > configuration." [Brian Braatz Writes:] I must say, I need to fully absorb how bjam \ boost.build interoperate, until doing so, please understand the details of this idea maybe ill formed. I get it conceptually, but it is still a "black box" in my head. At a high level all I am talking about is the same style of thinking that goes into coding a unit test being applied to a runtime environment. maybe if I provide a different context: (to at least describe the style of thinking I am espousing) lets say I have developed a command line compiler that has a series of dependencies: * INCLUDE var needs to be set to a valid path * We assume some standard files are available here (stdio.h etc) * LIB var needs to be set to a valid path * we assume some standard lib files- or Maybe just assume there is at least ONE lib file there lets say I have shipped my compiler to the masses, and soon I get reports from the users that they have funky errors when trying to compile something. Most of the time, it is USER error. In fact frequently, I may spend hours on the phone with them only to discover they did not configure something correctly or set it up properly. in my frustration over time wasted I decide to write a env checker for my compiler. ill call it clenvcheck.exe. when you run clenvcheck, if I elected to be extreme, I would: 1- validate INCLUDE and LIB vars are set 2- Read the contents of dirs to ensure some or all of the required core files exist 3- display a list of these "dependencies" in my output report i.e. "found stdio.h at c:\brianscompiler\include" 4- check to see if I can find my linker- send the version and location of it to the report 5- display a HIGH Level message denoting whether the "environment passed the test" for my compiler. so armed with this new tool I can now, when talking with folks over the phone, ask them to run the report. when it says "passed"- I can quickly re-direct them back to their code. if they are not convinced, I can have them send me the report and I can look at it and try to determine where the issue is. ADDTIIONAL scenario: Lets say, in my compiler business, I have a scenario where I occasionally release to the users a bug fixed header file. I send out a mail with the new file and explicit instructions on where to put it. After I have released a few bug fixed header files, I find users complaining about weird problems. Turns out, I am now back to spending an dreadful amount of time on the phone only to discover 9 times out of 10 the user did not follow instructions. 1 time out of 10 there actually was a bug in something I released. 10 times out of 10, the customer is frustrated. Even if the customer REALIZES THEY made the mistake, it still leaves them frustrated with ME and my PRODUCT. So I elect to get a bit more extreme in my env checker. I upgrade it so that it adds to the report a hash of all the "things it depends on", i.e. header files, link.exe etc. So now, when the user has a problem, I have them send me the report. I can also make available to them a list of the hashes for the files which I have tested to "work". I spend less time supporting my product, and my customers are happier because I can keep them running much more effectively. I have put a system in place to "Introspect" the users environment. By doing so, I have decreased the amount of time I have to spend introspecting manually. HOW THIS RELATES TO BOOST.BUILD: I need to understand boost.buiid better to give a better suggestion. Hopefully my example might inspire the "Dependancies" to shake out, even if I do not fully understand boost.build yet. I believe this STYLE of thinking can be applied, but I have to get my current boost things done before I can start down this track. As I said before, if the thinking here inspires someone to START something like this all the better . :) IF NOT, I intend on tackling this in the future. (I first have to become a expert in boost.build though :)) I would like to eventually see something that allows someone to SPIT out a report, mail it to the list, and have the people on the list be able to IMMEDIATELY tell the person what could be horked, or why it is not building for them. Cheers, Brian "The Village Idiot" Braatz

2 1

RE: [boost] Re: Customer Friendlier Boost Installation
by Brian Braatz 06 Jun '05

06 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > > I have read the MPL book now FIVE TIMES cover to cover. On the fith > > pass, I "saw it". (the mpl::for_each<> is what kicked it in for me) > > Wow, I applaud your fortitude and apologize for writing something that > took you so long to "see." [Brian Braatz Writes:] Hmm.... I believe the MPL book is an excellent body of work. The difficulty is because 1- I am either VERY smart about a subject or it is a black box. there seems to be little middle ground (this is learning style I think) 2- Metaprogramming is "training your brain" to think differently. Honestly with the subject matter being so DIFFERENT from what us normal blokes are used to, I am not sure if I could even suggest a better way to present it. Being able to write compile time code is a skill that belongs to people who have the commitment to struggle through and learn it. the TWISTED thing, is as I am getting more and more, it feels natural. Also I think I am wearing out my copy of the book- I continually go back and re-read sections and chapters. THANKS to both you and Aleksey for birthing that sucker. Lots of good information in there. TO ANYONE READING THIS BOOK: DON'T GIVE UP. KEEP AT IT. YOU WILL GET IT. You just have to read it enough that you begin to bleed through your eyes. When that happens, you know you are close......

2 1

[parameter] Patch for Tru64/CXX65
by Markus Schöpflin 06 Jun '05

06 Jun '05

Hello, attached patch fixes the current regression failure for the basics test. The code in questions contains a non-working workaround for this compiler, the patch removes this workaround as well. Ok to commit? Markus Index: basics.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/parameter/test/basics.cpp,v retrieving revision 1.8 diff -u -r1.8 basics.cpp --- basics.cpp 16 May 2005 12:58:48 -0000 1.8 +++ basics.cpp 3 Jun 2005 16:29:10 -0000 @@ -14,7 +14,6 @@ namespace test { - // A separate function for getting the "value" key, so we can deduce // F and use lazy_binding on it. template <class Params, class F> @@ -39,8 +38,13 @@ typename boost::parameter::binding< Params, index_, int - >::type i = p[index | 999]; - + >::type i = +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) + p[test::index | 999]; +#else + p[index | 999]; +#endif + p[tester](n,v,i); return 1; Index: basics.hpp =================================================================== RCS file: /cvsroot/boost/boost/libs/parameter/test/basics.hpp,v retrieving revision 1.2 diff -u -r1.2 basics.hpp --- basics.hpp 15 May 2005 10:15:56 -0000 1.2 +++ basics.hpp 3 Jun 2005 16:29:10 -0000 @@ -88,13 +88,6 @@ { return values_t<Name,Value,Index>(n,v,i); } - -#if defined( __DECCXX_VER ) - && BOOST_WORKAROUND(__EDG_VERSION__, BOOST_TESTED_AT(245)) - // Some kind of nasty ambiguity arises here -- is there an index in - // the global namespace? - using test::index; -#endif } // namespace test

2 2

RE: [boost] Re: ICE ICE BABY! (my MPL code is ICEing)
by Brian Braatz 05 Jun '05

05 Jun '05

> >> > >>template <class type_t, class sequence_t> > >>struct copy_col_if_in_dest > >>: public if_< typename is_same< typename deref<typename > >>boost::mpl::find<sequence_t, type_t>::type >::type, type_t>, > > > > do_copy_col, > > > >>do_not_copy_col>::type > >>{ > >>}; > > This code has a problem when type_t is not in sequence_t: the > past-the-end iterator gets dereferenced. I wrote a short program to do > what you want (it's more explicit, it uses mpl::contains<>): > > #include <boost/mpl/vector.hpp> > #include <boost/mpl/if.hpp> > #include <boost/mpl/contains.hpp> > > namespace mpl = boost::mpl; > > struct do_copy_col {}; > struct dont_copy_col {}; > > template<typename T, typename Seq> > struct copy_col_if_in_dest > : mpl::if_< > mpl::contains<Seq, T>, > do_copy_col, > dont_copy_col > >::type > { > }; > > int main() > { > typedef mpl::vector<char, short, int, long> v; > do_copy_col do_copy = copy_col_if_in_dest<int, v>(); > dont_copy_col dont_copy = copy_col_if_in_dest<bool, v>(); > return 0; > } > [Brian Braatz Writes:] Wow. Many THANKS- the mpl::contains<> is REALLY what I was looking for. (Though the exercise of doing it with if_<> was a useful experience) THANK YOU ( I have been burning the morning and afternoon oil here the last few weeks trying to get a lib I am proposing ready for boost people to look at) -I am going to replace the code I had with the code you presented, and make a note of your contribution. THANKS AGAIN! Brian

1 0

problems buidling latest cvs version
by Christopher Lux 05 Jun '05

05 Jun '05

hi, bjam cancels buidling in v1 and v2 mode on the latest cvs checkout. i used bjam built from the source from the checkout. error message said: Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). C:\_development\boost_cvs\tools/build/v1\boost-base.jam:1966: in subvariant-target *** argument error * rule library-file ( target : sources + ) * called with: ( <@boost!libs!iostreams!build\libboost_iostreams.lib\vc-7_1\debug\runtime-link-static>libboost_iostreams-vc71-sgd-1_33.lib : ) * missing argument sources C:\_development\boost_cvs\tools/build/v1\boost-base.jam:119:see definition of rule 'library-file' being called C:\_development\boost_cvs\tools/build/v1\boost-base.jam:2403: in stage Jamfile:195: in load-jamfiles C:\_development\boost_cvs\tools\build\v1\bootstrap.jam:21: in boost-build C:\_development\boost_cvs\boost-build.jam:16: in module scope

1 0

[typeof] Small feature request
by Pavel Chikulaev 05 Jun '05

05 Jun '05

Hi all, I've got a small feature request to type_of library: 1) BOOST_TYPEOF_CONSTANT_COMPLEXITY Macro is defined if typeof can't evaluated with constant complexity 2) BOOST_TYPEOF_LINEAR_COMPLEXITY Macro is defined if typeof can't evaluated with linear complexity -- Pavel Chikulaev

2 2

[1.33] recent check-ins break date-time serialization tests
by Jeff Garland 05 Jun '05

05 Jun '05

I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere... summary: http://tinyurl.com/ayl5j detailed example: http://tinyurl.com/e2pa5 Jeff

4 4

boost::lock_error - documentation bug
by Paul Groke 05 Jun '05

05 Jun '05

Hi everybody, there seems to be a bug in the documentation (or implementation?) of boost::lock_error. The documentation (http://www.boost.org/doc/html/lock_error.html) describes lock_error as: Synopsis: class lock_error : public std::logical_error { ... Whereas them implementation (1.32.0, thread/exceptions.hpp) declares boost::lock_error as derived from boost::thread_exception which is derived from std::exception and nothing more. Even assuming std::logic_error was ment (there is no class std::logical_error ) I'd say that's a documentation bug. I haven't looked through all the other exception classes defined by boost::thread ... maybe someone should :-) bye, Paul

1 0