- Boost - lists.boost.org

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

03 Apr '04

> I thought I'd try an example to see what happens. > whether this is best example I dont know....whatever > Many more variants of course possible. > operator()() could be moved into multiply_traits etc > which would give user yet more control. > Perhaps that is the difference. Move all the implementation > out of the class gives the user more flexibility. But is it > the flexibility that se wants. (Sorry boost pros uses she > above, but men users, women developers, viceversa...just a > personal thing) > > First observation from below ....Obviously the application > has a great deal to do with it.! :-) Many more experiments to > do ... but ... Interesting debate. > > regards > Andy Little > > ----------- > > #include <iostream> > template< typename A , typename B > > struct multiply_traits; > > // use traits > template< typename A , typename B > > struct multiply1{ > > typedef multiply_traits<A,B> traits; > typename traits::result_type operator () > (typename traits::first_argument_type a, > typename traits::second_argument_type b) > { > return a * b; > } > > }; > //use policy > template< typename A , typename B, typename Policy> > struct multiply2{ > > typename Policy::result_type operator () > (typename Policy::first_argument_type a, > typename Policy::second_argument_type b) > { > return a * b; > } > > // or Policy ()(a,b); etc if ---> policy > > }; And give me single example where second design is preferable to first? Actually I think the best design would look like this: namespace { struct multiply_t { template< typename A , typename B > struct sig : multiply_traits<A,B> {}; template< typename A , typename B > typename sig<A,B>::result_type operator ()( typename sig<A,B>::first_argument_type a, typename sig<A,B>::second_argument_type b ) { return a * b; } } multiply; } int main() { std::cout << multiply( 10, 1.5 ) <<'\n'; MyInt i( 10 ) std::cout << multiply( i, 10 ) <<'\n'; } Gennadiy.

3 2

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

03 Apr '04

> > both for that type. A trait class is never passed as a template > > parameter; it's name is ubiquitous. > > Whoops, can't agree there. The boost type traits are passed > as template parameters all the time: > > mpl::apply_if< > is_pointer<X>, remove_pointer<X>, add_reference<X> > > What he meant, I think, is "never passed as a template parameter together with primary type" > > A traits class never has state. > > > > Policy - A class template passed to other templates for the > purpose of > > providing a named grouping of metainformation, > > I think a Policy might be a non-templated class. True. > 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. Could you please rephrase. It's a bit unclear. Gennadiy.

6 17

Re: Re: [BGL] forced client complexity
by Johnny Yune 03 Apr '04

03 Apr '04

