February 2006 - Boost - lists.preview.boost.org

Re: [boost] Preprocessor: Nested loops
by Martin Bonner 21 Feb '06

21 Feb '06

From: Paul Mensonides > All of this is the status quo of the library. There are two other > models that are superior in terms of ease of use and avoidance of > these types of issues. > > The first of these, I use in a different (far more powerful) > preprocessor library. The problem with this model is that it > isn't portable to broken preprocessors (which are heavily used > by users of Boost--e.g. VC++). > > The second alternative model revolves around automatically deducing > all algorithm states whenever they are needed. [snip]. There is a third model - don't use the C++ preprocessor, but use a more general purpose text transformation tool like M4, or awk/perl/python, or a custom tool written with bison or boost::Spirit. I'm not knocking the preprocessor library with that suggestion. An external tool would be no use for a library like boost where it is very difficult to control the compilation system. Furthermore, the heroics involved in implementing the boost preprocessor library mean that using it is remarkably simple. I just wanted to point out that there is always another option. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 3

Re: [boost] [website] Link styles.
by Martin Bonner 21 Feb '06

21 Feb '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: 14 February 2006 00:43 To: boost(a)lists.boost.org Subject: Re: [boost] [website] Link styles. > Rene Rivera wrote: >> After some thought, and complaints from some, I've change the link >> style of the new design to use colored links. It's a tyle similar >> to the one I use in my blog, and although it is also similar to the >> style use in Wikipedia there are some significant differences. >> >> So floodgates open for comments on this style. In particular if this >> is an improvement or not? I'm particularly interested in visibility >> issues. Are the links visible enough? Do they get in the way of >> reading? etc. > > Oops I forgot to include the link again > <http://boost.redshift-software.com/> :-\ I like the links, but .... Could you increase the space between the "Get Boost" box and the "Search" box? Or perhaps make the "Search" text be the same style as "Get Boost". My initial reaction was that I had to do a search in order to get boost (and I couldn't see why). Actually, I think I would organize it as "Get Boost" and "Search Boost" with the drop down having options "All Boost", "Documentation", and "Mailing Lists". (Actually, I think I'd like the links a slightly darker blue - but that is very much a matter of taste) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[Iostreams] Patches in 1.34?
by Sylvester-Bradley, Gareth 21 Feb '06

21 Feb '06

Hello, Boost.Iostreams is definitely making my life a lot easier! However I do hope a number of patches can be included in time for 1.34. There have been a number of patches proposed on the list, such as this patch for a file_descriptor openmode bug on Windows: http://lists.boost.org/Archives/boost/2006/01/99425.php. Here are a number of other issues it would be great to fix. 1. Support for binary openmode in file_descriptor Extend the above patch to incorporate selecting O_BINARY for ios_base::binary. Or is this not necessary even on Windows? 2. file_descriptor_source and file_descriptor_sink aren't Seekable This is because they have the wrong category. I believe this is an oversight (their base, file_descriptor is Seekable) and very easy to fix. 3. A significant performance problem for streams on Seekable Indirect Devices This is due to the setg(0,0,0) in indirect_streambuf::seek_impl(). The real killer is that even tellg() causes the buffer to be reset. I have a real application that makes many small istream::read() calls, each followed by an istream::tellg(). This results in a huge number of redundant reads from the underlying Device. E.g. starting at the beginning of the stream, I call istream::read() for 4 bytes, which results (correctly) in a Device read of optimal_buffer_size which is 64K. Then I call tellg() which unfortunately clears the buffer. Then I read another 4 bytes, which reads 64K from offset=4, resulting in 65532 bytes being re-read. Etc. I believe that relative seeks within the buffer need not cause the buffer to be reset. I.e. something like: if ( gptr() != 0 && way == BOOST_IOS::cur && which == BOOST_IOS::in && eback() - gptr() <= off && off <= egptr() - gptr() ) should result in something like: { gbump( off ); off = 0; // Really we don't want the involvement of the // Device at all, but at the moment, in order to // return the new position, we must ask the Device // for its current position again. Hopefully that's // cheap. const pos_type pos_at_egptr = obj().seek(0, BOOST_IOS::cur, BOOST_IOS::in, next_); return offset_to_position( position_to_offset( pos_at_egptr ) - static_cast<stream_offset>(egptr() - gptr()) ); } ... falling back to the existing behaviour in all other cases. This patch works for me, but there may be situations that I haven't encountered (combined input/output streams, the presence of code converters, ...) when this optimization would actually result in incorrect behaviour. Can anybody comment? 4. (feature request) file_descriptor could support wide character filenames One of the possible advantages I see to using file_descriptors rather than std::fstream is that we could add wide-character filename support on platforms that have a matching wopen(), _wopen(), or _wrtl_open() as well as open(), _open() or _rtl_open(). This would mean the file_descriptor could have wstring constructor and open() methods. Neat or not? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sonys global policies and standards

