March 2005 - Boost - lists.preview.boost.org

[filesystem] symbolic_link_exists naming AND is_file
by Jeff Garland 22 Mar '05

22 Mar '05

I'm writing a small program with filesystem and I needed to check for symbolic links so I can avoid processing them. I noticed the symbolic_link_exists method and, like all good programmers, didn't read the docs b/c I was sure it didn't do what I needed. So I set about writing a function that would and when I looked at the filesystem implementation I realized I was wrong. I was thinking that symbolic_link_exits would check that a symbolic link points to a valid file -- essentially following the symlink. Any reason why this funtion isn't called is_symlink to match the is_directory call? Also, in the code I'm writing I need to only process regular files. So it would be nice to write: if (is_file(my_path)) { //do stuff } where is_file is defined as follows: // equivalent of if (-d path) in perl // returns !is_directory(p) && !is_symlink(p); bool is_file(fs::path p); Or maybe it could be is_regular_file or is_plain_file if we want to be verbose. Seems like this would be handy to have in the filesystem lib. I can probably be talked into supplying patches ;-) Thoughts? Jeff

2 5

BOOST_CHECK_EQUAL again
by Stefan Slapeta 21 Mar '05

21 Mar '05

Hi, attached are the test cases for BOOST_CHECK_EQUAL on strings. I don't know which of the combinations are actually supported, but as you can see in the comments, it's quite mixed at the moment what does work and what not for Intel and VC. (the comments show failing test cases) Gennadiy, shall I add these test cases or are there some we definitely don't support? BTW, the (commented) results are for 1.32 as the code still doesn't work for Intel at all because of the numeric_limits problem! I tested with VC 7.1 and Intel 8.1. Cheers, Stefan #include <boost/test/test_tools.hpp> int test_main( int, char *[] ) { char const *buf_ptr_cch = "abc"; char const buf_array_cch[] = "abc"; char *buf_ptr_ch = "abc"; char buf_array_ch[] = "abc"; std::string buf_str("abc"); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_ch); // VC BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_ch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_str); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_array_ch); // Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_str); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_cch); // VC BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_cch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_str); BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_ch); BOOST_CHECK_EQUAL(buf_array_ch, buf_str); BOOST_CHECK_EQUAL(buf_str, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_str, buf_array_cch); BOOST_CHECK_EQUAL(buf_str, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_str, buf_array_ch); BOOST_CHECK_EQUAL(buf_str, buf_str); return 0; }

2 3

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

Just quickly- I am making good progress on app integration and adding to the Profiler library by Chris Diggins. I will be mailing out more info in the next few weeks. Additionally- a quick look at below looks like it would be something that would add value to profiler lib. I plan on taking a deeper look at that and will report back what I see. I want to REALLY spend some time with below to understand it better\ see how it could fit in with current profiler being worked on. THANK YOU for sending this out, very interesting.... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Martin Wille > Sent: Friday, March 18, 2005 12:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: google going open source > > Thorsten Ottosen wrote: > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > news:4239ED44.5090508@rubikon.pl... > > | under BSD 2.0 license > > | http://code.google.com/ > > | > > > > Hm...would anyone volenteer to boostify > > https://sourceforge.net/projects/goog-perftools/, > > Can't be done, due to the license. > > Regards, > m > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Mersenne Twister seed fix
by Daniel van der Zee 21 Mar '05

21 Mar '05

I was wondering if the fix to mersenne twister as suggested in http://lists.boost.org/MailArchives/boost/msg78304.php made it into the random number library for the next release. Thanks, Daniel

1 0

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

I would also like to request anyone who looks at this or spends time with it share on the list what they have learned. So far, it looks like it is gcc only as shipped, so porting is one area that needs analysis > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Monday, March 21, 2005 9:22 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: google going open source > > Just quickly- I am making good progress on app integration and adding to > the Profiler library by Chris Diggins. > > I will be mailing out more info in the next few weeks. > > Additionally- a quick look at below looks like it would be something > that would add value to profiler lib. I plan on taking a deeper look at > that and will report back what I see. I want to REALLY spend some time > with below to understand it better\ see how it could fit in with current > profiler being worked on. > > THANK YOU for sending this out, very interesting.... > > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] > > On Behalf Of Martin Wille > > Sent: Friday, March 18, 2005 12:50 AM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] Re: google going open source > > > > Thorsten Ottosen wrote: > > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > > news:4239ED44.5090508@rubikon.pl... > > > | under BSD 2.0 license > > > | http://code.google.com/ > > > | > > > > > > Hm...would anyone volenteer to boostify > > > https://sourceforge.net/projects/goog-perftools/, > > > > Can't be done, due to the license. > >

