- Boost - lists.boost.org

Should we provide hot fixes?
by Beman Dawes 02 Sep '08

02 Sep '08

Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases. To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate? Hot fixes might work something like this. (I'll use an embarrassing Boost.Filesystem mistake I made as an example.) * Individual developers will decide on a case-by-case basis if they want to provide a hot fix for a given bug. * There would be a prominent link on the web site to a "Hot Fixes" page in the trac. * That "Hot Fixes" page would have a section for each release. * Under release 1.36.0, there would be a changeset number, a description of the problem, and a directory-location: 48192 Restore deprecated basic_directory_entry names inadvertently removed. (boost/filesystem) * The changeset number would link to http://svn.boost.org/trac/boost/changeset/48192 * The "Hot Fixes" page would include instructions on how to apply a changeset. The instructions are the same for all operating systems: -- Click on "Download in other formats: Unified Diff". -- From the command prompt, cd directory-location patch <download-location/changeset_r48192.diff * The "Hot Fixes" page would include instructions on how to install "patch" for popular operating systems, and give an example of actual usage. Comments? --Beman

23 81

Try-out Adler-32 code?
by Daryle Walker 01 Sep '08

01 Sep '08

I added Adler-32 code to the MD5 trial library at <http:// svn.boost.org/trac/boost/browser/sandbox/md5>, if anyone would like to try it out and comment. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[interprocess][process] Synchronizing libraries and efforts (+ bugs)
by Ion Gaztañaga 01 Sep '08

01 Sep '08

Hi to all, I recently needed s library to launch processes and I took a look to the recently announced Process 0.2 (http://lists.boost.org/Archives/boost/2008/07/139322.php) I just needed the library for Windows, and I think the library is interesting although still lacking in some basic aspects (explained later in this post). A process-launching library is a very nice utility for Interprocess and I was thinking of adding this possibility for a future version (Boost 1.37 or 1.38) of the library. If Boost.Process is going forward, it would be glad to collaborate and develop a library that can satisfy all our needs and plays nicely with Interprocess. My main requests for a process-launching library are: 1) Ability to launch a process and a blocking or non-blocking wait operation to obtain its result (Boost.Process already has this). 2) Ability to redirect child process stdin/stdout/stderr to /dev/null, to share the stdin/stdout of the parent or to redirect it to a file. And in the latter case, append or overwrite options (Boost.Process implements some of this options). I slightly modified Boost.Process to implement a rought version of file redirection. 3) Ability to modify the environment variables of the child (Boost.Process already has this). 4) Blocking and non-blocking redirections of stdout and helper functions to simplify its usage (Boost.Process does not have this). For example: bool send_stdio_and_get_stdout (const void* stdin, std::size_t stdin_size, std::vector<char> &stdout); or similar would avoid many programming errors because at any moment stdin can block and we must extract stdout so that the child process can continue processing stdin. 5) I don't know if streams are the right way to communicate with processes, because they don't offer non-blocking support. 6) I think that process-launching interface should be similar to the soon to be standardized C++ futures. So I'm interested in a process-launching library and I offer my collaboration in case Boost.Process development needs help. Regards, Ion PS: Some possible bugs found on Boost.Process 0.2 version (Windows): -> main thread handle returned by CreateProcess in PROCESS_INFORMATION structure the must be closed and I can't find this in the code. -> child::wait function returns sporadic errors when multiple children are launched and waited. I changed the code from: do { ::GetExitCodeProcess(handle_, &code); ::Sleep(500); } while (code == STILL_ACTIVE); ::WaitForSingleObject(handle_, 0); ::CloseHandle(handle_); with ::WaitForSingleObject(handle_, INFINITE); ::GetExitCodeProcess(handle_, &code); ::CloseHandle(handle_); ->environment::set does not correctly overwrite existing variables): void set(const std::string &var, const std::string &value) { insert(value_type(var, value); } should be void set(const std::string &var, const std::string &value) { this->operator[](var) = value; } -> Using named pipes has been problematic because it returns errors when launching multiple processes aggressively: Error 231 - All Pipes are Busy. This does not happen with anonymous pipes and I think it has some relationship with the guid code. By the way, I think a uuid library is too much to create a unique identifier to be shared with the child a simple atomic count would to the job in my opinion. That would reduce Boost.Process dependencies. -> systembuf::close() should call sync() to push the last charaters into the pipe, othewise, characters are lost if the user does not flush the stream. -> I've changed the "stream_info::usefile" case in win32_start to support redirecting to files, changing "CREATE_NEW" parameter of CreateFileA with CREATE_ALWAYS. -> And now, the most important one ;-) Please, avoid tabs! Read boost development guidelines: http://www.boost.org/development/requirements.html#Tabs

3 10

[serialization][frame] Is there any interest in a frame serialization library?
by vicente.botet 01 Sep '08

01 Sep '08

Hi, >From wikipedia "a frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames." Is there any interest in a frame library which will be based on an extension of the archive concept. The saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the begining of the archive. The saving frame concept will allows to save serializable data either at the end or the *begin* of the frame, and the loading frame concept allows to read serializable data from the begining or the *end* of the archive. I'm not sure which syntax will be the more adequated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more adequated candidates but I don't know if it is correct in C++ to define this operators with this prototype template <typename T> frame& operator<<=(const T&, frame&); template <typename T> frame& operator>>=(const T&, frame&); template <typename T> frame& operator&=(const T&, frame&); h1 >>= h2 >>= sf << t2 << t1 ~ (h1 >>= (h2 >>= ((sf << t2) << t1))) sould be equivalent to sa & h1 & h2 & t2 & t1 if sf and sa were empty. The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements. frame sf; h_n >>= sf << p_n << t_n; Then this top layer will use a primitive of the lower level having as parameter the frame as payload. primitive_n-1(sf); A primitive at the k level will add its own header and trailer information element to the payload of the upper level void primitive_k(frame& sf) { // ... h_k >>= sf << t_k; // ... another_primitive_k_1(sf); // ... } So the frame allows to serialize top-down. With the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization. I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly. Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels. lf >>= h_1; // ... t_1 << lf; In addition, it would be greate to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers. | L4 |<----------------------------->| L4 | | L3 | | ADAPTATION | | L3 | | L2 |<-->| L2 | | X2 | <--> | X2 | | L1 |<-->| L1 | | X1 | <--> | X1 | It would be greate that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a little example: Class C has 3 information elements to serialize (a, b and c). So the save functions could be something like template <typename ARCHIVE> void C::save(ARCHIVE& sa) { sa & a & b & c; } This save function works well from left to right, but can not be used when saving at the begining of a frame, because the expected result when saving at the begining is | a | b | c | sa | but the result will be | c | b | a | sa | So unhappylly we need a different save function template <typename FRAME> void C::save(FRAME& sa, begin_tag&) { a >>= b >>= c >>= sa; // a >>= (b >>= (c >>= sa)); } Please let me know if you are interested in such a library, and what are your requirements. Robert, do you think that this can be seen as an extension of the serialization library? Best regards, Vicente Juan Botet Escriba

1 0

[log] filtering performance
by Igor Nazarenko 01 Sep '08

01 Sep '08

It seems that the library does quite a bit of work before filtering away a record, unless the logging is turned off entirely. There's at least two mutex locks, some memory allocation, etc. Callgrind claims ~2500 instructions when the record is thrown away by the global severity filter. Shortened callgrind output is in-line below; full output and the test program attached. Compiled by gcc 4.2.3 using boost.build variant=release threading=multi. 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 99,557 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 5,212 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) . 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 218,306 => record_pump::~record_pump() (1x) 24,144 => bool basic_severity_logger::open_record() (1x) 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,963 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x) 11 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,644 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x)

2 1

install boost_1_34_1 on fedora
by keren hochman 01 Sep '08

01 Sep '08

Im trying to install boost_1_34_1 on fedora (reference to http://www.boost.org/doc/libs/1_36_0...-boost-library<http://www.boost.org/doc/libs/1_36_0/more/getting_started/unix-variants.htm…> ) But after make install i receive the following error message: bin/sh: ./tools/jam/src//bjam: No such file or directory Not all Boost libraries built properly. Could anyone advise me ?

1 0

[boost 1.35][thread] Compile error with GCC 3.2
by Alexander Dong Back Kim 01 Sep '08

01 Sep '08

Dear members, I wrote an application using boost thread. It compiled well with GCC 3.4 but not with 3.2. I'm using Boost version 1.35. When I compile the application it shows the following error messages... /usr/local/include/boost-1_35/boost/config/requires_threads.hpp:47:5: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pt hreads (Solaris) or -mthreads (Mingw32)" /usr/local/include/boost-1_35/boost/thread/detail/platform.hpp:67:9: #error "Sorry, no boost threads are available for this platform." /usr/local/include/boost-1_35/boost/thread/thread.hpp:19:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/condition_variable.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/condition.hpp:13: syntax error before `;' token /usr/local/include/boost-1_35/boost/thread/mutex.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/once.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/once.hpp:23: type specifier omitted for parameter `once_flag' /usr/local/include/boost-1_35/boost/thread/once.hpp:23: syntax error before `&' token /usr/local/include/boost-1_35/boost/thread/once.hpp: In function `void boost::call_once(...)': The codes were compiled well with boost 1.32 but once I upgraded to 1.35, this error starts occurring. Any ideas or suggestions are welcomed and appreciated. best regards, Alex Kim

2 2

[boost 1.35] Linking problem with GCC 3.2
by Alexander Dong Back Kim 01 Sep '08

01 Sep '08

Hi members, I'm using both GCC 3.2 and 3.4 in different linux machines. The application uses a number of BOOST libraries such as program_options, iosterams, thread and system. When I compiled the application with GCC 3.4 (of course linking correct library files like "libboost_program_options-gcc34-mt"), it compiled well and works well. I did "ldd" to see what library files are linked... and it says... libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0048a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005e8000) libm.so.6 => /lib/tls/libm.so.6 (0x00372000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00555000) libc.so.6 => /lib/tls/libc.so.6 (0x0023e000) /lib/ld-linux.so.2 (0x00224000) Now, I compiled the same application and link different gcc version of boost library files because it uses GCC 3.2 instead. I compiled it and there was no compile-time error but it cannot be executed because it can't find the target library files. I did "ldd" for the application and now it has all the boost library files... libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0038d000) libboost_system-gcc32-mt-1_35.so.1.35.0 => not found libboost_thread-gcc32-mt-1_35.so.1.35.0 => not found libboost_serialization-gcc32-mt-1_35.so.1.35.0 => not found libboost_program_options-gcc32-mt-1_35.so.1.35.0 => not found libboost_iostreams-gcc32-mt-1_35.so.1.35.0 => not found libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00b8e000) libm.so.6 => /lib/tls/libm.so.6 (0x007a6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00179000) libc.so.6 => /lib/tls/libc.so.6 (0x00182000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00d66000) Both machine has the same boost 1.35. Only differences is they have different versions of GCC (3.2 and 3.4). Is there any idea or hints where this problem comes from??? regards, Alex Kim

3 4

F# Units of Measurement
by Mårten Rånge 01 Sep '08

01 Sep '08

This is not C++ but since it was used as an example in the boost mpl book maybe it could insterest some. http://blogs.msdn.com/andrewkennedy/ -- Mårten

2 1

lifetime of ranges vs. iterators
by Arno Schödl 01 Sep '08

01 Sep '08

> When stacking N difference_ranges, the size difference between "fat" and "lean" > iterators is 2^N. Thus in fully generic code where you don't know anything about > the stacking depth, even generating a single fat iterator carries a potentially > exponential penalty. > This fact makes me think that range is not merely a fancy name for a pair of > iterators but a concept in its own right between containers and iterators. > Generic algorithms must be written on the basis of ranges rather than iterators > or take a significant performance hit. To be fair, this hit could be avoided by storing the sub-iterators of the difference_iterator in their factored form, e.g., m_ittrav/m_ittravEnd would be stored as m_ittrav/m_ittravEnd/m_travcommon. But this would put a big burden on the compiler to optimize the frequent compose/decompose operations. For example: *m_ittrav; would become *compose( m_ittrav, m_travcommon ) // common data not used at all and ++m_ittrav; would become m_ittrav=decompose( ++compose( m_ittrav, m_travcommon ) ).first; -Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

1 0