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

Something strange with multi_array view iterator
by Neal Becker 25 Sep '06

25 Sep '06

The following test shows something strange. In the first test, a 1-dim view of a 1-dim array is created. Then the view iterators are used. In the second test, a 2-dim view of a 2-dim array is created. It seems the iterator in this case is not an iterator at all. Is this broken, or do I misunderstand something? -------------- #include <boost/multi_array.hpp> #include <algorithm> int main () { using boost::multi_array_types::index_range; typedef boost::multi_array<double,1> m1_t; m1_t m1; typedef m1_t::array_view<1>::type view1_t; view1_t v1 = m1[boost::indices[index_range()]]; std::fill (v1.begin(), v1.end(), 0); << This is fine typedef boost::multi_array<double,2> m2_t; m2_t m2; typedef m2_t::array_view<2>::type view2_t; view2_t v2 = m2[boost::indices[index_range()][index_range()]]; std::fill (v2.begin(), v2.end(), 0); << This is not } ----------------- There are lots of error messages, here is one: error: request for member ‘begin’ in ‘other’, which is of non-class type ‘const int’

2 1

[OpenBSD] Incorrect std::numeric_limits?
by Daniel James 25 Sep '06

25 Sep '06

Hello, From the test results at: http://tinyurl.com/ezs3o It appears that std::numeric_limits<long double> might be defined incorrectly on OpenBSD on x86 (for example, the 1 + epsilon != 1 test is failing for long double). Is there someone with access to this operating system who can look into this? On FreeBSD long doubles are defined as having the same accuracy as doubles, so maybe that's the case for OpenBSD as well? Another possibility is that OpenBSD doesn't have floating point functions defined for long doubles - but that wouldn't explain why the epsilon test is failing. thanks, Daniel

3 3

[fusion] separate tags
by David Abrahams 25 Sep '06

25 Sep '06

Is there a good reason there's a separate tag hierarchy for iterators and sequences? Seems a bit redundant, as a random access sequence is surely just a sequence with random access iterators (?) -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[integer] cstdint test failing
by larsbj＠gullik.net 25 Sep '06

25 Sep '06

I have a test failing on gcc 4.1.1 with glibc 2.4. This test from cstdint_test.cpp fails: integral_constant_type_check(boost::uint8_t(0), UINT8_C(0)); http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… At least some discussions I found seems to say that UINT8_C cannot be used to deduce types because of some integer promotion issues and that UINT8_C should return int. The UINT8_C macro has been changed from returning c ## u, to returning just c, between version 2.3.5 and 2.4 of glibc. http://comments.gmane.org/gmane.os.cygwin.patches/3101 Is the test wrong or is the C standard library in error? -- Lgb

2 3

Re: [boost] Windows and apache stdcxx
by Duft Markus 25 Sep '06

25 Sep '06

Hey! The thing is, that the stdcxx reall should behave as if it was part of the compiler, since it's integrated into my wgcc program, so nobody should have to do anything special to use it (no need to define or include anything, it just replaces the MS libc++) The thing is, that i allready got really far with a little patching ;o) the only thing is, that date_time wouldn't build, because of some weird errors in lexical_cast.hpp where some operators are not found. This has to do with not useing /Zc:wchar_t. I don't understand why this breaks compilation, but i didn't want to compile stdcxx with Zc:wchar_t. Since we have an automated build system it would be a great deal of work to change the wchar_t behaviour in all builds. But at the moment i disabled stdcxx, because it didn't work out that good, so we're now waiting for things to get better ;o) Cheers, Markus -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Sunday, September 24, 2006 4:09 PM To: boost(a)lists.boost.org Subject: Re: [boost] Windows and apache stdcxx John Maddock wrote: > Boris Gubenko wrote: >> Jeff Garland wrote: >>> As I understand it, Apache stdcxx is derived from the Rogue Wave >>> standard library. This library was used by the Solaris and perhaps >>> some other compiler vendors. >> HP is one those vendors: HP-UX, Tru64 and VMS all use RW library. > > Right, the RW lib should be reasonably well supported by Boost.Config > "as is", I think the issue was how to build with the Apache lib when > it's *not* the one that comes with your compiler, which I suspect is a bit trickier. Agree, and I'm sure it's also evolving....so shouldn't we have a new config setup for it that starts from current RW config? Of course to get this right we really need someone to setup at least one test machine... Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Any interests in a template library for distributed message passing and event dispatching?
by Yigong Liu 25 Sep '06

25 Sep '06

