- Boost - lists.preview.boost.org

[range] Collection Concept
by David Abrahams 03 Sep '04

03 Sep '04

Are the authors of range libraries aware of http://boost/libs/utility/Collection.html? Just wanted to make sure. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 15

Building Boost with PathScale compiler
by Richard Hadsell 03 Sep '04

03 Sep '04

I am trying to build the Boost 1.31.0 libraries on an AMD Opteron platform using PathScale C++ 1.2. There is no toolset for this compiler, which looks something like a MipsPro compiler and something like a g++ compiler. Has anyone created a toolset for it? If not, how do I build a new toolset, or is there an easier way to build and install the libraries? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 5

Boost serialization: release configuration linker errors
by Andrew Favell 03 Sep '04

03 Sep '04

Ive been using Boosts serialization library with MSVC 7.1 (the first time that Ive used it). For most of my project I put the load / save function declaration in the class header (the .h file) and the definitions in the .cpp file VC 7.1 allows this for templated functions, unlike some older compilers. In debug mode this compiled and linked fine except for abstract base classes through trial and error I found that for abstract classes the functions had to be defined in the .h file to avoid linker errors. My project built fine in Debug mode and I then tried to compile / link it in Release mode this threw up quite a few LNK2001 errors relating to just a few of the serialization load / save functions in just some of the classes most of the classes that declared the load / save functions evidently linked fine (as they all did in Debug mode). After much double checking of the compile / link project configurations I tried the following: 1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the .h files in which the load / save functions were not linking. On recompiling / linking most of the linker errors were gone, but a few remained. 2. For the remaining classes that were not still not linking, I moved the load / save functions from the .cpp file into the .h file (these were not abstract classes). This fixed the remaining linker errors and my application compiled / linked / ran fine. I can't see why this occurred. I havent checked yet (its very time consuming to rebuild this application) but possibly option (2) would have worked for all the affected classes. For most of this project, the load / save functions remain defined in the .cpp file and clearly link fine in both debug and release configurations. Before someone asks, I did complete clean / rebuilds for both configurations anybody any ideas? andy :-) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

IOStreams review
by Dietmar Kuehl 03 Sep '04

03 Sep '04

Hi, let's start with the obvious formal requirement for review, i.e. the answer to the question: Should this library be included into Boost? I don't know. I have no strong feelings either way. Maybe I'm too used to writing stream buffers without help from any library but to me it is unclear whether this really makes things simpler. The number of different concepts is, at least to me, quite confusing. The library does, however, avoid a small fraction of boilerplate code (mainly for buffer maintenance). Unfortunately it does not at all address the really problematic area in stream buffers, namely seeking: the interface of stream buffers is retained. This is interface is, in my opinion, really hard to use. Typically, I don't bother implementing it unless some specification requires me to do so. On the other hand, I'm not using seeking with streams anyway. The documentation should make clear that the filters are not usable as temporary add-ons: I have some uses where I have an underlying stream buffer which is used directly until a portion of the stream needs special processing. At this point, a filter is used to process the portio and normal processing is continued afterwards. For example, when parsing a mail, a mime-decode filter is used to handle embedded binary data. This assumes, however, that the filter synchronizes with the underlying stream buffer. On the ACCU 2003 conference JC (I can figure out the full name if necessary...) presented the idea for creating filters which I really liked. It looked something like this: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); This would create a stream which writes everything to 'std::cout' and also encodes the stuff before sending it on to compress it and finally write it to the file. I like this notation... Finally, here are some issues I stumbled over in the documentation: - The description for "boost::io::read()" seems wrong to me: "returning a value less than n indicates end-of-sequence". At least on POSIX systems, return less than the number of requested bytes indicates that *currently* no more characters are available. The next call may return more characters. This behavior could be useful e.g. when filtering: get a buffer from the underlying stream and pass on what is left from this buffer after filtering. - On the "Filter" concept page, "OutputFilter" is not found (but it is reachable from the "InoutFilter" page). - On the "SeekableFilter" concept page, I think the preconditions for "f.put()" and "f.write()" should be "output" rather than "input". At least, I would consider it confusing if "input" were right... -- <mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software Development & Consulting

5 6

[mpl] bug: has_xxx, default bool parameter
by Daniel Wallin 03 Sep '04

