March 2005 - Boost - lists.boost.org

[serialization] BOOST_CLASS_EXPORT regression?
by Vladimir Prus 14 Mar '05

14 Mar '05

Hello, I've have a header file like this: namespace lvk { namespace nm_model { namespace runtime { class IntTraceItem {}; }}} BOOST_CLASS_EXPORT(lvk::nm_model::runtime::IntTraceItem); The header is included in two files. It used to work before, but I've just updated to CVS state of the serialization lib, and get: src/runtime/bin/gcc/debug/threading-multi/TraceArbiter.o(.bss+0x0):src/runtime/TraceArbiter.cpp:16: multiple definition of `boost::archive::detail::guid_initializer<lvk::nm_model::runtime::IntTraceItem>::instance' src/runtime/bin/gcc/debug/threading-multi/Trace.o(.bss+0x0):src/runtime/Trace.cpp:21: first defined here I attach the testcase. When I run g++ -I ~/Work/boost-rc s1.cpp s2.cpp the first error is about duplicate symbols. Am I doing something wrong or is this a regression? - Volodya

3 5

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 14 Mar '05

14 Mar '05

In-Reply-To: <d0kr8r$gl6$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It's a pleasure to announce that the review of Daniel James' hash > functions library starts today (8th of March) and ends the 12th > of March. I see I have missed the deadline. Oh, well. Several queries have been raised during the review, some of which have merit. Firstly, I think we have some agreement that the signature: size_t hash_range( It first, It last ); is wrong and there should be some way to provide an initial seed. I am not yet decided on what the best signature should be; I am tempted towards a 3rd argument with a default value, but I can also see some merit in mimicking hash_combine() by making the seed the first argument. Secondly, the proposed implementation for hashing pointers produces undefined behaviour because it subtracts pointers not in the same array. We have some agreement that using reinterpret_cast would be better. Thirdly, I think there is also a legitimate query over whether the default hash_range should provide better quality hashes for arrays of bytes, eg along the lines discussed in: http://www.azillionmonkeys.com/qed/hash.html With boost interface is more important than implementation, but apparently implementations of the hash library will not be allowed to vary. My impression is that the proposed implementation of hash_combine: seed ^= hash_value(v) + (seed << 6) + (seed >> 2); was designed to combine 8-bit character values; do we have any evidence it also performs well to combine 32-bit values? Perhaps hash_value(v) would be better treated as an array of 4 bytes? Fourthly, there seems to be a design philosophy behind the current proposal which is not stated explicitly in the documentation. It apparently favours some notion of safety over speed and hash quality, where "safety" means that different objects should have the same hash values if they look at all alike to someone possibly. For example, the proposal has no specialisation for chars at all. I can't tell if that is an oversight, or whether it is a design aim that: char chars[] = { 1, 2, 3, 4 }; int ints[] = { 1, 2, 3, 4 }; assert( hash_range( chars, chars+4 ) == hash_range( ints, ints+4 ) ); I gather it is a design aim that hash_value( pair<int,int> ) match hash_range( int[2] ). Presumably if hash_range takes a seed argument, this means hash_value must too, else how can it match it? I am not sure about all this philosophy. I had kinda hoped that a boost hashing library would offer good quality industrial-strength hashing; that it would save me having to do my own research. Regardless, I think the aims and guarantees of the proposed library should be documented more explicitly. In conclusion, I feel that if we given only 5 days to review a proposal, that proposal needs to be spot on, uncontroversial, with all issues nailed accurately in advance. I don't think that is the case here. Although I think all the problems could be resolved, I don't think we have enough time to do that in the given review period. If I have to decide now, I'd say: This should not be accepted as a Boost library. Stock questions: I have not tried to compile the code. I have looked at the documentation, the source, and followed some of the references. I have raised design questions here and followed the discussion. Total time is a few hours. I am not an expert on hashing, but I have implemented my own hashing library. I have encountered practical problems due to different objects having the same hash values. -- Dave Harris, Nottingham, UK

6 14

[aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 Mar '05

The class aligned_storage in boost/aligned_storage.hpp has the following decl: template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1) > class aligned_storage; GCC 4.0 complains about the default value for aligmnent_ saying that: '(size_t)((-1))' is not a valid template argument for type 'unsigned int' because it is a non-constant expression which is ruining some of the regression tests. Is GCC right or shall I submit a bug report at gcc.gnu.org/bugzilla? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

Boost Graph - internal datastructures of graph
by Peter Billen 14 Mar '05

14 Mar '05

Hello all, I was wondering what internal datastructures are used in the different graph concepts (Graph, IncidenceGraph, etc.), to achieve efficient implementations of these different concepts. Is this documented somewhere? I couldn't find anything about the implementations on the website. Is this discussed in the book? I am aware I can browse through the code, but I thought it might be a good idea to ask it first here. Thanks for your replies, -- Peter

2 1

[Boost-bugs] [ boost-Bugs-1163091 ] push_relabel_max_flow may be broken
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163091, was opened at 2005-03-14 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: push_relabel_max_flow may be broken Initial Comment: The push_relabel_max_flow algorithm seems to be dereferencing past-the-end iterators. The initial bug report is here: http://lists.boost.org/MailArchives/boost-users/msg10032.php Doug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1163077 ] EdgeListS = setS for adjacency_list does not work
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163077, was opened at 2005-03-14 10:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163077&group_… Category: graph Group: None Status: Open Resolution: None Priority: 4 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: EdgeListS = setS for adjacency_list does not work Initial Comment: The adjacency_list class template requires the EdgeListS selector to indicate a Sequence container (and may very well require the default listS). setS, for instance, does not work. See http://lists.boost.org/MailArchives/boost-users/msg09557.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163077&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[wiki] New content filtering to reduce spam
by Jeff Garland 14 Mar '05

14 Mar '05

All - I've instituted a new content filter on the Wiki to try and cut off the spamming without going to a login or other user intrusive mechanism. The timing of this feature turned out to be important as a sophisticated spambot that evades the ip banning strategy by using many different ip addresses (presumably using zombie machines) has been attempting to SPAM the wiki all day today. The new content filter has sucessfully stopped this bot. Note that if a spammer is successful I am now reverting all spam content from the Wiki history so that there is no change of googlebot finding it. For the moment, I'm not going to publish the regular expressions I'm using to filter, but suffice to say, normal boost content should be unaffected. If you get an error indicating content has been blocked due to spam, send me and email. Thanks, Jeff

2 1

Hash function review
by John Maddock 14 Mar '05

14 Mar '05

A little late in day, here we go: >What is your evaluation of the design? The design is basically fixed by the TR, so there's not much to review here. The extensions to the TR proposed by Peter Dimov, and implemented here look fine to me as well. >What is your evaluation of the implementation? Modulo the suggestions to the pointer hashing, it looks very good: I spent some time examining the floating point implementation, along with the associated test cases, and everything that could be tested looks like it is. I agree with those opinions expressed here that it's better to have a reliable implementation, that produces good hash values, than an artificially fast version that produces bad hash values. I have one query regarding hashing of integer types, regarding hashing of long long, Daniel says: "Also, it will need a different hash function to the other integer type as the current one won't take account of the higher bits. I want to take my time over things like this and get it right." But I think this is a (mostly theoretical) issue already: type long may have more bits than size_t does. I don't think this is a big issue though, it should effect very few platforms, and shouldn't hold up acceptance of the library. >What is your evaluation of the documentation? Also looks very good, I would like to see some more description of how the implementation differs from the TR (all the bits are there in the docs, it's just not clear which are part of the TR, and which are the extensions). >What is your evaluation of the potential usefulness of the library? Can't believe we haven't had this in Boost already. It's about time. >Did you try to use the library? With what compiler? Did you have any >problems? I've spent some time examining and running the test cases, everything that should pass does so with: gcc-3.3.2 Intel 7, 8.1 and 9Beta VC++ 6, 7, 7.1 and 8Beta. The tests are failing with Borland, due to a problem with Boost.Test. >How much effort did you put into your evaluation? A glance? A quick >reading? In-depth study? A couple of hours reading the code and the docs. >Are you knowledgeable about the problem domain? I don't claim to be any kind of expert in hashing. >Do you think the library should be accepted as a Boost library? Yes, please ;-) John.

1 0

[test] still regressions with IsDebuggerPresent()
by Stefan Slapeta 14 Mar '05

14 Mar '05

There are still regressions caused by a missing definition of IsDebuggerPresent(). These failures have been introduced by the recent changes in boost.test. What is to do here? see http://tinyurl.com/6vdo9 Cheers, Stefan

2 1

Sockets: proposal for a library design
by Boris 14 Mar '05

14 Mar '05

I updated the Wiki pages for a net library at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. After collecting all the information I found at the Wiki pages for the socket and multiplexing library I try to explain how a net library should basically look like. The proposal includes various I/O models and is based on I/O streams. As usual any comments are appreciated, Boris

6 10