- Boost - lists.boost.org

MPL Question on crossing the compile \ runtime barrier with bind | adding to boost profiler abstracted file access
by Brian Braatz 30 Mar '05

30 Mar '05

I have been reading (ahem and re-reading) "C++ Template Metaprogramming" I have a problem I am trying to solve and was up late last night looking for the answer to jump out at me. If nothing else this helps me as I tend to re-read the same chapters over and over. Here is what I am trying to do In working on coded I am adding to the proposed Boost Profiler (started by Chris Diggings, inherited by yours truly). I am using RAII all "over" my program in the extensions I am adding to the profiler. This puts me in a spot where I have MACROs which stuff the profile points in the program. Now the problem is I would like to be able to add a template param to the TYPE of the profile points which gives it the initialization code for the STREAM it is using. The problem is since the objects themselves get created ALL OVER the program, I don't have a single point of construction (because I am using RAII to track the life cycles inside the functions themselves). I.e. I want to be able to use Boost.IOstreams or ofstream or whatever for these objects.I just need to , at the TYPE DEFINITION be able to define how to initialize this passed stream. I need to be able to do something like this Template <typename STREAMTYPE, typename INITFUNCTOR> Class MyClass { Public: STREAMTYPE outstream; MyClass() { INITFUNCTOR f(outstream); // open the file, init iostreams , or whatever } }; I can always pass in a functor, but what I really want for Christmas is to be able to Tyepdef MyClass<std::ofstream, bind(&std::ofstream::open,_1,"MyFile.txt") > MyNewClass; This doesn't work because bind returns an actual OBJECT instead of a type. (intuitively - it would be cool if I could say bind(...)::Type which would give me the TYPE of the generated functor) SO that led me to be up until 3 am reading about mpl::lambda. I am still trying to determine if THAT can be used in place, but the dots are not connecting for me yet. Any suggestions or directions pointed GREATLY appreciated. Is there a way to make this work with MPL::Lambda? Thanks Brian

2 1

[thread] condition::wait docs clarification
by Vladimir Prus 30 Mar '05

30 Mar '05

Hello, the docs for condition::wait say: blocks the current thread of execution until readied by a call to <code>this->notify_one()</code> or<code> this->notify_all()</code>, and then reacquires the lock. Shouldn't the docs also mention 'spurious wakeups', that is returns from wait without any notify_one or notify_all coll? I won't pretend to know why those wakeups can happen and on what systems, but at least is relevant to pthreads conditions. I'm asking because a colleague just read this, and though that a parent thread can launch child thread and wait for it to become ready with just condition.wait(); on parents side and condition.notify_one(); on child's side, while in fact return from condition.wait() only means that the predicate waited on must be reevaluated. - Volodya

3 2

Open watcom
by Charles Schwartz 30 Mar '05

30 Mar '05

Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation? Are there plans to test against this compiler in the future?

8 12

RE: [boost] Re: Lock free shared_ptr on gcc, help needed
by Brian Braatz 30 Mar '05

30 Mar '05

I talked to Andrei about this. It IS possible to do this as a std::allocator<> replacement, but I have been led to believe it is not a simple matter. The lock free algo (I have been studying this) is one that seems to be more tailored to specific implementation and less to a general library concept. The problem with the std containers is that they are "too power" and provide many conceptual ways to access the data. The model of how std containers work is very different from the "purposely" heavily constrained access provided with the lock free mechanism. I was thinking it might be useful to write a simple lock free container with a limited interface. With this pattern, one could do something in alignment with lock free, but I am not sure it would be palatable for people as the first thing folks would say is "Hey, that's not a std::vector<>". > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, March 30, 2005 8:08 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Lock free shared_ptr on gcc, help needed > > Robert Zeh wrote: > > Could the primitives used by the lock-free shared_ptr be made > > available from boost threads? It would be helpful for other people > > writing lock-free code. > > Probably not, and even if they are made available, it wouldn't be helpful. > You can't write correct lock-free code with primitives that have > unspecified > memory synchronization properties. Well... maybe you can, but most of us > cannot. ;-) > > (Most of us can't write correct lock-free code at all, but that's a > different story.) > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

3 4

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

1 0

[call_traits]split
by Gennadiy Rozental 30 Mar '05

30 Mar '05

Hi, Is there any plans to split call_traits? I really need only reference type trait. Shouldn't it be part of type traits lib? Is there an alternative already in there? Thanks, Gennadiy

4 7

Re: [BGL]edge connectivity code won't compile
by Vladimir Prus 30 Mar '05

30 Mar '05

> Hi, I ran into problems trying to compile the BGL example code, > edge_connectivity.cpp. (There are two codes, this is the short one with > underscore, the other is hyphen edge-connectivity.) I used VC7. I have > been running other codes without any problem. Hi, > Basically, I got two errors: > 1)C1076--I have changed from /Gm to /Zm1000, and it went way. > 2) C2039--it flagged error "reference is not a member of property map" and > points to boost/property_map.hpp in boost-1-29-0. I have no idea how to > fix this one. I think that in order for somebody to look into the problem, you should provide *exact* error messages. The property_map.hpp file is big, and guessing what line upsets VC7 is impossible. In first case, you did not even say where error occurs. BTW, could you also try with CVS version? - Volodya

