- Boost - lists.preview.boost.org

Re: [boost] Re: Empty member optimization
by JOAQUIN LOPEZ MU?Z 09 Sep '04

09 Sep '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Septiembre 9, 2004 6:44 pm Asunto: [boost] Re: Empty member optimization [...] > Second, I don't have time to look into the details of your > implementation, but I > wan't to make sure you're aware of the EBO problems Dave Held ran > into with his > policy_ptr, based on the loki SmartPtr. Basically, compilers will > apply EBO once > or twice for a given class, and that's it. The exception seems to > be recent > versions of gcc (I don't remember if its 3.3 or 3.4). > Maybe the implementation can be changed so that compressed_member can inherit from another compressed_member, so as to make this syntax feasible: template <typename T0, typename T1> struct A : private compressed_member<T0> ::and<T1, 1>::type ::and<T2, 2>::type { } or something similar, resolving to a linear hierarchy of compressed_member's. AFAICS, EBO applicability limitations would be solved that way. An sketch of copmresed_member implementation would be as follows: struct dummy{}; template <typename T, size_t Index = 0, typename Base=dummy> struct compresed_member: public Base { // utility metafunc for adding members template <typename Q, size_t AnotherIndex = Index+1> struct and { typedef compressed_member< Q, AnotherIndex, compressed_member<T, Index, Base> > type; }; // rest of the implementation } Get the idea? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Boost-bugs] [ boost-Bugs-1025124 ] boost::function doesn't accept classes declared in functions
by SourceForge.net 09 Sep '04

09 Sep '04

Bugs item #1025124, was opened at 2004-09-09 06:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: boost::function doesn't accept classes declared in functions Initial Comment: Submitter: John Engström <john.engstrom\spam\(a)\spam\solcorp.com> Using MSVC 7.1, I use a functor defined in-scope, as in the following example. ///////////////////// code snippet void bar() { ... struct my_functor { void operator () (int arg1, int arg2) { ... foo(); ... } ... }; my_functor my_functor_instance; boost::function2<void, int, int> my_function1 = boost::ref(my_functor_instance); boost::function2<void, int, int> my_function2 = my_functor_instance; } /////////////////// explanation This fails to compile, see below for error messages, however if I move the declaration of the functor out of the function bar(), it compiles fine. Perhaps it only happens with MSVC. /////////////////// error messages main.cpp(116): error C2893: Failed to specialize function template 'const boost::reference_wrapper<T> boost::ref(T &)' main.cpp(117): error C2440: 'initializing' : cannot convert from 'WinMain::my_functor' to 'boost::function2<R,T0,T1>' with [ R=void, T0=int, T1=int ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Boost Digest, Vol 844, Issue 5
by Michael Stevens 09 Sep '04

09 Sep '04

On Thursday 09 September 2004 05:42, David Abraham wrote: > If these are (supposedly) random access iterators, it's because the > ublas people aren't using iterator_facade or iterator_adaptor to > define them. I think you hit the nail on the head there! Making this change is number one on the priority list. The base classes to do this are already partially in place. Just a little work is required to change the rest of the code! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

[mpl][vacpp] remaining problems
by Joaquín Mª López Muñoz 09 Sep '04

09 Sep '04

Tests are failing due to a problem with BOOST_MPL_ASSERT_RELATION, for instance: "../libs/mpl/test/arithmetic.cpp", line 25.5: 1540-1264 (S) The template argument must be preceded by an ampersand (&). I've checked boost/mpl/assert.hpp, and seems like there is already an alternative implementation for buggy compilers driven by the macro BOOST_MPL_CFG_ASSERT_USE_RELATION_NAMES If given permission, I can commit a fix to define this for vacpp as well, and see how things work. If Markus is listening, maybe he can do a local test before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [admin] Overlapping reviews -- should this be allowed?
by Dave Gomboc 09 Sep '04

09 Sep '04

> > I wonder if enough libraries are going through the preliminary > > submission/refinement phase outlined at > > http://www.boost.org/more/submission_process.htm#Preliminary > > Many are not. The items listed there before submission for review are not that onerous. If they haven't been performed, the package should not be added to the review queue. Also, FWIW, I'm ixnay on the overlapping reviews. Dave

1 0

Re: ublas iterator problem
by Michael Stevens 09 Sep '04

09 Sep '04

Neal, > > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > Actually, I'm having trouble tracing this. AFAICT, in vector.hpp > // Array based vector class > template<class T, class A> > class vector: > ... private: > typedef typename A::const_iterator const_iterator_type; > typedef typename A::iterator iterator_type; You missed out that iterator_type a private (at least in CVS!). Later you will see some thing like: class const_iterator: public container_const_reference<vector>, public random_access_iterator_base<dense_random_access_iterator_tag, const_iterator, value_type> { public: Which does the work. The documentation is correct. Here const_iterator is a uBLAS Indexed Random Access Iterator concept which SHOULD (indirectly) supply operator[]. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Re: ublas iterator problem
by Michael Stevens 09 Sep '04

09 Sep '04

On Thursday 09 September 2004 05:42, David Abraham wrote: > If these are (supposedly) random access iterators, it's because the > ublas people aren't using iterator_facade or iterator_adaptor to > define them. I think you hit the nail on the head there! Making this change is number one on the priority list. The base classes to do this are already partially in place. Just a little work is required to change the rest of the code! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

problem compiling spirit in VC7.1
by Arkadiy Vertleyb 09 Sep '04

09 Sep '04

Hi, Somehow my post to the Spirit forum didn't pass through, so I am repeating it here. The following problem results from just including spirit.hpp from the current Boost CVS, when compiling with VC7.1: boost\spirit\utility\impl\chset\range_run.ipp(57) : warning C4003: not enough actual parameters for macro 'min' Apparently there is a conflict with an STL macro... Is it a known problem? Regards, Arkadiy

3 2

ublas iterator problem
by Neal D. Becker 09 Sep '04

09 Sep '04

#include <boost/numeric/ublas/vector.hpp> namespace ublas = boost::numeric::ublas; void F () { ublas::vector<int> u (10); int y = *u.begin(); int x = u.begin()[0]; } This code fails to compile with g++34 + current boost.cvs. Test.cc:8: error: no match for 'operator[]' in 'boost::numeric::ublas::vector<T, A>::begin() [with T = int, A = boost::numeric::ublas::unbounded_array<int, std::allocator<int> >]()[0]' u.begin() should return an iterator, and the iterator should define operator[]. Why doesn't this work?

3 2

RE: [boost] ublas iterator problem
by Stefan Seefeld 09 Sep '04

09 Sep '04

> From: Neal D. Becker [mailto:ndbecker2@verizon.net] > Sent: September 8, 2004 15:59 > u.begin() should return an iterator, and the iterator should define > operator[]. Why doesn't this work? huh ? Which iterator defines operator[] ? It may define operator+(size_type) or similar, if it allows random access, but not operator[]. If you know your container manages contiguous memory you may use '&*u.begin()' to access the raw memory, and apply your operator[] to that. Regards, Stefan

3 2