- Boost - lists.boost.org

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

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

29 Mar '04

Vladimir Prus wrote: >Eljay Love-Jensen wrote: > > > Take the Standard C Library. > > Create a new namespace, "boost::xtd::" for instance. > > For every function in the Standard C Library, create an analog in the > > "boost::xtd::" namespace. > > The analog function would have the same functional behavior as the >StdCLib > > function, with the notable difference that any errors will generate an > > exception. > >Personally, I find this to be a good idea. Whenever I had to write code >like: > > int controlling_tty = open(ctermid(0), O_RDWR); > if (controlling_tty == -1) > perror("open"); > > int result = tcsetpgrp(controlling_tty, parent_group); > if (result == -1) > perror("tcsetpgrp"); > >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. A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type): class errorcheck { private: int error; public: inline operator int() { return( error ); } public: inline errorcheck & operator=( int ec ) { error = ec; if( ec < 0 ) throw( *this ); return( *this ); } inline errorcheck & operator=( const errorecheck & ec ) { error = ec.error; return( *this ); } public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); } inline errorcheck( const errorcheck & ec ): error( ec.error ) { } }; try { errorcheck ec; ec = open(ctermid(0), O_RDWR); ec = tcsetpgrp(controlling_tty, parent_group); } catch( errocheck error ) { // ... } Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 3

[Boost-bugs] [ boost-Bugs-925163 ] Compiling Boost with Python without Unicode
by SourceForge.net 29 Mar '04

29 Mar '04

Bugs item #925163, was opened at 2004-03-29 17:14 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=925163&group_i… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Gray (codeazure) Assigned to: David Abrahams (david_abrahams) Summary: Compiling Boost with Python without Unicode Initial Comment: If compiling Boost 1.31.0 against Python 2.2.3 where Python has been compiled to not include Unicode support, Boost fails to compile. The problem is caused by a function within libs/python/source/converter/builtin_converters.cpp The function encode_string_unaryfunc() needs to be preceded by #ifndef BOOST_NO_STD_WSTRING, which is currently below the function. It is also necessary to add #define BOOST_NO_STD_WSTRING to libs/config/user.hpp to compile Boost without Unicode support. I am using Python on an embedded system where Unicode is not required and support for these libraries requires considerable memory. To build Python without Unicode support, do this: ./configure --disable-unicode ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=925163&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

[program_options] nasty bug!
by Neal D. Becker 29 Mar '04

29 Mar '04

There is a bug in program_options. Now I remember, this is why I stopped using it before. It can't accept negative numbers as command line arguments! #include <boost/program_options.hpp> #include <iostream> #include <cxxabi.h> // demangle using namespace std; namespace po = boost::program_options; int main (int argc, char** argv) { double angle; std::set_terminate(__gnu_cxx::__verbose_terminate_handler); po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("angle,a", po::value (&angle)) ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help")) { cout << desc << "\n"; return 1; } cout << "angle: " << angle << '\n'; } ./Test1 -a -0.2 terminate called after throwing a `boost::program_options::invalid_command_line_syntax' what(): required parameter is missing in '-a' Aborted

2 1

Re: [boost] Indexed Set needs a name?
by JOAQUIN LOPEZ MU?Z 29 Mar '04

29 Mar '04

Hi Tom ----- Mensaje original ----- De: Tom Brinkman <reportbase(a)yahoo.com> Fecha: Domingo, Marzo 28, 2004 11:11 pm Asunto: [boost] Indexed Set needs a name? > I think that you should call the library "Nautilus". > This name is arbitrary and sufficiently different than > any other library name on boost or stl. You are > expecting too much if you want the name of the library > to represent the complete functionality of the > library. If you named the library Nautilus, you could > then name the indexed set, just a set. Everyone nows > what a "set" is. Adding "indexed" to everthing does > not help me understand what the library does. > Well, I hope we don't have to resort to an arbitrary name. IMHO those should be reserved for larger libraries, indexed_set after all is nothing but a container full-o-gadgets. Anyway, you're right that trying to find the perfect descriptive name is probably impossible, but at least some indication on what the library is about is useful (if "index" and "container" somehow appear around, you'll know the library is not about genetic algorithms, for instance.) The review will finish in a couple of days. By the last day I'll try to propose something reasonable which, if not loved by everybody, is at least a sufficiently good compromise. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1