Hello All, Is there any interests in libraries for distributed message passing and event dispatching? There are many aspects involved in the design of these systems, such as choosing proper message/event id types, routing/dispatching algorithms, synchronization strategies for routing data structures and remote connection transport, etc.. Various application domains present different requirements for performance and functionalities (in embedded systems, integers or sub-int (bit-fields) are used as ids and routing is based on registration table, while in the e-commerce applications, class/structs with key attributes can be used as ids to facilitate more advanced routings). I am working on a C++ template library for generic publish/subscribe called Channel. Channel's major components (message IDs, routing algorithms...) are configurable as template parameters. As a namespace shared by peer threads, channels support publish/subscribe scope control, message filtering, and translation. Channel is used the same way as we use STL containers; by instantiating Channel template with proper id type, id trait and routing algorithms, user can create customized message passing and event dispatching facility for a particular application. More documentations and code can be found at : http://channel.sourceforge.net Right now Channel is built on top of ACE (adaptive communication environment) to gain platform independence. Besides classes related to socket connections and message marshaling, most channel classes are quite platform independent. I am refactoring the code and move the platform dependent code into a few policy classes. I would like to know is there any interests in boost for such frameworks. If so, I'll be glad to present a boostified version of the framework for a review process and use existing boost classes for platform abstractions. Thanks Yigong

6 11

Re: [boost] Geometry/Vector Lib
by brangdon＠cix.compulink.co.uk 25 Sep '06

25 Sep '06

In-Reply-To: <20060922201042.GO21158(a)lie.Stanford.EDU> irving(a)cs.stanford.edu (Geoffrey Irving) wrote (abridged): > Especially if you can make it a static assert (which I'm not sure of). Making it a static assert is not straightforward because addresses are not compile-time constants. The straightforward way to compute offsets is by subtracting addresses. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] [threads] Permission given to change to Boost.License
by Andriy Tylychko (mail.ru) 24 Sep '06

24 Sep '06

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > What does the Boost community think of > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2090.html > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2094.html > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2096.html > 1. Two different classes "future" and "task" with so simple goals and with a difference of just a single method's return type (almost). What do you think about some more lightweight approach? A new future's method (future::move_result() e.g.) instead of class "task"? Template parameter? Something else? Of course, if it's possible from implementation point of view. 2. Naming. I think "future" and "task" names doesn't reflect the difference between them. More self-explanatory names can simplify learning. OTOH, I don't like the name "future". Of course, it's possible that I'm not very familiar with parallel computing terminology, don't beat pls, but it's completely new multithreading term for me that doesn't raise any contiguity with threads and parallelism. "Task" is wider-popular term IMHO, but "task" in case of N2094 is just an optimization of "future". What about: "task" (instead of "future") and "movable_task", or "copyable_task" and "movable_task", or task<copyable> and task<movable> (pls see #1). 3. Functionality. Original boost::thread simplified multithreading programming because was: 1) portable 2) carefully designed Presented proposals go further on this way, because provide: 1) an ability to return results and to catch an exception (more about this later) 2) thread termination, if I've understood correctly But neither boost::thread nor proposals doesn't significantly simplify multithreading development. What about thread-safe message-queues and concurrency used in functional languages, e.g. erlang? Can you point me to any discussions about this topic? 4. Looping threads. Proposed design is best-suited for "single-task" threads. You have a task and you'd like to do it in a separate thread. This task has a result, and proposed design accents this. It's can be specific enough, but most of my threads work in loop, taking messages from the queue or just "working" until client explicitly stops them, and so doesn't have any results. So why I should worry about this, where's an interface for me? :) It's possible all this questions were many times discussed in the past, so pls refer me. Best regards, Andriy Tylychko, telia(a)vichnavich.com

3 2

[date_time][asio] Compilation errors due to winsock includes
by Ion Gaztañaga 24 Sep '06

24 Sep '06

Hi, While trying to resolve a Interprocess error when using it with asio, I've found that the problem is caused because Interprocess uses date_time. If you compile: #include <boost/date_time/posix_time/posix_time_types.hpp> #include <boost/asio/asio.hpp> int main() { return 0; } You get a lot of socket redefinitions because date_time seems to be including winsock.h whereas asio uses winsock2.h. Is there any way to avoid these errors? Regards, Ion

4 4

[threads] Permission given to change to Boost.License
by Beman Dawes 24 Sep '06

24 Sep '06

I've just had an email exchange will Bill Kempf, and he has given permission to change the Boost.Threads licensing to the Boost license. He said that the reasons he has not been able to continue work on Boost.Threads are entirely personal, and that he does not expect to be able to help for the foreseeable future. He wishes Boost well. Will someone volunteer to change the files involved? Thanks, --Beman

13 52