03 Sep '04

The traits generated with BOOST_MPL_HAS_XXX_TRAIT_DEF() doesn't work with lambda on VC7.1+. I think the problem is the default bool parameter: template< typename T, bool fallback_ = default_ > struct trait \ ^^^^^^^^^^^^^^^^^^^^^^^^^ This template will never match: template<template<typename ..> class F, class U1 .. UN> struct lambda<F<U1 .. UN> >; So lambda breaks. I guess the solution is to stop using a default bool parameter and use a class type instead. -- Daniel Wallin

2 1

[mpl] patch for config/has_xxx.hpp
by Jonathan Turkanis 03 Sep '04

03 Sep '04

Hi Aleksey, It looks like boost/mpl/aux_/config/has_xxx.hpp has an unnecesary include directive for boost/mpl/aux_/config/gcc.hpp. Jonathan begin 666 has_xxx.patch M26YD97@Z(&AA<U]X>'@N:'!P#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0I2 M0U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O8F]O<W0O8F]O<W0O;7!L+V%U>%\O M8V]N9FEG+VAA<U]X>'@N:'!P+'8-"G)E=')I979I;F<@<F5V:7-I;VX@,2XR M#0ID:69F("UU("UR,2XR(&AA<U]X>'@N:'!P#0HM+2T@:&%S7WAX>"YH<' ) M,B!397 @,C P-" Q-3HT,#HT-2 M,# P, DQ+C(-"BLK*R!H87-?>'AX+FAP M< DR(%-E<" R,# T(#$X.C$P.C$X("TP,# P#0I 0" M,38L-R K,38L-B! M0 T*("\O("12979I<VEO;CH@,2XR("0-"B -"B C:6YC;'5D92 \8F]O<W0O M;7!L+V%U>%\O8V]N9FEG+V]V97)L;V%D7W)E<V]L=71I;VXN:'!P/@T*+2-I M;F-L=61E(#QB;V]S="]M<&PO875X7R]C;VYF:6<O9V-C+FAP<#X-"B C:6YC M;'5D92 \8F]O<W0O;7!L+V%U>%\O8V]N9FEG+W=O<FMA<F]U;F0N:'!P/@T* M( T*("\O(&%G=7)T+" Q,2]J86XO,#,Z('-I9VYA;',@82!S='5B+6]N;'D@ :)VAA<U]X>'@G(&EM<&QE;65N=&%T:6]N#0H` ` end

2 1

[BGL] Compilation failure of adjanceny_list on IBM
by Matthias Troyer 03 Sep '04

03 Sep '04

Since a recent CVS update the assignment operator of an adcacency_list graph fails to compile under the IBM vacpp compiler (xlC). The simplest test case is: #include <boost/graph/adjacency_list.hpp> int main() { typedef boost::adjacency_list<boost::vecS,boost::vecS,boost::directedS> G; G g; g = G(); } which fails as follows: "/users/matroyer/boost/boost/optional/optional.hpp", line 353.66: 1540-0210 (S) "T" is not a base class of "pair<boost::detail::out_edge_iter<std::_Ptrit<boost::detail:: sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,unsigned long>,long>,boost::detail::out_edge_iter<std::_Ptrit<boo...". "/users/matroyer/boost/boost/optional/optional.hpp", line 353.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::pair<boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,un...". "/users/matroyer/boost/boost/optional/optional.hpp", line 212.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::pair<boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,un...". "/users/matroyer/boost/boost/graph/detail/adj_list_edge_iterator.hpp", line 38.11: 1540-0719 (I) The previous message was produced while processing the implicit member function "boost::detail::adj_list_edge_iterator<boost:: counting_iterator<unsigned long,boost::use_default,boost::use_default>,boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsign...". "/users/matroyer/boost/boost/tuple/detail/tuple_basic.hpp", line 578.10: 1540-0700 (I) The previous message was produced while processing "boost::tuples::tuple<boost::detail::adj_list_edge_iterator<boost:: counting_iterator<unsigned long,boost::use_default,boost::use_default>,boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,...". "/users/matroyer/boost/boost/graph/detail/adjacency_list.hpp", line 1943.19: 1540-0700 (I) The previous message was produced while processing "boost::vec_adj_list_impl<boost::adjacency_list<boost::vecS,boost:: vecS,boost::directedS,boost::no_property,boost::no_property,boost:: no_property,boost::listS>,struct boost::detail::adj_list_gen<class boost::adjacency_list<boost::vecS,boost::vecS,boost::directedS,boost:: no_property,boost::no_property,boost::no_property,boost::listS>,boost:: vecS,boost::vecS,boost::directedS,boost::no_property,boost:: no_property,boost::no_property,boost::...". "../../src/alps/lattice/unitcell.C", line 3.5: 1540-0700 (I) The previous message was produced while processing "main()" Can any of the BGL experts help? Matthias

