- Boost - lists.boost.org

[Review] Named Parameters library (ongoing)
by Doug Gregor 22 Nov '04

22 Nov '04

Today is the last day of the review of the Named Parameters library by David Abrahams and Daniel Wallin. Let's hear some more comments! The original announcement follows: The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

1 0

[patch] [shared_ptr] out-of-date comment
by Jonathan Wakely 22 Nov '04

22 Nov '04

The attached patch removes an old comment from shared_count.hpp that refers to initial_use_count and initial_weak_count. Those parameters were removed from the constructor a while ago. jon -- "Whenever you find that you are on the side of the majority, it is time to reform." - Mark Twain

2 1

[TYPO] MinMax Library
by Javier Estrada 22 Nov '04

22 Nov '04

Under the Motivation section, the sentence: Please note: the intent is not to fix the known defaults of std::min and std::max, but to add one more algorithms that combines both; Should read: Please note: the intent is not to fix the known defaults of std::min and std::max, but to add one more algorithm that combines both;

2 1

shared_ptr and serialization
by Robert Ramey 22 Nov '04

22 Nov '04

Would it be possible to add something like friend template<class Archive> boost::serialization::serialize(Archive &ar, T &t); to boost::shared_ptr ? This would let me remove a problematic hack in boost/serialization/shared_ptr which is creating a headache when shared_ptr serialization is used with some other headers. The same may be necessary for some other headers - e.g. weak ptr. Another alternative would be to change the private members to protected or maybe even public. I realize that this creates a dependency between boost::serialization and boost:: shared_ptr that you have hoped to avoid. But until this is resolved at another level, its would be better than the current situation. Alternatively, you might want to consider expanding the shared_ptr interface with enough information to permit serialization to be implemented via the public interface. This has worked well for the stl collections. I don't know if this was an intentional design decision or just an accident. We really need a real solution now for boost::shared_ptr / boost::serialization . Robert Ramey

9 33

[Boost-bugs] [ boost-Support Requests-1070583 ] boost_1_32_0: Cant build date_time
by SourceForge.net 21 Nov '04

21 Nov '04

Support Requests item #1070583, was opened at 2004-11-21 12:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1070583&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost_1_32_0: Cant build date_time Initial Comment: boost_1_32_0 bjam -sTOOLS="vc-7_1" --with-date_time stage ...found 447 targets... ...updating 34 targets... vc-C++ bin\boost\libs\date_time\build\boost_date_time.dll\vc- 7_1-stlport\debug\threading-multi\greg_month.obj greg_month.cpp C:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,O utputIterator>::string_type' (or there is no acceptable conversion) with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::c har_traits<wchar_t>> ] C:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (189) : see reference to function template instantiation 'bool boost::detail::lexical_stream<Target,Source>::operator >><Target>(InputStreamable &)' being compiled with [ Target=boost::date_time::date_names_put<boost::greg orian::greg_facet_config,wchar_t,std::ostreambuf_iterat or<wchar_t,std::char_traits<wchar_t>>>::string_type, Source=const char *, InputStreamable=boost::date_time::date_names_put<bo ost::gregorian::greg_facet_config,wchar_t,std::ostream buf_iterator<wchar_t,std::char_traits<wchar_t>>>::strin g_type ] C:\_Vlad_Job\boost_1_32_0 \boost\date_time\date_names_put.hpp(126) : see reference to function template instantiation 'Target boost::lexical_cast<boost::date_time::date_names_put< Config,charT,OutputIterator>::string_type,const char*> (Source)' being compiled with [ Target=boost::date_time::date_names_put<boost::greg orian::greg_facet_config,wchar_t,std::ostreambuf_iterat or<wchar_t,std::char_traits<wchar_t>>>::string_type, Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::c har_traits<wchar_t>>, Source=const char * ] C:\_Vlad_Job\boost_1_32_0 \boost\date_time\date_names_put.hpp(122) : while compiling class-template member function 'void boost::date_time::date_names_put<Config,charT,Output Iterator>::do_put_special_value (boost::date_time::date_names_put<Config,charT,Outpu tIterator>::iter_type &,boost::date_time::date_names_put<Config,charT,Outp utIterator>::special_value_enum) const' with [ ... etc Any suggestions how to fix this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1070583&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[mpl] replace_if
by Jonathan Turkanis 21 Nov '04

