- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-926039 ] examples/kruskal-example.cpp shadows variables
by SourceForge.net 30 Mar '04

30 Mar '04

Bugs item #926039, was opened at 2004-03-30 06:16 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=926039&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: examples/kruskal-example.cpp shadows variables Initial Comment: $g++ -Wshadow -Wall kruskal-example.cpp -lbgl-viz generates a lot of shadow warnings, making it impossible to use kruskal-example related code in a program that is supposed to be shadow-free. $g++ --version g++ (GCC) 3.3.3 (Debian 20040321) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=926039&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

1 0

Re: [boost] Re: IndexedSet Review
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

Hi Dave, 2nd part of your post. ----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Lunes, Marzo 29, 2004 9:57 pm Asunto: [boost] Re: IndexedSet Review [...] > > As for the Composite Sorted Associative Container concept, we > > have the same problem. Technically, the requirements imposed > > to current or future index types by indexed_set are much weaker > > than being some sort of associative container. I cannot even state > > global complexity bounds (please check the reference, page > > "Index reference", section "Complexity signature"). > > Ok, so if the concept is not a refinement of Associative Container, > then create a new concept! > > > I agree with you a concept section would be highly desirable, but > > here I definitely need some help. What you request is not trivial. > > Then let's take a first stab at it. What you have is similar to an > Associative Container, but is fundamentally different. The way in > which it is different is that there is more than one way to access > the data. And, as you say, it is like multiple containers in one. > So > I think the most fundamental concept here is Composite Container. > [...] Agreed. > Let's rip off SGI for a minute: > > Description > > A Composite Container is a variable-sized Container that > supports retrieval of elements (values) based on one or more > keys. It supports insertion and removal of elements, but differs > from an Associative Container in that the complexity of the > operations depends on the type of key indices used. Not agreed. A Composite Container is more primitive than that. Keys properly belong to the indices (some indices are even not key-based.) I would try first to forge the Index concept. Then a Composite Container is more or less trivially defined as a "composition" (wants definition) of indices. We could call an Associative Composite Container to a Composite Container whose indices model Associative Index (wants def). A bimap is a model Assoc Comp Container, as well as some instantiations of indexed_set. The part of index retrieval (the get<> stuff) I don't see any hope of being conceptualized, as bimap, for instance, could perfectly lack such interface in favor of something simpler for the data structure at hand. Probably, a Composite Container is *not* any kind of Container (its indices are, though): imagine an indexed_set that does not inherit the functionality of its first index. [...] > Now, here we have a tricky issue. By default, IndexedSet *is* > default constructible, but we can't say that Composite Container > should be, because IndexedSet might *not* be default c'tible if > one of the key types are not. The STL solved this by simply > implicitly requiring key comparators to be default c'tible, but > perhaps this requirement is not justified. Anyway, let's continue: Oh, I hadn't thought of this before. Really std::sets implicitly require that their key objetcs are Default Constructible. Seems a defect to me. [snipped rest of stuff] Well, all these sections really belong (IMHO) to the Index concept. > > Models > > * indexed_set (of course) > * bimap (if anyone makes it ;) > > That's a start anyway, and if you fill in as much of that as you can, > I think others will be able to help you fill in the rest. It also > mighthelp if you define other concepts first, like Ordered Unique > Index,etc. I know it's a lot of work, but I think it's worthwhile > (especiallyfor people wanting to extend the library, i.e.: by > defining custom > index types). Well, I'll try to come up with something, but it'll take long. If this is a requirement for acceptance, it certainly will affect to the availability time. > > > [...] > > My Latin (I speak Spanish) heritage makes me favor "indices" > > to "indexes" (and "minuscule" to "miniscule", etc.) The Google > > metric could be biased by the fact that "indexes" is not only the > > plural of "index" but also the 3rd singular formal of the Present > > tense of the verb "index". > > Good call! That was some sloppy reasoning on my part. ;) To be honest, there's bias on the other side to: "indices" is a valid French and Spanish word. Cheers, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Problem: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)
by Stephen Torri 30 Mar '04

30 Mar '04

