- Boost-users - lists.preview.boost.org

Can't build or install
by James Buchanan 24 Oct '03

24 Oct '03

I managed to run bjam -sTOOLS=mingw, and it seemed to do something for 10 minutes or so, but that was it. I found some of the libraries, such as the Regex project's libraries in the debug and release folders in static and dynamic link form, but other libraries didn't seem to build. Where are they, and how do I install the libraries in my library directory? I'd like all libraries except the Python libraries installed. Many thanks for your help, James

1 0

Re: [OT a bit] Condition variable and const-correctness
by Weston Markham 23 Oct '03

23 Oct '03

This might actually be slightly less off topic than the previous post, because it parallels the way that I think about that condition::wait method... Anyway, I'm curious what people think about: void perverse_strcpy( const char *src, char *dest, const char *done // note const ) { while (!done) { // note we expect change *dest++ = *src++; } } The caller can do something like: src = "hello world"; dest[strlen(src)] = 1; // store a nonzero value perverse_strcpy(src, dest, dest+strlen(src)); Yes, its a kinda stupid and, well, dubious function. However, the point is that "const char *" simply means that the pointer points to a char that can only be accessed as a "const char" through that pointer. It does not imply that the referenced thing is physically const. Nor does it imply that the referenced thing is logically const. (meaning that non-const methods can still be called on an object that has a "const Foo *" pointing to it; they simply can't be called through that pointer.) Does this run counter to what people believe the semantics of "const char *" to be? Are compilers permitted to optimize out the check of "!done" based on const-ness? (IIRC, they actually may in some related examples, if "src" and "dest" are types that should not alias to "done"; but this is not the case here) Is there any undefined or implementation-defined behavior of the above code? As separate aside, I believe that "physically const" refers specifically to a property of an object, say, the string constant "x". It is the reason why: const_cast<char*>("x")[0] = 'y' ... results in undefined behavior. The const keyword _could_ be used on an interface to indicate that a method will not produce undefined behavior when invoked on an instance that is actually physically const. This is different from using the const keyword to identify methods which maintain "logical constness". The latter meaning (whatever that may be) is what I believe is used in practice. (and the language is, I believe, designed to support this other meaning) Of course, I'm not, in some cases, sure what that meaning is! I suspect, by the way, that different people may have different ideas of how the const keyword should be applied to interfaces in practice. Each person might have an internally consistent viewpoint, but there may still be several mutually incompatible views. (I'm pretty sure that there are at least a few. I hope they are not as "notoriously arbitrary" :) as naming conventions!) Lastly, just because it amuses me: C++ Shrink: How does that const Foo * make you feel? Programmer: I feel frustrated, doc! I want to change things, but I can't. I know that the other coders do things that I can't; I can see all the changes that they make! Why not me? C++ Shrink: Hmm. Interesting. Weston Markham

1 0

RE: [Boost-users] Re: Condition variable and const-correctness
by Weston Markham 22 Oct '03

22 Oct '03

