September 2004 - Boost - lists.boost.org

RE: [boost] Re: problem with intersection test_tools and mpl/list .hpp andborland
by Rozental, Gennadiy 16 Sep '04

16 Sep '04

How do I manage to step in all these compiler bugs??;)) I am quite sure I do not have nor function nor class template named next. How does it happened? Gennadiy > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Vozenilek > Sent: Thursday, September 16, 2004 2:42 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: problem with intersection test_tools and > mpl/list.hpp andborland > > > > "Robert Ramey" wrote: > > > The following program: > > > > > > #include <boost/mpl/list.hpp> > > #include <boost/test/test_tools.hpp> > > > > fails to compile with borland compilers with the messages: > > > > c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: > > Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot > have both > > a template class and function named 'next' > > > > > Old BCB bug, e.g. > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&th readm=3BDD798D.130E38F8%40divalsim.it&rnum=1&prev=/groups%3Fnum%3D100%26hl%3 Den%26lr%3D%26ie%3DUTF-8%26c2coff%3D1%26q%3DE2479%2BBorland%2BOR%2BBCB%2BOR% 2Bcompiler%26btnG%3DSearch (http://tinyurl.com/5ltk9) It won't be fixed, ever. One ugly way is to use macro: #include <boost/mpl/list.hpp> #define next xyz #include <boost/test/test_tools.hpp> #undef next other is to separate code into two TUs. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: problem with intersection test_tools and mpl/list.hpp andborland
by Robert Ramey 16 Sep '04

16 Sep '04

Pavel Vozenilekwrote: >> The following program: >> >> >> #include <boost/mpl/list.hpp> >> #include <boost/test/test_tools.hpp> >> >> fails to compile with borland compilers with the messages: >> >> c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: >> Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot have both >> a template class and function named 'next' >> >> >Old BCB bug, e.g. > (http://tinyurl.com/5ltk9) >It won't be fixed, ever. >One ugly way is to use macro: >#include <boost/mpl/list.hpp> >#define next xyz >#include <boost/test/test_tools.hpp> >#undef next >other is to separate code into two TUs. I don't think this will work for me as it shows up due to file header inclusion about 7 levels deep. Note that this is a new phenomenon that I believed was introduced with the latest MPL update. I realize that's it's a lot, but would it possible for the authors of the two libraries to agree that the name be changed in one of them just so I that us users don't have to resort to a hack such as the above? Robert Ramey

1 0

Re:[boost] Serializing bitsets and tuples
by Robert Ramey 16 Sep '04

16 Sep '04

>Again, Robert, I have to thank you immensely for the Serialization >library. It has made my life much easier. >Anyway, I was wondering, since you state in the manual that all STL >containers are supported, why I can't seem to find std::bitset in that. >I realize that it is probably not the most common container to >serialize, but still. Also, considering the is Boost library now, I'm >wondering about the apparent absence of serialization for boost::tuple. >It's not the end of the world (I can write them myself rather easily, I >suppose), but for completeness I'd think at least Boost.Tuple should be >supported. LOL - I never heard of std::bitset until you mentioned it. Also I think I overlooked vector<bool> as well. Feel free to implement serialization for them and put your name on it. Make a test and we'll add it in. Robert Ramey

3 3

bug in recursive_mutex
by James Ahlborn 16 Sep '04

16 Sep '04

I previously posted about issues when using a recursive_mutex and a condition. after some more inspection, it turns out it is a minor bug in the recursive_mutex implementation (the pthread version). I've included the patch below, which was generated against the 1.31.0 version of boost (but the bug is still in the latest cvs as well). Would be great if someone could integrate this into the latest code, or possibly a bug fix release for 1.31 (this is a major bug for anyone using recursive_mutex with condition). thanks, -james *** boost_1_31_0/libs/thread/src/recursive_mutex.cpp Fri Dec 26 18:22:00 2003 --- boost_1_31_0.jta/libs/thread/src/recursive_mutex.cpp Thu Sep 16 10:01:10 2004 *************** *** 412,417 **** --- 412,418 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_try_mutex::recursive_try_mutex() *************** *** 608,613 **** --- 609,615 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_timed_mutex::recursive_timed_mutex() *************** *** 787,792 **** --- 789,795 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } #elif defined(BOOST_HAS_MPTASKS)

3 3

problem with intersection test_tools and mpl/list.hpp and borland
by Robert Ramey 16 Sep '04

16 Sep '04

The following program: #include <boost/mpl/list.hpp> #include <boost/test/test_tools.hpp> fails to compile with borland compilers with the messages: c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot have both a template class and function named 'next' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 34: Cannot have both a template class and function named 'next' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 40: Cannot have both a template class and function named 'prior' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 44: Cannot have both a template class and function named 'prior' *** 4 errors in Compile *** Could someone shed some light on this? Robert Ramey

2 1

Re:Re: [boost] Serializing bitsets and tuples
by Robert Ramey 16 Sep '04

16 Sep '04