"Cromwell Enage" <sponage(a)yahoo.com> wrote: (much snipping throughout) > > Boost.Graph seems to expose and require an > > unnecessarily large amount of complexity, > > though. > > If by "exposure" you mean lots of source code, I'll > take that complexity any day of the week and twice on > Sundays. :) Yes, I should�ve mentioned in my original post that I am unaware of another c++ graph library as powerful and flexible as BGL. It seems peerless at present. I was worried that my queries would be abrasive and am pleased to get such well-written responses. > The library does have a rather steep learning curve, > especially if you're somewhat unfamiliar with graph > theory and/or template programming. Perhaps my unrest is an extension of my naivety. We seem to be in agreement about BGL�s complexity, though. I guess the question is whether or not that complexity is absolutely necessary. > > The amount of scaffolding required > > to use BGL for even the simplest of projects > > often dwarfs the code size of a naive, > > yet functional, special-purpose implementation. > > Special-purpose implementation of a graph library? Or > the project? Special-purpose implementation of the graph related functions that would otherwise have been provided by a graph library. > Furthermore, while most STL > algorithms confine themselves to handling just those > STL container elements, most graph algorithms also > need the properties of vertices and/or edges as input. Unquestionably. > BGL delegates some of the responsibility of property > storage to the Boost Property Map Library. My confusion is as to why managing those properties are left to the client instead of the underlying container. In the case of properties that are intrinsic to the (user-defined) object being stored in the graph, I feel like they should be accessed as attributes of the object and �connected� to algorithms by generally trivial functors. What advantage is had by forcing the client to manage a property map of properties to vertices when they could instead provide a functor to reveal the same information? What about the cases where the needed properties are only relevant to the underlying graph structure and the algorithm, like indices? Wouldn�t it be more elegant to have graph container manage those properties than the client? > Having dwelt in the academic circle known as the > University of Central Florida, and thus familiar with > the theoretical uses of a graph library (plus I've > studied some game development apps on the side), I'd > like to learn more about how the Real World would want > to use BGL. I can�t speak for the �Real World� at large, but I can give you an example of the kinds of problems I would typically use a graph library for. When evaluating new programming languages (and often just for fun), I download problem sets from old top-coder and ACM programming contests. In almost every set of problems, there is at least one challenge which would benefit from a standard library graph extension. Usually, they center on things like building conversion equations from a series of ratios, walking a family tree, choosing a good path, scheduling planes, etc � the kind of stuff in an undergrad discreet math class. These problems will almost solve themselves in certain programming languages, but in C++, they require a bit more work (as you know). Doing a few of these problem sets always drives home, to me, the fact that C++ really needs standard facilities for graphs and regular expressions. > > Even knowing that ease-of-use is not a criterion > > for acceptance into boost, looking at what is > > required of the client to use the BGL always leaves > > me feeling perplexed. Is there any particular reason > > that a simplified interface is not made available? > > Again, I don't know a simple graph problem that > requires a simplified graph interface. Simplicity is rarely a requirement as such. Perhaps it is just ignorance on my part, but riddle me this: I can describe a graph in visgraph�s format in a very small number of simple statements, render it, hand it to a person and ask them to answer questions like �is there any path from A to Z?� What fundamental functionality would this kind of simplicity preclude if applied to BGL? > > Perhaps a container adapter could be packaged with > > the library allowing a compromise of functionality > > and flexibility for simplicity? > > I thought the boost::vector_as_graph class template > served that purpose. Wrap it around a > std::vector<EdgeList>, with EdgeList = > std::list<unsigned int> (or an edge list container of > your choice, so long as the value type is usable as an > index in the vector), and you should be good to go. This may be an option, although it doesn�t really seem to offer the generational leap in simplicity that I would like. Maybe I am simply needing one more layer of abstraction? Perhaps, I need something that removes the seemingly awkward distinction between the �thing you want to store in the graph� and �the attributes of the thing you want to store in the graph but are not a part of the thing and are instead part of this other thing.� Confusing, isn�t it? > > If a graphing problem is trivial, shouldn't BGL > > provide a trivial solution? Why are the simplest > > useful examples several hundred lines of code? > > The examples don't seem that big and hard to > understand. Of course, quite a few of them have > #ifdefs that I could do without since I don't use the > compilers in question, but I can live with them. For reference, this is from the Kevin Bacon example: typedef property_map < typedef adjacency_list < vecS, vecS, undirectedS, property < vertex_name_t, std::string >, property < edge_name_t, std::string > >, vertex_name_t >::type actor_name_map_t; I, personally, would find it much more natural to define an actor type with appropriate members than to manage such declerations. While my views are probably shaped by my limited understanding of the stylistic model, that is one UGLY typedef. It doesn�t really come trippingly off the tongue, does it? The amount of scaffolding required for BGL use is generally large and complex enough that I would find myself writing wrappers for the BGL so that I could use it without constant need for a reference manual. That would generally be a bad situation for me (more work), for other developers (unfamiliar framework dependency), and for end-users (greater risk of bugs via unproven code). > > I apologize for all of my vague criticisms - my > > intention is not to flame but rather to test the > > waters. > > Your criticisms seem healthy, and I hope my responses > are helpful. Thanks ever so much. I guess that all I have to worry about now is making a fool of myself. > > It is difficult for me to assess whether the > > simplicity I yearn for isn't present for stylistic > > reasons or whether it would rather necessitate a > > sacrifice of flexibility, functionality or > > implementation clarity. Nor is it clear to me to > > what extent these criteria can be compromised to > > promote clarity of client code. For what it is > > worth, the kind of ease-of-use I'm imagining might > > look like: > > #include <less_than_10_graph_headers> > ... > digraph<some_node_type,some_edge_context_type> g; > g << "vertex" << make_pair("vertex", > "implicit_vertex"); > g.add_edge("brother", "sister", "sibling"); > if(g.find(make_pair("brother", "sister"))) > related = true; > > > Could someone please elucidate on why it is > > impossible/impractical/unnecessary/whatever for a > > graph library to have such an interface? > > I believe the potential for ambiguity would hinder > this syntax the most. In this case, you'd have to > overload operator<< to input both edges and vertices, You are absolutely correct. I should�ve been more careful in presentation. Using operator<< in this case was probably a poor choice, anyway. Using add_* would�ve conveyed more information. > and what if some_node_type turned out to be std::pair? > You couldn't pass in make_pair(vertex,vertex) as an > edge then. I believe that would be ambiguous only if a vertex was somehow illegally defined to be a pair of vertices. Regardless, g.add_edge(x,x,x) is just as simple to type. > The same goes for g.find(); is it supposed > to find a vertex, an edge, or both? find would�ve been much more descriptive written as std::find(g.dfs_begin(�brother�), g.dfs_end(), �sister�) or some such. These are just ideas, of course, not proven interfaces. And my illustration wasn�t really intended so much as an example of syntax as an example of what I considered to be a �friendly� api. > Also, it seems you want to be able to use non-built-in > or custom types as vertex IDs. Actually, I would prefer to use non-built-in types as the vertex. If additional meta-data is needed for internal maintenance, then I don�t generally want to be bothered/privileged with it as a client. > You'll have to build > your own custom-type-to-vertex map and bind it to the > graph; It seems like that would be better left to the framework. > BGL won't do it for you, to retain its > genericity. It seems like adding another layer of abstraction should decrease coupling instead of adding it. I don�t really see how specifying that I want a graph of file dependencies, for example, is any less generic than saying that I want a graph of property maps where the id is a filename. Regards, prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

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