- Boost - lists.boost.org

Apple GCC conditional in boost.python ??
by Marshall Clow 21 Feb '05

21 Feb '05

In boost/libs/python/src/converter/registry.cpp, I found: >#if defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__) \ > && __GNUC__ == 3 && __GNUC_MINOR__ <= 4 && !defined(__APPLE_CC__) ># define BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND >#endif I have no idea what defining that big long symbol does, but I think that the conditionals are incorrect. <http://developer.apple.com/technotes/tn2002/tn2071.html> says: __APPLE__ This macro is defined in any Apple computer. __MACH__ This macro is defined if Mach system calls are supported. __APPLE_CC__ This macro is set to an integer that represents the version number of the compiler. This lets you distinguish, for example, between compilers based on the same version of GCC, but with different bug fixes or features. Larger values denote later compilers. I can't see any case where __APPLE__ and __GNUC__ are defined, and __APPLE_CC__ is not defined. Metrowerks? ==> No __GNUC__ Not on a Mac? ==> No __APPLE__ __APPLE_CC__ was defined for Apple-released versions of GCC, starting with 2.95.2 (so says Chris Espinosa at Apple). More historical info is at <http://developer.apple.com/releasenotes/DeveloperTools/GCC2.html> So, I think that that whole #if expression always evaluates to "false". -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

[boost::signals] connect/disconnect management suggestion
by kolach56＠yandex.ru 21 Feb '05

21 Feb '05

I used boost::signals in number of projects and found one thing inconvenient. I could easily connect anything to signal but sometimes it became hard to disconnect form it. It's ok if a connection time is bounded by a lifetime of trackable or connection objects. I used to use Group id for disconnection, but sometimes I needed it for call priority. ( In that case I would write a special GroupCompare function but it looked ugly. ) For experimental purposes, I constructed an alternative approach. For connection/disconnection management I used the following syntax: struct Test { void test( bool, int ); }; void f( bool ); signal<void (bool)> s; s.connect( &Test::test, t, _1, 5 ); s.disconnect( &Test::test, t, _1, 5 ); s.connect( &f, _1 ); s.disconnect( &f, _1 ); I just form a hash code from the arguments. It certainly makes the process longer, but in most cases I don't need something extremely fast there. In my projects, the performance is important in invocation process. It's only a variant, there might be a lot of other ways. So actually my suggestion is why not to have both approaches of connection/disconnection management? One for fast connection/disconnection and the other for extra control over it. -- Best regards, Nick mailto:kolach56@yandex.ru

1 0

Review managers needed
by Tom Brinkman 21 Feb '05

21 Feb '05

The following libraries are scheduled to be reviewed in the coming weeks. Finite State Machine (FSM) Andreas Huber Review Manager - Pavel Vozenilek Policy Pointer David Held Fixed Strings Reece Dunn FOREACH Macro Eric Niebler typeof Arkadiy Vertleyb,Peder Holt If you are familiar with one of the these libraries and would like to volunteer to be the review manager, please contact me at reportbase(a)yahoo.com. Tom Brinkman Review Wizard __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

3 2

[Boost-bugs] [ boost-Bugs-1145183 ] Can't build on cygwin
by SourceForge.net 21 Feb '05

21 Feb '05

Bugs item #1145183, was opened at 2005-02-20 21:32 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=1145183&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build on cygwin Initial Comment: boost 1.32.0 from cvs while i'm trying to compile it under cygwin with: bjam -sTOOLS=gcc install i have an error: unknown target type for <@boost!libs!test! build>libboost_prg_exec_monitor. Anybody can help me? Thank you, diabolo(a)gcnet.ru ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1145183&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

wave gcc "bits/c++config.h" invalid name
by Larry Evans 21 Feb '05

21 Feb '05

Getting: cd ~/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ wave -S/usr/include/c++/3.3 test_link.cpp #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header /usr/include/c++/3.3/iostream(42): exception caught: boost::filesystem::path: invalid name "c++config.h" in path: "bits/c++config.h" Should the criteria for valid name be changed?

4 10

Two more typos
by Julio M. Merino Vidal 20 Feb '05

20 Feb '05

Hi again, another fix for two more typos is attached. Cheers, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

1 0

Re: [boost] Re: [multi_index][hash][rfc] Hashed indices preview+Boost.Hash
by JOAQUIN LOPEZ MU?Z 20 Feb '05

