- Boost - lists.boost.org

Re: typeof
by Arkadiy Vertleyb 09 Sep '04

09 Sep '04

Hi Goran, > First, why there isn't a way to register wstring type, even though I've registered wchar_t? I've > managed to use it only after I've registered basic_string template with one template parameter. > Seems inpractical... There are a few choices here: 1) BOOST_TYPEOF_REGISTER_TYPE(wstring); 2) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 1); 3) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 3); BOOST_TYPEOF_REGISTER_TEMPLATE(std::char_traits, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(std::allocator, 1); Pre-registration of STL types would be a very nice addition to the library. For now I am avoiding this, and trying to focus on the facility itself. > Second problem, no matter whether I've used wstring or basic_string for registration, I wasn't able > to get a type of wstring::iterator expression! This is much more complicated problem, and I am not sure it can be resolved... The problem is that you can't specialize (or overload) on a nested types. The Standard clearly says that this is a non-deducible context. So we can't do something like: template<class V, class T> encode_type<V, T::iterator>{}; // compiler error! This is VERY unfortunate, and I 've been trying to think of workarounds, but so far I only came up with one that is quite limited and ugly... So I decided to put this on hold. Regards, Arkadiy

2 2

Test of list access through gmane -- please ignore
by Larry Meehan 09 Sep '04

09 Sep '04

Test of boost list access through gmane -- please ignore.

1 0

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