1 0

[filesystem] include_pathes?
by David Abrahams 21 Mar '05

21 Mar '05

Seems to me that this should be "include_paths," no?? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

How much should I care about allocators?
by Dan Rosen 21 Mar '05

21 Mar '05

Hi all, I'm in the process of putting together my own submission for a boost::tree<>, which has been discussed here on occasion before. Without getting into much detail about the tree itself, I have two nuts-and-bolts questions about conventions using allocators in containers. First: The standard allocator concept has several distinct typedefs: "value_type", "pointer", "reference", etc. My understanding is that the main motivation for allocators was the necessity to abstract out differences in pointer types on different platforms. So I assume this implies that to use an allocator properly, one can't necessarily expect that "pointer" is identical to "value_type*". I hope this assumption is correct so far. What I take this to further imply is that in my container, I need to write code of this nature: template <typename T, typename A = std::allocator<T> > class tree { public: typedef A allocator_type; typedef typename A::value_type value_type; typedef typename A::pointer pointer; typedef typename A::reference reference; // etc. private: class node_t; typedef typename A::template rebind<node_t>::other node_allocator; typedef typename node_allocator::value_type node; typedef typename node_allocator::pointer node_pointer; class node_t { pointer t_; node_pointer parent_; // etc. }; // etc. }; In other words, to respect the allocator I've been given, I need to make sure my internal node structure uses the rebound node allocator's pointer and value types, and so forth. So my first question is, is this assumption correct? The reason I ask is that looking over the standard library implementation that comes with gcc 4.0, I noticed that their implementation of std::list<> has nodes which contain straight pointers, rather than the allocator typedef equivalents. To me that seems to contradict my assumption, assuming the gcc implementation is correct. My second question is about allocator's construct() method. The implementation of std::allocator has construct() invoking the copy ctor using placement new(). That much is self-explanatory. It also seems reasonable to me that allocator does not have construct() methods taking arbitrary parameters. But I'm not sure I understand the reason why it does not have a construct() method to invoke an object's default ctor. What that implies to me, and seems to be supported by gcc's list implementation, is that the nodes in my tree mustn't have a default ctor that actually does anything, because the only way to properly initialize objects using an allocator is through copying. Is that correct? What this boils down to is, using allocators seems to dictate some aspects of how I design and implement this tree (or any container). So how much should I strive to operate within their limitations, and am I understanding these limitations correctly? I hope this is an appropriate forum for these questions. Thanks very much, dr

1 0

[Post review] Pointer Container
by Thorsten Ottosen 20 Mar '05

20 Mar '05

Dear all, The Pointer Container library is very almost finished. Since the review, the following major changes has been made - improved docs with new tutorial and improved browsing - new indirect functions - new Cloneable and Clone Allocator concepts - support for null values - refactored template interface off all classes - implementation guarantees to only instantiate std::container<void*> - rewritten iterators - improved tests The new docs, and code can be downloaded from the files section: http://groups.yahoo.com/group/boost/files/pointer%20container/ptr_container… The test runs with vc7.1 and gcc.3.3.3. Comments, suggestions and portability fixes are welcome. There are one major issue and one minor I need to have resolved during the post-review. Minor issue: allocation in map:operator[] ---------------------------------------- should a default allocated object use operator new or heap_clone_allocator::allocate_default(); ? This happens in ptr_map<string,int> m; m["foo"] = 5; // will allocate an int with new Normally the use can control all allocations because he always add objects manually or via cloninin (which he also controls). But the default object is just allocated with operator new inside ptr_map::operator[]. Should some hook be provided in a new allocator concept, map_heap_allocator? Major issue: ptr_iterator implementation. ----------------------------------------- So what is the problem? Well, since void* is used internally, the iterators must cast to the proper type in operator*; that is no problem for the default indireted iterators; the problem is with the iterators from ptr_iterator ptr_begin(); ptr_iterator ptr_end(); One way to define would be to say typedef internal_container::iterator ptr_iterator; Then the reference type would be void*& and not T*& as we would like. So if the user wanted to sort the container, he would do std::sort( cont.begin(), cont.end(), void_ptr_indirect_fun< std::less<T>, T>() ); This give us a rather insecure interface where you have to cast manually to T* inside the functor. So I wish we could get a T*& reference type. I think, from discussion with David Abrahams, that the current implementation is non-portable even though my test works: typedef T*& reference; reference dereference() const { // void_type is void* or const void* // I'm not sure why this is needed, but it seems to be return reinterpret_cast<reference>( const_cast<void_type&>( *iter_ ) ); } Does anybody knows how to rewrite this crappy code propoerly? I think we're faced with three options 1. keep the current behavior and describe in the docs that it is non-portable 2. go back to making ptr_iterator the default iterator with void*& reference type; 3. add a small subset of algorithms to the classes themselves; I'm thinking that the subset from std::list is appropriate: - sort - remove_if - remove - unique - reverse - merge Let me hear what you think best regards -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 4

[FSM library] review result: accepted with few conditions
by Pavel Vozenilek 20 Mar '05

20 Mar '05

FSM library written by Andreas Huber has been accepted into Boost, with few conditions and few recomendations. Thanks, Andreas, for your work and stamina to get thus far! Also thanks to all courageous reviewers. Short overview: =============== Opinions of reviewers were mixed. Large group liked the library, some even used it in production code. Other large group had objections Most questioned were performance and API. At the end my opinion is: no single perfect fit exists so it makes little sense to dismiss this library waiting for a hypothetical everyone-is-happy solution. Other variant was to ask for changes and for second review later. FSM is mature, has been developed for years and will be maintained in the future: its not likely such solution would make much of good for end result. Conditions: 1. Name of the library should be changed: - not to suggest that only one FSM implementation may exists in Boost - not to give wrong impression to people who look for tool with maximal runtime efficiency. - to stress the "high-level" nature of the library Names suggested during review were Statechart (by Alexander Nasonov) and umlfsm. 2. Information about performance overhead should be separated into page of its own and made clearly visible. Recomendations: 3. API of the library should be simplified as much as possible. Quirks and dangerous situations should be eliminated as much as possible. 4. The documentation should be improved as much as possible. 5. Runtime overhead should be decreased as much as feasible but without sacrifying currently available features of the library. Detailed information: ===================== 1. Name of the library should include change of namespace as well. 2. The information about runtime overhead. Separate page should be created and made visible on front page. It should contain examples of applications where FSM may not be the best solution (e.g. parsers). 3. API of the library, quirks and features. People asked many ways to simplify the API and increase orthogonality of its features: - the danger in using transit<> should be eliminated (Jonathan Turkanis suggested way how to do it) - the syntax to add deferred event should be cleaned up, even it it adds overhead - similarly posting events from inside FSM: if there's chance to make its syntax easier it should be done (no matter what IMHO) - reducing # of template parameters for state, possibly putting reactions as typedef inside state - it was suggested (by Daryl Green) to deduce reaction-list by examination of class interface - polymorphic events may be added for completeness (Peter Petrov found workaround but it may be better to do it right) - add handling of unknown events - custom allocator for FSM used for all states constructed in it. Perhaps it is possible to detect presence of overloaded operator new in state and it if doesn't exist then use state_machine allocator - not using containers keeping historical data when history feature is not used - possibility to use flyweight classes for states or class factories to create states - eliminate need for mpl::list for history parameter - description of transition guards in header was requested (perhaps it may be optional feature) Whether the library should separate its asynchronous part out was not discussed much. I guess it is better to keep it in and possibly submit it as standalone library. 4. Documentation. Among suggested improvements were: - better indentation in code snippets, inlined comments, syntax highlighting - adding complete examples to code snippets so users can try immediatelly - more information for error handling and asynchronous FSMs - reduce the radius of big black dots for initial states - external documents describing UML mapping should be more visible - avoiding forward declarations of events in code snippets - more examples (e.g. half-adder used twice to create a full-adder, suggested by Dave Gomboc, combination of synchronous and asynchronous machines) The documentation is now very dense, splitting it into smaller parts may help. More hyperlinking would also help a lot. The documentation may contain page "How to" with tricks, workarounds and non-obvious examples of use. For example how to use nested state to keep data related to inner states. I think adding UML and/or FSM tutorial in documentation is not task if this library. 5. Runtime overhead. Best effort should be made but only after stabilizing features and API. Reducing executable code size (per state/transition) may be the first direction here. ------------------------------- I hope that alternative FSM implementations (like the one currently developed by Alexander Nasonov) or dynamic FSM will appear and will be submitted to Boost as well. /Pavel

3 3

[fsm] Outstanding answers to review questions
by Andreas Huber 20 Mar '05

20 Mar '05

It seems I have finally managed to answer all the questions. In case someone is still waiting for answer, please let me know. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0