- Boost - lists.boost.org

RE: [boost] Re: [Threads] Much faster try_mutex on Windows NT
by Hanson, Iain 25 Mar '04

25 Mar '04

> Dijkstra's 1965 paper "Cooperating Sequential Processes" > explained the > problems associated with events and any other constructs that > depend on > processing speed assumptions to work correctly. That paper > was recently > reprinted in the book "The Origin of Concurrent Programming", > Per Brinch > Hansen, editor, 2002. > "Cooperating Sequential Processes" is also available here. http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF /ikh ------------------------ #include <std_disclaimer> Everything following this line has been provided courtsey of my ISP and I have no control over it. ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================

1 0

[BGL] How to fix read_graphviz? with spirit?
by HIRAKI Hideaki 25 Mar '04

25 Mar '04

Hello there, I submitted a bug fix on read_graphviz() to the bug tracker (Bug ID 865882, see P.P.S. below for the summary). When thinking about possible fixes, I got some questions. Q1) May boost depend on build tools other than C++ compiler? There seemed to be a building problem due to the dependency of the parser code on some specific versions of bison. This is not a real problem because the generated C++ codes are bundled. I think the dependency should be removed, if possible. Q2) How easy is it to migrate a flex/bison code to spirit? Boost seems to have its own parser generator, spirit. Its features are uncertain for me. I just expect that it is straightforward for an expert of spirit to write a reentrant parser to be replaced with the current flex/bison parser. Q3) Why boost::subgraph isn't general subgraph but "induced" subgraph? BGL seems to have a fundamental restriction on reading graphviz files. The graph data read in read_graphviz() is stored in the boost::subgraph<> where any edge connecting vertices of a subgraph is assumed to be part of the subgraph. This is against the semantics of the graphviz format. For example, digraph g0 { edge [color=blue] subgraph g1 { edge [color=red] n1 -> n2 } n1 -> n2 } this graph has one edge in the subgraph g1 (red) and the other not in g1 (blue). But the graph read by BGL must have both edges belonging to g1. I guess that the complexity to realize this restriction may be the cause for the wrong codes in boost/graph/subgraph.hpp (see the comments at the lines 603 and 612). Anyway, a handy data structure to treat general subgraph is useful. I hope boost::subgraph will be the one. Q4) How are the graph adapters for graphs of graphviz library? Another option imagined is wrapping the graphviz library. This will introduce library dependency instead of build tool dependency. But no parser need to be developed. A data structure for general subgraph will be provided as a wrapped object. BGL seems to include wrappers for Stanford GraphBase and LEDA, C++ libraries. How are they adapted to graphviz, a C library? Regards, Hideaki Hiraki P. S. To Vladimir Prus: I'm sorry to lay this subject aside so long. I appreciate your every effort. P. P. S. Summary of the bug: The problem was that calling read_graphviz() for the second time was failed. The fix was to clear the garbage left in static variables: --- boost_1_31_0/libs/graph/src/graphviz_parser.yy Fri Aug 29 16:02:59 2003 +++ boost/libs/graph/src/graphviz_parser.yy Mon Jan 26 18:16:16 2004 @@ -259,6 +259,10 @@ graph_header: graph_type graph_name { + graphviz::vlist.clear(); + graphviz::attributes.clear(); + graphviz::subgraphs.clear(); + graphviz::nodes.clear(); std::string* name = static_cast<std::string*>($2); graphviz::previous_graph = static_cast<graphviz::Subgraph*>(g); graphviz::current_graph = static_cast<graphviz::Subgraph*>(g); This workaround was found without understanding the code. As this worked for me, I gave up digging more. A better fix may remove the uses of static variables. The item in the bug tracker has been closed but is accessible: http://sf.net/tracker/index.php?func=detail&aid=865882&group_id=7586&atid=1…

3 4

borland-5.6.4, auo_link and common-names (v1)
by Hugo Duncan 24 Mar '04

24 Mar '04

The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails. I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets. Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense. Thanks Hugo Index: auto_link.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/auto_link.hpp,v retrieving revision 1.9 diff -u -r1.9 auto_link.hpp --- auto_link.hpp 21 Jan 2004 11:54:55 -0000 1.9 +++ auto_link.hpp 22 Mar 2004 14:09:39 -0000 @@ -120,9 +120,14 @@ // vc71: # define BOOST_LIB_TOOLSET "vc71" -#elif defined(__BORLANDC__) +#elif defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) // CBuilder 6: +# define BOOST_LIB_TOOLSET "bcb56" + +#elif defined(__BORLANDC__) + + // BCB: # define BOOST_LIB_TOOLSET "bcb" #elif defined(__ICL)

4 7

Naming Issues [part of Formal Review: Indexed Set]
by Pavel Vozenilek 24 Mar '04

24 Mar '04

This should be starting point of discussions about proper indexed_set naming. indexed_set name was picked long before the library gained much more functionality. Instead of changing name immediatelly it was decided to wait on opinion of others (any change requires quite a lot of work). Here are my suggestion of names, with rationale: 1. the data structure should be named "multi_container" and should reside (or be lifted) in boost namespace. Rationale: it is superset of std::set/multiset/list and possibly slist and deque). Therefore the "multi". The structure is important and will be probably unique - therefore the boost namespace. 2. library specific names that won't fit into boost namespace should be in "multiindex" namespace. Rationale: it will be used mainly for index related names. The name is aso reasonably short. 3. indexes should be named: set_like, multiset_like, list_like, slist_like, deque_like. Rationale: it gives idea to user what it is about (more than e.g. sequenced). 4. Since indexed_set::unique may clash with std::unique I suggest to use words "distinctive", "non_distinctive". Rationale: I found it in a dictionary as the only one word synonum to unique. English native comment welcomed. /Pavel