21 Nov '04

Hi Aleksey, The new MPL document is very nice! I believe the synopsis for replace_if (http://www.boost.org/libs/mpl/doc/refmanual/replace-if.html) is missing the third template parameter. Is that correct? Jonathan

2 3

Can I get the function signature of the result of a bind() ?
by Roland Schwarz 21 Nov '04

21 Nov '04

Sorry if my question seems somehow weird. I already posted a similar one to the users list but with no result. So I try again but also post a small example to make my question clear. The purpose of the example is to autoconnect a couple of member classes to a containing class without the need to explicitely call the constructors of the member classes: #include <boost/signal.hpp> #include <boost/any.hpp> #include <boost/bind.hpp> boost::any pinit; // todo: should be thread local in MT version template<typename Function> struct ctor_signal_push : public boost::signal<Function>{ ctor_signal_push() { pinit = this; } // todo: make it a stack }; template<typename Signature, typename Function> void ctor_connect(Function fn) { boost::any_cast<ctor_signal_push<Signature>* >(pinit)->connect(fn); // can this be done without the Signature parameter? // i.e. can the Signature be deduced from Function? (which might be a functor) } class A; class B { public: B() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class C { public: C() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class A { public: A(); ctor_signal_push<void (A*)> init; B aB; C aC; B aB1; B aB2; // ctor_signal_pop; }; A::A() { init(this); // connect all member classes } int main(int argc, char* argv[]) { A aA; return 0; } This does work well so far, but I would like to get rid of the explicit "void (A*)" parameter in ctor_connect<void (A*)>(boost::bind(init, this, _1)); Is this possible? Perhaps I am even trying to do something that I should better avoid because there is a better solution available. Does anyone know? Thank you for any hints, Roland

1 0

Re: [boost] Re: Front page redesign...
by JOAQUIN LOPEZ MU?Z 21 Nov '04

21 Nov '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Noviembre 21, 2004 4:29 pm Asunto: Re: [boost] Re: Front page redesign... [...] > I'll have some additional thoughts on content organization if I > can ever get > finished with my OOPSLA workshop writeup. We had some specific > discussionsabout content changes that need to be made... > Dou you have any idea when you'll have this done? I'm very much interested in knowing what the workshop came up with (as most of us here at the list, I guess.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: Re: Re: shared_ptr and serialization
by Dave Gomboc 21 Nov '04

21 Nov '04

> Honestly, I don't need to serialize std::tr1::shared_ptr - why would > any of us ever use it as long as we have boost::shared_ptr which (with > serialization is a superset of std::tr1::shared_ptr.) That's a completely bogus argument. > I understand your objection to boost::serialization depending upon the > implementation details of boost::shared_ptr. I just don't see any way to > address this other than making big changes to either the serialization > libary or shared_ptr. Even then, its not obvious to me that its even > possible. Doesn't Peter's own serialization library succeed in not requiring special access to boost::shared_ptr? If so, it is an existence proof that there's a way to do it, which I think means that big changes may need to be made to Boost.Serialization. It will be a reasonable expectation for a Boost.Serialization user to serialize std::tr1::shared_ptrs in the future. Has Peter described the algorithm he used? Dave

3 2

[name_params] Flag arguments?
by Rene Rivera 21 Nov '04

21 Nov '04

Dave, Daniel, I have a use case which would be nice to support. I have some functions which take some number of flag arguments, akin to: void foo(const char * name, float value, bool flag1 = false, bool flag2 = false) { std::cout << name << " = " << value << "\n"; } And I can add the named arg interface, so I can use it as: foo((value = 5.2f, name = "baz", flag1 = true)); But ideally I'd like the use to look like: foo((value = 5.2f, name = "baz", flag1)); That is, the presence of the keyword is enough to set the argument to true. Possible? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2