I am having problems with compiling a simple parsing example that I created. I have read over half of the spirit guide and took one of the examples a guide for creating my program. Here is the full error message that I hinted above. What is wrong with my code? I am using boot-1.31.0 with gcc-3.3.2 (gentoo). g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"cs507_EC\" -DVERSION=\"0.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../../src -O2 -c -o RE_Parser.o `test -f RE_Parser.cpp || echo './'`RE_Parser.cpp RE_Parser.cpp: In function `int main()': RE_Parser.cpp:18: error: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)' make[2]: *** [RE_Parser.o] Error 1 The code is: -------------------- Parser -------------------- #ifndef RE_PARSER_H_ #define RE_PARSER_H_ #include <string> #include "FileException.hpp" #include <boost/spirit.hpp> #include <iostream> using namespace std; using namespace boost::spirit; //namespace re_parser { class RE_Parser; struct RE_Grammar : public grammar<RE_Grammar> { template <typename ScannerT> struct definition { definition (RE_Grammar const& self) { r_rule = *r_rule[&RE_Parser::process_Kleene] | (r_rule >> s_rule)[&RE_Parser::process_Concat] | (r_rule >> ch_p('+') >> s_rule)[&RE_Parser::process_Or] | s_rule[&RE_Parser::process_Char]; s_rule = ch_p('a') | ch_p ('b') | ch_p ('c') | ch_p ('^') | ch_p ('0'); } rule<ScannerT> r_rule, s_rule; rule<ScannerT> const& start() const { return r_rule;} }; }; class RE_Parser { public: void process_Kleene (char const*, char const*){ cout << "Kleene star" << endl;}; void process_Concat (char const*, char const*){ cout << "Concatenate" << endl; }; void process_Or (char const*, char const*, char* const*){ cout << "Or" << endl;}; void process_Char (char const*){ cout << "Char" << endl;}; }; //} /* namespace re_parser */ #endif /* RE_PARSER_H_ */ ---------- Main ---------- #include "Parser.hpp" #include <string> #include <iostream> #include <fstream> using namespace re_parser; int main () { RE_Parser reg_rdr; string input_str; ifstream reg_file; reg_file.open("reg_expr.txt"); while (getline(reg_file,input_str)) { parse_info<> info = parse(input_str.c_str(), reg_rdr, space_p); if (info.full) { cout << "Parsing succeeded." << endl; } else { cout << "Parsing failed. Stopped at: " << info.stop << endl; } } } Stephen -- Stephen Torri GPG Key: http://www.cs.wustl.edu/~storri/storri.asc

2 1

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Vladimir Prus wrote: >John Torjo wrote: > >>> I really wish there were exception-throwing versions -- since that > >>> code is > >>> boring and still contains a couple of error-handling problems. > >>> However, most > >>> of the functions above are acutally from POSIX, not from standard C, > >>> so I'm > >>> not sure how much wrapped C functions would help me. > > Unless I'm mistaken, you're talking something similar to Andrei > > Alexandrescu's ENFORCE: > > http://www.cuj.com/documents/s=8250/cujcexp2106alexandr/ >Yes, you're right. However, there's one additional wish -- I'd like an >appraoch different macroses for different functions. E.g. for POSIX calls I >only encounter -1 returns and NULL returns for error reporting. So I'd like > int tty = check(open(check(ctermid(0)), O_RDRW); >to work. I guess this could be done by providing two overloads for the >'Wrong' function...., but not, the 'Enforcer' template only works for >specific type of return value :-( My errorcheck class (see other posts) has an error policy where you can change the fail test. The default is to test errorcode < 0. A current weakness is that it does not return the value passed to it on assignment, so you cannot use exactly like the above example. I have been updating it to support errno handling, but this (at present) requires something like: boost::errorcheck< ... > check; FILE * fp = ::fopen( 0, "r" ); check( fp != 0 ); // assert-like syntax ::fclose( fp ); If you are interested, I'll work on supporting constructs like your example above. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Index_set observations
by Tom Brinkman 30 Mar '04

30 Mar '04