5 6

FC++ Review results: Real Soon Now
by Mat Marcus 24 Mar '04

24 Mar '04

Some folks have been wondering whether they missed the FC++ review results. I am still working on it. I must apologize for the delay, but please be assured that completion of the determination is at the top of my list of priorities. - Mat

1 0

[Boost-bugs] [ boost-Bugs-918568 ] signals
by SourceForge.net 24 Mar '04

24 Mar '04

Bugs item #918568, was opened at 2004-03-17 23:57 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=918568&group_i… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: signals Initial Comment: //to suppoet intel-win32 under inter8.0, change bellow! file:singals namespace boost { namespace BOOST_SIGNALS_NAMESPACE { class trackable; namespace detail { // Represents an object that has been bound as part of a slot, and how // to notify that object of a disconnect struct bound_object { void* obj; void* data; void (*disconnect)(void*, void*); bool operator==(const bound_object& other) const { return obj == other.obj && data == other.data; } bool operator<(const bound_object& other) const { return obj < other.obj; } //Add by ty, to support intel 80 compiler, 2004/03/18 bool operator!=(const bound_object& other) const { return !(*this==other); } bool operator>(const bound_object& other) const { return !(*this < other); } }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918568&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

RE: [boost] Re: Formal Review: Indexed Set
by Powell, Gary 24 Mar '04

24 Mar '04

>> I think there may be the problem that the various predicates used for >> the indices do not generally define comparison operators which compare >> predicates specialized on different types. >I think Gary and you are talking about different things. >As you point out, there are difficulties in using the >internal comparison objects of indices for defining >operator <. Moreover, the standard clearly dictates that >comparison between containers a and b be implemented as >lexicographical_compare(a.begin(),a.end(),b.begin(),b.end()) >leaving no option to use other comparison predicate than >operator < between element objects (see std 23.1.5) A rationale >for the decision of not using the internal comparison >predicates is given in >http://www.sgi.com/tech/stl/FAQ.html >(section "Why doesn't map's operator< use the map's comparison >function?") >So, IMHO there's little doubt that operator < between indices >of an indexed_set must use value_type::operator <, >conterintuitive as it may seem. A similar reasoning applies >to equality comparison between indices. >Now, what Gary proposes (if I understand it right) is that >we extend operator == and < so that indices on different element >types can be compared. As I see it, this can be legally done, and >it should do no harm as it merely extends the current >functionality. It'd be something along these lines: >template<...(1),...(2)> >bool operator==( > const *index class*<...(1)>& x, > const *index class*<...(2)>& y) >{ > return x.size()==y.size()&&std::equal(x.begin(),x.end(),y.begin()); >} >template<...> >bool operator<( > const *index class*<...(1)>& x, > const *index class*<...(2)>& y) >{ > return std::lexicographical_compare(x.begin(),x.end(),y.begin(),y.end()); >} >where ...(1) and ...(2) are (possibly different) sets of >template intantiation arguments for *index class*. >Is this what's being proposed? Right! Sorry I was too terse in my previous email. There is no reason why not to extend operator==() and operator<() to allow for two different container types to be compared. Either there is a comparison that will work for the two types or there is not, but it isn't the indexed set that enforces it, but rather std::equal and std::lexigraphical_compare. So the proprosal is to also extend all of the comparison operators to take the two complete sets of templated arguments. ie. Old: template<typename Value,typename IndexSpecifierList,typename Allocator> bool operator==( const indexed_set<Value,IndexSpecifierList,Allocator>& x, const indexed_set<Value,IndexSpecifierList,Allocator>& y); New: template<typename Value1,typename IndexSpecifierList1,typename Allocator1> template<typename Value2,typename IndexSpecifierList2,typename Allocator2> bool operator==( const indexed_set<Value1,IndexSpecifierList1,Allocator1>& x, const indexed_set<Value2,IndexSpecifierList2,Allocator2>& y); etc.. AFAIK there is no penalty for the library and much to be gained for the user. Yours, -Gary-