1 0

RE: [boost] Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Mar '05

30 Mar '05

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: September 30, 2004 03:04 > Count me as interested. Are you going to base that parser on > OpenC++, which, > IIRC, was used by Synopsis some time ago? Last time a looked > at OpenC++, it > did not even distinguish between ordinary names and > typenames, which makes me > wonder if it's a good parser. You are right, there remains a lot of work to be done. The C++ parser backend of synopsis which we are talking about here is indeed based on OpenC++, but has already undergone lots of improvements. In its original design the parser didn't contain any form of semantic analysis such as symbol lookup to disambiguate certain expressions. For what it had been used so far it was good enough. I'm now working on the features that allow it to get closer to the standard, i.e. constant expression evaluation, symbol (type) lookup, etc. As I said, any help would be very appreciated ! Regards, Stefan

2 2

boost::tree advice?
by Dan Rosen 30 Mar '05

30 Mar '05

Hi all, Over the past few weeks I've been slowly working on (what I hope to be) a candidate for a boost::tree. I've reviewed the comments on previous submissions by Kasper Peeters (http://www.damtp.cam.ac.uk/user/kp229/tree) and Justin Gottschlich (http://nodeka.com/TreePart1.pdf) and I'm trying to put together a set of concepts to address some of the issues that were discussed here. Of the two "how to design a generic tree container" camps, I'm finding myself mostly in the one where individual nodes are not exposed to users, and the tree is an opaque structure. Also, nodes are not identical to iterators, and the iterator concept is not extended in any significant way from the standard. (Anybody who would like more detail, I'm happy to provide my draft of the concepts, but I don't want to get into that detail here -- it's not particularly relevant to my questions that follow.) I feel like I've been making decent progress so far, mostly working on paper, just documenting the concepts, and doing some coding exercises for proofs of concept. But I don't have anything I'd consider ready for primetime yet -- not even remotely -- and in fact as I progress more solidly into the coding phase, I'm finding myself getting somewhat mired in the details. So I thought I'd solicit opinions from experienced Boosters here on some of the issues I'm trying to work through. I'm primarily finding myself conflicted about what degree of flexibility the concepts and their concrete implementations need to offer. I thought it would be useful to allow clients of tree<> to be able to specify the container type for a node's children. In the code I'm currently playing with, I have a couple "selector" structs, basically identical to Boost Graph Library's vecS, listS, etc, and the tree<> class template takes one of these selectors as a template parameter. That much is all well and good, but I quickly run into trouble once I start dealing with nodes and iterators. First of all, I'd like to provide access to the children of a given node as a sequence of the type specified by the client. So if you have an iterator to an element in the tree (the structure of the tree being otherwise opaque), I want to be able to say something like: tree<foo, list_selector> t; tree<foo, list_selector>::some_kind_of_iterator i; // assume t contains something useful and i points to an element in t std::list<foo> children = t.children(i); At this point, I've got a problem: internal to the tree<>, the lists representing child sequences contain not instances of type "foo" but instances of something like node<foo>. So I can't simply provide access like this unless I can guarantee that my nodes are convertible in all contexts to their stored data. That seems like a rat hole. Another thing I'm stuck on is, even if I don't expose the container structure like this, I still have a problem with iterators. The above example omits the actual iterator type, but to get into some specifics, one type of iterator I'd like to provide is a pre-order traversal iterator. In my current code, this iterator is basically just a wrapper for iterators into the flat sequences I've been instructed to use, and some minimal code that knows how to jump between these sequences appropriately (for example: if a node has children, operator++ yields the first child of that node). It's easy to get an iterator into the sequence containing a node's children (internally, it's just something like node.children.begin()), but it's not so easy to get an iterator into the sequence containing a node's parent, unless a node contains not a pointer to its parent but an iterator instead. And that scheme breaks down for children of the root node, which is not in any sequence, as it has no siblings. I'm sure there are other options for how to implement the node structure and iterator relationships, but none jump out at me. In short, although I'd like my concepts for trees to allow users to specify and access the sequences representing the children of a node, my implementation of this is proving very clumsy. So I'm wondering two things: 1. Is this a good idea in the first place? Are there really any compelling use cases, where you'd want one tree to store its node structure in vectors and another in lists? Or is this a case where a policy-based approach is misplaced effort? 2. If this actually is a good idea (which I'm starting to get the feeling is not the case), my experience so far is that there's some significant overhead -- both in terms of the size of the structures, and in terms of speed (extra pointer traversals when doing anything with iterators). Does anybody have any brilliant ideas about how to minimize this overhead? If these questions are too vague, or lacking in context, I'm more than willing to provide the rough draft I've got of the structural concepts, and the very incomplete code (such as it is). Thanks in advance for your expert advice! dr

6 21