Comments: Again, congratulations on this library. I see it, combined with the serialization library , as having the potential to eliminate the need for relational databases in c++ applications. Granted, if the development staff consists of DBAs and Java developers they would not agree to such a thing. However, if you have an application that consists of just c++ code, you could make the argument that relational databases are no longer needed. That would be a great thing, as relational datbases and sql are not c++ friendly. I spent many years writing c++ applications that were simply wrappers over relational datbases designed by DBAs. I've always thought that there had to be a better way. It would appear that you have done just that with this library. Questions: 1) When you add a record to an indexed_set, and it violates the index definition in some way, could you throw an exception, instead of simply replacing the original record? 2) Is there support for mult-key unique indicies. I read in the documenation that you can have more than one unique indice in the definition, but they are unique individually. Question: Can you combine two or more of those unique indice to create a multi-key unique indice. __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

8 7

IndexedSet Review
by David B. Held 30 Mar '04

30 Mar '04

*** What is your evaluation of the design? Overall, the design seems sound. I didn't look at every aspect of the design in my review, but the usage seems straightforward, and as the end-goal, I think it passes. It's too bad that you have to specify the type of the member when using member<>, but I don't see a way to infer it without having measurable runtime overhead. The range() member is very clever and is a good use case for Boost.Lambda, IMO. It seems to me that modify() need not have the destructive policy that it does. It appears that modify() erases the node from the index, then reinserts it into the appropriate place. However, it seems to me that modify() could first look to see if the modified node already exists, save the iterator to the correct insertion point, and then only unlink the node if the modification would be succesful. So the strategy would be like this: 1) Change the modifier function object to require a value() member that gives the new value to be used. 2) Instead of calling mod() right away, call something like lower_bound(), using mod.value(). Save the iterator if there isn't already an element there that conflicts. 3) Perform the erase as usual, and then do mod(), link2(), etc. Wow, Boost.Lambda looks like a home run, were it not for the fact that directly assigning to members through the set interface is a serious violation of encapsulation. ;) The safe mode and invariant checking are also nice features. Perhaps they could be a guideline or recommended feature for Boost libraries. One thing that I think should be added (though not affecting my vote) is ranked indexes. So just as an index might be unique or non-unique, it can be ranked or not ranked. Ranking gives an index an O(log n) ordinal search. That is, you can search for the ith item according to a certain index in O(log n) time, given an ordered index (obviously, the sequenced indexes would have an O(n) search time). This does change the structure of the nodes, and necessarily makes them bigger for ranked indexes. So it is not a trivial change. However, I am sure that it is doable and would add value to the library. *** What is your evaluation of the implementation? The implementation seems fairly clean, modulo the regular portability hacks. The coding style is tighter than I prefer (w.r.t whitespace) but doesn't affect my opinion of the code itself. It seems that some care has been taken to consider performance issues without necessarily providing the fastest implementation possible. While the use of MPL, Lambda, and Tuples makes the implementation a little fat, this is the kind of compile-time cost that I think is justified by the run-time and code expressivity benefits. Some of the lines are > 80 columns (e.g.: the copyright notice). I don't like the C-style comments, but I don't expect to be modifying the source, so it's not really an issue. I think that BOOST_NO_MEMBER_TEMPLATES should be deprecated. I don't think there's a single supported compiler in the Boost compiler configs that defines this any more. I think checking against BOOST_MSVC6_MEMBER_TEMPLATES is sufficient, but it would be nice to not even have to check against that. I do believe the parts that come from other code need to retain the original copyright. The parts that were inspired by, but not directly derived from, another implementation probably don't need a copyright notice, but should probably give a mention in the copyright, at the least as a matter of professional courtesy. *** What is your evaluation of the documentation? The documentation is very good, except that it could use some very minor editing (which does not affect the clarity or understandability of the documentation). Here is a somewhat minor nitpick. In the tutorial, the index_list is specified as so: (type of index)<[(tag)[,(key extractor)[,(comparison predicate)]]]> (type of index)<[(key extractor)[,(comparison predicate)]]> I would change it to thus: (unique | non_unique)<[(tag)[,(key extractor)[,(comparison predicate)]]]> (unique | non_unique)<[(key extractor)[,(comparison predicate)]]> It would be nice to be able to read through the documentation like a manual. Thus, next links on each page would be appropriate. On the performance page, you state that the tests were performed on a system with 260 KB "RAM memory", running W2K. I'm absolutely certain that is not correct. ;) "256 MB RAM" sounds a lot more likely. Something that I think should be added to the documentation is a concept page that lists the main concepts in IndexedSet and a concept interface a la the SGI STL reference (www.sgi.com/tech/stl) *** What is your evaluation of the potential usefulness of the library? I think the library is very useful and fills an important gap in the STL. I think it would be "complete" if it were to add ranked index support. Then it would be a total replacement of containers like VB's Collection. In particular, I think the key functors alone make it useful, let alone multiple indexes and the like. *** Did you try to use the library? With what compiler? Did you have any problems? I did try very briefly. However, I got blocked by BJam, and didn't take the time to d/l the latest Boost to fix it (assuming it does). I will try to get BJam working later, and if I succeed before the review is over, I will at least run the tests and create a few small test programs myself. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read all the documentation except for the reference section, and I spent some time looking over random parts of the code. *** Are you knowledgeable about the problem domain? Yes. I've had need for similar containers and have hand-rolled some solutions. The scope of IndexedSet is impressive without being too feature-bloated. *** Do you think the library should be accepted as a Boost library? Yes, most definitely. *** Naming issues: Here's my take on names, but should not be construed as affecting my vote for inclusion... Namespace: I think too many namespace levels are not helpful. A separate 'container' namespace seems a bit superfluous to me. There is no danger in name clashes within Boost between container libraries and other kinds of libraries that I can see, and I don't see that it provides a significant documentation benefit. I think additional namespace depth is most appropriate for collections of algorithms, where a proliferation of names is more likely to lead to name collisions. Library name: I don't think IndexedSet is so bad, but an alternative that I like is CompositeSet. Then there could be a Composite Sorted Associative Container concept which would support the notion of containers with multiple keys. Then CompositeSet would be a model of Composite Sorted Associative Container. A synonym for Sorted Associative Container could be Simple Sorted Associative Container or Trivial Sorted Associative Container. Indexes: According to the American Heritage Dictionary, Fourth Edition, as channeled by www.dictionary.com, "indexes" is preferred to "indices". Another spelling metric I like to use is Google. According to Google, "indexes" returns 5.8 million hits, while "indices" returns 5.5 million hits. So that's only a 5% difference, but it's statistically significant. ;) I personally think the preferred spelling should be used throughout the documentation, but that's more of a nitpick than a criticism. Anyway, I prefer "ordered index" to "regular index". As far as index types go, I prefer "ordered_unique" to "set_like", due to consistency. I think Ordered Index should be a concept for this library. Key extraction: Leave it in the library. nth_index_type: I don't like the word "nth", personally. I suggest either of the following naming schemes: nth_index_type -> ordinal_index index_type -> named_index | tagged_index nth_index_type -> index_byval | index_bynum index_type -> index_byname | index_bytag Generalize appropriately to the iterator types. update(): Actually, I do prefer "replace()" over "update()", because it does more accurately reflect the operation. As far as header organization goes, I would think of it this way: What are the major features and concepts of the library, and how will they be used separately or together? Organize the headers in a way that allows users to include feature sets as modules. If you have to, create dummy headers that just include sets of headers that are logically dependent so that users can activate a certain feature by including that header. Also, consider the cost of each header. It is worth the extra effort to isolate expensive headers than cheap ones. Other than that, I don't have any particular suggestions. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.581 / Virus Database: 368 - Release Date: 2/10/2004

