- Boost-users - lists.boost.org

bjam only finding system python on mac
by David Philp 18 Aug '08

18 Aug '08

I am trying to write a python extension for the Python that comes with Sage (Sage bundles its own Python). My user-config.jam is supposed to direct bjam to the Sage version of Python, but whatever I do, it links to the System Python. I think my configuration is correct, because if I (as root) move the System Python.framework so that bjam cannot find it, I can compile a working extension. ("Working" in the sense that it can be loaded into Sage's python, and runs perfectly.) Otherwise (without hiding System Python), the extension compiles just fine, but cannot be loaded into the Sage version of python. When loaded into Sage's python, it fails with "Fatal Python error: Interpreter not initialized (version mismatch?)" which seems reasonable. The extension can be loaded into the System Python. Here are the details. I've used "Sage_root" for the base directory of Sage to make this a bit more readable. (It is actually /Users/dphilp/ sage-3.0.3.): boost 1.35.0 sage 3.0.3, which contains python 2.5.2p2 (slightly patched for sage, and is built using --enable-framework=Sage_root/local/Frameworks/Python.framework ) Everything seems to work fine, Sage's doctests run perfectly, etc. In user-config.jam (this is overkill, but I wanted to remove any possible ambiguity): using python : 2.5 : Sage_root/local/Frameworks/Python.framework/Versions/2.5/bin/python : Sage_root/local/Frameworks/Python.framework/Versions/2.5/include/ python2.5 : Sage_root/local/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/config ; bjam --debug-configuration reports that it is using the requested version of python, i.e. the one inside Sage. Using --with-python=... on the command line does not help. When I use --debug-building, there is no hint of the System Python.framework anywhere. But when I run otool -L my_ext.so, it reports that the extension is linked to the System framework---that is, unless I hide the System framework, in which case it reports that it is linked to the Sage framework. This seems to me to be a bug in bjam, but I would appreciate any help either way. (Moving the System's python doesn't seem to be a good long term solution!) Thanks in advance for any answers or redirections. David ================================== David J Philp Postdoctoral Fellow National Centre for Epidemiology and Population Health Building 62, cnr Mills Rd & Eggleston Rd The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8260 F: +61 2 6125 0740 M: 0423 535 397 W: http://nceph.anu.edu.au/ CRICOS Provider #00120C

2 2

STL iterator issue in signals::detail::named_slot_map_iterator on MS VisualStudio?
by Ákos Maróy 18 Aug '08

18 Aug '08

Hi, I'm trying to compile a code sample using boost signals on Windows using Visual Studio 2008, that works fine on Linux using gcc. My application crashes at the first time a signal's operator() method is called, and it seems that the issue is with some STL-related iterator magic. The application breaks in named_slot_map.hpp, in the call to boost::signals::detail::named_slot_map_iterator::init_next_group(), basically in operator== of class _Tree_nod, in file xtree - probably an MS STL implementation. basically it breaks here: #if _HAS_ITERATOR_DEBUGGING if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont) { _DEBUG_ERROR("map/set iterators incompatible"); _SCL_SECURE_INVALID_ARGUMENT; } #else I tried to search on the issue, and found this thread: https://lists.secondlife.com/pipermail/sldev/2008-July/010867.html this even specifying _SECURE_SCL=0 doesn't help. I'm using boost 1.35.0, linking againts libboost_signals_vc90-mt-1_35. at the time of the call, actually there are no listeners bound to the signal. Is this an issue with boost::signals? or with MS VS? Akos

2 2

XML Serialization forward compatibility
by Terdale, Shantibhushan 18 Aug '08

18 Aug '08

I am trying to use XML serialization for streaming data on network. I could understand that with versioning you can make any class backward compatible. I have a situation which demands the other way; I need to read and construct an old object from new XML data. Currently it throws stream_error exception for any newly added member. I am trying to figure out how to deal with it; either write new archive or derive from existing XML archive and do changes etc. I am wondering whether anybody has done any work towards this idea and would like to share their insight. Thanks Shanti

2 1

Re: [Boost-users] size_type doubts / integer library..
by Lang Stefan 18 Aug '08

18 Aug '08

-----Ursprüngliche Nachricht----- > > If the developer > > chooses either type, others looking at the code might not recognize that > > certain values outside that range (but well within the limits of the > > chosen type) will cause problems or might indicate an error elsewhere. > > That's the job of the programmer. You have the native types with platform > dependent ranges. Good. That's a good start (without which you couldn't do > anything anyways). Now you need integer types to be defined in terms of > ranges, ok, you can do it with templates. Arbitrary precision arithmetic is > not the C++ standard IMO, it sits perfectly fine in third-party library space. > There was also a BigNum boost library proposal for GSoC. After that is done > then maybe everyone will be happy about this. > > -- > Dizzy > "Linux is obsolete" -- AST I am not sure you got my meaning. What I was trying to point out that today, like thirty years ago, when a programmer looks at a variable, he has to consider what integral type it fits in. And he needs to do so in terms of the machine! (can you say DWORD?) This implies two anachronisms: 1) the programmer needs to know the exact range the built-in integral types cover. While this is not a big problem, the mere fact a programmer needs to know such internal details indicates a design problem of the language. 2) the programmer can not easily express the true limits of the integral variables he uses: if he needs to make sure a variable does not exceed a certain limit, this requires excessive testing, or alternativly substituting his type with a custom class. On top of that he needs to devise mechanisms that prevent other programmers from circumventing these limitations. These two artifacts of the C language are the cause for uncountable runtime errors. If a programmer wasn't forced to think about internal representations and could instead just define the type he needs in terms of the range his variable should be tied to, then a lot of run time errors could never happen! Yes, it is the job of the programmer to avoid such errors. Today. As it was thirty years ago. But it shouldn't be! Of course, in many cases there is no need to check a variable's range, simply because it is being used inside a very limited scope. But even then the ability for simple range checking without added effort could help detect runtime errors! Stefan

3 2

[boost signal] Connecting while a notification is being processed
by Eric B 18 Aug '08

18 Aug '08

Hi I wonder what would happen (if) - while a signal is being processed - one of the listener method cause a new listener to connect to this signal Will the new listener append to the end of the listeners and therefore be called last ?

1 0

[boost]smart iterator
by Eduardo Panisset 18 Aug '08

18 Aug '08

Hi, Just for clarifying what I mean by "smart iterator": a smart iterator would be a iterator that acquires/releases locks on container/container items. If we would consider a Reader/Writer paradigm - few writtings and many readings, then a const_iterator would acquire/release a read lock on container and read lock on item, and a iterator would acquire/release a read lock on container and a write lock on item. For writting operations on container (e.g insert, remove), we would acquire write lock on container. Of course, we would consider a container stability, if stable (e.g. std::list, std::map) or unstable( e.g. std::vector, std::deque) in order to optimizing the solution (stable containers would allow simultaneous read/write operations on container). obs:Maybe the paradigm of concurrency could be a parameter. There is an analogous iterator in boost ? Thanks. Eduardo Panisset

1 0

AIX xlC error on static_move_ptr.hpp
by Gary Fu 18 Aug '08

18 Aug '08

Hi, Could anyone help why the AIX (5.3) xlC complains on the include file 'static_move_ptr.hpp' and how to solve the problem if possible ? I tried on Linux g++ without problem. Thanks, Gary 8:52pm > xlC -I $HOME/BOOST/boost_1_36_0 example.cpp -o example "/home_dir/Ggfu/BOOST/boost_1_36_0/boost/ptr_container/detail/static_move_ptr.hpp", line 182.22: 1540-2611 (S) The name "typename move_ptrs::enable_if_convertible<TT,T,boost::ptr_container_detail::static_move_ptr &>::type::type" can only be used to declare a constructor. #include <boost/ptr_container/detail/static_move_ptr.hpp> #include <iostream> #include <string> using namespace std; int main() { //print out the text string, "Hello, World!" cout << "Hello, World!" << endl; return 0; }

1 0

Re: [Boost-users] size_type doubts / integer library..
by Lang Stefan 18 Aug '08

18 Aug '08

Some thoughts: 1. Original problem Assigning a size to an ID type, IMHO appears to be completely unrelated to the general integral types' problem. There are two possibilities: A) you intend to use your ID to later reference some address or offset (which is the same) in memory. If that is your intention, then you should stick to the size type (i. e. std:size_t). Problem solved. B) if you don't intend to ever use your ID in the future to refer to an address in memory, then using an integral type might prove short-sighted. Unless you have a very concise knowledge about how many IDs you will need in, say, 5 years, or maybe 10 years from now, it's dangerous to limit yourself to a specific integral type for such a value. The least I would do is a typedef to hide the true type of that value and prevent anyone from making presumptions about it's potential size. Better yet define a class for this ID. If you do that you can write your own conversions and mathematical operators exactly the way you want them to be. Plus you have a central place to fix your conversions if you decide to change your ID class in a couple of years. Problem solved - in a very clean way. (IMHO) Then again I might be overestimating the importance and scope of this ID value. But in that case, why is 'unsigned long' the 'correct' type? Regarding this question, see my comments in part 3 of this message. 2. Size types (and difference types) I disagree on your complaint about size types all being unsigned. The quotation from B. Stroustrup explicitly made an exception for specific cases, and as I understand it he *was* referring to size types. The problem with size types is that they do need to be able to point to every location within the addressable memory space. Unfortunately this means they will need every single bit of the biggest data entity a CPU can handle at any one time. If size types were signed, they would need one extra bit for the sign, effectively doubling the amount of memory such a type would take up in memory. Unfortunately 'difference types' technically should be both signed and able to address every legal address in memory - which means one bit more than the current size types! However, see below.... 3. Integral types situation I agree with your general assessment of the integral types' situation. For several reasons actually, some of them not pointed out yet: A) Whenever signed and unsigend types are mixed, the compiler implicitly converts some of the values or intermediate results. Unfortunately it's often not obvious, which values and terms are being converted, and whether that can lead to problems. Most of the time (but not always, as you have correctly pointed out) the compiler issues warnings in such situations, but many compilers just point to the line, not the exact variable or term. B) What makes this problem even more difficult, is the widespread use of libraries, which may or may not use signed/unsigned values for specific properties, and thus don't even leave it open to the developers to avoid such combinations! C) Built-in integral types are based on internal representations of numbers. From the perspective of a designer this is just plain wrong! It is a violation of the principle of information hiding! Types shouldn't reveal anything about their internal representation, and after 20+ years of history in object oriented programming I really don't understand why we are still forced to use such types! When a developer selects an integral type for a variable, he considers the preconditions and postconditions, and decides the range of values his variable could legally assume. However, he shouldn't be forced to map this range to one of a few predefined ranges, just because these predefined ranges happen to fit the compiler's preferred internal representation. If a variable can assume values in the range [0..999999], then is 'long' the 'correct' type? Or is it 'unsigned long'? My answer is: neither! If the developer chooses either type, others looking at the code might not recognize that certain values outside that range (but well within the limits of the chosen type) will cause problems or might indicate an error elsewhere. 4. Resolution I like the suggestion of an integral type that is defined as a range of valid values. An additional (optional) parameter could be provided to define policies such as behavior on overflow, conversion problems and the like. This would be in the spirit of information hiding. In the case of size types or difference types, the address space could be reasonably restricted to a range that allows for a sign bit without compromising the maximum internal data size. In most cases anyway. And when it turns out an additional bit is still needed, then so be it! This design would take away the need to think in internal representations, and instead would allow the developers to concentrate on the true limitations of their variable types. 5. Advantages A) Developers can set more concise limits on their variables and behavior on violation of these limits. B) Predefined behavior on violations at runtime. C) Compiler developers can optimize internally needed storage by clustering mechanisms, depending on whatever memory access and processing capabilities the available cores provide. D) Compiler developers need to deal with just one basic integral class instead of a dozen or more. Depending on processor architecture this may or may not be very helpful (it might be neccessary to redefine the current integral types internally), but at least the use of these types would be more secure and less prone to programming errors. (Of course this implies the annihilation of current integral types which won't happen for some time, even after a standard basic adaptable integral type would be provided.) So these are my 5 cents, sorry for the lengthy post. Stefan

4 3

trunk documentation
by Felipe Magno de Almeida 18 Aug '08

18 Aug '08

Is there a link where I can access the generated trunk documentation? Thanks in advance, -- Felipe Magno de Almeida

5 6

Serialization in Bost 1.36
by Hansi 18 Aug '08

18 Aug '08

Hello, has the version used in boost 1.36 now the same features as the version on the homepage www.rrsd.com ? best regards Hansjörg

2 1