Mark, (and group) I may not have explained myself clearly in my original message. Your example ThreadedQueue::bMessageAvaliable() const actually demonstrates _exactly_ why I feel that condition::wait should be const. Your method modifies something internally (a boost::mutex; I have no argument whatsoever with the view that locking a mutex changes its state). Then it does some other things that don't affect its const-ness. Then it undoes the modifications it originally made. (By unlocking the mutex) A caller of this function should not care that these things go on internally. In this sense, it is logically const. I would also add that the caller of the function does not care that the precise behavior (say, when it returns, or in other examples, the exact value that it does) of the function can depend on the actions of other threads; this is the point that I had expected resistance on.) Similarly, the condition::wait will modify a mutex (unlocking it, and yes, through a non-const Lock object). It will do some other stuff. Bookkeeping or whatever, maybe even blocking itself. No matter what it does internally, by the time it returns control to its caller, all of this has been undone. The thread is not blocked. It is not in a waiting queue. The mutex that we pointed it at has been locked again. From the caller's perspective, the only things different after the call are: 1. Time has passed. 2. Some other threads have done some things that they might not have done otherwise. What they do is their own business. I don't see how that can affect this function's const-ness. (Am I missing something _here_?) My conclusion is that condition::wait is logically const. I will certainly admit that const-ness may be in the eye of the beholder. I expect that the physically const vs. logically const is a problem with some people. However, there do seem to be other examples of functions that are const (in their signatures) in the same spirit that my intuition tells me condition::wait is. Does this elucidate my position? Weston Markham Mark Sizer wrote: The condition wait() requires a lock, which requires a mutex. The mutex state is toggled from acquired to free to acquired whilst the wait() is waiting. It's the same problem that having a lock creates on a method such as this one: ThreadedQueue::bMessageAvailable() const { { boost::mutex::scoped_lock( _mutexQueue ) return !_queue.empty(); } } The only way to make that work is to declare the _mutexQueue as "mutable". In the case above, I agree with you: In terms of logical "const-ness", these methods are (or can be) const. In terms of physical "const-ness", they are not. Solve the problem with "mutable". However, the condition case is a bit more subtle. ThreadedQueue::messageNext() const { { boost::mutex::scoped_lock lockQueue( _mutexQueue ); if ( _queueOut.empty() ) { // (the lock is released before blocking, // then re-locked before continuing) _conditionMessageReady.wait( lockQueue ); } // get a message } } Is that really const? if the _mutexQueue and _conditionMessageReady are made "mutable" we can MAKE the method const (as shown), but is it? I'd say there is a EXPLICIT state change in the object: Into the waiting state. This is a change, therefore non-const. In the bMessageAvailable() case, there is no explicit state change, you're returning the existing state of the object. There is an implicit state change required to safely do so, which we've decided to hide. The only way this can block forever is bad coding - deadlock. When using a condition.wait(), you are making 2 big state changes: Both the object and the thread involved go from a "running" state into a "blocked" state, perhaps forever if nothing notifies (which is reasonable if the event never occurrs, not a coding deadlock error). That doesn't seem "const" to me. - Mark

4 6

smart_ptr without memory allocation
by John Aughey 22 Oct '03

22 Oct '03

I have a class that implements a buffer pool that allocates block of memory, and the users "free" the memory when it is no longer needed back to the buffer pool. Future allocations simply return the front of the free list. Simple enough, and the class returns shared_array<T> objects to automatically free the memory back into the proper buffer pool. The problem is, this mechanism is used so that during real-time operation (this is a real-time system), there is absolutely no memory allocations required. However, inside shared_array, it uses detail::shared_count and inside shared_count it performs a new to create a sp_counted_base object. So for every smart pointer object that supplies a deleter, it must perform a new. My proposal would be to include another constructor to both shared_array (and probably it's corresponding smart pointer brothers) and to shared_count that looks like: shared_array(T *p, sp_counted_base *d) : px(p), pn(d) { } shared_count(sp_counted_base *d) : pi_(d) { } (I haven't implemented this yet, so the above may not be quite right) The purpose of this is to supply an sp_counted_base object to the shared_* object that does the delete functionality. This eliminates the new in the case where a sp_counted_base object can be supplied. In the case of the managed buffer pool mentioned above, the sp_counted_base object could be allocated with the corresponding buffer, and then re-used for subsequent "allocations" from the free list. This should result in no dynamic allocations to create a shared_* object with a corresponding deleter. I hope this makes sense. It should only require two new constuctors. John

2 1

Bind causing crashes with VS.Net 7.1
by Mark Loew 22 Oct '03

22 Oct '03

I am using bind heavily in my application. I noticed a problem that may/may not be a boost issue but wanted to check if anyone had any quick insights. I am using 2 and 3 paramater functions with bind over a range with the for_each operator. What I have noticed is everything is fine when the system is build in debug mode. I then rebuild in release modes with all optimizations turned on. The boost code crashes with access violations. I disabled the optimization of Whole Program Optimization and everything is fine. I believe I have noticed this with other template functions where the whole program optimization causes problems. Has anyone seen this before and do you know what causes it? Just checking if this is a known boost problem or a VC 7.1 issues. Mark Loew, MCSD, MCSE Application Development Consultant Sagestone Consulting www.sagestone.com <http://www.sagestone.com/> Grand Rapids, MI 616-954-9556 x149 Microsoft Gold Certified Partner mloew(a)sagestone.com

2 1

enable_shared_from_this and inheritance
by sashan 22 Oct '03

22 Oct '03