1 0

RE: [boost] Java style GUI in C++
by Hurd, Matthew 03 Sep '04

03 Sep '04

> Behalf Of David Turner > Sent: Friday, 20 August 2004 3:32 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Java style GUI in C++ > > > I am currently designing a GUI framework in C++ (initially > > targeting the > > Windows platform) that uses a model similar to that which > > Java uses in it's > > AWT and Swing libraries. Specifically: > > [snip] > > > I would appreciate comments and ideas as to what people would > > like out of a > > GUI framework, especially one that will be multi-platform. > > > > Boost-style C++ GUI library utilizing boost::signals and with a nice way > of handling message loops: > > http://cxxgui.sf.net/ Looks like a very nice conservative approach. I think you're wise to keep it simple and take a conservative c++ approach. Only trouble is it still feels like a lot of other things just shines a bit brighter and has cleaner lines. However I must say I've never seen a UI lib I've been happy with. Nor have I written one, or infrastructure that uses one, that I've been fond of. I find even 200 lines of code (not cxxgui) for a simple split windows file explorer-like interface scary, but the sad thing is that it is a great improvement over the norm. Some rambling thoughts on things I'd like to see are: 1. run-time and compile-time configurability, especially with some like compile time specification language like layout capability. There was some talk about this and some suggestions previously on this list. Marrying this to run-time would be interesting. Perhaps at compile time you can decide if there is an explicit handling method and if not call something with your source and event type that will dispatch. However this would lock you in at run-time if did this as a compile time metaprogramming thing that ending up optimizing to a function call equivalent but perhaps both options are appropriate... 2. reverse structural inheritance of events handler equivalents. Widgets are composed of other widgets. A window may handle the click, or prevent it, for a child. You can attach a handler for a named event at any point in the composition / structural hierarchy, it doesn't have to be the source, but is aware of it. Handling goes down the hierarchy to source. 3. get rid of the distinction between properties, events and methods. Consider a widget a functor with visual side affects. Consider it like a dataflow where properties being set, events and method calls are just messages coming into this node. Allows you to interpose handlers, recorders, do nice testing and all sorts. Draw backs are interoperability with initialization requirements of widgets. That is, some things are set at widget create time. But this might handled by avoiding by not changing such parameters and thus not needing to change, but if initialization only parameters of legacy components change, then destroy and recreate the component. 4. Structural context sensitivity, 4a inherit properties from your run-time structural parents, fonts, colours, whatever, perhaps from theme packages that are higher in the tree. The structural tree is used to find the appropriate handler for properties, events and methods (all one in the same) 4b Context sensitive addressing and sources. Just like event handling, property setting and method calls are sinks that are handled with structural sensitivity, sources, such as changing properties, data propagation flow out and can be addressed in a context sensitive manner. E.g. if you have a widget that is expecting an source for stock code, it should look up the structural hierarchy to find it, unless it is provided with an explicit mapping to a different source. Allow non UI components that can act as holders for properties (like a root blackboarding thingo (technical term) ) so that components can reflect context of non-parental nodes. 4c Context sensitive addressing. Want to be able to get the properties / sources of siblings, i.e. children of parents of yours. "Instrument" -> "maturity". You find the parent and then lock into its context for a piece of detail. 5. must be multiplatform, leveraging off something like wxwidgets like notus does for its implementation layer would probably be a good idea. 6. must have a wysiwyg designer (though I could live without it) (self hosting would be a neat goal) - integrating the compiler into this and being an ide would be nice - perhaps something like eclipse could help 6a Because of the run configurability of everything there is nothing to stop external descriptions of components, including the mapping of sources to sinks to capture most of the requirements. Obviously where code is needed you need code and an xml resource description will not help. 7. Should support run time type conversions to allow easy hooking up of stuff. Not sure how explicit or implicit this should be. A while ago I did something like this that also supported the dimensionality of the data so you could cut, slice and aggregate stuff easily between widgets. E.g. use the entire list, the selected items, etc... would take some kind of multidimensional iterator thing I guess. Allows some sophisticated run-time modelling capabilities. See the data in a grid, or a list control, a combo, .... With this kind of structure you should be able to compose widgets hierarchies that have awareness of the others around them and will have reasonable normal functionality without too much coding at all. Supporting this at run time as well allows you to have some nice drag / drop or otherwise dynamic configurability. Have some that get a list of strings, displays it in a list. Click on a list item and a chart and grid automatically updates. A detailed pane of items relevant to the first click docked at the side updates. The exit item in the menu does the default behaviour of shutting down the application. My goal is that this should be possible with out an enormous number of lines of code. Structurally specify it. Use context sensitivity, standardish workflows and data set handling / iterator capabilities to avoid code. Thwack custom events in where needed. Been thinking about this for years and have implemented various systems that do bits of this approach. Enough to know it works pretty well. It has always been too much work to chew on as a generic solution though... $0.005, Matt. Side issue: resizing / device independence. Problem with swing / wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen. This is often the issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel ( I really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize. Also for device independence you might be able to target a different device by using a capability set where controls map to other controls for that device, they just have to handle the same sources and sinks for their node, i.e. have the same conceptual support. Perhaps that be a nice level of indirection to solve problems. Use a tree control, grid or list or whatever, just don't specific which. The platform configuration maps in the explicit control. Is you use a more refined control that is not available on that specific platform, you can substitute a generic one based on a substitutability principle (like Liskov SP), or perhaps it is an error (perhaps the design can specific the functionality that must exist for the there to be no error). A thin client approach to this would be even nicer, separate the visual aspects from the data it refers to by protocol and/or method call so that interesting thin / thick / adaptive clients can be built. 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.