1 0

regressions: release or not release?
by Arkadiy Vertleyb 21 Feb '06

21 Feb '06

Hi all. There seem to exist certain inconsistency between which compilers are marked as "required" in explicit-failures-markup.xml, and how often the regressions are run on these compilers. For example, for a long time there has been no results for msvc or vc-7_0. The cw-8_3 appeared in the regression tables some time ago (adding 20 or so failures to the typeof test results), had the regressions run a couple of times, and vanished (probably somebody removed the old results). This situation makes it very difficult to address the issues on these compilers. For example very few or no people on this list have cw-8_3 installed. The "batch mode" (modifying the library or tests and waiting for the next regression results) is almost not practical, since the regressions on this compiler are run once a week or even less often. Is there any other possibility that I am missing? At the same time at least three parties run the regressions on vc7_1. I wonder if such resource utilization is wise... I think regression testing is essential, and, ideally, should be run before every commit. I also understand that with Boost this is not feasible. But running regressions at least daily for every required compiler should be a must, IMO. If we can't achieve this for some compilers, this compilers should be, I think, downgraded to "optional". Regards, Arkadiy

5 9

link problem -regex
by mahesh karanth 21 Feb '06

21 Feb '06

Hello All, I have some link problems when I try to compile example give in regex (grep example). I have given the command as below. g++ grep.cpp -I/home/mahesh/boost/boost_1_33_1 -L/home/mahesh/boost/boost_1_33_1/libs/regex/build/gcc -lboost_regex I got so many 'Undefined references' error.. Below is the snipshot of error what I got on the console... /tmp/ccp2j6yI.o(.text+0x42b): In function `main': grep.cpp: undefined reference to `boost::program_options::options_description::options_description(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)' /tmp/ccp2j6yI.o(.text+0x4df):grep.cpp: undefined reference to `boost::program_options::options_description::add_options()' /tmp/ccp2j6yI.o(.text+0x507):grep.cpp: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /tmp/ccp2j6yI.o(.text+0x51d):grep.cpp: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /tmp/ccp2j6yI.o(.text+0x533):grep.cpp: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /tmp/ccp2j6yI.o(.text+0x549):grep.cpp: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /tmp/ccp2j6yI.o(.text+0x55f):grep.cpp: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /tmp/ccp2j6yI.o(.text+0x575):grep.cpp: more undefined references to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' follow .. . . . . . . . . ..grep.cpp: undefined reference to `boost::program_options::invalid_option_value::invalid_option_value(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: ld returned 1 exit status Can any one tell me what is the problem? Or am I using wrong command to compile the example? Best Regards Mahesh Karanth --------------------------------- --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments.

2 1

[Boost-bugs] [ boost-Support Requests-1435714 ] Link problem-boost regex
by SourceForge.net 21 Feb '06

21 Feb '06

