May 2006 - Boost - lists.preview.boost.org

[SoC] what do we do when we have multiple applicants for projects
by Thorsten Ottosen 08 May '06

08 May '06

Dear List and SoC interested, I have received emails from several people that would like to do my Associtive Container project. What should we try to do in that case? Should we ecourage them all to write the same library or should we try to make up similar projects? How do we decide on who gets to what if only one may do the project? Thanks -Thorsten

3 2

Re: [boost] [asio] Draft version uploaded to vault
by Christopher Kohlhoff 08 May '06

08 May '06

I have just uploaded a new draft version of Boost.Asio to the vault ("Input - Output" directory). The changes since the last draft are: - Emulation of getaddrinfo/getnameinfo has been added. This is used to provide thread safety implementations on Mac OS X (since the supplied getaddrinfo and getnameinfo are not threadsafe on this platform), and to allow code built for Windows to transparently handle the lack of IPv6 when run on Windows 2000 or earlier. - The custom memory allocation changes discussed in this thread have been made. I.e. added size parameter to asio_handler_deallocate function, moved default implementations into boost::asio namespace. - Always call the error_handler function object even if a function succeeds. This is needed to ensure that assign_error always updates the specified error object, as used in daytime1/client.cpp tutorial program. - Various bug fixes. Cheers, Chris

2 2

Re: [boost] [Logging] logger as class's member
by Silex 08 May '06

08 May '06

I'm not sure you can do (string)"A.". Try ::createlog(string("A.") + get_name()); On 5/8/06, mos <mmosquito(a)163.com> wrote: > > Hi! > I have a class A, and A have several instance, each instance I want have > a logger (not all of A share a logger), what can I do. > I had throught like this: > > class A{ > logger m_log; > const char* get_name(); //like tom,jarry... > void CreateLog() { > m_log = ::createlog((string)"A."+get_name()); > } > } > > but seems can not get there, what can I do? > Thanks in advance for your help. > mos. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

quiche receipe
by Larry Evans 08 May '06

08 May '06

Should be attached. Enjoy! Ingredients: 1 lb. Kraft mexican cheddar Jack natural finely shredded cheddar and monterrey-Jack cheese 1 lb. cottage cheese (small curd) 6 eggs 1/2 cup Bisquick Directions: Mix all the above into 9 x 13 in. floured pan or pan covered with cooking spray. Bake at 400 deg. for 15 min. Bake at 350 deg. for 40 min. or until knife comes out clean when inserted in middle of pan.

4 4

Status of BCB2006 support
by Nicola Musatti 08 May '06

08 May '06

Hallo, this is really meant for Alisdair, but I thought that others might be interested. As far as I'm concerned I believe there's not much more that I can do in the 1.34 timeframe, so I consider the remaining failures as 'expected'. Before looking into how to actually mark them as such I wanted to know if anybody is still working on Borland support for BCB2006. Cheers, Nicola Musatti

3 3

Deprecation and Boost
by AlisdairM 08 May '06

08 May '06

It has been agreed that several platforms will be deprecated in this version of Boost. To support that I have added a warning to the Borland config to alert anyone using old versions of this platform that it is being deprecated and this is the last compatible release. What I notice is the warning gets annoying pretty quickly. I propose to wrap the warning in the following test: #if __BORLANDC__ <= 0x581 && !defined(BOOST_ACKNOWLEDGE_DEPRECATED_1_34) # pragma message "..."; #endif This will allow users to disable the warning by defining the macro in their environment. I would like to extend this to a general policy, to make deprecation more visible were it occurs. Using the BOOST_ACKNOWLDGE_DEPRECATED test we could deprecate libraries or functions, as well as platforms. The test is a simple 'does this macro exist' rather than testing for a value, so should be compatible with toolchains that allow defining macros, but not giving them values. The macro is tied to the specific version that is deprecated, so in later releases we should grep for BOOST_DEPRECATED and either update the version, or do something stronger such as use #error (platform) or remove the code entirely (library) If this meets approval I will try to write up some more formal documentation for early next week, and provide something for the 1.34 release notes. For reference I believe we agreed to deprecate the following platforms in this release: borland < 5.8 [Recommend we only support 5.82] gcc 2.95 MSVC < 7.1 CW 8.3 -- AlisdairM

10 27

[Logging] logger as class's member
by mos 08 May '06

08 May '06

