- Boost - lists.boost.org

potential problem with indirect_iterator (GCC 3.3.2)
by Shannon Stewman 03 Mar '04

03 Mar '04

I sent this a couple days ago, but I think it became lost in the ether when the list moved machines.... apologies if it didn't. I noticed a small potential problem with indirect_iterator. I've been using it with raw pointers, and the default constructor appears broken in this case (gcc-3.3.2): #include <boost/iterator/indirect_iterator.hpp> #include <iostream> struct MyType {}; typedef MyType* MyTypeList; typedef boost::indirect_iterator< MyTypeList, MyType > Iter; int main( int argc, char** argv ) { std::cout << "Iter() == Iter() ? " << ( Iter() == Iter() ) << std::endl << "Iter(NULL) == Iter(NULL) ? " << ( Iter(NULL) == Iter(NULL) ) << std::endl; } The output is: Iter() == Iter() ? 0 Iter(NULL) == Iter(NULL) ? 1 Is this an actual bug, or am I misusing the code? If I'm misusing the code, is there some reason for this? It's inconvenient that the default constructor doesn't initialize pointers to some consistent value; the problem goes away when I change the indirect_iterator default constructor: 94c94,96 < indirect_iterator() {} --- > indirect_iterator() > : super_t( Iterator() ) > {} Best, -- Shannon Stewman | Let us walk through the waning night, Caught in a whirlpool, | As dawn-rays tickle our toes, the dew soothes A quartering act: | Our blistered soles, and damp bones stir Solitude or society? | As crimson cracks under the blue-grey sky.

3 5

RE: [boost] Assignment Library
by Powell, Gary 02 Mar '04

02 Mar '04

After a quick look at the Assignment library, it would appear that this library would benefit from a "container traits" library that it could query for things like whether to use "insert" or "push" to call for make_insertion() rather than specify each std::stl container. It just doesn't seem to be very extensible. Rather wouldn't it be better if a user could define the traits class for your container and then the assignment would pick the right one? Yours, -Gary-

2 1

RE: [boost] [Threads] Simple active object wrapper, take 2
by scott 02 Mar '04

02 Mar '04

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt nice! only one item of feedback really. think that i follow your machinery and can envisage the "model of execution" - its pretty slick. its also somewhat different to the pattern :-| so i would wonder at the use of "active object"? is your model of execution the one that everyone is expecting of the previously, unimplemented class? this does seem to be a class/framework for (very convenient) arrangement of concurrent method execution. which piece of the ActiveObject pattern does this map to? other than the "claiming of the name", it looks like its got legs! ps: i s'pose anything declared in the private scope of "object" is thread safe? > > // test_active_object.cpp > -------------------------------------------------- > > > #include "active_object.hpp" > > using std::cin; > using std::endl; > <big snip>

3 20

minor min/max regression
by John Maddock 02 Mar '04

02 Mar '04

