September 2004 - Boost - lists.preview.boost.org

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

finding jscript ebnf
by Chau Johnthan 08 Sep '04

08 Sep '04

I am totally a newbie of boost lib, I am finding ebnf of jscript, and I wish I can gen c source of lexer, parser by using boost. thanks.

1 2

[serialization] BOOST_SHARED_POINTER_EXPORT and namespaces
by Jeff Flinn 08 Sep '04

08 Sep '04

The following is invalid: namespace x { class y { ... }; } BOOST_SHARED_POINTER_EXPORT( x::y ) Which requires something like: typedef x::y x_y; BOOST_SHARED_POINTER_EXPORT( x::y ) The following additional macro mimics some of the other export macros: #define BOOST_SHARED_POINTER_EXPORT_GUID(T,N) \ typedef boost::detail::sp_counted_base_impl< \ T *, \ boost::checked_deleter< T > \ > __shared_ptr_ ## N; \ BOOST_CLASS_EXPORT(__shared_ptr_ ## N) \ BOOST_CLASS_EXPORT(T) \ /**/ So this is valid: BOOST_SHARED_POINTER_EXPORT_GUID( x::y, x_y ); Thoughts on adding this. Thanks, Jeff

1 0

Different results for identical (?) regressions
by Stefan Slapeta 08 Sep '04

08 Sep '04

There are some toolsets in the regression results that are run by more than one person and which produce different results! As example the results for vc7.1 in this table: http://tinyurl.com/6zmuo Could somebody explain this? It's not easy to guess which one is the "better" test result... Stefan

4 3

Re: [boost] [serialization] request: low-level info about order of serialization
by Robert Ramey 08 Sep '04

08 Sep '04

Joaqu?n M? L?pez Mu?oz wrote: >Ummm, I guess I'm not explaining myself, let me try with an example: >consider a multi_index_container like this: >typedef multi_index_container< > int, > indexed_by< > sequenced<>, > sequenced<> > > >> bilist; >Then, when serializing such a bilist, the order maintained by indices #0 and >#1 must be recorded separately. Roughly speaking, this involves: >1. serializing the elements in the order induced by index #0. >2. traversing index #1 and serializing a record of rearrangements with >respect to index #0. >Step 2 can be accomplished in a simple manner by serializing pointers to >the (previously serialized) elements, but in the order induced by index #1. >As Boost.Serialization keeps track of previously stored objects, this will >work OK. To further exemplify this, consider a particular bilist like this: >index #0: [begin(),end) = 1 4 3 5 2 6 >index #1: [begin(),end) = 1 3 5 6 2 4 >then all the info we need to reconstruct the container can be saved as: >1 4 3 5 2 6 >&1 &3 &5 &6 &2 &4 >where & means we save a pointer to a previously serialized element. >I hope everything's clear up to this point. This looks clear to me. It seems well within the normal application of the serialization library and would seem to work as expected. Question: have you built and tested this? I think this would be a useful starting point for what follows. I will refer to this as the plain vanilla implementation. (PVI) Assuming that the above works as expected, I understand that your concern is that the sequences of pointers could be reduced to a smaller sequence. The question is what would be the best way to exploit this possibility. One way would be just keep a list when serializing index #0 and referring to it when serializing index #1. This would give you everything you need without changing anything about the serialization library. Of course, this does replicate some of the information within the serialization library. I would be extremely reluctant to make the library more elaborate to accommodate what I see as a very special case. If it were me, I would think the PVI was plenty good enough as the space for a replicated pointer is very small relative to the data as whole. The PVI also has a pleasing symmetry in that no index is "privileged" by being first and will work automatically for an arbitrary number of indexes. But that's my opinion and its your library. We have one alternative - keeping your own list of saved/loaded object addresses which can be used to streamline the process. There might be another way that would give you what you want. Rather than thinking: a) serialize data b) serialize index 0 c) serialize index 1 d)... e).serialize index n which is the way that the serialization library encourages one to think. One might consider: a) serialize data b) serialize all indexes in parallel: i) read indexes in order ii) "merge indexes" into a virtual list iii) for each unique index entry 1) serialize the list of indexes to which it applies 2) serialize the index entry itself I think this would be "sort of" equivalent to what you want to do in that replicated pointers would not be stored. This would even eliminate the need to track the addresses of the serialization of base data allowing one so designate all instances of indexed_set as not using tracking. So even the address-object id lookup inside the serialization library would be skipped. This would be maximally efficient. Personally, I'm skeptical that it would be worth the effort - but of course its up to you. One thing I would like to see is that the "Plain Vanilla Implementation" is working before something like the above is considered. Robert Ramey

1 0

Boost.Threads MinGW compiler warning patches
by Daniel Schlyder 08 Sep '04

08 Sep '04

Hello, Attached are patches to fix a few warnings I get when compiling Boost.Threads using MinGW (GCC 3.4.1): native_error-dllimport-warning.diff fixes (maybe not in a good way, but at least now you know the warning exists :)): boost/thread/exceptions.hpp:37: warning: inline function 'int boost::thread_exception::native_error() const' is declared as dllimport: attribute ignored. tss-no-newline-warning.diff fixes: boost/thread/detail/tss_hooks.hpp:78:39: warning: no newline at end of file libs\thread\build\..\src\tss.cpp:206:37: warning: no newline at end of file -- Daniel Schlyder http://bitblaze.com/

2 1