April 2005 - Boost-users - lists.boost.org

RE: [Boost-users] Mutexes (Was: (no subject))
by Sliwa, Przemyslaw (London) 25 Apr '05

25 Apr '05

Volodya, Thanks for answer. Right I have forgotten to put the subject->it was stupid. But the try_mutex and scoped_tyy_lock cause that both processors are used properly. Can you explain? Thank you in advance. Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 22 April 2005 13:13 To: boost-users(a)lists.boost.org Subject: [Boost-users] Mutexes (Was: (no subject)) Hi Przemyslaw, (btw, it's better to give some subject to postings). > I have found a very strange behaviour (for me at least!) in > boost.Thread. > The same dummy code: > boost::mutex M; > > void functionA(int j) > > { > > for(int i=0; i<j; ++i) > > { > > boost::mutex::scoped_lock lock(M); And it would be good if the code was properly indented. > > sqrt(static_cast<double>(i)); > void functionB(int j) > > { > > for(int i=0; i<j; ++i) > > { > > boost::mutex::scoped_lock lock(M); ..... > If we do not lock the mutex then both processors are used on 100%. > However, in case the line is uncommented (we lock the mutex) only one > processor is used. If you lock the mutex, then only one thread can be inside loop body at the moment. Since the code outside of mutex is very small, most of the time only one thread will be running. So, it's reasonable that OS uses just one processor. - Volodya _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

3 2

Re: [Boost-users] Need a method to compare types of data objects at runtime
by kauai 25 Apr '05

25 Apr '05

I ran into a similar problem. If you read any recent C++ book the authors will tell you to limit your use of dynamic_casts (or any casts for that matter) in favor of virutal functions. I know you want your base class simple, but you can add set_pressure() as virtual in your base and have it do nothing, then just override in the class where it does something. You can also override in all sub classes and simply throw() in classes where it doesnt apply to be called. --- Stephen Torri <storri(a)torri.org> wrote: > If I have a abstract class with two classes that > implement it how can I > make a check that tests for the type of the > implementation classes? > > For example: > > class Base { > public: > virtual void run (){} > virtual void stop (){} > }; > > class Gas_Pedal : public Base { > public: > virtual void run (){} > void set_rate (unsigned int); > private: > unsigned int m_rate; > }; > > class Brake_Pedal : public Base { > public: > virtual void stop (){} > void set_pressure (unsigned int); > private: > unsigned int m_pressure; > }; > > When I have a client that receives a Base object I want > to be able to > check at run-time. So that if I am expecting a Gas_Pedal > object and I > receive something else I can perform some recovery > action. The software > I am designing contains an untold number of arrangements > of items. Each > item expect a distinctive input type. If it receives > something that it > does not know how to handle or need I want to throw an > error. > > In order to do this I would like to do something like: > > void process (Base* sobj) > { > if (! (isExpectedType(sobj)) > { > throw NotForMeException (); > } > > Brake_Pedal* bp = > dynamic_cast<Brake_Pedal>(sobj); > bp.set_pressure (50); > } > > So perhaps my design is flawed that I am running into > this situation. I > am attempting to keep the interface for the Base class > simple. The > underlying types could have different data and access > methods because > they differ so widely in what they will do. This example > was given to > keep things simple. > > Stephen > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

boost_unit_test_framework, no dynamic libraries?
by Mattias Brändström 25 Apr '05

25 Apr '05

Hello! A questions about the boost_unit_test_framework library. Is it correct that I can't build a dynamic version of that library? When I build under cygwin: bjam -sTOOLS=gcc --with-test This does not produce any dynamic version of boost_unit_test_framework. The build instructions tells me that there is no dynamic library. However, my Fedora Core 3 installation contains a file called /usr/lib/libboost_unit_test_framework.so. Can anyone tell me if I am supposed to be able to build a dynamic unit test library in cygwin. Any comments will be appricated! :.:: mattias

2 1

[optional] self-assignment and assignment of references
by Fernando Cacciola 24 Apr '05

24 Apr '05

Hi people, Recently, here: http://lists.boost.org/MailArchives/boost/msg78947.php Joe Gottman pointed out that optional<T> fails on aliasing situations like self-assignment, and proposed to forward assignment to T's assignment operator (when the lhs is initialized). In the current implementation, Optional's assignment uses a destroy + copy-construct pattern. But in the upcoming 1.33 release, it will forward the assignment to T::operator=(T const&) whenever the optional<T> is originally initialized AND when T is not a reference. This is a slight change that I doubt would cause any troubles in practice. However, that change brings up a long standing issue: assignment of optional references. You may have noticed that assignment upon optional<T&> is currently undocumented. That was on purpose. The reason is that the destroy + copy-construct pattern used in the current implementation has the effect of rebinding references upon assignment. And that is something I never felt comfortable with. That is, the current implementation works like this: int a = 1 ; int b = 2 ; int& ra = a ; int& rb = b ; ra = rb ; // [1] Changes the value of 'a' to '2' optional<T&> ora(ra); int c = 3 ; int& rc = c ; optional<T&> orc(rc); ora = orc ; // [2] Does NOT changes the value of 'a' to '3' // Instead, it rebinds 'ora' to 'c' ora = rc ; // Same as before The issue of optional<T&>'s assignment (and direct-value assignment) was initially discussed here: http://lists.boost.org/MailArchives/boost/msg53225.php And then at length here: http://lists.boost.org/MailArchives/boost/msg54871.php And a couple of weeks ago, once again here: http://lists.boost.org/MailArchives/boost/msg79670.php After reading all the discussions thoroughly and thinking over again and again, I decided that in the upcoming 1.33 release, optional<T&> will RETAIN it's current rebinding semantics. Here's a short rationale for the decision (which will be included in the updated documentation) Rationale for Boost.Optional assignment semantics: One is logically drawn to expect optional<T> to follow the behaviour of T as much as possible. The reason being that the very purpose of optional<T> is to wrap objects of type T that may or may not exist. Though different users may choose to view optional<T>'s nature in different ways, I think that it's purpose is clear and so are the things users might want to do with it. So, what do users want to do when they assign to an optional<T>? Clearly-I think- if you assign an optional B to another optional A you want the postcondition of equivalence, that is: T a = <whatever> ; T b = <whatever> ; optional<T> oa(a) ; optional<T> ob(b) ; oa = ob ; assert(oa==ob); So far so good. But if T there is a reference, what actually involves the expected postcondition of equivalence? Let see: int a = 1 ; int b = 2 ; int& ra = a ; int& rb = b ; ra = rb ; // ra IS NOT rebound to b b = 3 ; assert(rb==3); assert(ra!=3); Then, given: optional<int&> ora(ra) ; optional<int&> orb(rb) ; ora = orb ; // what shall happen here? Following the logical expectation of requiring optional<T> to follow T as much as possible, one would expect: ora = orb ; to change the value of the referee (a) to that of 'b' But there is a catch: As the song goes, optional<T> can follow T down but not that far. :-) The reason is that assignment must operate on optional<T> itself, so it must be well defined in the case it is uninitialized, and there it just can't follow T's behaviour. If 'ora' is uninitialized, 'ora = orb' can ONLY rebind the wrapped reference to 'b' if you expect any kind of equivalence to be the postcondition of the assignment. It clearly can't just ignore the assignment cause there is no referee to change its value. AFAICS, there is no doubt about what shall assignment upon an uninitialized optional<T> do: INITIALIZE the wrapped object as a copy of the object wrapped by the optional<T> rvalue. If the wrapped object is a reference, then assignment upon an uninitialized optional cannot (IMO) do anything but rebind the reference. A choice optional<T>'s assigment operator has is what to do when it is already initialized. It can, for example, CHANGE the wrapped value forwarding the assignment to T::operator=() Alone by itself, this is a reasonable choice, but... If in your code you actually need assignment to an optional<T&> reference no to rebind, then you just can't use optional<T&> assignment directly unless you can precondition that the lvalue will always be already initialized. Yet in that case, you don't really need to use optional<T&>'s assignmet. You can use the actual reference assignment directly through the access operator, as in: *opt = newvalue ; If you're using optional<T>'s assigment is because it might be the case that the lvalue is uninitialized. In fact, the very purpose of the assignment operator is to allow a user not only to change the wrapped value but to initialize it if there is none. Optional<T>'s assignment could initialize the wrapped object when the lvalue is unitialized, and change it's value (forwarding to T::operator=) otherwise. In the case of non-reference values, the difference between copy-initialization and assignment is likely to be sufficiently insignificant as to prevent any problems arising from this duality. But in the case of reference values, that difference translates into rebinding or not. That is, if optional<T&> where to forward to T&::operator=() when the lvalue is already initialized (which is the only scenario where it can do that), the following would ocurr: int a = 1 ; int& ra = a ; optional<int&> ora = ra ; int b = 2 ; int& rb = b ; optional<int&> orb = rb ; ora = orb ; // Suppose this just changed the value // of 'a' to '2' as if it were 'ra=rb' ora = none ; // 'ora' is unitialized now ora = orb ; // 'ora' CAN ONLY rebind to 'b' now. As you can see, there is no way to consistently prevent optional<T&> assignment for rebinding. If you are writting generic code and rebinding references are not a choice (as it most likely is) then I'm sorry but you just can't use optional<T&> assignment no matter what the semantics are in the already initialized case. Furthermore, if you can't rebind references upon assignment, it is highly possible that you won't ever assign to an uninitialized optional reference (because how would you do it anyway?); so most likely, you can use *opt=newvalue safely. In C++, assignment to a reference doesn't rebind, but no lvalue reference can ever be uninitialized. The possibly-uninitialized extended state brought up by optional<T&> requires a change of rules so it can offer a _consistent_ semantic. In the most recent discussion about this, Brock Peabody suggested that I could make optional<T&> entirely non-assignable. After much thinking, I don't think that's neccesary. As I've shown above, generic code just can't rely on optional<T&> assignment whether it keeps its current rebinding semantics or not. As in the case of Spirit, the matter must be handled explicitely, so I don't think rebinding semantics would really cause code to be subtletly and silently (as far as the coder is aware) incorrect. Concluding: In the upcoming 1.33 release, optional<T> assignment will have the following semantic: If the lvalue optional<> is uninitialized: Copy-initializes the wrapped object as a copy of the object wrapped by the rvalue optional<>. If a reference is being wrapped, that copy-initialization implies binding (for the first time in this case) to the referee. If the lvalue optional<> is already initialized: If the wrapped object is not of reference type, assigns to the wrapped object the value of the object wrapped by the rvalue optional via forwarding to the wrapped operator=() If the wrapped object is of reference type, copy-initializes the wrapped reference rebinding it to the referee wrapped by the rvalue optional reference. Finally, Notice that all the rationale above referred to optional<T>::operator=( optional<T> const& ) The "direct-value" assignment operator currently available in optional<> as a convenience: optional<T>::operator=( T const& ) will keep the current semantic of being equivalent to the other, that is: opt = val ; is the same as: opt = optional<T>(val) Also, note that currently references are rebinding, so there is no change there. The change is that for non-reference types assignment will forward to T::operator=() when possibe. All this digression will be properly included in the documetation. Best Fernando Cacciola

2 3

hash_table iterator problems
by Martin Wartens 24 Apr '05

24 Apr '05

Hi, I have got some problems with the unordered containers from the sandbox files. The problem is that iterator_base<T> can't be converted into iterator or const_iterator. I helped myself by adding "friend class const_iterator; friend class iterator;" to iterator_base and adding a constructor like "const_iterator (iterator_base_type i)" to const_iterator/iterator. I have no clue if this is could be an official solution. See sample code below to expose the problem. Bye, Martin typedef boost::unordered_set<int> MySet; { MySet myset; MySet::const_iterator citer = myset.begin(); MySet::iterator iter = myset.begin(); MySet::const_iterator citer2= ++citer; //doesn't work, but should (?) MySet::iterator iter2 = ++citer; //doesn't work, and should not work (?) MySet::iterator iter3 = ++iter; //doesn't work, but should (?) MySet::const_iterator citer3 = iter; //works, you can't do that //with std::containers (?) }

2 3

Fix location STL/boost containers?
by Bo Peng 23 Apr '05

23 Apr '05

Dear list, I need direct access ( save and use element pointers) to container elements in my application. std::vector<obj> can not be used since vector::push_back etc may relocate objs. std::list<obj> seems to be working but I could not find any guarantee that an element will not be moved around because of operations on other elements. Is there a std or boost container that fits my need? Many thanks in advance. Bo

5 7

RE: [Boost-users] Re: A Simple Problem: File Transfer...
by Sliwa, Przemyslaw (London) 23 Apr '05

23 Apr '05

Ace is good, but it is huuuuuuuuuuuuuuuuugeeeeeeeeeeeeee -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Sarvex Jatasra Sent: 19 April 2005 09:57 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Re: A Simple Problem: File Transfer... What i feel is ACE is a good library for network programming in C++ http://www.cs.wustl.edu/~schmidt/ACE.html With Regards Sarvex Jatasra Software Engineer +91-9891989156 +91-9350933295 _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

RE: [Boost-users] Re: A Simple Problem: File Transfer...
by Sliwa, Przemyslaw (London) 23 Apr '05

23 Apr '05

Here you are: http://www.huihoo.org/ace_tao/ACE-5.2+TAO-1.2/ACE_wrappers/docs/tutorial s/001/page01.html -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Hossein Haeri Sent: 22 April 2005 09:39 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Re: A Simple Problem: File Transfer... Caleb, > > Yes, you're right. As I told in another posting to > the > > list, I need sth "freely downloadible". Sorry for > not > > being specific enough... > > ACE is entirely free. There are books and support > you can pay for, > but all the code is totally open source. I see that I still haven't been specific enough. Sorry! What I was (and am) asking for is a free tutorial. I already know that the code is freely downloadble. Thanks, --Hossein Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

a question about incremental_component and disjoint_sets.
by Vivid Yang 22 Apr '05

22 Apr '05

Hi, I have a question about incremental_component and disjoint_sets. Here is the context: I have a class object initialized with an empty boost::graph. The algorithm incrementally builds the graph with the function add_vertex(graph). At the same time, I have to maintain the connected components of the graph. Here is the question: I know incremental_component.hpp can deal with the case edges are being added. Could it deal with the case that vertices are being added? Especially at the beginning, the graph is empty. And it seems I cannot declare an empty disjoint_sets variable in the class: classe X { ...... protected: //.... some graph typedef std::vector<graph_vertex_size_type> rank; std::vector<graph_vertex_descriptor> parent; disjoint_sets<Rank, Parent> ds; ...... }; Here is the compiler error: error C2248: 'disjoint_sets<unsigned int *,void * *,struct boost::find_with_full_path_compression>::disjoint_sets<unsigned int *,void * *,struct boost::find_with_full_path_compression> ' : cannot access private member declared in class 'boost::disjoint_sets<unsigned int *,void * *,struct boost::find_with_full_path_compression>' e:\temp\boost\boost_1_32_0\boost\pending\disjoint_sets.hpp(68) : see declaration of 'disjoint_sets<unsigned int *,void * *,struct boost::find_with_full_path_compression>::disjoint_sets<unsigned int *,void * *,struct boost::find_with_full_pat h_compression>' Could anybody help? Thanks a lot. Vivid

2 1

test library: run a single test
by Daniel van der Zee 22 Apr '05

22 Apr '05

I am using the unit testing framework with the BOOST_AUTO_UNIT_TEST macros. While debugging, is there a way to run a single test instead of running them all everytime? This is probably a FAQ, but I couldn't find it. Thanks, Daniel

7 16