- Boost - lists.boost.org

[vault] ctor_shared_from_this()
by Robert Sitton 24 Dec '07

24 Dec '07

I've had a few cases where my design required calling shared_from_this() in a constructor and destructor. I made some modifications to enable_shared_from_this which I have posted here: http://www.boost-consulting.com/vault/index.php?order=rating&direction=1&di… There is a test function in a test file in the zip archive that will fail if you call shared_from_this() instead of my ctor_shared_from_this() method. Rob

2 1

[Units] can't view the documentation
by John Salmon 23 Dec '07

23 Dec '07

I am very interested in the recently accepted Boost.Units library. I'm interested enough that I'd really like to read the documentation.... I have checked out the sources from the svn sandbox, but I can't seem to turn the units.qbk into something more readable. I tried the "obvious": run bjam in the docs directory, but that issues the complaint below. I added 'using boostbook;' to the user-config.jam in the top-level source directory, to no avail. I fear that I'm in a maze of twisty tools, all alike. a) is there an easy way to build the documentation or b) could some kind soul who has found their way through the maze of bbv2, boostbook, xsltproc, etc. do the rest of us a favor and put the html docs up on the web somewhere. $ bjam Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, you may not be able to build C++ programs. warning: Use the "--toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html warn: Unable to construct ./standalone error: the boostbook module is not initialized error: you've attempted to use the 'doxygen' toolset, error: which requires Boost.Book, error: but never initialized Boost.Book. error: Hint: add 'using boostbook ;' to your user-config.jam salmonj(a)drdws032.nyc$

3 4

[GIL]: extended png io
by Andreas Pokorny 23 Dec '07

23 Dec '07

Hello Lubomir, Hailin and the other boosters, I implemented support for more png file types, including palette and grayscale with alpha images. For the implementation I had to add a gray_alpha layout, and extend the color_type metafunction for homogeneous bit_aligned_pixel_* types - packed_pixel is still missing. I tested 1,2 and 4 bit images with http://www.schaik.com/pngsuite/pngsuite_bas_png.html and some images with I also added additional calls to png_packswap to get proper results for 1bit images. Could you review the changes? A svn diff of boost/gil/ is attached to the email. I have a boost svn account, and could add that stuff myself, if you want me to. I could also add more test cases that capture more of the png file types. kind regards Andreas Pokorny

1 0

Re: [boost] [Boost-build] [1.35] what gets built and installed?
by John Maddock 22 Dec '07

22 Dec '07

Rene Rivera wrote: > John Maddock wrote: >> If I do a: >> >> bjam stage --toolset=msvc-8.0 --with-regex >> >> Then with 1.35 I don't get any static libraries built, just the >> dll's. Was this a deliberate change somewhere? It's a problem >> because the default for auto-linking is to look for static rather >> than dynamic libraries. > > Yes, it was intentional > <http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also > discussed it at one point > <http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess > we > should switch autolink to default to the dynamic libs? That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise. There's a great deal of documentation that would have to change to reflect this as well. There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic There's a further issue with building only one variant under MSVC: it doesn't work! By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them. We need to be *very* careful with this, or the complaints will be loud and vociferous! If the aim is to reduce the number of variants built, then I would suggest: Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single build on Unix variants (2 build variants). Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants). That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-) Sorry to be the bearer of the bad news, John. PS this is too important and far reaching to be discussed only on boost-build IMO.

10 14

Re: [boost] [review] Formal Fast-Track review of the Boost.Functional/Factory library - extended until sunday
by Tobias Schwinger 22 Dec '07

22 Dec '07

shunsuke wrote: > BTW, Boost.Lambda can support result_of without modifying its source code. > > #include <boost/lambda/result_of.hpp> // imaginary header for now. > namespace bl = boost::lambda; > > // result_of conforming FunctionObject > bl::bind( > bl::constructor< boost::shared_ptr<int> >(), > bl::bind(bl::new_ptr<int>(), bl::_1) > ) > > If interested, I think I can upload result_of.hpp. Sounds good to me - but it isn't up to me to decide. You should probably repost this suggestion with '[lambda]' in the subject or file a feature request with a patch for that library's authors to pick it up. IIRC there was a planned merger of Lambda and Phoenix2. Itseems you have some time to contribute ITM and your "Egg" library showssome experience in that domain. I'm CCing Joel as he might be interested in your help. Getting "Factory functionality" out of the Lambda library does not deprecate the utility we are reviewing: Using Boost.Lambda just to create a single class instance seems sorta wasteful. Factory's greatest strength is its simplicity: We can easily make it compile (and optimize decently) even with legacy compilers and it's lightweight in terms of dependencies and template instantiations. Regards, Tobias