3 4

Suggested addition for BOOST_WORKAROUND
by Gennaro Prota 24 Mar '04

24 Mar '04

Hi, as pointed out when BOOST_WORKAROUND was being discussed, Borland C++ (I think, up to 0x600 excluded) just emits an optional warning for division by zero. The warning is enabled by default, but can be turned off with -w-zdi or -w-8082. So I (re)propose to add a special BOOST_WORKAROUND implementation for it: #if defined(__BORLANDC__) && (__BORLANDC__ < 0x600) // Borland needs a special version, as it just emits a warning for // division by zero (and you can even disable it with -w-zdi or // -w-8082 !!). But it supports sizeof expressions in #if-s // (NOTE: that's non-conforming) // # define BOOST_WORKAROUND(symbol, test) \ (((symbol) != 0) && (1 != sizeof(char[1 + ((symbol) test)]) )) #else # define BOOST_WORKAROUND(symbol, test) \ ((symbol != 0) && (1 % (( (symbol test) ) + 1))) ... Notes: a) it should be verified whether version 0x600 has the same problem or not; given that it uses an EDG front-end it probably won't, but who knows what they could have decided in the name of backward non-conformity :) b) I suggest to use __BORLANDC__ directly, instead of the (maybe) upcoming BOOST_BORLAND_xxx, to avoid including config.hpp for such a simple header. PS: Giovanni, I asked you in private mail a while ago. What does your 'typo revealing' patch do? -- Genny.

2 4

[program_options] post-review version -- compile problem
by Rob Lievaart 24 Mar '04

24 Mar '04

Hi, I just downloaded and compiled the version 262 of the library using Mingw (gcc 3.2.3) and I ran into a problem compiling parser.cpp: The function parse_environment contains the following lines: #if defined(_WIN32) char **environ = _environ; #endif But the mingw provided stdlib.h contains an unconditional #define environ _environ So it does not compile :-( I changed parser.cpp to #if defined(_WIN32) && !defined( __MINGW32__ ) char **environ = _environ; #endif And now it compiles and the samples run, but I have not actually tried to use enviroment variables. Also I checked the stdlib.h provided with MSVC6.5 and that contains #ifdef _POSIX_ extern char ** environ; /* pointer to environment table */ #else But I guess this would not cause a problem when _POSIX_ is defined, because the local environ would just hide the one from stdlib.h. And a small question, is the library supposed to work with 6.5 at all? I get a rather large amount of errors and warnings when I try to build it. I haven't looked into them yet, if it is not supposed to work then I won't spend any time on it. Rob Lievaart

3 3

RE: [boost] Formal Review: Indexed Set
by Powell, Gary 24 Mar '04

24 Mar '04

After a first quick review of the code, indexed set has the same problem as circular queue does with comparison operators. Only one value type comparison is possible. IMO, if two value types have a valid comparison operation, then they are comparable. Memory allocation should have no bearing on this, and the types do not have to be identical. i.e. an indexed set of shorts, { 1, 2, 3 } is equal to an indexed set of longs { 1L, 2L, 3L }. This means that less user code is written for these sort of things. More to come as I have time to spend... -Gary-

3 2