The recent min max changes have caused breakages with vc7.1 + STLPort, the problem is that this configuration defines BOOST_NO_STDC_NAMESPACE (because STLPort doesn't quite manage to import everything into it's "fake" std namespace), which causes the following code: template< typename T > inline T const & std_max( T const & a, T const & b ) { #if defined(__COMO__) || defined(BOOST_INTEL) || defined(BOOST_NO_STD_MIN_MAX) using std::max; #elif defined(BOOST_NO_STDC_NAMESPACE) using ::max; // <- error here #else using std::max; #endif return max BOOST_PREVENT_MACRO_SUBSTITUTION ( a, b ); } to fail, because min and max *are* in namespace std. Now the thing is, BOOST_NO_STDC_NAMESPACE was only really designed to check for C lib functions, it was assumed that std lib functions like min and max are always in namespace std, are there any situations where that is not the case? If not we can just ditch the #elif defined(BOOST_NO_STDC_NAMESPACE) clause altogether. John.

5 5

Question regarding usage of scoped_ptr and PIMPL
by Robert Ramey 02 Mar '04

02 Mar '04

The follow little example illustrates an issue I have with scoped_ptr. I would like to use this to automatically manage destruction of a pointer to and undefined class. It seems that scope_ptr is instantiating its destructor "too early" and complaining about incomplete type for b; In my view, this should not occur as ~a() isn't defined yet. The following example fails on vc 7.1 and gcc 3.2 Note that shared_ptr works as one would hope in this context. Is there anyway to adjust scoped_ptr to work here? Robert Ramey // in my opinion this should not fail to compile under any circumstances. // however it seems that that the inline destructor of scoped_ptr // requires a complete type even though the destructor is not defined. // note: changing scoped_ptr to shared_ptr works as one would hope // note:: changing to auto_ptr still fails in with the same problem #include <boost/scoped_ptr.hpp> struct b; struct a { boost::scoped_ptr<b> pimpl; ~a(); }; int main() { a a_instance; }

3 2

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > Actually the point of my remark is that would we be able to > write meta > > programs in imperative style instead of FP style > compilation would be > > much faster. > > The slowness of metaprogram compilation has almost *nothing* > to do with the FP style of metaprogramming, and almost > everything to do with the accidental nature of the > metaprogram evaluation engine (using template instantiation). And why do we have so many template to instantiate? Exactly my point: because we couldn't change type definition we could only create new one. How many helper templates gets instantiated to remove const types from the type-list? Should be none. So you are right: it has everything to do with nature of metaprogram evaluation engine, which is FP based one. > In fact, you *can* write metaprograms in an imperative > style, given an appropriate framework designed to interpret > them correctly. It'll be much slower than what we use today. You have any grounds for this statement? > > And Spirit framework would benefit from it the most. > > I doubt that. Parsing in particular has little to gain from > the use of mutable data. I meant from compilation time standpoint. Gennadiy.

2 1

FC++ -- formal review over
by Mat Marcus 02 Mar '04

02 Mar '04

The formal review period for FC++ is over. Thanks to the authors and those who submitted reviews/comments. I will now ask for your patience as I spend some time considering the discussion and preparing my decision. - Mat

1 0

Re: win32.hpp and min/max macros
by Eric Niebler 02 Mar '04

02 Mar '04

John Maddock wrote: > Would you like to make and manage the change? Remove the workarounds from > win32.hpp, and then patch all occurrences of min and max throughout boost? > > John. <recap> We agreed to make boost work in the presence of the min/max macros by wrapping all min/max function identifiers in parens, like (std::min)(a,b); </recap> I have spent some time and made the 800 or so edits throughout boost required to make it play nice with the min/max macros. I'm running regressions now. I have a couple of questions about procedure before I can commit the changes. 1) Is this a good time? I know there's talk about a 1.31.1 release. Will this be done from the 1.31.0 branch or from main? I don't want to destabilize before a release. 2) I can't test with old compilers, which are the ones most likely to have a hard time with this change. Also, I'm not a CVS guru. If all hell breaks loose as a result of this change, is there someone willing to help me back it out? 3) Is there a boost developer style guide where we can document the fact that all calls to min/max functions must be wrapped in parens? 4) This is the sort of thing developers will forget to do even if it's in a style guide. A simple way of ensuring this stays fixed would be to run the regressions with min() and max() #defined to garbage, so that violations are detected and corrected early. Is this possible? Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 37

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > I never question usefulness of function object > (any-morphic). What I > > do seek is an example of lazy list application. > > Then you should say so. "FP has no advantages" is a far cry > from "Lazy lists have no advantages". I actually "cry" "FC++ has no advantages". Take lazy list out of FC++, what we you be left with? Polymorphic function objects? I was agree from the very beginning it should be incorporated. Maybe though not as part of FC++, but boost::function and boost::functional Gennadiy.

1 0

review manager wanted
by Thorsten Ottosen 02 Mar '04

02 Mar '04

Dear all, I'm looking for a review manager for both these two libraries (and it need not be the same person): assignment library (see http://groups.yahoo.com/group/boost/files/assignment/ ) container traits (see http://groups.yahoo.com/group/boost/files/container_traits/ ) Both libraries are fairly small, so they should be fast-track reviews. My personal calendar says that I can handle one review in Marts. There is a good possibility that there could be a 'hole' in the review process during this month where one of these fast-track reviews can be put in. Anyone interested should contact me privately. best regards Thorsten

1 0