>> I'll see if I can get a test case thrown together for std::bitset. >> I'll take a look at boost::tuple as well (but that should be big time >> trivial, so... :) ) >Erh... trivial, but tedious. Seeing as I have to redo the serialize >funtion for all possible lengths of a tuple (0 to 10 contained >elements). Unless I missed something obvious? (again) >Anyway, is serialization for tuples supposed to be a Boost.Serialization >add-on or a Boost.Tuples add-on? As Jeff Garland mentioned, generally >std::* should be in Serialization, and anything else in the respective >library. However, Boost.Serialization already provides support for e.g. >shared_ptr<> and Boost.Optional. So...? This question has come up before without being explicitly/publicly agreed upon. Jeff Garland and I have come to the following consensus: Serialization for standard containers and objects, ie members of namespace std:: will go into the boost::serialization namespace and their corresponding test will go into the serialization test library. Other serialization implementations will go into the namespace/test set of their respective libraries. All maintainence of serialization modules will be responsibility of their respective authors. There are a few boost classes in the serialization library which ended up there during development of the library. shared_ptr is and example. These are anomalous cases and not a pattern that will be continued. Obviously, its my desire to keep the serialization library as task of O(1000) rather than O(1000 + N). So that's our policy. Robert Ramey

1 0

State of giallo, (sockets and demultiplexing)
by Hugo Duncan 16 Sep '04

16 Sep '04

Spend a few days off line and you suddenly miss a whole conversation :-( It's going to take a while to catch up... Recent IOstreams discussion has indeed been very interesting, espescially as I am finally getting round to implementing buffers and filters for giallo (boost.sockets). At the moment I am leaning towards ACE style message buffer, using the apache filter idea of flush/eos/eoc control (but trying to avoid any knowledge of the underlying resource). So where is giallo today (apart from being temporarily broken on gcc due to mpl changes)? i) Low level, platform header hiding, object based wrappers of sockets, named pipes, select, and completion ports (and a POSIX aio wrapper on linux that I have tried to get to work in many different ways and failed so far). ii) proactor and reactor interfaces, with policy based implementation, provided by bridge classes to the low level completion port and select wrappers above. iii) 'event completion notification' style connector, acceptor and connection classes for sockets and named pipes. These classes combine a demultiplexer with a resource (socket, pipe, etc), and can use a proactor or reactor demultiplexer interchangeably (via template parameter). The connection selects the synchronisation mode (block, non-blocking, asynchronous) of the socket based the demultiplexer. The library is thread aware (can run multithreaded, will create threads if asked to, uses threads to do asynchronous connect if not natively supported, etc) There is a streambuf implementation, but I have not found a way to implement this without it degenerating to a thread per connection model. I feel quite strongly that the decision to implement connection, connector and acceptor concepts with a single (in this case 'event completion' style) notification interface, regardless of the demultiplexer mechanism used, is very important, and can lead to a stream/filter concept that is independent of demultiplexer, of blocking/non-blocking/asynch mode and thus independent of the resource used.

5 12

RE: [boost] State of giallo, (sockets and demultiplexing)
by Hurd, Matthew 16 Sep '04

16 Sep '04

> The only exception I can think of is if the data is to be 'multicast' down 2 > TCP connections... Another exception for you: In place messaging with a "fast message" format would be nice for support. Some network hardware, including TCP via TOE cards and infiniband and the like, support very low latency messaging, e.g. < 10 microseconds. You don't want to copy, but also you don't want to serialize. In fact, for many applications you are prepared to sacrifice architecture portability on the altar of speed and you might send a contiguous c++ object, padding from alignment and all, directly as a message block. The CPU never has to see the whole object. A diminutive $0.02, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[mpl] gcc problem with include order dependency
by Hugo Duncan 16 Sep '04

16 Sep '04

Aleksey, With gcc (GCC) 3.3.3 (cygwin special) there is a include order dependency. Including boost/bind.hpp before boost/mpl/transform.hpp causes a compile error type named `type' in `struct boost::mpl::apply_wrap2<boost::mpl::push_front<mpl_::na, mpl_::na>, mpl_::arg<1>, wrapper<mpl_::arg<2> > >' I have not been able to test with other gcc versions. Regards, Hugo #include "boost/bind.hpp" #include "boost/mpl/transform.hpp" #include <boost/mpl/apply.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/assert.hpp> // computed type template <typename T> struct wrapper{}; // metafunction class to compute type struct wrapped_type { template <typename T> struct apply { typedef wrapper<T> type; }; }; void test_transform() { typedef boost::mpl::list<int, char> typelist; typedef boost::mpl::list< wrapper<int>, wrapper<char> > wrapped_typelist; typedef boost::mpl::transform< typelist, wrapped_type >::type result; BOOST_MPL_ASSERT(( boost::mpl::equal<wrapped_typelist, result> )); }

3 3

RE: [boost] spirit 1.8 / vc 8.0 test results
by Reece Dunn 16 Sep '04

16 Sep '04

Paul A Bristow wrote: >I was under this impression from the MS docs, but a recent reply to my >query >by Brandon Bray at MS cites a 40901 release (perhaps an internal beta 2?), >whereas I have says 8.0.40607.16 but I am not sure if the compiler release >has changed. >(cl.exe file is 8.00.40607.16 too) I have beta 1 installed with the first tool refresh and have: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40809 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. I think 40607.16 refers to the initial beta1 release, 40809 refers to the first tool refresh and I assume that 40901 would be the second (upcoming) tool refresh. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2