5 6

Re: [boost] Index_set observations
by JOAQUIN LOPEZ MU?Z 29 Mar '04

29 Mar '04

----- Mensaje original ----- De: Shannon Stewman <stew(a)uchicago.edu> Fecha: Lunes, Marzo 29, 2004 10:33 pm Asunto: Re: [boost] Index_set observations > On Mon, Mar 29, 2004 at 08:14:09AM +0200, Joaqu?n M? L?pez Mu?oz > wrote: > > If the insertion violates some constraint, then it does > > not take place. insert operations return a > > pair<iterator,bool>: the bool indicates whether insertion > > succeeded or not. > > Forgive me if this has already been asked, but why don't you > return a > boost::optional<> object? > It has not been asked before. The only reason is that this is how STL containers (like std::set) do it. But this raises an interesting possibility. Maybe optional<T> can be augmented with a ctor accepting an std::pair<T,bool>. I'll post this in a separate thread. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

depreciated iterator warnings with gcc
by Chris Garrett 29 Mar '04

29 Mar '04

Hi, I have a simple collection template that uses boost::shared_ptr and std::list. I have used this with Borland Builder 5/6 for sometime now with no problems. I am moving some code that uses the template to GCC(3.2.3) and have found that this is giving me some depreciation warnings. A snip of my template(coll.h): template <class T> class Collection { private: list < shared_ptr<T> > items; list < shared_ptr<T> >::iterator iter; ... }; And the errors: coll.h:106: warning: `typename std::list<boost::shared_ptr<T>, std::allocator<boost::shared_ptr<T> > >::iterator' is implicitly a typename coll.h:106: warning: implicit typename is deprecated, please see the documentation for details coll.h:107: warning: `typename std::list<boost::shared_ptr<T>, std::allocator<boost::shared_ptr<T> > >::iterator' is implicitly a typename coll.h:107: warning: implicit typename is deprecated, please see the documentation for details Is there a different method that I need to use for GCC? Thanks, Chris

