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

Re: [Boost-users] [boost.thread] destruction of condition variables
by Vladimir Pozdyaev 30 Jul '08

30 Jul '08

Howard Hinnant: > For the moment consider that all mutex and cv operations are atomic. > They can not be interrupted (as if they were a single machine > instruction). In this model your code is still not safe. You have a > race: Does the cv get destructed before cv.notify_all() is called? > The answer is that we don't know. If it does, you have undefined > behavior. You would be referencing a member of a destructed object. > > Can you construct code that will reliably test your question? Your > current code does not. If your question can not be tested, then the > answer becomes irrelevant. > > To be clear, your original code would be just as "correct" if you > commented out the cv.wait(l) in ~C(). Because of spurious wakeups, > this call to wait does not *reliably* have any effect whatsoever. It doesn't seem possible to isolate the original problem without introducing SW-related issues, so from the practical point of view your reasoning is perfectly understandable, thanks for clarification. What irks me here, is that even when there are no "bug-activating" events (read, SW), and the sequence of executed instructions does not violate the specs in any way, the program is still allowed to fail. From the practical point of view, I agree, it doesn't matter. From the logical point of view though, I can't help noticing the inconsistence, since it is exactly "executed instructions" (program behaviour for each particular run, that is, not the source code as such, however many other issues might be in there) that the specs are talking about: "being in such-and-such state, we are allowed to execute such-and-such actions". ---- Vladimir

1 0

[Boost.Fusion] Compile-time callbacks.
by Vjekoslav Brajkovic 30 Jul '08

30 Jul '08