Hi! I have a class A, and A have several instance, each instance I want have a logger (not all of A share a logger), what can I do. I had throught like this: class A{ logger m_log; const char* get_name(); //like tom,jarry... void CreateLog() { m_log = ::createlog((string)"A."+get_name()); } } but seems can not get there, what can I do? Thanks in advance for your help. mos.

1 0

Re: [boost] [review] Fusion review
by David Abrahams 07 May '06

07 May '06

Joel de Guzman <joel(a)boost-consulting.com> writes: >> In the extension example, I see repeatedly the same patter >> transferring the cv-ref qualification from one type to another. Can't >> that be made simpler for extenders? >> >> typedef typename mpl::if_< >> is_const<Sequence>, >> std::string const&, >> std::string&>::type type; > > Can you point me to an example in the library, please? This isn't from the library code. I copied it directly from the docs at libs/fusion/doc/html/fusion/extension.html -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 9

Re: [boost] Another proposal for Bimap and Boost.MultIndex
by Adrián Etchevarne 07 May '06

07 May '06

Thorsten Ottosen wrote: > Hi Adrian, > > Jeff Garland wrote: >> Adrián Etchevarne wrote: >> >>>Hello boosters, >>> >>>I am submitting a proposal to Summer of Code of Google, and I am asking >>>for some opinions about it. >>>If you are intereste you can reach it at >>> >>>http://termovirtual.homeunix.org/~saknussemm/SoCGoogle.pdf >>>http://termovirtual.homeunix.org/~saknussemm/SoCGoogle.ps.gz >> >> >> Your URL isn't quite right -- it's missing an soc >> >> http://termovirtual.homeunix.org/~saknussemm/soc/SoCGoogle.pdf Ops! Thanks Jeff. > - if possible, prerserve the semantics of std::map<K,V>::operator[]() > and provide throwing behavior by an at() member. > It's one if the options. What would be best to do? : bimap<int, std::string> bm; bm.from[5] = "Hello"; bm.to["Hello"] = 10; // Silently ignore or throw ? cout << bm.from[10]; // If ignored, key not found. Or let the user specify what behavior he wants ? > - consider not having to/from, but to have > > find( const Key1& ); > find2nd( const Key2& ); > at( const Key& ); > at2nd( const Key& ); > ... > One of the advantages of having to/from is that you can pass them where an associative container is expected (modulo some uses with value_type in ::to) > etc. > > best regards > > -Thorsten Thanks for your comments, Adrián Etchevarne.

1 0

Re: [boost] Another proposal for Bimap and Boost.MultIndex
by Adrián Etchevarne 07 May '06

07 May '06

Jeff Garland wrote: > Thorsten Ottosen wrote: >> Jeff Garland wrote: >>> Thorsten Ottosen wrote: >> >>>> - I would srongly consider making the interface a refinement of >>>> std::map to allow drop in-replacement, and to minimize surprises for >>>> people It is one of my goals >>>> >>>> - Letting operator[]() work with Key1 and Key2 seems like a bad thing: >>>> what if the types are the same? What if the types are implicitly >>>> convertible to eachother (seems error-prone). >>> >>> It seems like a nice convenience in the case where the key and the value >>> are different. I think it would be fine if it's documented in bold >>> print in the docs. Certainly it creates is for the cut/paste programmers >>> that just try to follow an existing example with different key types and >>> then change it to be the same. >>> Noted. >> >> My concerns where also with keys that can be *implicitly* converted >> to eachother, say, int and unsigned. > > Oh yes, that's a good point. I think I'm in agreement now -- that > interface is probably just too dangerous. > It is possible that the ambiguity can be detected at compile time with metaprogramming (is_convertible, etc) and disable part of the interface. Then the user has to use bimap.to or bimap.from >> >>> 1) change name of mbimap_one_to_many --> perhaps multi_bimap_1_to_m >> >> FWIW, I think bimap and bimultimap make a good basis. This would allow >> for bimap_1_to_m and bimultimap_1_to_m > > Yep, even better. Wonder if spelling it out a bit more would be even > clearer. > > bidirectional_map_1_to_m > bidirectional_multimap_m_to_m > > seems a bit too much, while > > bidir_map_1_to_m > bidir_multimap_m_to_m > > seems about right. > > Jeff The name definitively is subject to change. Thanks for the comments, Adrián Etchevarne.

1 0