- Boost - lists.boost.org

[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

[flyweight] some minor comments
by Thorsten Ottosen 20 Dec '07

20 Dec '07

Hi Joaquín, Your docs looks real nice. But I have the following suggestion: - make it possible to use boost::flyweight<T> without the use of factories. The number of elements I want to create is fairly low, and so does not justify having a seperate container "flying" around. -Thorsten PS: what a shame we can't overload operator.() in C++

6 12

[review] Review of Unordered library started December 7 and still running!
by Ion Gaztañaga 20 Dec '07

20 Dec '07

Hi all, The formal review of the Unordered library started December 7, we have a few nice reviews, but they are not enough. If you are interested in the library (and I *know* you are), please take some time to review it. This is the info you need to do a review: *Description*: An implementation of the unordered containers specified in TR1, with most of the changes from the recent draft standards. *Author*: Daniel James *Download*: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… The documentation is in the zip file. I've put documentation online here: http://igaztanaga.drivehq.com/unordered http://tinyurl.com/yw8wjp What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

4 4