Hi, I am somewhat new to Boost Fusion and MPI, therefore I apologize if I am asking a trivial question (I wasn't able to the answer). I have a map of <mpl::int_<N>, boost::function> pairs. Each integer is a command, and based on that command I would like call some specific function. However, after debugging through the code, I have realized that the callbacks are not compile time. So, I was wondering if anybody could tell me if there is a way of modifying my code in such a manner that there is no run-time overhead associated with map indexing. Here is an example code. ////////10////////20////////30////////40////////50////////60////////70////////80 int main(int argc, char* argv[]) { boost::function<void (int)> _int_1_; boost::function<void (std::string)> _int_2_; _int_1_ = &fun_1; _int_2_ = &fun_2; { using boost::fusion::map; using boost::mpl::int_; boost::fusion::result_of::make_map<int_<1>, int_<2>, boost::function<void (int)>, boost::function<void (std::string)> >::type fmap; boost::fusion::at_key< int_<1> >(fmap) = _int_1_; boost::fusion::at_key< int_<1> >(fmap)(5); }

3 6

Converting tuples
by Orhun Birsoy 29 Jul '08

29 Jul '08

Hi, I have a function that is templated with a tuple. I would like to convert the input tuple to a different tuple with the same size, and with related but different types. I can have any number of items in the tuple, not just two as given in the example. ie tuple<shared_ptr<Foo>, shared_ptr<Bar>> r = GetProperties<tuple<Foo, Bar>>(); The template magic that will achive this currently eludes me. How can I do this? Thanks. -- Orhun Birsoy

2 1

boost::lambda to replace a for loop
by Meryl Silverburgh 29 Jul '08

29 Jul '08

Hi, Can you please tell me if there is an easy way to replace the following for loop using boost:lambda? I have a vector of A, i want to call 'aMethod of each A, and stop it when one of them return true. for (vector<A*>::const_iterator iter = aList.begin() ; iter != aList.end(); ++iter) { A* anA = (*iter); // break out the for loop if aMethod return true; if (anA->aMethod()){ break; }

5 5

[Boost.Serialization] Deserialization of very small doubles
by Markus.Himmerich＠oppenheim.de 29 Jul '08

29 Jul '08

Hi, I am using the Serialization library version 1.33 with MSVC 2003. From the serialization of a class with an uninitialized double member "a" I got the following XML: <a>1.0198947755763149e-312</a> When I deserialize this number I get a stream_error. Is this a bug? Best regards. Markus </PRE> <meta content="text/html; charset=ISO-8859-1" Diese E-Mail und eventuell beigefügte Anhänge enthalten vertrauliche Informationen, die rechtlich besonders geschützt sein können, zum Beispiel durch das Bankgeheimnis. Diese Informationen sind ausschließlich für die als Adressaten genannten Personen bestimmt. Wenn Sie nicht der angeschriebene Empfänger sind oder diese E-Mail durch einen Übertragungsfehler erhalten haben, informieren Sie uns bitte sofort per E-Mail, Telefon oder Telefax und löschen danach die vorliegende E-Mail. Das unbefugte Kopieren dieser E-Mail, ihrer eventuell beigefügten Anhänge sowie die unbefugte Weitergabe der enthaltenen Informationen an Dritte sind nicht gestattet. Wir danken für Ihre Hilfe. This e-mail message together with its attachments, if any, is confidential and may contain information subject to legal privilege, e.g. banking secrecy. The information contained in this e-mail or its attachments is intended solely for the persons named as addressees. If you are not the intended recipient or have received this e-mail in error, please advise us immediately by e-mail, telephone or fax and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Thank you for your co-operation. <PRE>

2 1

Re: [Boost-users] dll-interface problems
by Andrej van der Zee 29 Jul '08

29 Jul '08

Yes okay, but how do you then export these methods from the base class if they appear in an external library (boost::exception in this case), without changing the external library? Cheers, Andrej ----- Original Message ---- From: gast128 <gast128(a)hotmail.com> To: boost-users(a)lists.boost.org Sent: Tuesday, 29 July, 2008 6:09:37 AM Subject: Re: [Boost-users] dll-interface problems Andrej van der Zee <mavdzee <at> yahoo.co.uk> writes: > #include <boost/exception/exception.hpp> > > namespace speedo { > > typedef boost::error_info<struct tag_error, unsigned> error_info; > > class __declspec(dllexport) exception : public boost::exception > { > }; > > } > > When I try to compile this, I get the following warning: > > c:\cygwin\home\andrej\speedo\trunk\util\exception.h(14) : warning C4275: non dll-interface class > 'boost::exception' used as base for dll-interface class 'speedo::exception' > C:\cygwin\home\Andrej\speedo\trunk\boost/exception/exception.hpp (47) : see declaration of 'boost::exception' > c:\cygwin\home\andrej\speedo\trunk\util\exception.h(13) : see declaration of 'speedo::exception' > > Is this a problem, and, how do I get rid of this without changing the boost- exception lib itself? The exported attribute indicates that all functions from the class are exported. The warning is that you can potentially call a non exported function from the base class, e.g.: struct public Base { void Foo1(); //impl. in cpp }; struct __declspec(dllexport) Derived : public Base { void Foo2(); //impl. in cpp }; void Foo() { Derived d; d.Foo1(); //error, but at least a linker error d.Foo2(); } wkr, me _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

2 1

[tokenizer] simple way to iterate over wrods in a string?
by frederic.bron＠alcan.com 29 Jul '08

29 Jul '08

I find that tokenizer is rather complicated to use when the separators in a string are not the standard whites. I am looking at something that would simply give : for (some_iterator word=word_begin(s, ";!") ; word!=word_end() ; ++word) { /* */ } I have written the following code which works well but I wonder why. My questions are : 1.) the object "tokens" created in function wbegin(...) is deleted when the function exists; is it an issue when iterating over the elements? 2.) I use default constructor of the iterator as end iterator; is it legal? This allows me not to provide 2 times the string and the list of separators. F. Bron #include <iostream> #include <string> #include <boost/tokenizer.hpp> typedef boost::tokenizer< boost::char_separator<char> >::iterator const_witerator ; const_witerator wbegin(const std::string &s, const char *separators=" \t\n\f\r\v") { boost::tokenizer< boost::char_separator<char> > tokens(s, boost::char_separator<char>(separators)) ; return tokens.begin() ; } const_witerator wend() { return const_witerator() ; } int main() { std::string s(" a; bc ;def;ghi") ; // -> [ a][ bc ][def][ghi] for (const_witerator w=wbegin(s, ";") ; w!=wend() ; ++w) { std::cout << '[' << *w << ']' ; } std::cout << '\n' ; // -> [a][bc][def][ghi] for (const_witerator w=wbegin(s, " ;") ; w!=wend() ; ++w) { std::cout << '[' << *w << ']' ; } std::cout << '\n' ; return 0 ; } Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 2

BGL undirected graph
by Line Blander Reinhardt 29 Jul '08

