- Boost - lists.boost.org

Wave C++ Review Begins Today - February 7, 2005
by Tom Brinkman 18 Feb '05

18 Feb '05

The Wave C++ preprocessor library review begins today February 7, 2005. The library author is Hartmut Kaiser <hartmutkaiser(a)t-online.de> The review manager is Tom Brinkman <reportbase(a)yahoo.com> Download at http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip 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. The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It is not a monolitic application, it's rather a modular library, which exposes mainly a context object and an iterator interface. The context object helps to configure the actual preprocessing process (as search path's, predefined macros, etc.). The exposed iterators are generated by this context object too. Iterating over the sequence defined by the two iterators will return the preprocessed tokens, which are to be built on the fly from the given input stream. The C++ preprocessor iterator itself is fed by a C++ lexer iterator, which implements an abstract interface. The C++ lexers packaged with the Wave library may be used standalone, too, and are not tied to the C++ preprocessor iterator at all. The flexible interface exposed by the library makes it usable in a variety of applications ranging from simple lexing (tokenising) a C99/C++ input stream to complex preprocessing with fine control over the details of the macro expansion process. For instance it's very simple to inject your own #pragma handling into the preprocessing, allowing to expand it in virtually unlimited ways. The Wave C++ preprocessor library is known to be compilable on VC7.1, Intel7.1 and 8.0, gcc 3.2.x and 3.3.x. Work is currently underway to make it usable with VC6.5 as well. The library contains samples, which show different ways of it's usage. A full blown preprocessing command line oriented driver application is included in the Boost tools section as well. The review candidate version of Wave is accessible here: http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip additionally it is included in the Boost-sandbox CVS. If you're interested in what's new or changed since the last releases, please refer to the enclosed documentation or the changelog file contained inside the archive. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

15 40

A library: out-of-core containers and algorithms
by Roman Dementiev 18 Feb '05

18 Feb '05

Hello, I am developing a library called Stxxl. It is an implementation of STL for external memory (out-of-core) computations, i.e. Stxxl implements containers and algorithms that can process huge volumes of data that only fit on disks. Currently I have implemented vector, stack, and priority_queue. External memory map, list, and queue are coming soon. The containers take only specified (given) fixed amount of main memory, but can contain more elements than can fit into the main memory. The containers are compatible with STL algorithms, an example: #include <stxxl> // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::fill(HugeVector.begin(), HugeVector.end(), 0.0); STL algorithms that rely on Output, Input, Forward and Bidirectional iterators will work I/O efficiently with Stxxl containers. For the RandomAccessIterator algorithms (sortting) I have implemented specialized I/O efficient implementations: // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::generate(HugeVector.begin(), HugeVector.end(), MyRandom()); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); or another example (sort a file): stxxl::file myfile("../myfile.dat",stxxl::file::RDWR); stxxl::vector<double> HugeVector(&myfile); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); More details about the Stxxl library: http://i10www.ira.uka.de/dementiev/stxxl.shtml Would such a library be interesting for Boost users? Does it fit here? Is it worth to boostify it? I would be very glad to know your opinion. With best regards, Roman

9 22

[inspection]
by Jonathan Turkanis 17 Feb '05

17 Feb '05

Hi, A high percentage of the html documents in the iostreams library are listed by the inspection tool as unlinked. These documents are not really unlinked, however, and I am having trouble figuring out what is triggering the erroneous report. Among the documents listed as unlinked are menu.html and home.html, which are the entry points into the iostreams documentation. Any help would be appreciated. Jonathan

4 7

inherited operators
by Jason Hise 17 Feb '05

17 Feb '05

Sometimes I like to play around with obscure code, just to see what it does. The following really surprised me: #include <iostream> struct A { public: bool operator == ( const A & rhs ) { std::cout << "A\n"; return true; } }; struct B { public: bool operator == ( const B & rhs ) { std::cout << "B\n"; return false; } }; struct C : public A, public B { }; int main ( ) { C c1, c2; if ( c1 == c2 ) std::cout << "Equal\n"; return 0; } Compiled on MSVC 7.1, this outputs: A Equal I would have expected this code not to compile at all, because the == overload seems ambiguous. Is this result standards conforming? If not, what would the standards conforming result be? Does this fall into the realm of undefined behavior? -Jason

3 3

Re: [boost] Re: [indirect container] RFC on naming of libraryandclasses
by JOAQUIN LOPEZ MU?Z 17 Feb '05