I'm trying to use enable_shared_from_this with my classes that have an inheritance structure and a virtual function. I'd like to get a shared pointer to the descendant class B. I've attached 2 files. One compiles but errors at runtime, the other doesn;t compile. The first method uses makes both class A and B inherit from enable_shared_from_this. The 2nd method makes only the base class A inherit from enable_shared_from_this and tries to dynamic cast to shared_ptr. -- sashan http://www.cs.auckland.ac.nz/~sgov008/ #include <iostream> #include <boost/enable_shared_from_this.hpp> using namespace std; using namespace boost; class A : public enable_shared_from_this<A> { public: A(){ cout << "A" << endl; } virtual void f() { shared_ptr<A> pA(shared_from_this());} }; class B : public A, public enable_shared_from_this { public: B() { cout << "B" << endl;} virtual void f() { shared_ptr pB(enable_shared_from_this::shared_from_this()); } }; void main() { shared_ptr<A> a(new A); a->f(); shared_ptr b(new B); b->f(); } #include <iostream> #include <boost/enable_shared_from_this.hpp> using namespace std; using namespace boost; class A : public enable_shared_from_this<A> { public: A(){ cout << "A" << endl; } virtual void f() { shared_ptr<A> pA(shared_from_this());} }; class B : public A { public: B() { cout << "B" << endl;} virtual void f() { shared_ptr<A> pA(shared_from_this()); shared_ptr pB(dynamic_pointer_cast< shared_ptr >(pA)); } }; void main() { shared_ptr<A> a(new A); a->f(); shared_ptr b(new B); b->f(); }

2 2

which variant code should I use?
by Tom 22 Oct '03

22 Oct '03

It appears that there is a new variant library (boost::variant), but that it has been delayed. Also, there is the old boost.any library. And CUJ has a simple, ref-counted one here http://www.cuj.com/documents/s=8034/cuj0010cacciola/cacciola.htm. Also, CUJ has an article about boost::dynamic_any. Which should I use? I want to use one of the boost libraries, but I would like something small - meaning it won't addmuch to the size of my executable. Most boost libraries I can't use because they are too big (due to dependencies I assume). Thanks, Tom.

2 3

code bloat?
by Marton Fabo 22 Oct '03

22 Oct '03

Hi! I have looked around in the documentation and FAQs about my question, but I don't seem to have found a satisfying answer. My problem is that the boost libraries (especially function) seem to successfully boost the code size of my C++ Builder program, too. The source written by me is around twenty-some thousands of lines, plus the VCL and stdc++ headres, the end result may be somewhere around half a million lines in summary. But after having added some boost headers (mainly function and bind) to where it's appropriate, the amount of compiled lines on a full rebuild jumped to the ten million (!) range. This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app. So, does anyone have some clues regarding why boost may cause so much bloat, and how I could reduce that? thx mortee

5 8

enable_shared_from_this
by sashan 22 Oct '03

22 Oct '03

I'm trying to use enable_shared_from_this with my classes that have an inheritance structure and a virtual function. I'd like to get a shared pointer to the descendant class B. I get a compile error when I try to dynamic cast the shared ptr of type A to a shared_ptr of type B. See the attached sample. -- sashan http://www.cs.auckland.ac.nz/~sgov008/ #include <iostream> #include <boost/enable_shared_from_this.hpp> using namespace std; using namespace boost; class A : public enable_shared_from_this<A> { public: A(){ cout << "A" << endl; } virtual void f() =0; }; class B : public A { public: B() { cout << "B" << endl;} virtual void f() { shared_ptr<A> pA(enable_shared_from_this<A>::shared_from_this()); shared_ptr pB1(dynamic_pointer_cast < shared_ptr >(pA)); } }; void main() { B b; b.f(); }

1 1

Linking STLPort 4.3 and Boost with VC7.0
by Ray 21 Oct '03

21 Oct '03

How do i get theese three things to work together nicely? I cannot find any help for this (and i know it had to be asked before). //#include <iostream> #include <boost\spirit.hpp> int main () { boost::spirit::rule<> p = *(boost::spirit::real_p); return 0; } I get linker errors if i uncomment the iostream include STL Port is built to use its own streams. Works fine in other examples not using boost. I looked through the boost user config but didnt see anything relavant to throw boost a bone that im using STL Port. Any help would greatly be appreciated! Ray Hilton

3 6