- Boost - lists.preview.boost.org

[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

[Boost-bugs] [ boost-Bugs-1021799 ] struct pointer_iterator_traits<T*> fails on VC7.1
by SourceForge.net 03 Sep '04

03 Sep '04

Bugs item #1021799, was opened at 2004-09-03 14:50 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=1021799&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marvin H. Sielenkemper (sielenk) Assigned to: Nobody/Anonymous (nobody) Summary: struct pointer_iterator_traits<T*> fails on VC7.1 Initial Comment: We are using boost::iterator_facade in our project. During compilation we got an error: c:\Boost\include\boost-1_31\boost\detail\iterator.hpp (270) : warning C4346: 'boost::remove_const<T>::type' : dependent name is not a type The error was caused by class k_EntryIterator : public boost::iterator_facade<k_EntryIterator, r_DirectoryEntry, boost::single_pass_traversal_tag> { public: k_EntryIterator(k_DirectoryInfo& ak_Owner); ~k_EntryIterator(); private: friend class boost::iterator_core_access; k_DirectoryInfo& mk_Owner; void increment(); bool equal(k_EntryIterator const& other) const; r_DirectoryEntry& dereference() const; }; and was easily fixed by adding a 'typename' in line 270 of iterator.hpp: old: typedef remove_const<T>::type value_type; new: typedef typename remove_const<T>::type value_type; MfG, Marvin H. Sielenkemper ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1021799&group_… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

compile-time variables
by Goran Mitrovic 03 Sep '04

03 Sep '04

I've got a question. Is a compile-time variables concept known? It would be a set of macros that would allow assigning and changing a number assigned to a variable's name. Such variable would be considered as a constant from template argument's perspective, for example. One of the usage for such classes I have in mind would be the painless type registration of typeof macro, for example...

6 8

An alternative typeof macro
by Daniel James 03 Sep '04

03 Sep '04

I've come up with an alternative way to invoke the typeof emulations that have been posted. It basically works by defining an iterator over the encoded type. Unfortunately, it can't be used inside a function, and is awkward to use in general, but has the advantage is that it only has to define the call to foo once, which might result in faster compile times. It could possibly also remove the limit on the complexity of the type. Arkadiy's version would require a some changes to do this, but I think Peder's could quite easily. Although I'm not sure as I've only had a brief look at his version. I've implemented it as a sort of typedef, which seems like the easiest way to use it. It's probably easier to understand the code than my explanation, so here it is. It's based on Arkadiy's version in the yahoo groups file section. #define BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) \ BOOST_PP_CAT(BOOST_TYPEOF_TYPEDEF_ITERATOR_##Name##_, __LINE__) #define BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ struct BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) { \ template <int pos> \ struct iterator { \ typedef boost::mpl::int_< \ sizeof(boost::type_of::foo<pos>(Expr))> type; \ typedef iterator<pos+1> next; \ }; \ }; #define BOOST_TYPEOF_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; #define BOOST_TYPEOF_TPL_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef typename boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; Here is an example of it's use: template <class Op> struct result_of_nullary_functor { static Op op; BOOST_TYPEOF_TPL_TYPEDEF(op(), type); }; struct g { int operator()(); }; BOOST_MPL_ASSERT_IS_SAME(result_of_nullary_functor<g>::type, int); I've only tested on the intel linux compiler. Daniel

5 38

RE: [boost] Porting to SCO Unix
by Ben Hutchings 03 Sep '04

03 Sep '04

John Maddock <john(a)johnmaddock.co.uk> wrote: > > The following tests in libs/config/configure produce incorrect > > results: > > > > ** checking for pthread_exit in -lpthread... no > > This test tries to compile a C source file that prototypes > > "pthread_exit" as "char pthread_exit();". But my compiler driver > > always adds "-include <...>/pthread.h" to the command line, which > > includes a different, conflicting prototype for this function. I > > think the test ought to include <pthread.h> instead. > > Grrrrr, I used the standard autoconf macros for checking this, if I > get the time I'll try and write my own version that does what you > suggest. > > > ** checking pthread_yield... no > > This is correct, but I do have a pthread_yield_np() function, > > maybe we should look for it, too. > > It's up to the thread lib guys to use it (or not), maybe you could > hassle the authors of the thread lib you are using to provide a > standard function signature? pthread_yield is non-standard; you should use sched_yield instead (if at all). See <http://groups.google.com/groups?selm=3ecbb70c%40usenet01.boi.hp.com>

2 1

Minor preprocessor library documentation typo fixed.
by Jurko Gospodneti� 03 Sep '04

03 Sep '04

Hi all. I'm attaching a patch for a minor typo fix in the Boost preprocessor library docs. HTH, Jurko begin 666 enum_binary_params.html.diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,RXY+C(P,#0@,3(Z,C0Z-3(- M"@T**BHJ(&5N=6U?8FEN87)Y7W!A<F%M<RYH=&UL(#(P,#(M,3 M,#0@,# Z M,3 Z,C N,# P,# P,# P("LM,#(P, T*+2TM(&5N=6U?8FEN87)Y7W!A<F%M M<RYH=&UL(#(P,#0M,#DM,#,@,3(Z,3@Z,C,N,# P,# P,# P("LM,#(P, T* M*BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@,C$L,S4@*BHJ*@T*(" )"0D\9'0^<#$\ M+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER<W0@ M<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/4U1? M4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M8F5R M<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@/&D^ M,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D)"3PO M9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H92!T M97AT(&]F('1H92!F:7)S="!P87)T(&]F('1H92!P87)A;65T97(N)FYB<W [ M#0H@( D)"0D\8CY"3T]35%]04%]%3E5-7T))3D%265]005)!35,\+V(^(&-O M;F-A=&5N871E<R!N=6UB97)S(')A;F=I;F<@9G)O;2 \:3XP/"]I/B!T;R \ M:3YC;W5N=#PO:3X@+2 \:3XQ/"]I/@T*(" )"0D)=&\@9V5N97)A=&4@<&%R M86UE=&5R<RX-"B @"0D)/"]D9#X-"B @"0D\+V1L/@T*(" )/&@T/E)E;6%R M:W,\+V@T/@T*(" )"3QD:78^#0HM+2T@,C$L,S4@+2TM+0T*(" )"0D\9'0^ M<#$\+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER M<W0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/ M4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@ M/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D) M"3PO9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H M92!T97AT(&]F('1H92!S96-O;F0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N M8G-P.PT*(" )"0D)/&(^0D]/4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B M/B!C;VYC871E;F%T97,@;G5M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@ M=&\@/&D^8V]U;G0\+VD^("T@/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E M('!A<F%M971E<G,N#0H@( D)"3PO9&0^#0H@( D)/"]D;#X-"B @"3QH-#Y2 896UA<FMS/"]H-#X-"B @"0D\9&EV/@T* ` end

1 0

[mpl][multi_index][intel-8.0-linux]
by Joaquín Mª López Muñoz 03 Sep '04

03 Sep '04

Newly merged MPL seems to be having problems in Intel 7.x/8.0 under Linux with BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN, as shown in http://tinyurl.com/5rj4d Appart from this, the merge is mostly working fine, as far as multi_index is concerned. There's another MPL-related problem, but it's due to a previously masked bug of mine. Congrats and thanks for the staggering effort. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0