December 2004 - Boost - lists.boost.org

logos
by David Abrahams 11 Dec '04

11 Dec '04

For a while there, we were having such fun posting proposed logo designs; there were easily 20 posts a day on the topic. I requested that the local posting stop so we could run a contest "for real," that would include the wider C++ community, and solicited a contest manager, but so far nobody has stepped forward. It would be a real shame if Boost ended up with no new logo or an inferior logo just because of that. Really, for some of you who've been very involved with the previous flurry of posts, this job shouldn't occupy much more time than you were already going to spend on it. Someone just has to: 1. write up a voting system 2. modify the wiki page to reflect recent requirements consensus 3. post an announcement 4. tally the results Rene has already established a great "head start" by setting up the Wiki page. Isn't there anyone out there who's willing to perform this valuable service to the Boost community? Don't make me start emailing individuals to prod them ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 5

[smart cont.] Const semantics in boost::ptr_map vs. std::map
by Eelis van der Weegen 11 Dec '04

11 Dec '04

Two issues: (1.) I stumbled upon a strange inconsistency in boost::ptr_map's iterator interface. I've attached some demonstration code that shows the problem. (2.) Given a (nonempty) const std::map<X, Y*> object, it is possible to retrieve a Y& from it. Given a const boost::ptr_map<X, Y> object, it is not possible (without casting) to retrieve a Y& from it. Thus, it is not possible (in general) to refactor code which uses a std::map<X, Y*> combined with manual ptr_map-like lifetime/ownership management to use a boost::ptr_map<X, Y> without changing const semantics. Was this effect intentional? If so, why was this approach chosen? It seems like ptr_map attempts to "hide" the level of indirection that a standard container of pointers has. While this may be desirable, I think it should be mentioned in the documentation since it can come as a surprise to people (like me) who actually try to perform the refactoring mentioned above. Eelis #include <map> #include <boost/smart_container/ptr_map.hpp> typedef std::map<int, int *> M; typedef boost::ptr_map<int, int> N; void f (M & m) { M::iterator i = m.begin(); M::iterator const ci = i; int & a = *(i->second); // ok int & b = *(ci->second); // ok } void g (N & n) { N::iterator i = n.begin(); N::iterator const ci = i; int & a = *i; // ok int & b = *ci; // error: invalid initialization of reference of type 'int&' from expression of type 'const int' }

2 4

auto-link, DLLS and exported constants
by Robert Ramey 11 Dec '04

11 Dec '04

I'm trying to implement auto-link and build static versions of the serialization libraries. It seems I'm making progress but I'm sort of stuck on one point right now. one my header files now contains: extern BOOST_SERIALIZATION_DECL const char * ARCHIVE_SIGNATURE; extern BOOST_SERIALIZATION_DECL unsigned int ARCHIVE_VERSION; while the corresponding implemenation file contains: /////////////////////////////////////////////////////////////////////// // constants used in archive signature //This should never ever change. note that is not an std::string // string. BOOST_SERIALIZATION_DECL const char * ARCHIVE_SIGNATURE = "serialization::archive"; // this should change if the capabilities are added to the library // such that archives can be created which can't be read by previous // versions of this library // 1 - initial version // 2 - made address tracking optional // 3 - numerous changes - can't guarentee compatibility with previous versions BOOST_SERIALIZATION_DECL unsigned int ARCHIVE_VERSION = 3; When I link an executable with the static library things work fine. When I link with the dll import library I get errors indicating undefined symbols for these const variables. What is recommended here? Robert Ramey

2 1

[Boost-bugs] [ boost-Support Requests-1083024 ] Boost Library Unknown compiler version
by SourceForge.net 10 Dec '04

10 Dec '04

Support Requests item #1083024, was opened at 2004-12-10 08:47 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=1083024&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost Library Unknown compiler version Initial Comment: I have used the Boost Library (boost_1_32_0) until this afternoon, when my system was updated. Now the c++ version 3.4.2 is installed and I'm not able to compile anymore. I tried to run ./configure script and move the user.cpp file in the config directory, but I din't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1083024&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