2 2

Boost.Thread and BoostBook
by Michael Glassford 29 Mar '04

29 Mar '04

The Boost.Thread documentation in the thread_dev branch in CVS appears to have been partially converted to BoostBook format. I've been hoping to build it to take a look and see what state it's in currently, then update pieces as I work on them. As a preliminary step, I've been trying to follow the instructions at http://www.boost.org/doc/html/boostbook.getting.started.html for building the Boost documentation that has already been converted to BoostBook but am getting errors. As I'm not very fluent yet with either bjam or BoostBook, I'd appreciate some help. FYI: I'm trying to use it on WinXP Pro without CygWin. I've already downloaded libxml, libxslt, and iconv libraries and made sure all of the pre-built utilities are on the system path. I've downloaded source for bjam and built it just today. The problem is that when I run "bjam --v2" I get the output at the end of this message and nothing builds. Any suggestions? Mike C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/tools\boostbook.jam:321: in construct warning: rulename $(base-target).depends expands to empty string C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:955: in object(boostbook-target-class)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/tools\boostbook.jam:325: in construct warning: rulename $(target).set-path expands to empty string C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:955: in object(boostbook-target-class)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:1060: in check-for-unused-sources from module object(boostbook-target-class)@1 warning: Unused source { src/boost.XML } in main target ./doc C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:957: in object(boostbook-target-class)(a)1.generate from module object(boostbook-target-class)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really from module object(main-target)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate from module object(main-target)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate from module object(project-target)@9 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load from module build-system C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import from module modules C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build from module C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope from module BoostBook warning: no DocBook XSL directory specified. If you have the DocBook XSL stylesheets installed, please set DOCBOOK_XSL_DIR to the stylesheet directory on either the command line (via -sDOCBOOK_XSL_DIR=...) or in a Boost.Jam configuration file. The DocBook XSL stylesheets are available here: http://docbook.sourceforge.net/ Stylesheets will be downloaded on-the-fly (very slow!) BoostBook warning: no DocBook DTD directory specified. If you have the DocBook DTD installed, please set DOCBOOK_DTD_DIR to the DTD directory on either the command line (via -sDOCBOOK_DTD_DIR=...) or in a Boost.Jam configuration file. The DocBook DTD is available here: http://www.oasis-open.org/docbook/xml/4.2/index.shtml The DTD will be downloaded on-the-fly (very slow!) ...found 3 targets...

2 6

c++ help for a boost synch lib
by Hurd, Matthew 29 Mar '04

29 Mar '04

Trying to find the neatest way to do this: template <class U > class c { template< class S = U> void f(Param p) { S::other lock(a); } U::something a; }; That is, I'm trying to work around not have function/method template defaults. Trying to find the least messy solution for a boost::synch library that can use alternative locking strategies, e.g. none, for a particular mutex, e.g. shareable. This is about the simplest I think I can come up with: template <class U > class c { void f(Param p) { f<U>(p); } template< S > void f(Param p) { S::other lock(a); } U::something a; }; and I could use the boost pp lib to get it to something like template <class U > class c { HACKEROOSKI ( U, void, f, Param, p) { S::other lock(a); } U::something a; }; but it is something almost every method I write will need so I end up with ugly macro code everywhere. Inner class with a default template and static fn's with a reference being passed in from the out doesn't seem to buy me much in the prettiness stakes. Any ideas on how best to approximate a default type for a template method? Is there a standard trick for this? Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0