1 0

[property_tree] minor detail/ptree_implementation.hpp patch for gcc 3.3
by Ryan Gallagher 21 Dec '07

21 Dec '07

Using rev5 from the vault of this library I ran into a minor issue when compiling for gcc 3.3. I can compile code against this for msvc71 both before and after the patch. BTW, while I know its accepted to Boost, is this library to be in 1.35? Thanks, -Ryan Unified diff on property_tree/detail/ptree_implementation.hpp: @@ -813,7 +813,7 @@ const key_type &path, const std::locale &loc) const { - return get_child(separator, path).get_own<Type>(loc); + return get_child(separator, path).template get_own<Type>(loc); } // Get value from data of child ptree (custom path separator) @@ -852,7 +852,7 @@ const std::locale &loc) const { if (optional<const basic_ptree<Tr> &> child = get_child_optional(separator, path)) - return child.get().get_own_optional<Type>(loc); + return child.get().template get_own_optional<Type>(loc); else return optional<Type>(); }

2 3

old style streams support?
by Eames, Andrew 21 Dec '07

21 Dec '07

Hi, My DSP compiler comes with an ancient version of STL which only has old-style streams support (non templated streambuf etc.). It seems that in order to use some parts of boost that use streams, I would need to either modify boost to allow old style streams or use something like STLPort to get a more modern version of STL (My compiler vendor is unlikely to provide me with a more modern version). Using STLPort comes with its own porting issues - I have tried it briefly and it could probably be made to work but it would definitely require some modification. Is there any interest in supporting old-style streams in boost? Andrew

1 0

Boost.Thread and extensibility
by Eames, Andrew 21 Dec '07

21 Dec '07

Hi, I've been continuing my quest to try and use Boost for my DSP and its C++ compiler. I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source. Is this an issue that has been raised before? Thanks Andrew

4 5

'indexed' multi arrays?
by Chris Hamilton 21 Dec '07

21 Dec '07

In a recent project I've been working on, we had need for something that I'm calling (for lack of a better, more inspired name ;) an 'indexed' multi array. Essentially, we wanted something like a boost multi_array but that also allowed indexing along each dimension using some kind of indexing function. For example, along one dimension the indexing function may except a string as input and use a map to return an integer index, while along some other dimension the real line may be cut into non-overlapping intervals and a double value is looked up returning the index of the interval it belongs to. We looked at various solutions, but in the end rolled our own based off of the boost multi_array and a new concept of an 'indexer'. Is this something that anybody else would see as useful? I hope my explanation was sufficiently clear ;) Cheers, Chris Hamilton

3 4

Non-thread-safe thread library (Boost.Function)
by Phil Endecott 21 Dec '07

21 Dec '07

Dear All, In November Sergey Skorniakov wrote to this list asking about the non-thread-safety of Boost.Function and consequently of Boost.Thread itself. Steven Watanbee replied pointing out that the problem is resolved in the trunk. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/167877 My thought at the time was "chocolate teapot". I put understanding this issue on my to-do list and it has finally got to the top. However, looking at the trac pages that Steven linked to, I am none the wiser; they contain patches but with no comments in the code and don't mention thread safety in the commit messages. So can someone please help me understand the scope of this problem? i.e. - Are all uses of Boost.Function affected, or only certain uses (e.g. member functions vs. free functions)? - What exactly is the race between? E.g. if I know that I'll never create two threads at the same time, do I still need to worry about other uses of Boost.Function that may be concurrent? Is the race between creating the function objects or between using them, or both? - Can I avoid the problem by using a new version of Boost.Function, without upgrading other libraries? (Is Boost.Function header-only?) - What would the symptom of failure be? I'm currently debugging a double-free somewhere below std::string::assign, which is probably unrelated. I'm also curious to know how much more serious than this a bug would need to be before a Boost release would be recalled, or a new point-release released, or an announcement made on the Boost web page (which links to bugs fixed in 1.34.1, but not bugs introduced). Surely there aren't many users of Boost.Thread who are happy to use a non-thread-safe thread library..... Many thanks, Phil.

4 7