typeof integrated
by Arkadiy Vertleyb 10 Dec '04

10 Dec '04

Hi all, Peder and I have put together a combined version of our typeof implementations. The integrated library supports both compliant and vintage compilers, and can be found in the Boost sandbox CVS (boost/typeof, libs/typeof) or at: http://groups.yahoo.com/group/boost/files/typeof_integrated.zip As always, any comments are most welcome. Regards, Arkadiy

6 38

missing regression tests?
by John Maddock 10 Dec '04

10 Dec '04

What's happened to most of the regression tests? The Tru64, SGI, AIX etc test results have all disappeared. Thanks, John.

3 2

boost::shared_ptr<> uses mutex rather than CAS methods
by Dayton 09 Dec '04

09 Dec '04

Shared_ptr<> down deep uses a light-weight mutex to protect the increment and decrement of its reference count. A mutex isn't needed here. A mutex may yield the context of execution. This seems silly to protect a single instruction. To support threads, all modern processors offer some form of interlocked operation or atomic compare-and-swap instruction. On SPARC cpus, it is the CAS instruction, which acts much like a spin-lock. Windows offers InterlockedIncrement() and InterlocledDecrement() functions, which in the newer Microsoft compilers may be compiled as an intrinsic. I'm a bit allergic to context yielding synchronization objects thrown randomly into my server code. Does anyone know of any reasons to not use CAS-style programming here before I propose using it for smart_ptr<>? Glen

6 7

[Boost-bugs] [ boost-Support Requests-1082491 ] Linker error
by SourceForge.net 09 Dec '04

09 Dec '04

Support Requests item #1082491, was opened at 2004-12-09 13:52 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=1082491&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Linker error Initial Comment: Hi, Does anyone know why I get this linker error? fatal error LNK1104: cannot open file 'libboost_regex-vc7- sgd-1_32.lib'. I search my system for the file but no luck. I'm on Windows XP, using C++ .Net 7.0. Thanks in advance. Ken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1082491&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

RE: Re: Re: Re: typeof integrated
by Jason Shirk 09 Dec '04

09 Dec '04

> From: Arkadiy Vertleyb [mailto:vertleyb@hotmail.com] > Sent: Wednesday, December 08, 2004 1:16 PM > Subject: Re: Re: Re: Re: typeof integrated > > "Peder Holt" <peder.holt(a)gmail.com> wrote > > > Then again, the following compiles with VC7.1, so maybe there is hope > > after all :) > > Wow... > > The reason it compiles is that you are using "class" where I used > "typename". The following does not work: > > template<typename A0> > void deduce_container(*typename* std::_Tree<A0>::iterator) > { > std::cout << "map" << "\n"; > } > > I don't think this is a legal standard usage, though... Probably a > Microsoft - specific "feature"... Any comments from language experts? > Should the following work according to the Standard? > This is definitely a compiler bug, not a feature. -- Jason Shirk VC++ Compiler Team

1 0

Re: Problem with boost.iterator II
by David Abrahams 09 Dec '04

09 Dec '04

Bob Bell wrote: > Dave- > > I was looking over my "sent" items and I think something was wrong with > my return address, so I'm resending this with the right address. Sorry > for any confusion it may have caused. Bob, Please post Boost questions to one of the Boost mailing lists (unless you want to hire us for consulting services, that is!) > I've been using the boost iterator adaptor library, and first let me say > thanks; it's really a great library. You're welcome :) > Having said that, however, I'm having a problem. I'm trying to build an > iterator that uses both boost::filter_iterator and > boost::transform_iterator, but what happens is that when I combine these > two adaptors, it seems to lose the iterator category of the original > iterator. That is, say I build an iterator like this: > > boost::transform_iterator<SomeTransform, > boost::filter_iterator<SomeFilter, int*> > > > The resulting iterator only seems to be a forward iterator. My > understanding is that the iterator category of the base iterator (int*), > should become the category of the resulting composite. So my first > question is: is this a correct understanding on my part? Not according to http://www.boost.org/libs/iterator/doc/filter_iterator.html#filter-iterator… A filter iterator is never more than a forward iterator. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0