April 2004 - Boost - lists.preview.boost.org

RE: [boost] problem with global mutex object on windows
by Darryl Green 02 Apr '04

02 Apr '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld > Sent: Friday, 2 April 2004 4:59 AM > To: boost(a)lists.boost.org > Subject: [boost] problem with global mutex object on windows > > > hi there, > > we'v run into a problem with the boost_thread mutex class, > when used as a global object. > > Imagine a singleton class as > > class Singleton > { > public: > static Singleton *GetInstance(); > static void Destroy(); > private: > > struct Guard > { > ~Guard() { Singleton::Destroy();} > }; > static Singleton *instance; > static Guard guard; > static boost::mutex mutex; > }; > > where the internal access to 'instance' is serialized by means of the > mutex (inside methods GetInstance() and Destroy()). > > It is the Singleton::Guard destructor that is responsible to free > the instance (if it isn't destructed already). It, too, uses the > mutex to protect access. > > In a specific context on windows xp it happened that the mutex > variable was destructed before the guard, leading to a global 3.6.2 Objects with static storage duration .. shall be initialized in the order in which their definition appears in the translation unit. 3.6.3 ... These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization. So as long as the Singleton::Guard definition is before the definition of the mutex it should work. I assume that despite having the definitions in that order it doesn't work? Does that make it a compiler bug or am I missing something? In any case, I'm not convinced that this is sufficient to make your singleton useful. Do you know that GetInstance isn't called by the constructor of a static object? Do you know that no other threads (which might call GetInstance) are started prior to the mutex being constructed? I haven't tried to get a truly thread-safe singleton working - I remember several discussions about it here - but I'm not sure that any of them resulted in an efficient working solution? Sorry - perhaps not an altogether helpful response. Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1

Nightly CVS not using current BoostBook L&F
by Reece Dunn 02 Apr '04

02 Apr '04

A while back, Doug Gregor mentioned that the metacomm Nightly CVS did not use the new BoostBook L&F. This has since been updated, and the problem has persisted -- the Nightly CVS does not reflect the latest XSL:T. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

4 8

Virtual member functions cause exception in get_derived_class_object
by David Rostowsky 02 Apr '04

02 Apr '04

I have a couple of really simple classes: class MyBase { public: int x; virtual int foo(int new_x) { }; // our derived classes may or may not override this function. Coders choice. }; class MyDerived: public MyBase { public: int y; MyDerived() { y = 0; }; int Get(void) { return y; }; void Set(int val) { y = val; }; }; My main goal in life is to create an instance of MyDerived class in C++: MyDerived my_derived = new MyDerived(); and then pass the pointer to a Python script where the Python script can call any of the public member functions. Yes, I am careful to keep the pointer around in the C++ code while the Python script uses it. So I expose the class (this may or may not be the source of my problems, need help): BOOST_PYTHON_MODULE(test) { using namespace boost::python; class_<MyDerived>("MyDerived") .def("Get", &MyDerived::Get) .def("Set", &MyDerived::Set) ; } /* test*/ My impasse is that the virtual function seems to really give Boost hell when Im trying to pass the pointer to the class over to the python script. Heres the code snippet for that. Its the conversion thats just KILLING me. If I comment out the virtual function, everything works perfectly! I can pass the pointer over to my script, it calls the public member functions, and Im happy. HOWEVER, if I put the virtual function back in, the following line of code just EXPLODES! // It crashes and burns in make_ptr_instance.cpp, function get_derived_class_object() boost::python::object my_arg(boost::ref(my_derived)); // pass the pointer over to the script now. int rval = callPython("myTestFunc", "Test String argument from c++", my_arg); Im completely frustrated by this. I need some psychological help! Thanks in advance! Dave

4 9

RE: [boost] Re: Policy or Trait?
by Hurd, Matthew 02 Apr '04

02 Apr '04

From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > > Rob Stewart <stewart(a)sig.com> writes: > > I think your definitions are mostly on target, but I think where you > go wrong is that traits/policies has less to do with how a template > is defined than how it's used. Can a method call be part of a trait class? I don't think traits should have anything to do with enacting behaviour (they may describe it). If it is not clear and I see a method I think of it as policy-like. A collection of types and static constants and I think of it as trait-like. I think it gets confusing with the overloading of the English word policy. A policy on how to do something could be passed by value as a polymorphic object or as a simple Boolean flag for that matter... which is not the common intended meaning that MCD brought into common focus. I'll try to add something... Traits are used to get information at compile time. Policies are used to modify behaviour. Traits could be used by a client to modify behaviour which makes them feel like a policy class, but they aren't in what we normally think of as a policy. If a trait is used to direct the modification of behaviour, is it a policy from the client classes point of view I guess... which points to the terminology confusion. Policies can be chained, multiply inherited from or just be ordinary template classes with static methods, maybe such different styles should have different names... a chain aspect, a base aspect (MCD-like), a static aspect... You could then say aspects and traits could be used as policies perhaps... A policy is then something that maybe used to modify behaviour. A trait carries information for use such as for behaviour modification. An aspect extends the definition of trait to also encapsulate behaviour. An aspect and a trait may be used as a policy. Does that work? It would be nice if something new like "aspect class" or some such could be defined and used commonly to avoid the mess, but I suspect it is too late. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

7 18

Re: [boost] [BGL] least common ancestor
by Cromwell Enage 02 Apr '04

02 Apr '04

Walter Landry <wlandry(a)ucsd.edu> wrote: > Hmm. I don't know if I'm that patient. How about > _I_ convert it to C++, and then you can Boostify it? Okey-dokey! There's a subdirectory in the File Vault called "bgl_algo", you can upload it in there so I can find it easily. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

RE: [boost] Re: Policy or Trait?
by Reece Dunn 02 Apr '04

02 Apr '04

David Abrahams writes: >I think your definitions are mostly on target, but I think where you >go wrong is that traits/policies has less to do with how a template >is defined than how it's used. To me a traits class provides information to a template class that gives (possibly platform or type dependant) information. For example, the decimal point character (100.00 or 100,00?) would be in a traits class (I know this is in a locale, but this is an example). Another example would be a format string to use as a separator between items in a list, depending on whether a character, string, wide character, wide string, etc are used. A policy class provides functional, i.e. behavioural, information. Examples include string comparison, pointer validation (for smart pointers) and error handling (e.g. smart pointers and how to handle InvalidPointer - nothing, throw std::exception, assert failure, etc.). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] Policy or Trait?
by Rozental, Gennadiy 02 Apr '04

02 Apr '04

> Trait - A class template parameterized on a single type that > associates information with that type. A traits class, > therefore, provides an external, named grouping of > metainformation, behavior, or both for that type. A trait > class is never passed as a template parameter; it's name is > ubiquitous. A traits class never has state. By state you mean non-static data members, yes? > Policy - A class template passed to other templates for the > purpose of providing a named grouping of metainformation, > behavior, or both to those templates. Because it is a > template parameter, different policy classes can be used as > desired. In many cases, a policy class is used as a base class. Well, apparently there is somebody who think the same as I do. Thank you Rob, for your definitions. They seems sound and close to what I have in mind. > What do you think? I know that my definitions mean that > std::char_traits is a policy class, despite its name, and > they probably deviate from some other ad hoc definitions. > The question is whether these provide sound, distinct, and > defensible concepts that could be codified for future use at > Boost (and elsewhere). That's flaw in char_traits not in definitions above, IMO. Gennadiy.

2 1

BCP error for 1.31 on Windows
by Edward Diener 02 Apr '04

02 Apr '04

I built bjam for 1.31 and then I built bcp for 1.31 using MingW/GCC 3.3.1 using bjam version 1. I then opened a command prompt, went to the root directory of my Boost 1.31 distribution and tried: bcp --list shared_ptr I received this error message: **** exception(205): std::runtime_error: Error opening for output. ******** errors detected; see standard output for details ******** I then went to the boost subdirectory of my Boost 1.31 distribution and typed the same command as above and received: no errors detected but no other output was printed on standard out. I am just trying to get a list of any dependencies which shared_ptr has using bcp. What am I missing in this entire procedure ? It does not appear that bcp is working correctly but maybe I am missing something in how it should be working.

2 3

Re: [BGL] forced client complexity
by Vesa Karvonen 02 Apr '04

02 Apr '04

Provisional Dissonance: >What I was looking for, really, was dialog on existing design >strategies. It sounds like your issues with property maps mirror my >confusion with the library design, though. While I can fully appreciate >the desire to write generic code, it feels like BGL has pushed the >complexity of creating and enforcing coupling between the generic >graph/node/visitor/algorithm/etc onto the client. [...] A graph algorithm must be able to associate information on the elements of the graph. For instance, depth-first search needs to know whether it has already discovered a specific node or not (and more). In the graph utilities we implemented as part of a school project in Java, we basically relied on the hashCode() and equals() methods that every Java Object provides. The algorithm templates then internally use HashMaps for associating information on node and edge objects. This means that each time an algorithm needs to access some information (that the algorithm requires internally) on a node, a hash table lookup is performed. Assuming a good hash function, hash table lookups are O(1), but they are still slower than a direct array accesses, or accessing a member of a structure. The design employed by BGL makes it possible to provide faster lookups than what is possible with hash tables. The cost is, as you have noticed, tougher requirements for the client. [...] >If, instead, it is a synthesized construct for communication between a >graph and the algorithm operating over it, why should the client be >responsible for its maintenance instead of the framework? What are the >advantages of this approach? The advantage is that the client can choose how nodes are mapped to indices. The client can, in particular, provide a significantly faster mapping method. For example, the color of a node could be stored in the node itself, which would mean that accessing the color property would be a very fast O(1) operation. It could easily be an order of magnitude faster than a hash table lookup. >What are the disadvantages of simplifying things for the client? The minimal information needed by graph algorithms, assuming best asymptotic complexity guarantees are desired, is that the client provides hashing and equality comparison functions for nodes and edges. The disadvantage of requiring only hashing and equality comparison from the client is that sometimes there are significantly more efficient ways to associate information with nodes and the opportunity to take advantage of those more efficient ways is lost. It should also be possible for a graph algorithm to internally convert a graph to an isomorphic copy that allows essentially optimal accesses (it should be doable in O(V+E) time and space in most cases). However, the time and space required by the conversion would probably make such a conversion useless except for graph algorithms whose complexity is significantly higher than O(V+E). >This is the type of design issue that I intended to question with my >initial post. Does this answer your question? Regards, Vesa Karvonen _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

[ublas] Patch to triangular.hpp
by Giovanni Bajo 02 Apr '04

02 Apr '04

Hello, the attacched patch fixes a compilation problem of uBLAS with GCC 3.4. The fix looks legit to me, but I cannot assure this won't break other compilers due to bugs. Maybe you can monitor closely the regression fixes after having applied this. OK to commit to HEAD? -- Giovanni Bajo begin 666 triangular_gcc34.txt M26YD97@Z('1R:6%N9W5L87(N:'!P#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M#0I20U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O8F]O<W0O8F]O<W0O;G5M97)I M8R]U8FQA<R]T<FEA;F=U;&%R+FAP<"QV#0IR971R:65V:6YG(')E=FES:6]N M(#$N,3@-"F1I9F8@+74@+7<@+6(@+7(Q+C$X('1R:6%N9W5L87(N:'!P#0HM M+2T@=')I86YG=6QA<BYH<' ),C@@3F]V(#(P,#,@,#<Z-3@Z-3<@+3 P,# ) M,2XQ. T**RLK('1R:6%N9W5L87(N:'!P"3(@07!R(#(P,#0@,3$Z,#$Z,#(@ M+3 P,# -"D! ("TY-3@L,3 @*SDU."PQ,"! 0 T*( T*(" @("!T96UP;&%T M93QC;&%S<R!4+"!C;&%S<R!&,2P@8VQA<W,@1C(L(&-L87-S($$^#0H@(" @ M('1Y<&5N86UE('1R:6%N9W5L87)?;6%T<FEX/%0L($8Q+"!&,BP(a)03XZ.G9A M;'5E7W1Y<&4@=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!!/CHZ>F5R M;U\@/0T*+2 @(" @(" @=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!! M/CHZ=F%L=65?='EP92 H*3L-"BL@(" @(" @('1Y<&5N86UE('1R:6%N9W5L M87)?;6%T<FEX/%0L($8Q+"!&,BP(a)03XZ.G9A;'5E7W1Y<&4@*"D[#0H@(" @ M('1E;7!L871E/&-L87-S(%0L(&-L87-S($8Q+"!C;&%S<R!&,BP@8VQA<W,@ M03X-"B @(" @='EP96YA;64@=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R M+"!!/CHZ=F%L=65?='EP92!T<FEA;F=U;&%R7VUA=')I>#Q4+"!&,2P@1C(L M($$^.CIO;F5?(#T-"BT@(" @(" @('1R:6%N9W5L87)?;6%T<FEX/%0L($8Q M+"!&,BP(a)03XZ.G9A;'5E7W1Y<&4(a)*#$I.PT**R @(" @(" @='EP96YA;64@ M=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!!/CHZ=F%L=65?='EP92 H M,2D[#0H@#0H@(" @("\O(%1R:6%N9W5L87(@;6%T<FEX(&%D87!T;W(@8VQA E<W,-"B @(" @=&5M<&QA=&4\8VQA<W,@32P@8VQA<W,@1CX-"@`` ` end

1 0