________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Mathias Gaunard [mathias.gaunard@ens-lyon.org] Enviado el: martes, 11 de mayo de 2010 20:35 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] metafunction question

Le 11/05/2010 19:30, John Dlugosz wrote:

...

Consider a class derived from an STL collection.

You should never do that.

Why not, why never? My opinions on this issue at: http://bannalia.blogspot.com/2008/02/derivation-without-virtual-destructor.h... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

While there are technical reasons not to do so (absence of virtual destructor), there are also non technical ones.

It simply doesn't make sense to use inheritance for this. Inheritance is for polymorphism, not code reuse.

This is why for example free functions that take any range are better than member functions.

So, you would prefer to use a generic programming model rather than member-function calling syntax? Do you write your classes to have only private virtual member functions, and declare non-member friend functions that take an instance as one of the parameters and call the virtual functions? No public members at all! If I have public member functions, and I want to extend that, it would be annoying to say "these 20 functions are members, and here is 1 more that is a non-member". TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

is your function an algorithm working WITH the container, or is it a function providing access to the container's contents? when you derive from a standard container without any additional state, it's most likely the former. for example, there is no std::vector::sort(), only std::sort(vector...) (although it seems to me the standard library doesn't draw a clear line there either. a lot of the member functions of std::string should have been free function algorithms)

And, container-specific versions of algorithms are available as member functions, rather than just automatically picking up container-specific form based on the iterator. The reason for that is because the iterators in general don't reference back to the original container. But, with overloading, should there be a container-based find as well as iterator find algorithms, as opposed to find being a member? His example is called "find", so probably is a member because the plain find functions are also members of various containers. If the std::find was an overloaded non-member, he might "naturally" write his that way too. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

On 11 May 2010 20:58, John Dlugosz wrote:

Why should he not derive from a standard collection?

Because they don't have a virtual destructor. To be more precise, you should never derive publicly from a STL collection. ps : please don't top post

the return type cannot be parametrized based on the const-ness of "this". but parametrizing _functions_ based on constness rarely makes sense anyway, the best aproach imho is to keep the overloads but let them only handle the const/non-const specific stuff and forward the rest. in your example:

private: node_ptr find_node(x) const; public: iterator find(x){ return iterator(find_node(x)); } const_iterator find(x) const{ return const_iterator(find_node(x)); }

That was exactly what I showed him. And that would work for "contained" stuff that was not contained by value. But, the find_node works using the inherited iterators, not his own mechanisms. So, the private iterator do_find(x) const finds itself limited to const_iterator in its own implementation from the getgo. I was thinking template Iter do_find(Collection& c, find_params x); and the question is, is there already a handy metafunction get_proper_iter<C> that will return C::const_iterator if C is const qualified, and C::iterator otherwise? I suppose something like mpl::if_ wrapped up as the interesting part of the metafunction. I've never tried anything like that, but I just read the first part of "C++ Template Metaprogramming" book and I see if_ used on page 63. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.