29 Jul '08

Hi all I have a problem with an graph which is undirected. I thought that this meant that an edge (u,v) was the same as an edge (v,u) however when I insert (u,v) into a map and later asks the map to find (v,u) then the map does not find it. s=edge(target(*oei,graph_),source(*oei,graph_),graph_).first; EMap.insert(EdgeElementPair(s,p)); Esp=NULL; s=edge(source(*oei,graph_),target(*oei,graph_),graph_).first; Esp = EMap[s]; how can this be???? My graph is: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties, EdgeProperties, GraphProperties> Graph; Thanks Line

1 0

Re: [Boost-users] [boost.thread] destruction of condition variables
by Vladimir Pozdyaev 29 Jul '08

29 Jul '08

Howard Hinnant: > On Jul 28, 2008, at 6:49 AM, Vladimir Pozdyaev wrote: > > > > Looking at, e.g., > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_init.h… > > reveals that "It shall be safe to destroy an initialized condition > > variable upon which no threads are currently blocked." Am I right in > > understanding that the wait-destroy sequence should be quite safe > > this way (provided no one else waits)? > > I believe your code as shown is subject to "spurious wakeup". If the > wait ends (spuriously) before the notify_all() completes, or is even > initiated, then the notify happens on a destructed cv. POSIX says > that in this case the pthread_cond_broadcast will return EINVAL. I believe I should apologise for this distraction. I am aware of possibility of spurious wakeups; they are one reason for the claim that the original code is not an example of good practice. The point is, spurious wakeups have nothing to do with the problem at hand, so I just opted for a more concise code sample. > The sentence you refer to means that the thread doing the notifying > can safely destroy the cv even if the waiting thread has not yet > returned from the wait (as long as that thread or any other do not try > to initiate a new wait after the final signal/broadcast). Note though This is a somewhat narrower interpretation, since the original sentence does not consider roles of threads (notifying or waiting). Is it a matter of bad wording on the part of the latter? Because I don't see in what way does my code contradict the condition "no threads are currently blocked" (on a cv). AFAICT, after the only cv.wait has finished... > that it is not safe to destruct the mutex which is being waited on, > until the waiting thread wakes from the wait (locking the mutex) and > then unlocks that mutex. ... and the only (scoped) lock on a mutex released, no threads are blocked on them, so it shouldn't be problematic to destroy both mutex and cv, should it? (The problem doesn't seem to reproduce with a trunk version of the lib, so the point may well be moot anyway, but still I'm wondering...) ---- Vladimir

2 1

[CRC] Compilation fails with #include <boost/crc.hpp>
by Norbert Riedlin 29 Jul '08

29 Jul '08

Hi all, I want to use boost CRC, but when I #include <boost/crc.hpp>, I get the following error: "error: ISO C++ forbids variable-size array 'table_type'" in line 468 of crc.hpp. gcc --version tells me, I'm using the following gcc on my Mac (OSX 10.5): "i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5484)" I use boost 1.34.1, but as crc.hpp of version 1.35 does not differ, I suppose updating the library would not help. The error is in the following context: <code> struct crc_table_t { BOOST_STATIC_CONSTANT( std::size_t, byte_combos = (1ul << CHAR_BIT) ); typedef mask_uint_t<Bits> masking_type; typedef typename masking_type::fast value_type; #if defined(__BORLANDC__) && defined(_M_IX86) && (__BORLANDC__ == 0x560) // for some reason Borland's command line compiler (version // 0x560) // chokes over this unless we do the calculation for it: typedef value_type table_type[ 0x100 ]; #else typedef value_type table_type[ byte_combos ];//<-- error here #endif static void init_table(); static table_type table_; }; // boost::detail::crc_table_t </code> I suppose it has to do with a bug of gcc, that cannot calculate "byte_combos" at compile time (or at least it acts as if it had to calculate "byte_combos" at runtime). A fix would be to enhance the "#if defined..." to the gcc versions with the said bug. I just realized there was an entry in the bug tracking system at sourceforge concerning this problem: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1478435&gro up_id=7586 but I have no permission to view the issue. The entry was made in early 2006. Is there any work on this issue? TIA Norbert P.S.: I also realize I can get around the problem by not using "-pedantic", but for me this is a valuable switch.

2 1