December 2004 - Boost - lists.preview.boost.org

[filesystem] Major changes before standardization
by Beman Dawes 13 Feb '05

13 Feb '05

I'm currently working on a major revision of the Boost filesystem library aimed at getting it ready to be proposed to the C++ committee for the next Library TR. The critical technical change required is internationalization. The plan is to provide a templated basic_path class, with typedefs for path and wpath. In other words, an approach very similar to the current std::basic_string, std::string, and std::wstring. Doing this adds a certain amount of complexity compared to the current path class. For example, a path_traits class has to be introduced to give basic_paths on user defined types a way to import the conversions, delimiters, and other traits. To offset the added complexity, I'd like to reduce some of the complexities in the current design: * Eliminate the distinction between native and generic grammars; either would be permitted in all contexts. As well as simplifying the class interface a bit, this will also eliminate a source of user confusion. * Move the name error checking from the basic_path class into stand alone functions. Although the current error checking could be further improved by Peter Dimov's suggested change allowing failure to be treated as either a warning or a hard error, moving it out of the class simplifies the interface, allows full path (rather than name-by-name) error checks, and eases internationalization. The primary downside of these changes will be that users who want path portability checks will have to code calls to checking functions that are currently being called automatically. The internationalization of the library is a big enough change that we will probably want to have at least a mini-review once the changes are complete. Comments? --Beman

12 55

StringAlgo::split issue
by Dirk Gregorius 29 Jan '05

29 Jan '05

Hi, I used the split function on the following string: vector<string> tokens; string str= "( 448 448 64 ) ( 448 0 64 ) ( 0 448 64 ) name 0 0 0 0.5 0.5 0 0 0"; split( tokens, str, is_any_of( ()), token_compress_on ); // I pass 'space' , '(' and ')' into is_any_of() I was supposed to get 18 tokens. The first nine values, the string "name" and the remaining eight digits. "split" always returns a string vector containing 19 tokens, where the first element of the vector is an empty string. Why does the function insert empty strings into the collection? Can I use split to obtain the 18 wanted tokens? -Dirk

3 4

Re: [iterator] small feature request
by David Abrahams 23 Jan '05

23 Jan '05

Eric Niebler wrote: > The iterator_adaptor<> template has a base() function to access the > underlying iterator. Well and good. However, iterator_adaptor<> doesn't > have a public typedef for the iterator type returned from this function. > Can it be added? > > Rationale: > Given some iterator of type T that is built of an unknown number of > adaptors, extract the underlying iterator. Consider: > > template<class Iter> > typename disable_if<is_adapted<Iter>,Iter>::type > base(Iter const & it) > { > return it; > } > > template<class D,class B,class V,class T,class R,class Di> > ?????????? > base(iterator_adaptor<D,B,V,T,R,Di> const & it) > { > return base(it.base()); > } > > I can't think of a way to write the return type of the second overload. > If iterator_adaptor had a nested typedef for its Base template > parameter, this would be very straightforward. Seems reasonable. Can you submit a patch? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 6

xml_grammar.cpp and OS X
by Alan 17 Jan '05

17 Jan '05

What is the state of the release build hang on xml_grammar.cpp on OS X? Has anyone endevoured to block out the offending optiminzation? This is were I saw the message discussed last. http://aspn.activestate.com/ASPN/Mail/Message/2233439 -- Alan Gutierrez - alan(a)engrm.com

13 36

[program_options] multi-line description patch
by Bertolt Mildner 17 Jan '05

17 Jan '05