Support Requests item #1435714, was opened at 2006-02-21 00:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1435714&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Building Boost Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Link problem-boost regex Initial Comment: Hi i have been trying to compile boost programs and i get link error even for the examples that is with in the boost this is the cooman i have used: g++ test.cpp -I /home/mahesh/boost/boost_1_33_1 -L /home/mahesh/boost/boost_1_33_1/libs/regex/build/gcc i Get this undefined ref errors as below: /tmp/ccIjeBwk.o(.gnu.linkonce.t._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j[boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned int)]+0x13): In function `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign(char const*, char const*, unsigned int)': test.cpp: undefined reference to `boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int)' /tmp/ccIjeBwk.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEC1ES6_S6_RNS_13match_resultsIS6_S9_EERKNS_11basic_regexIcSD_EENS_15regex_constants12_match_flagsES6_[boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __ . . . test.cpp: undefined reference to `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find()' collect2: ld returned 1 exit status if anyone knows what might have gone wrong please do reply. Regards, RNA ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1435714&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost.Test and VC6
by John Maddock 21 Feb '06

21 Feb '06

What did we decide to do with Boost.Test and VC6 support in the end? I ask because as of this morning I'm getting a whole load of regression failure notices from VC6 failures that are a result of Boost.Test not working with that compiler: see for example: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output… So either we should get the nag notices turned off for that compiler, or else get Gennadiy to fix things (with apologies to Gennadiy for dumping another problem on him!) John.

3 2

Re: [boost] [multi_index] "Criterium"
by JOAQUIN LOPEZ MU?Z 20 Feb '06

20 Feb '06

Hi Dave, ----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Lunes, Febrero 20, 2006 6:50 pm Asunto: [boost] [multi_index] "Criterium" > > "Criterium" is a kind of bicycle race on a short course with many > laps, periodic "primes," and that usually ends in a sprint finish. > A > rider that can stay near the front of the pack tends to use less > energy sprinting out of the corners as the pack slows to enter > them; a > rider near the back of the pack is both susceptible to fatigue and > getting caught in any crashes that may happen. Ahh, bike racing. I > do miss it so! > > The word the authors of the multi_index docs were looking for is > "criterion," or, when pluralized, "criteria." > Ouch! Will correct it, thanks for the notice, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[filesystem] Critical patch for Tru64
by Markus Schöpflin 20 Feb '06

20 Feb '06

Attached patch fixes a long standing problem with boost.filesystem on Tru64 which has resulted in test failures since quite some time. It seems that readdir_r() on this platform behaves incorrect when errno is not set to 0 previous to calling readdir_r(). This problem now has become critical, as it shows up during regression testing with bb.v2, essentially prohibiting the report creation step of the regression test run. Therefore I would like to ask if this patch can be committed. Thanks, Markus Index: operations.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/filesystem/src/operations.cpp,v retrieving revision 1.17 diff -u -r1.17 operations.cpp --- operations.cpp 12 Feb 2006 23:18:45 -0000 1.17 +++ operations.cpp 17 Feb 2006 13:05:29 -0000 @@ -1187,6 +1187,8 @@ inline int readdir_r_simulator( DIR * dirp, struct dirent * entry, struct dirent ** result ) // *result set to 0 on end of directory { + errno = 0; + # if !defined(__CYGWIN__) \ && defined(_POSIX_THREAD_SAFE_FUNCTIONS) \ && defined(_SC_THREAD_SAFE_FUNCTIONS) \ @@ -1197,7 +1199,6 @@ # endif struct dirent * p; - errno = 0; *result = 0; if ( (p = ::readdir( dirp )) == 0 ) return errno;

2 1

[important] Preparing to Test Release Builds
by David Abrahams 20 Feb '06

20 Feb '06

In order to make it viable to do boost-wide regression testing in release mode, I've gone through all the instances of assert() in our libs subdirectories and replaced any that seemed to be used for testing with constructs that don't get compiled away in release builds. This affects the following libraries: boost/cast.hpp mpl conversion function functional graph iterator mpl parameter program_options ptr_container python spirit If you maintain one of these libraries please review the attached patch, which I plan to apply on Wednesday unless there are objections. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 13