- Boost - lists.boost.org

[1.33.0 zip version] Broken Images & Broken Links
by Pavel Chikulaev 13 Aug '05

13 Aug '05

Hi everyone, There is at least two bugs in zip version: 1) Corrupted image /libs/ptr_container/doc/cboost.gif (on site everythins is ok) Also it's an old logo, should that be img src in \libs\ptr_container\doc\ptr_container.html changed from /libs/ptr_container/doc/cboost.gif to /boost.png? As far as I know image is not corrupted in tar.bz2 version. 2) There is a broken link in /libs/program_options/doc/index.html which incorrectly redirects to ../../../doc/html/program_option.html instead of ../../../doc/html/program_options.html Same on site and another distributions. Can these things be changed until more people download it? -- With best regards, Pavel Chikulaev.

3 2

[iostreams] Typo in docs
by Caleb Epstein 12 Aug '05

12 Aug '05

In http://boost.org/libs/iostreams/doc/tutorial/container_sink.html "Finally, I should mention that the Iostremas library easier ways..." Note misspelling of Iostreams and the missing verb. "Offers" perhaps? -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

[bind] Named placeholders and TR1
by Christopher Kohlhoff 12 Aug '05

12 Aug '05

Hi all, As part of the asio library I have been using named placeholders for the common arguments to callback functions. For example: asio::async_send_n(sock, buffer, length, boost::bind(mycallback, asio::arg::error, asio::arg::last_bytes_sent, asio::arg::total_bytes_sent)); rather than: asio::async_send_n(sock, buffer, length, boost::bind(mycallback, _1, _2, _3)); I find having named placeholders saves time and helps prevent errors to do with the ordering of the parameters (e.g. in the case of something like the last_bytes_sent/total_bytes_sent example where both are size_t, and so incorrect order will not be detected by the compiler). Unfortunately, from my reading of the TR1 bind doco at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1455.htm it simply defines the placeholders as: namespace std { namespace placeholders { extern unspecified _1; extern unspecified _2; extern unspecified _3; // implementation defined number of additional placeholders } } and it doesn't say anything about the type of the placeholders. Since the placeholders are CopyConstructible, it seems like I ought to be able to do something using a typedef (if there was one), e.g: std::placeholders::_1_t my_placeholder(std::placeholders::_1); Is there some TR1-compatible (and therefore portable) way of working around it that's eluding me (other than #define :). It seems a shame not to have such a feature, especially if over time more libraries use complex function objects in their interfaces. Cheers, Chris

3 3

1.33.0 is out the door...
by Douglas Gregor 12 Aug '05

12 Aug '05

... and so am I. I'll be checking e-mail periodically, but barring a release-related catastrophe I'll only be lurking for the next week or so. Doug

2 1

singleton and thread safety
by Jason Hise 12 Aug '05

12 Aug '05

I need to ensure that certain objects (specifically the policy bundles which manage singleton instances) are created in a thread-safe manner. First question: Can two threads both initialize the same static variable if they pass through the same function at the same time? Ex: void foo ( ) { static Thing t; } Can t's constructor be called twice by two threads executing foo? If so, I feel that I need to construct my policy bundles before execution enters main, a time when it is pretty much guaranteed that the application is operating in a single-threaded context. I thought that this would be simple to do: just write a class that calls the function with the static variable in its constructor and create a global instance of that class. However, the standard appears to say that initialization of such global variables can happen after main is entered, so long as it happens before the global variable is used. If the program starts spawning threads before the global variable is constructed I would still have the same problem. How can I ensure that initialization is performed before main is entered? If I cannot, is there some other way to make initialization of static variables thread-safe? I cannot lock a mutex to manage this, because the mutex lives inside the threading policy instance and the threading policy instance lives in the policy bundle that I am trying to create in the first place. -Jason

7 14

Re: [boost] Boost 1.33.0 released
by JOAQUIN LOPEZ MU?Z 12 Aug '05

12 Aug '05

----- Mensaje original ----- De: Doug Gregor <doug.gregor(a)gmail.com> Fecha: Viernes, Agosto 12, 2005 7:33 am Asunto: [boost] Boost 1.33.0 released > Boost 1.33.0 Congratulations and thank you for your efforts! Shouldn't a notice be posted to clc++ and clc++m? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Spelling error on the new boost.org home page
by Jeffrey Williams 12 Aug '05

12 Aug '05

On the new boost home page there is a spelling error in the section about what is new with the serialization library: "Improved seialization of shared pointers" Should be: "Improved serialization of shared pointers" Jeff

1 0

Minor inconcistencies on the website
by Arkadiy Vertleyb 12 Aug '05

12 Aug '05

FWIW: Formal review schedule/past review results, references FOREACH and TYPEOF libs not in the chronological order of acceptance. Also the link to the FOREACH macro in the file vault is not provided. Regards, Arkadiy

1 0

test boost-1.33 srpm
by Neal Becker 12 Aug '05

12 Aug '05

I placed my test boost-1.33 srpm here: http://nbecker.dyndns.org:8080/boost-1.33.0-6.src.rpm Basically, I modified the redhat 1.32 spec file: 1) Don't mess with soname 2) Autoconfigure icu support 3) Build all variants 4) Add my (little) patch for serializing mersenne_twister. Yes, I know it's not optimal, but it's simple and good enough for my purposes. Please comment.

3 3

[Config][auto_link] BOOST_LIB_TOOLSET override does not work as intended when multiple libraries are used
by Sean Huang 12 Aug '05

12 Aug '05

For example, if BOOST_LIB_TOOLSET is defined as "iw90" and both thread and signals libraries are used in a cpp file, compiler prints out the following: Linking to lib file: libboost_thread-iw90-mt-s-1_33.lib Linking to lib file: libboost_signals-iw-mt-s-1_33.lib The problem is caused by BOOST_LIB_TOOLSET being undefined at the end of auto_link.hpp. The second time auto_link.hpp is included (it has no include guards and is meant to be included multiple times) BOOST_LIB_TOOLSET is not defined anymore and a default value will be assigned. Does it really need to be undef'ed? Thanks, Sean

2 1