- Boost - lists.boost.org

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

Another proposal for Bimap and Boost.MultIndex
by Adrián Etchevarne 07 May '06

07 May '06

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 Thanks in advance Adrián Etchevarne.

3 5

[SOC] Applicants -- Please Monitor Google for Comments
by Jeff Garland 07 May '06

07 May '06

Hi All - First let me say that we've had a tremendous response thus far to SOC. Some really excellent applications and ideas. I have high hopes that some very exciting Boost projects will come out of SOC. The reason I'm sending this is that I'm trying to reach out to applicants that may not be aware that proposal feedback is being provided on the SOC website. Please check your proposal for comments. Many of the proposals need additional details. There is no automated email when we add comments to a proposal, so you won't be notified. Goggle is looking into adding this, but it isn't there now. There are enough comments and proposals that it would be impractical for us to ensure that everyone got notified when a comment is added. Thanks, Jeff

3 3

google SoC
by Andrew Sutton 07 May '06

07 May '06

hi all, i'm a phd student at kent state university and have been contemplating submitting a proposal for google's summer of code to do some work with the boost libraries. as a long-time user, i thought it might be a good idea to try to give something back. i wasn't really sure who to contact, so i thought i'd post this here. i had originally thought to work on a generic tree library since i wrote a generic binary tree library last semester, but since the wiki now reports about 5 proposals, i decided agaisnt it. instead, i decided that i might give a shot at working with the boost graph library since i've been using it lately for large network measures. specifically, i'm interested developing directed and undirected graph interfaces to the adjacency list class. if there's any interest, please let me know. i could write and submit a proposal sometime over the weekend. thanks, andrew sutton asutton(a)cs.kent.edu

2 1