20 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Domingo, Febrero 20, 2005 7:53 pm Asunto: [boost] Re: [multi_index][hash][rfc] Hashed indices preview +Boost.Hash > JOAQUIN LOPEZ MU?Z wrote: > > The implementation I adopted (2 pointers per node + 2 pointers > > per bucket) has O(1) iteration, insert() and erase(), whatever > > the load conditions (provided the hash function behaves, of > > course.) I agree with you bidirectional iteration is of little > > value, and my main motivation was to achieve O(1). So, I'll be > > happy to go for a lighter implementation if these issues > > can be solved in another way --or if there's consensum that > > costly iteration under low load conditions is acceptable. > > FWIW, if you can find a spare bit in a pointer, I've thought of a > non-portable way to get something closer to O(1) without the extra > memory load. The nodes are stored in a singly-linked list which > includes > the buckets, so the last node in a bucket points to the next > bucket. The > spare bit is used to indicate if a pointer is pointing to a node > or a > bucket. So the data structure is something like: > [...] Hi Daniel, We can get rid of the spare bit if only iterators store a pointer to the container: then we can test whether a pointer points to a true element or a bucket just by checking if it is in the range [buckets.begin(),buckets.end()). Still constant, though admittedly slower than the bit thing. Main problem with this is, as you point out, that traces of empty buckets will be left when erasing. Still, it seems somewhat better than the classic implementation, at least wrt to theoretical complexity (in practice it'd probably be significantly slower.) Joaquín M López Muñoz Telefónica, Investigación y Desarrpññp

2 1

is_convertible patch for HP/aCC
by Toon Knapen 20 Feb '05

20 Feb '05

The latest incarnation of the HP compiler (version 6.0) looks to be a hugh improvement in respect to earlier versions. I'm looking into porting boost to HP aCC and I suggest to apply following (minor) patch (see attach). OK to commit this? toon cvs diff: Diffing . Index: is_convertible.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_convertible.hpp,v retrieving revision 1.28 diff -u -r1.28 is_convertible.hpp --- is_convertible.hpp 4 Sep 2004 10:34:48 -0000 1.28 +++ is_convertible.hpp 14 Feb 2005 13:09:41 -0000 @@ -125,7 +125,7 @@ }; #elif (defined(__EDG_VERSION__) && (__EDG_VERSION__ >= 245) && !defined(__ICL)) \ - || defined(__IBMCPP__) + || defined(__IBMCPP__) || defined(__HP_aCC) // // This is *almost* an ideal world implementation as it doesn't rely // on undefined behaviour by passing UDT's through (...). cvs diff: Diffing detail

3 4

profiling library and documentation update
by christopher diggins 20 Feb '05

20 Feb '05

I have now uploaded the new documentation for the library at: http://www.ootl.org/profiler/ I am no longer including the high-res timer as part of the library. I have moved the timer to http://www.ootl.org/ootl/misc/high_resolution_timer.hpp.htm for those that want, but I hope the library will be evaluated independantly of the design. I have tried to take into account as many suggestions and comments as possible, but it is hard to track their relevancy/urgency as the design has evolved. I would appreciate it if anyone has suggestions or concerns which they feel are still relevant, to please bring them up again. I am particularly interested in knowing how useful the library is in its current incarnation, and how far it is from something that could be seriously considered for Boost inclusion. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 1

Problem with multi_array and serialization
by Matthias Troyer 20 Feb '05

20 Feb '05

Hi, Trying to combine boost multi_array and serialization I found a very strange compiler bug (?) on MacOS X, using eother the Apple version of gcc-3.1. The following simple code will not compile: #include <boost/multi_array.hpp> namespace strange_namespace { class access { }; } int main() { boost::multi_array<int,2> x(boost::extents[3][3]); int y=x[0][0]; } It fails with the error message src/boost/boost/multi_array/multi_array_ref.hpp: In member function `typename boost::const_multi_array_ref<T, NumDims, T*>::reference boost::multi_array_ref<T, NumDims>::operator[](typename boost::const_multi_array_ref<T, NumDims, T*>::index) [with T = int, long unsigned int NumDims = 2]': test.C:11: instantiated from here src/boost/boost/multi_array/multi_array_ref.hpp:512: no matching function for call to `boost::const_multi_array_ref<int, 2, int*>::access( boost::type<boost::detail::multi_array::sub_array<int, 1> >, index&, int*, const size_type*, const index*, const index*)' src/boost/boost/multi_array/subarray.hpp: In member function `typename boost::detail::multi_array::const_sub_array<T, NumDims, T*>::reference boost::detail::multi_array::sub_array<T, NumDims>::operator[](typename boost::detail::multi_array::const_sub_array<T, NumDims, T*>::index) [with T = int, long unsigned int NumDims = 1]': test.C:11: instantiated from here src/boost/boost/multi_array/subarray.hpp:261: no matching function for call to `boost::detail::multi_array::const_sub_array<int, 1, int*>::access( boost::type<int&>, index&, int*&, const size_type*, const index*, const index*)' This looks like a compiler bug, since the code compiles when removing the class definition access in a completely unrelated namespace. Has something similar been observed before? Does anybody know a workaround? Matthias

1 0