17 Feb '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses [...] > | If indirection is not really the unifying theme, perhaps you > should use the > name > | Boost.ManagedContainer, which I think was suggested at some point. > | ('ManagingContainer' might be more correct, but doesn't sound good.) > > Managed container is a good name. To recap, I think these are good > condidates: > Boost. Managed Container > Boost. Managed Pointer Container > Boost. Pointer Container > Boost. Clonable Container > Boost. Clonable Pointer Container > Boost. Cloned Container > > My personal favourite would be Boost.Cloned Container > with class names like this: > > cloned_vector<T> > cloned_map<Key,T> > > When I think about it, I see cloning as the most central concept; > in fact, the > only new policy of the containers is the CloneAllocator. > IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones. As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!) So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds. To sum it up, I vote for "pointer container", "clone container" being my close-second choice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[indirect container] RFC on naming of library and classes
by Thorsten Ottosen 17 Feb '05

17 Feb '05

Dear all, I will soon start to write some more documentation for the indirect container library (formerly called the smart container library). Before I start on that I would like to get a vote on the preferred naming of 1. the library itself 2. library classes Ad 1: library name: -------------------- Boost.Indirect Cotainer was suggested by Joaquin. It sounds reasonable to me. I don't have any alternatives, but suggestions are welcome. Ad 2: library classes: --------------------- The library currently consists of the following major classes in namespace boost: ptr_array ptr_vector ptr_list ptr_deque ptr_set ptr_multiset ptr_map ptr_multimap ptr_sequence_adapter ptr_set_adapter ptr_multiset_adapter ptr_map_adapter ptr_multimap_adapter Should these names persist? Or should we go for something like indirect_array, indirect_vector etc? br -Thorsten

4 18

Re: bald singleton pointers
by Dave Handley 17 Feb '05

17 Feb '05

Jason Hise wrote: > > I would like to get general feedback on a feature that has been > requested. Some background: > > Right now, my singleton pointer classes serve a variety of purposes. In > the first place, they are the access mechanism for a singleton. Any > pointer constructed immediately points to the singleton instance (or > possibly null if the instance hasn't been created yet). If the > singleton uses instant_creation, the first pointer created creates the > singleton instance. When a member is accessed through a singleton > pointer, an intermediate pointer type performs locking, and if > lazy_creation is set it may also create the singleton instance. > Regardless of the lifetime mechanism used, when the singleton instance > gets destroyed all pointers instantly reflect this by becoming null. > > It has been suggested that I provide a mechanism to get a bald pointer > to the instance, such as an unsafe_ptr member function of either the > pointer class or the singleton itself. I feel that such a mechanism > would be very dangerous, because the bald pointer could not perform lazy > creation, it would not lock the operations, and it would not reflect > when the singleton is destroyed. > > Are there instances in which allowing bald pointers to exist is > necessary and/or useful? > The only instance that I can think of where you may want to do this is in a multi-threaded environment. And even then only in a very specific set of circumstances. Specifically, you may want to do this when you don't want the overhead of a lock, but, for some other reason, you can absolutely guarantee that concurrent access to the object (or parts of the object you are accessing) is valid. If I'm honest though, I'm having some difficulty convincing myself that something like this would actually genuinely be useful. Perhaps if you could get a "bald pointer" through a protected member, that was therefore only accessible to derived classes (hence the singletons themselves). This could be useful to build into a static access function that provided a safe pointer, but perhaps without the overhead of a lock? Personally, I would be quite reluctant to provide such a feature... Dave Handley

9 20

GMane Outage
by David Abrahams 17 Feb '05

17 Feb '05

GMane was apparently down for part of this morning, and it looks as though it may have dropped some Boost messages, such as http://lists.boost.org/MailArchives/boost/msg79129.php. If you care what you missed, you might want to go back and re-read. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Entire boost 1.32.0 source-code online
by christopher diggins 17 Feb '05

17 Feb '05

I have pretty-printed the entire source-code for boost 1.32.0 in html (along with my current version Jonathan Turkanis's BIL library) and placed it on the OOTL web site. The table of contents is at http://www.ootl.org/boost/toc.htm . The html formatted version is mirrored with the original source. For instance : http://www.ootl.org/boost/any.hpp.htm is a formatted html version while the raw text version is at http://www.ootl.org/boost/any.hpp . The formatting program used was built using the YARD parser version 2.0 beta ( http://www.ootl.org/yard/ ) which I mentioned previously on this list. The source for the formatter is at http://www.ootl.org/yard/toc.htm . Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org PS. Brian, I am still working on the next profiler release and test suite.

1 0

Dynamic Exception Handlers
by David Abrahams 17 Feb '05

17 Feb '05

Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python? http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162 Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0