- Boost-users - lists.boost.org

boost libraries dependecies?
by Sandor 25 Apr '05

25 Apr '05

Hi, Is there a dependency tree available of boost libraries? I mean what other boost libraries are used by a specific boost library. thanks in advance, Sandor

3 2

Boost Logging Library?
by Matthias Kaeppler 25 Apr '05

25 Apr '05

Hello, on http://www.torjo.com/ is a "Boost logging library" available for download, but it doesn't exist on the official boost website. Will this library be in a future release of boost, or has someone just abused the well-known name for pushing his work? A logging library would be a very nice thing to have in boost, but before I use this one, I want to make sure it will be available publicly in the official boost packages. -- Matthias Kaeppler

4 3

Compatibility between shared_ptr and Rational RoseRT
by Dave.Ware＠seleniacomms.com 25 Apr '05

25 Apr '05

Does anyone know of a compatibility problem between the use of the Boost shared_ptr class and Rational RoseRT (real-time version of Rational Rose). We are having problems with intermittent crashes (not repeatable), and the crash dump debugger always indicates a problem while destroying objects that were held in existence by a shared_ptr - The underlying objects are of many different classes. We are never destroying the objects explicitly, but let the shared_ptr object take care of this when the last pointer to an object is deleted. When running the executable under Rational Purify, it reports many FIM errors (Freeing Invalid Memory), and all of these are again due to the deletion of objects that were owned by a shared_ptr. Any help would be very much appreciated Dave ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.

2 1

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

25 Apr '05

Sorry, I cannot. This is my corporate client. I am not allowed to change it. It is MS Outlook. Perhaps you will know some tricks. Thanks Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 25 April 2005 07:32 To: boost-users(a)lists.boost.org Subject: [Boost-users] RE: Mutexes (Was: (no subject)) Sliwa, Przemyslaw (London) wrote: > 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? Ben has already given the answer to your question. I can only mention that you use mail client or NNTP client that does not preserve threading. So, every message from you is shows as a separate thread for me, making reading very inconvenient. Can you consider using some better client? On Windows, Thunderbird is known to work. On Linux, pretty much every mailer works fine, Thunderbird and KMail being two examples. You can also use gmane.org for posting. - 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/ --------------------------------------------------------

4 3

RE: [Boost-users] Need a method to compare types of data objects atruntime
by Marcin Tustin 25 Apr '05

25 Apr '05

const type_info& type = typeid(*v); Comparable based on string representation. Part of standard. Header <typeinfo>. > -----Original Message----- > From: Stephen Torri [mailto:storri@torri.org] > Sent: 24 April 2005 19:46 > To: boost > Subject: [Boost-users] Need a method to compare types of data > objects atruntime > > 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 > > >

1 0

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