What do you think about the attached patch to enable correct formated multi-line option descriptions? It is not pretty but is has the following features: - Formats multi-line descriptions using first_column_width and a given line length (currently hardcoded). - If set up for a shell with 80 chars per line it uses only 79 *but* also formats correctly in larger shells. - Handles '\n' in description strings. - Trimms leading *single* spaces in new lines (" that" gets trimmed, but " leave my formatting" not). - Words are not chopped at line endings but put to new line (if not more that half the line would be empty). Known problems: - If the current shell has too short lines the formatting is all messed up. - Chokes on '\t', they are currently not handled in any way. - Sacrifices one char to be able to format correctly in larger shells. - Code is a "iterator arithmetic" hell. :( - The line length should be a parameter of options_description with a default value (probably 80). With this users may query the current shell for its line length, if possible. Patch compiles fine on CW 8.3 and VC 7.1. Maybe heaving two modes would also be a good idea? One as a "safe mode" where one char is sacrifices but the line length may be longer and another mode where the exact line length is known and fully used ... The following code ... ---------------------------------------------------------- po::options_description options("Options"); options.add_options() ("help", "a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg ") ("well_formated", "As you can see this is a very well formatted option description.\n" "You can do this for example:\n\n" "Values:\n" " Value1: does this and that\n" " Value2: does something else\n" " Value3: has a very long\n description.") ; std::cout << options << "\n"; ---------------------------------------------------------- ... gives this output. ---------------------------------------------------------- Options: --help a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg --well_formated As you can see this is a very well formatted option description. You can do this for example: Values: Value1: does this and that Value2: does something else Value3: has a very long description. ----------------------------------------------------------

4 19

RFC: mixing std::map and boost::optional
by Ulrich Eckhardt 13 Jan '05

13 Jan '05

I had the idea to use boost::optional on the interface of a std::map-like object. I have neither coded a prototype nor is this a fully grown design yet, I'd just like to discuss this idea. The rough outline is this: class my_map { public: optional<value>& operator[](key const&); optional<value> const& operator[](key const&) const; // iterators, ctors, dtor, etc the same private: optional<value> const m_empty_value; tree< pair<key, optional<value> > > m_content; }; The important differences to std::map are: 1. operator[] is available as const and non-const memberfunction. The const memberfunction returns 'm_empty_value' in case the key is not found. The non-const one inserts a new node into the tree and returns a reference to that. 2. operator[] return an optional<value>, not a direct value. This means that you have to check the return-value of this call. OTOH, you _can_ check the return value to see if a key was associated with a value. Some example code, compared with the equivalents using std::map: // two maps std::map<string,float> stdmap; my_map<string,float> mymap; // const references, for cases where it makes a difference std::map<string,float> const& stdmapc = stdmap; my_map<string,float> const& mymapc = mymap; ///////// inserting an element: stdmap["key"] = 41.0f; mymap["key"].reset(42.0f); ///////// accessing an element access(stdmap["key"]); std::map<string,float>::const_iterator it = stdmapc.find("key"); if(it!=stdmapc.end()) access(it->second); else access(float()); boost::optional<float>& value = mymap["key"]; if(value) access(*value); else access(float()); boost::optional<float> const& value = mymap["key"]; if(value) access(*value); else access(float()); ///////// removing an element stdmap.erase("key"); mymap["key"].reset(); ///////// finding out if an element exists if(stdmap.find("key") != stdmap.end()) found(); if(mymap["key"]) found(); ///////// iterating and accessing for(std::map<string,float>::const_iterator it=stdmap.begin(); it!=stdmap.end(); ++it) access(it->second); for(my_map<string,float>::const_iterator it=mymap.begin(); it!=mymap.end(); ++it) if(it->second) access(*(it->second));

2 1

program_options: compilation fixes
by Graham Bennett 12 Jan '05

12 Jan '05

Hi, parsers.cpp and value_semantic.cpp in 1.32.0 both use 'tolower' without including <cctype>, which on my platform is not included as a side-effect of one of the other headers. I have attached patches which make it compile cleanly for me. Thanks, Graham. -- Graham Bennett

2 1

Boost Thread - Read Write Mutex Problem
by David Brownell 11 Jan '05

11 Jan '05

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. Thanks for your help! David Brownell

3 2

[iostreams] Version of Iostreams compatible with 1.32 available
by Jonathan Turkanis 11 Jan '05

11 Jan '05

Hi All, A version of the Iostreams library designed to work with release 1.32 is now available: http://home.comcast.net/~jturkanis/iostreams/ This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular, - The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them. I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0. I'm hoping to get a version into CVS soon. Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form. -- Jonathan Turkanis technews(a)kangaroologic.com

10 35

[gui] The Big Picture
by Reece Dunn 10 Jan '05

10 Jan '05

Hi All, We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required. There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc. Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)? The design for the UI object layer must be able to support: * native-based UI objects that are dynamically constructed. * native-based UI objects taken from pre-built elements, e.g. objects on a form. * lightweight UI objects that are not native-based. * custom drawn native-based UI objects (either dynamically constructed or from pre-constructed objects), in essence a hybrid of native-based and lightweight UI objects. All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as: ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ... Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs. A UI object consists of event processing and sizing/positioning. A frame is a UI object that has border (frame) decoration, with a main frame being a top-level frame, a form being a frame that is defined by an external resource and a popup is a frame that hosts components (e.g. a list of menu items for a specific menu item). A widget is a UI object that has specific events and data associated with it. A layout manager is a lightweight UI object that aids the positioning of widgets. The question is how to make it easy to specify both lightweight and native UI objects. Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible? I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider: ui::button ok( "OK", ui::button::push ); ui::button_impl< ui::lightweight_button > cancel( "Cancel" ); Likewise, having a constructor that takes an implementation, how do we construct the generic interface that allows this implementation. Consider: ui::button cancel( "Cancel", new ui::lightweight_button()); Also, having a shallow interface (i.e. each UI object is a top-level object), you would need duplicate code to handle common things like event handling and move/resize operations. All of these approaches has their own advantages and disadvantages. Regards, Reece

21 45