6 17

Boost::Python iterators are off by 1?
by Dan Eloff 03 Sep '04

03 Sep '04

If this is my fault the docs need to be more explanatory, but here's the problem: for the sequence (0, 1, 2), the Boost::Python iterator starts at 1 and ends 1 past 2 ( where 3 might be ). It does this because it calls the C++ iterators functions in this order: operator == post-increment dereference It should imho call them like (which would correct the issue) operator == dereference post-increment Like a normal for loop would execute: condition, code, action. The code to reproduce this is: #include <iterator> #include <boost/python.hpp> namespace py = boost::python; struct ctn { struct iterator: public std::iterator< std::input_iterator_tag, py::str > { int mNum; iterator( int num = 0 ): mNum( num ) {} py::str operator *() const { char temp[20]; const char * str = itoa( mNum, temp, 10 ); return py::str( str, strlen( str ) ); } iterator& operator ++(int) { mNum++; return *this; } friend bool operator ==( iterator lhs, iterator rhs ) { return ( lhs.mNum == rhs.mNum ); } }; iterator begin() { return iterator( 0 ); } iterator end() { return iterator( 3 ); // the range (0, 1, 2) three items } }; BOOST_PYTHON_MODULE(iter_bug) { py::class_< ctn >( "ctn" ) .def( "__iter__", py::iterator< ctn >() ) ; } >>> from iter_bug import * >>> c = ctn() >>> for i in c: ... print i ... 1 2 3 >>> Notice how it's off by one because of the very strange order of doing things. Please help! -Dan

2 8

[test][vacpp] problem with Boost.Test under IBM VisualAge C++ V6.0 for AIX
by JOAQUIN LOPEZ MU?Z 03 Sep '04

03 Sep '04

Many tests are failing with the following "/home/tk/boost_regression/boost/libs/test/src/unit_test_result.cpp", line 147.61: 1540-0130 (S) "std::__log10" is not declared. I've taken a look at the offending file and seems nothing has changed in the past months with respect to the usage of std::log10, so I guess this will have to do with some problem or misconfiguration in vacpp std lib. Any idea? Thank you Joaquín M López Muñoz Telfónica, Investigación y Desarrollo

3 3