April 2006 - Boost - lists.preview.boost.org

Re: [boost] [Boost Review] Property Tree Library
by Matt Doyle 21 Apr '06

21 Apr '06

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Snip> > > Performance is a concern given the recursive nature of the > tree. I want write a test case parsing Usenet's group list. > By it's nature it demands storage in a hierarchical tree > where every node is both a leaf and a branch (like ptree :) , > it's a big list, and insertion / retrieval is mostly random. > Hopefully I'll have time to do this before the review is over. > > Snip> > > Let me just say (as a review maanger) that such a test would > be immensely useful (an an obvious candidate for inclusion > with the library if it is accepted). > > I know it is an easy task, though. Well, I finally have some performance results and, at to me at least, it looks pretty good. I used a partial snap shot of the Usenet groups list with 34767 records in it. I choose that particular file because I had previously used it to compare performance between MFC's TreeView and a handrolled tree using Berkley DB_TREE. TreeView parsed it in ~1200 seconds, Berkley at ~40 seconds, and now Ptree came in at 7.5 seconds. To be fair, I didn't re-run the first two tests today, I just used my results from previous tests so that may have been a slower computer (~two years ago). Anyway, of the 7.5 seconds 4.3 of it was I/O time so the library time to build & populate the tree was 3.2 seconds, or 92uS per node. Iterating the tree and writing it back out took 2.187 seconds, the average seek time to search for a record was 16uS and the average time to search and modify the same record was 125us. SO all that being said, I want to re-affirm my vote that Ptree should be accepted. One thing aside though, I want to harp on the documentation again. While the library was easy to use there were a few nuances that I had to research along the way. I think that at a minimum we need to have some concrete examples, starting at main(), showing the usage of each of the parsers. Attached is the test dataset and the test program if anyone else wants to independently retest it. Regards, Matt Scanned by McAfee GroupShield {X3BTB534}

1 0

Building boost with STLport 5.0.2 and Visual Studio 2000 (vc80)
by Marcello Pietrobon 21 Apr '06

21 Apr '06

Hi, just in order to make life a bit simpler I desire to write some simple imformations about how I did compile boost with vc80 and STLport, as this is not in the boost help yet. The command line is: STLport was installed in the directory D:\Projs\Libraries\BSD\STLPort\STLport-Active and I build it with the cross compilation option on. I went to the boost installation directory and run: bjam "-sTOOLS=vc-8_0-stlport" "-sSTLPORT_VERSION=5.0.2" "-sSTLPORT_5.0.2_PATH=D:\Projs\Libraries\BSD\STLPort \STLport-Active" "-sBUILD=debug release <runtime-link>static/dynamic <threading>multi <native-wchar_t>on <stlport-cross>on" "--without-python" install The option "<native-wchar_t>on" is not necessary as in vc80 *wchar_t* is already a built in type by default ( and stlport 5.0 assumes the same by default when compiled with vc80 ) I also had to modify the file tools\build\v1\stlport.jam and modify the line: STLPORT_VERSIONS(5) ?= 5.0.2 5.0.1 5.0 ; ( by adding 5.0.2 ) And I had to create the file: tools\build\v1\vc-8_0-stlport-tools.jam which I created by comparing vc-8_0-tools.jam, vc-7_1-tools.jam, and vc-7_1-stlport-tools.jam I attached those files to this post. Everything seems fine now, Hope it helps, Marcello P.S. After switching to vc80 I decided to switch back to the previous version, because too slow, and tired after three weeks of working around bugs and problems with native C++ in that release... # (C) Copyright Gennadiy Rozental 2002. Permission to copy, use, # modify, sell and distribute this software is granted provided this # copyright notice appears in all copies. This software is provided # "as is" without express or implied warranty, and with no claim as # to its suitability for any purpose. # Use this toolset to add STLport flavor for any base toolset # define STLPORT_LIB_BASE_NAME to the shared between debug and release # versions prefix for stlport library name for example stlport_sunpro # Define STLPORT_AUTOLINK to use the autolink facilities of the new # STLport-5.0 # STLport iostreams or native iostreams feature stlport-iostream : on off ; # STLport extensions feature stlport-extensions : on off ; # STLport anachronisms feature stlport-anachronisms : on off ; # STLport debug allocation feature stlport-debug-alloc : off on ; # ? feature stlport-cstd-namespace : std global ; # STLport-5 libraries are located in cross-compilation individual subdirectories. feature stlport-cross : off on ; CURR_TOOLSET = $(gCURRENT_TOOLSET) ; # STLport versions STLPORT_VERSIONS(default) ?= 4.6.2 ; STLPORT_VERSIONS(4) ?= 4.6.2 4.6 4.5.3 4.5 ; STLPORT_VERSIONS(5) ?= 5.0.2 5.0.1 5.0 ; STLPORT_VERSION ?= $(STLPORT_VERSION(default)) ; STLPORT_VERSIONS ?= $(STLPORT_VERSIONS(4)) $(STLPORT_VERSIONS(5)) ; feature stlport-version : [ unique $(STLPORT_VERSION) $(STLPORT_VERSIONS) ] ; flags $(CURR_TOOLSET) STLPORT_VERSION_RELEVANT_FEATURE <stlport-version> ; # singleton variables... set-as-singleton STLPORT_INCLUDE_DIRECTORY STLPORT_LIB_DIRECTORY STLPORT_PATH STLPORT_ROOT ; ############################################################################# # Returns a path which is assumed to be the root of the STLport installation. # # The result depends on the current version X.Y of STLport. # 1. If global STLPORT_<X.Y>_PATH is set, return it. # 2. If global STLPORT_PATH is set, return $(STLPORT_PATH)/STLport-<X.Y> # rule get-stlport-root { local version = [ get-values <stlport-version> : $(gBUILD_PROPERTIES) ] ; version ?= $(STLPORT_VERSION) ; local path ; path ?= $(STLPORT_$(version)_PATH) ; path ?= $(STLPORT_PATH)$(SLASH)STLport-$(version) ; path ?= $(STLPORT_ROOT) ; #<< For backward compatability. if $(version) && ! $(path) { local dollar = "$" ; ECHO **** No STLPORT_PATH configured. *** ; ECHO To configure STLport for use with the $(CURR_TOOLSET) toolset, the following variables can be set: ; ECHO ; ECHO STLPORT_PATH - A directory containing at least one subdirectory of the form /STLport-<version> ; ECHO " where STLport installations can be found." ; ECHO ; ECHO STLPORT_<version>_PATH - The directory where the specific STLport <version> installation can be ; ECHO " found, in case there is no central location appropriate for STLPORT_PATH, above, or a" ; ECHO " particular version's installation is not located in the usual place." ; ECHO ; ECHO STLPORT_VERSION - The version of STLport in use by default. Defaults to \"$(STLPORT_VERSIONS(default))\". Other ; ECHO " values can be selected in parallel setting the build property <stlport-version> to" ; ECHO " values from the list of $(dollar)(STLPORT_VERSIONS)" ; ECHO ; ECHO STLPORT_VERSIONS - Alternate versions of STLport available on this machine. Defaults to $(STLPORT_VERSIONS:J=" ") . ; ECHO ; ECHO "Note that STLport iostreams are /not/ in use by default. To enable them, you must place" ; ECHO " <stlport-iostream>on in your BUILD variable or in target requirements." ; EXIT ; } return $(path) ; } ############################################################################# STLPORT_INCLUDE_DIRECTORY ?= stlport ; STLPORT_LIB_DIRECTORY ?= lib ; STLPORT_BIN_DIRECTORY ?= bin ; STLPORT_LIB_DEBUG_SUFFIX ?= _stldebug ; # Clear out the STD paths so that the real toolset doesn't include # anything but the STLport as the STD. But also set the STDLIBPATH to # include the compiler libs afterwards as STLport still relies on the # rest of the runtime. local .stdlibpath = $(STDLIBPATH) ; STDHDRS = ; STDLIBPATH = ; ### Common options. flags $(CURR_TOOLSET) STDHDRS : [ join [ get-stlport-root ] $(SLASH)$(STLPORT_INCLUDE_DIRECTORY) ] ; flags $(CURR_TOOLSET) DEFINES <stlport-extensions>off : _STLP_NO_EXTENSIONS=1 ; flags $(CURR_TOOLSET) DEFINES <stlport-anachronisms>off : _STLP_NO_ANACHRONISMS=1 ; flags $(CURR_TOOLSET) DEFINES <stlport-cstd-namespace>global : _STLP_VENDOR_GLOBAL_CSTD=1 ; flags $(CURR_TOOLSET) DEFINES <exception-handling>off : _STLP_NO_EXCEPTIONS=1 ; flags $(CURR_TOOLSET) DEFINES <stlport-debug-alloc>on : _STLP_DEBUG_ALLOC=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ### STLport 4.x flags $(CURR_TOOLSET) DEFINES <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>off : _STLP_NO_OWN_IOSTREAMS=1 _STLP_HAS_NO_NEW_IOSTREAMS=1 ; flags $(CURR_TOOLSET) STDLIBPATH <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>on : [ join [ get-stlport-root ] $(SLASH)$(STLPORT_LIB_DIRECTORY) ] $(.stdlibpath) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(STLPORT_VERSIONS(4))/<stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; ### STLport 5.x switch $(CURR_TOOLSET) { case msvc* : STLPORT_AUTOLINK = TRUE ; case vc* : STLPORT_AUTOLINK = TRUE ; } switch $(CURR_TOOLSET) { case intel-win32* : STLPORT_CROSS_DIR ?= icl ; case iw* : STLPORT_CROSS_DIR ?= icl ; case msvc* : STLPORT_CROSS_DIR ?= vc6 ; case vc-6* : STLPORT_CROSS_DIR ?= vc6 ; case vc-7-* : STLPORT_CROSS_DIR ?= vc70 ; case vc-7_0* : STLPORT_CROSS_DIR ?= vc70 ; case vc-7_1* : STLPORT_CROSS_DIR ?= vc71 ; case vc-8* : STLPORT_CROSS_DIR ?= vc8 ; } switch $(CURR_TOOLSET) { # GCC compilers have 'g' to indicate debug. case gcc* : STLPORT_DEBUG_SUFFIX ?= g ; case mingw* : STLPORT_DEBUG_SUFFIX ?= g ; case darwin* : STLPORT_DEBUG_SUFFIX ?= g ; # The others use 'd'. case * : STLPORT_DEBUG_SUFFIX ?= d ; } # STLport-5 doesn't directly support single-threaded builds. There is an open # question if single-threaded application code can be combined with the # multi-threaded STLport-5. Until that's answered this is commented out and # boost-base.jam requires all builds to be multi-threaded. #~ flags $(CURR_TOOLSET) DEFINES #~ <stlport-version>$(STLPORT_VERSIONS(5)) : #~ _STLP_THREADS=1 ; flags $(CURR_TOOLSET) STDLIBPATH <stlport-version>$(STLPORT_VERSIONS(5))/<stlport-cross>off : [ join [ get-stlport-root ] $(SLASH)$(STLPORT_LIB_DIRECTORY) ] [ join [ get-stlport-root ] $(SLASH)$(STLPORT_BIN_DIRECTORY) ] $(.stdlibpath) ; flags $(CURR_TOOLSET) STDLIBPATH <stlport-version>$(STLPORT_VERSIONS(5))/<stlport-cross>on : [ join [ get-stlport-root ] $(SLASH)$(STLPORT_LIB_DIRECTORY) $(SLASH)$(STLPORT_CROSS_DIR) ] [ join [ get-stlport-root ] $(SLASH)$(STLPORT_BIN_DIRECTORY) $(SLASH)$(STLPORT_CROSS_DIR) ] $(.stdlibpath) ; if ! $(STLPORT_AUTOLINK) { STLPORT_LIB_STATIC_SUFFIX ?= "" ; for local v in $(STLPORT_VERSIONS(5)) { flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(v)/<runtime-build>debug/<runtime-link>static : stlportstl$(STLPORT_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX).$(v) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(v)/<runtime-build>debug/<runtime-link>dynamic : stlportstl$(STLPORT_DEBUG_SUFFIX).$(v) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(v)/<runtime-build>release/<runtime-link>static : stlport$(STLPORT_LIB_STATIC_SUFFIX).$(v) ; flags $(CURR_TOOLSET) FINDLIBS <stlport-version>$(v)/<runtime-build>release/<runtime-link>dynamic : stlport.$(v) ; } } extends-toolset msvc ; flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ; STLPORT_LIB_BASE_NAME = stlport_vc80 ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ; include stlport.jam ; # singleton variables... set-as-singleton VC80_ROOT ; if ! $(MSVCDir) { if $(VS80COMNTOOLS) { VC80_ROOT ?= $(VS80COMNTOOLS:J=" ")..\\..\\VC ; } else { ProgramFiles ?= $(PROGRAMFILES) ; VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; } } if $(VC80_ROOT) { VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ; VC_SETUP = "CALL \"$(VC_TOOL_PATH)vcvars32.BAT\" >nul" ; } VC_PDB_NAME = vc80 ; VC_MANIFEST = "mt -manifest " ; VC_OUTPUTRESOURCE = -outputresource: ; # feature native-wchar_t : on off ; # commented as the default in vc80 # flags vc-8_0-stlport CFLAGS : /fp:precise ; # this is the old /Op ; /fp:precise is slower but really precise and handles NaN well. But then I should recompile STLport ? In the doubt I commented it. # flags vc-8_0-stlport C++FLAGS : /wd4675 ; # Doesn't warn about the use of ADL # flags vc-8_0-stlport C++FLAGS : /Zc:forScope ; # commented as the default in vc80 # flags vc-8_0-stlport C++FLAGS <native-wchar_t>on : /Zc:wchar_t ; # commented as the default in vc80 flags vc-8_0-stlport C++FLAGS : /wd4996 ; # disables _CRT_SECURE_NO_DEPRECATE warning. This is like _SCL_SECURE_NO_DEPRECATE. see tools/build/v1/vc-8_0-tools.html # The following #// line will be used by the regression test table generation # program as the column heading for HTML tables. Must not include version number. #//<a href="http://msdn.microsoft.com/vstudio/default.asp">Micro-<br>soft<br>VC++</a><br><a href="http://www.stlport.org/">STLport</a>

1 0

Improving the Boost Review process
by Jose 21 Apr '06

21 Apr '06

I would like to bring up some ideas to improve the review process: 1. Have a priority list with the new libraries that boost users need ---------------------------------------------------------------------------------------------- a) must have libraries b) nice to have c) interesting e.g. is Boost.SQL a nice to have or a must have ? is a Boost.Relational (e.g. RTL-like) a nice to have or a must have ? e.g. the current Property List library being reviewed: - shouldn't it be part of the existing program options library (if its intended usage is similar to program options library vs a generic tree container) ? This would help people working on related libraries to focus their effort or even contribute when they were not planning to. Also, review time will be optimized and the review queue can be prioritized based on this list. The names can be proposed at this stage so that they are general as intended. This could also help identify existing libraries that need to evolve, like the ongoing effort in Boost.Threads 2. Have a high level review before a detailed review -------------------------------------------------------------------------- a) Is the library in the priority list ? b) Should it be a separate library or merge with an existing one ? There can be lots of small libraries but many might not continue to evolve or be world-class. c) Is the library really world-class or broadly useful? There can be libraries that have multiple functionality but none is great. A good example for this is with libraries that incorporate some xml functionality but it's very limited and then you have to rely on another library for broader usage. The priority should be to add libraries that are designed with the intent of becoming a world-class library (even if they offer limited functionality when reviewed). The outcome of the high level review should be whether to engage in a detailed review or wait till some conditions are met. 3. Encourage specialized libraries ------------------------------------------------- There are many libraries that have a smaller audience but if they are designed to be world-class then they bring value to boost. Also, there has to be a process so that libraries can continue to evolve once they are part of boost, considering that in many cases the original authors may not be available to contribute. This needs thinking but it would be good to get more people to contribute to libraries in which they were not the original authors.

5 7

[function] Anything to adapt a boost::function object?
by Chris Uzdavinis 21 Apr '06

21 Apr '06

Hi, I have an idea of something, and am not sure if Boost provides it. In short, I'd like an adapter object that "wraps" a boost::function object, and changes the interface such that all the N arguments are taken as strings, automatically converted (using lexical_cast?) to the proper types, and then invoke the boost::function object passsing in those parameters. For example, I envision something like this: #include "boost/function.hpp" #include <iostream> void func(int i, char c) { std::cout << "f called with " << i << " and " << c << std::endl; } int main() { boost::function<void(int, char)> f; f = &func; // I'm wanting something like this. boost::function_string_adapter str_f(f); // call func() but pass string args instead of int,char str_f("123", "x"); // invokes f(123i, 'x') } The magic is that boost::function knows the proper types, so the adapter could ask it to what type each string needs to be converted, then it could do a lexical_cast to get the value. My motivation for wanting this is to implement a "simple" command interpreter for a socket-based administrative interface. I pre-register a bunch of function objects, then whenever someone sends a command down the socket, it arrives as a string. The function object is looked up by name, and then the call-operator is invoked given the string arguments. Internally, the proper string-to-type converstions occur, and the boost::function is called with those values. (If the conversion fails, an exception would be perfectly reasonable.) Is this possible with anything in boost? Would the idea I show above be a good way to go, or might boost::function be the wrong approach? Thanks in advance! -- Chris

2 2

filesystem/path behavior
by Sebastien Mirolo 21 Apr '06

21 Apr '06

Hi, I was trying to use the boost::filesystem::path class (from boost_1_33_1) and surprisingly, the following little piece of code just asserts: /* g++ -v -I${HOME}/installed/local/include -L${HOME}/installed/local/ lib \ -o boost boost.cc -lboost_filesystem */ #include <boost/filesystem/path.hpp> int main( int argc, char *argv[] ) { boost::filesystem::path p("/usr/include/c++/4.0.0/cstring"); return 0; } Bahia:bugs$ ./boost terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring" Abort trap Bahia:bugs$ Is there any reason why I couldn't construct a path like this? I was just trying to access a file in the default include directory of the gcc install on Mac OSX 10.4. Thank you, Sebastien.

7 11

Escape to HTML from QuickBook
by Alex Besogonov 21 Apr '06

21 Apr '06

Good <time-of-day>! I'm trying to write documentation for my project in QuickBook and I have a little question: is it possible to escape to direct HTML markup from QuickBook (or BoostBook) source? I'm trying to add imagemap as, for example, in this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/h… BTW, I've added support for VisualBasic and IDL syntax highlighting to QuickBook. I can send patches if anyone is interested in it. -- With respect, Alex Besogonov (cyberax(a)elewise.com)

5 4

[type_traits] function_traits doc bug
by Eric Niebler 21 Apr '06

21 Apr '06

In the documentation for function_traits, the "Function Traits Members" table says that argN_type is 1-based (which is right), but the "Examples" immediately below it show it to be 0-based (which is wrong). -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

Re: [boost] [Boost Review] Property Tree Library
by Matt Doyle 20 Apr '06

20 Apr '06

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Thorsten Ottosen > I have the great pleasure to announce that the formal boost-review of > Marcin Kalicinski Property Tree Library begins now (the 18th > * What is your evaluation of the design? > * What is your evaluation of the implementation? I think that both the design and the implementation are sound, clearly a great deal of thought and effort went into this design. I like the container-like interface so that I can iterate through the tree but more so I like the ability to just enter the full path to the element that I want with out first having to search for it. > * What is your evaluation of the documentation? I think it could use some expanding upon. First, as was already mentioned, the index needs to be broken up into smaller topics. Next I think there should be more discussion (tutorial) on customizing the library. > * What is your evaluation of the potential usefulness > of the library? Great! My opinion is that this library is going to see far more usage than just what it was intended for. My initial reaction when I looked at it is that it's more of a generic hierarchical tree, moreover, once you've populated your tree you can save it off and come back to it another day. Just taking those two aspects into consideration opens the door to a lot of possibilities, far more than just reading configuration data. > * Did you try to use the library? With what compiler? > Did you have any problems? In process > * How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? So far only a few hours, but more to follow. > * Are you knowledgeable about the problem domain? To a degree, yes. > > And finally, every review should answer this question: > > * Do you think the library should be accepted as a > Boost library? > Be sure to say this explicitly so that your other comments > don't obscure your overall opinion. Absolutely! I think this library will be suitable for a number of applications. > > In particular, consider if you can answer the following questions: > > - was the library suitable for your daily xml-tasks? If not, what was > missing? > > - was the library's performance good enough? If not, can you suggest > improvements? Performance is a concern given the recursive nature of the tree. I want write a test case parsing Usenet's group list. By it's nature it demands storage in a hierarchical tree where every node is both a leaf and a branch (like ptree :) , it's a big list, and insertion / retrieval is mostly random. Hopefully I'll have time to do this before the review is over. > > - was the library's design flexible enough? If not, how would you > suggest it should be redesigned to broaden its scope of use? The number one place I see this library being specialized, both by the users and the maintainer, is in the parsers. Case in point, my above test requires me to write a different parser. I think it would be useful in the long run to have a basic_parser<...> that could be inherited from as an interface to the user who needs to write their own parser. All the preprocessor stuff, or other implementation details, can be hidden there so that the user just inherits and parses away. There may be other places where customization hooks make sense... Any thoughts? regards, Matt Doyle > > best regards > > Thorsten Ottosen, Review Manager > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by McAfee GroupShield {X3BTB534}

4 4

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 20 Apr '06

20 Apr '06

Beman Dawes wrote: > The C++ Standards Committee met last week in Berlin, Germany. Of interest to > Boosters: > > * Boost Filesystem was voted into TR2. That is great news. It's good to see directory iterators in there too :). > * Boost Lexical Cast has been tentatively accepted by the LWG for TR2. This has to be one of the most useful utilities in Boost. > * A Boost Date-Time query was presented at the last meeting, and LWG members > again in Berlin indicated interest in seeing a full proposal for TR2. This is good news. > * It looks more and more likely that Concepts will go into C++0x. If > Concepts do go into the core language, the LWG has indicated their intent to > percolate Concepts throughout the Standard Library. (Concepts were being > held up by two competing proposals, but those two proposals are in process > of being coalesced into a single proposal by Bjarne Stroustrup and Doug > Gregor.) This is great news. Concepts will be a very useful addition to C++0x. In terms of C++0x features, what is the current state of lambda support as I have seen several papers from Bjarne, et. al.? - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

22 45

[bug] typo in type_with_alignment.hpp
by pongba 20 Apr '06

20 Apr '06

template<std::size_t TAlign, std::size_t Align> struct is_aligned { BOOST_STATIC_CONSTANT(bool, value = (TAlign >= Align) & (TAlign % Align == 0) ^^^ <<---- here! ); }; Should it be "&&" instead of "&"?

3 2

Re: [boost] [Boost Review] Property Tree Library
by Ivan Vecerina 20 Apr '06

20 Apr '06

"Thorsten Ottosen" <thorsten.ottosen(a)dezide.com> wrote in message news:44453A4C.2040302@dezide.com... : * What is your evaluation of the design? First I apologize for having no awareness of the lib's history. This is also my first review [ I usually don't have time for that, does it suffice to say that I have 4 small kids? ] I will highlight with ** (on the beginning of the line) each question/point for which I would appreciate an answer or discussion or action. I'd say at first glance that it felt a bit XML-centered [ which is neither good nor bad, but the reflection of some design choices, and wanting to be very general ] My vision of a property-tree is more of a "node" base class with three subclasses: - Leaf -- which stores actual data ~= string - Array -- which includes an array ~= vector<node> - Record/Dictionary/Object -- named fields ~= map<string,node> This is how most scripting languages support as building block for any data structure -- and why you find this at the core of JSON ( http://www.json.org/, probably a must-read for any reviewer). I dislike the fact that any 'tree' has a default value, that 'leaves' are trees, that a node can be an hybrid of an arrray and a record ( contain both unnamed or other repeated fields, and structured named fields). I prefer a design that imposes a minimal level of validation of the structure of the data (like I prefer xhtml to the excessively 'loose' original html) -- I think that the result is more maintainable. An example issue: ** [Based on Tutorial] what happens when I call pt.get<std::string>("debug.filename"); if there is two 'filename' fields under 'debug' ? This should generate a failure (throw an exception), and this should be explained in the documentation. Also, I would have preferred to have a better built-in support for arrays. As it is, one can use a "path" to directly access a child -- except if an array is involved. In my use of related libraries, arrays are very common, either as object lists, or as "leaves" (e.g. vector coords). I find this asymmetry (support for Records > Arrays) disturbing. Regarding iteration: In similar libraries I have been using, I liked having support for 'streaming' data or visiting the whole tree as a whole. Basically being able to flatten the 'tree' into a sequence of data fields. Having such an infrastructure at the core of the library makes it trivial to implement a number of i/o formats - see the reference to the DataTree design discussed below. This will also simplify cross-tree operations such as merge/intersect/override -- which you suggest as extensions. : * What is your evaluation of the implementation? Independently of the above design decisions, there are some things I would do differently for the library's interface: ** I would prefer the member-function interface to be minimal. ptree reminds me much of std::string, with too many overloads. Overall, a ptree is nothing more that a collection of named sub-tree, and its 'own' data field. I would only include getters and setters for these two fields, and leave all the rest to non-member functions, because different users may want to implement different interfaces. Keep things orthogonal and avoid multiplying overloads. ** 'separator' should not be a data member. This mixed usage of default/non-default separators only feels like a mess. Choice of separator is an access/interface method choice, not a property of the stored data. ** 'find-by-path' functions would be a set of non-member functions. Implement them with a default-separator choice (or make an internal but documented version that takes the separator as a param for those who want to customise their separator and use their own inline-forwarder functions). ** By the way, why not include support for arrays in: your paths - for example: get(pt,"debug.modules[0]"); ** the get/get_default/get_optional should be a *single* set of non-member functions applying to a ptree, or ideally maybe an optional<ptree&>. ** I have a similar library that provided template-overloads of node >> T and node << T , which can be a convenient notation for conversion/extraction. Specializing these template overloads is how you define custom converters for your built-in types. ** There should be a way to specialize get/put functions in a way that translate e.g. vec3f (3 float coordinates) to/from a ptree ( which I will implement as a 3-value array). Or from a struct to/from a ptree? How do I do implement this? The least is to have a plan defined for supporting this. The above would make the interface much cleaner IMO. It offers increased flexibility/customizability to end-users. I don't think that this has to impair usability. If I try to rewrite the "tutorial" based on the interface I envision, it could look like: reading: using boost::property_tree::ptree; ptree const pt = read_xml( filename ); //BTW: Should a value-returning version of read_xml() // not be provided? Some care more for convenience // than performance. And hopefully we will have // R-value references soon... m_file = get<std::string>( access(pt,"debug.filename") ); //or: get(pt,"debug.filename") >> m_file; //or: pt % "debug.filename" >> m_file; // too funky ?? m_level = tryget( access(pt,"debug.level") , 0 ); // for ex. writing: // simple overall anyway... put( pt, "debug.filename", m_file ); // or whatever... : * What is your evaluation of the documentation? Besides the error-handling for ambiguous paths mentioned early on, I would like to see: ** a description of the mechanism used to convert ordinal values into 'data'. I assume this is simply ostringstream, but I haven't seen this specified anywhere. ** Can you provide examples of the representation of common types (e.g. bool(true/false), char, int, double(precision?) ) ** If I want to implement a custom 'translator' (value to text and text to value) for a custom type (e.g. "BigInt"), what template functions do I need to specialize? Can I specialize this independently from istream/ostream ? [ and again, can I define a struct<->ptree conversion ? ] : * What is your evaluation of the potential usefulness : of the library? Very high, obviously. As it is, this lib is already much better (IMO) than many other similar libraries I've seen (xml and other). : * Did you try to use the library? With what compiler? : Did you have any problems? No, just reviewed the docs and sources. Too little time, sorry. : * How much effort did you put into your evaluation? : A glance? A quick reading? In-depth study? In-depth look for few hours. : * Are you knowledgeable about the problem domain? I have personally written a similar C++ library about 12 years ago, which I have refined and iterated several times. I had been calling it "DataTree" (but PrepertyTree is a much better name). The three companies I previoiusly worked at still use it... I even once started writing a version of this library in C, which is available at http://ivan.vecerina.com/code/datatree/ , and illustrates some of the core concepts (but obviously not the interface itself, which can be much nicer with C++ -- beware of the ugly C idioms in this posted code...). I would say that the C++ version of DataTree has pros and cons compared to ptree. [ sorry, I don't see how to post the C++ version as it relies on a number of proprietary libraries... ] Some of the key design differences include: - A Tree streaming or traversal system is built-in A tree can be transferred as a sequence of "tree steps". A tree can be built from such a sequence, or traversed as such a sequence (using a visitor pattern). A 'validator' class is able to verify the consistency of the sequence of tree steps (on-the-fly). This makes it *very easy* to create a reader/writer for a number of file formats (you don't need to check the grammar/consistency in each parser, it is all done in one place). >> This would be a nice-to-have; it eventually could be implemented later as an internal add-on to the current design. - 3 types of nodes are distinguished (leaf,array,record) Basically, these are 3 subclasses of a common 'node' base class. The fields of a record are (unique and ) sorted by name -- which might be better for performance if large records are used. I prefer having this more restrictive distinction between leaves, arrays, and records. But being more 'loose' also helps ptree support closer compatibility with some formats (Windows registry, XML). Is this desirable? YMMV. >> Having either an std::map<string,node> or an std::vector<node> could afford better performance, or be easier to implement. Do potiential users of ptree want this additional flexibility? I guess so. Should it be possible to check that the structure of a ptree instance obeys stricter structural rules? Maybe, but not critical, probably - all node types use built-in reference counting (you can therefore make shallow copies of a tree if desired, and sub-trees can be passed to other objects that store them without copying). >> This made sense with polymorphic base class approach I took, but ptree's current approach is good as it is. - I implemented a couple of binary and scrambled file formats too. This *is* convenient when you don't want users to mess with a configuration file. Checksums are also a requirement when storing potentially critical data (I do medical stuff). >> Adding new formats to ptree is easy for end-users to do. - I don't use iostreams for I/O but always byte-oriented streams. I consider the internal format to be fixed and byte-oriented. I also use memory-mapping and platform-specific tricks for most of the file I/O, because performance mattered in my applications. The encoding from C++ values to bytes is determined by the top-level value i/o functions. The default converters use stringstream, but they can be specialized at well for custom types. Users may also use a different set of converters (it would be possible to use binary formatters instead of text). >> ptree's approach is more conform to the boost approach. - With the above choices, the core library is not templated. Only the value<->node conversions are done in template code, and only this can be specialized. Implementation details are hidden, compile times are faster. >> ptree's approach is more conform to the boost approach. ( LOL ) - like 'archives'(IIRC) in boost::serialize, I have a system allowing to write a single template function that will either export or import values to a tree. >> This would be an interesting future add-on for ptree. - I never bothered to implement path-based access to heirs. I always wanted to do it. But in practice, I have never needed it. All in all, my C++ DataTree library design is more 'classic': more OOD, less templates (except for interface/usability magic), more performance-oriented (did matter for me). But less general. : And finally, every review should answer this question: : : * Do you think the library should be accepted as a Boost library? : Be sure to say this explicitly so that your other comments : don't obscure your overall opinion. YES - but with requests for modifications. ptree is superior to most efforts I have seen. As expressed in my above comments (**), I feel that the interface needs to be made leaner, to improve flexibility/customizability. I haven't gone into the details of how to break-up the orthogonal aspects of the interface ( 3-kinds of get, child access, path access). But I would strongly recommend to explore & do this, as it will matter to make the library more 'evolvable'. In the same line, I also would like to see a clear documentation of how the value<->tree conversions are made, and how they can be specialized. My gripe regarding the 'too loose' structure is a personal peeve, I understand well that many would not care. : In particular, consider if you can answer the following questions: : : - was the library suitable for your daily xml-tasks? If not, what was : missing? It's good that XML is supported as a text format too. But honestly I don't care. : - was the library's performance good enough? If not, can you suggest : improvements? Performance should be ok for most users. Just as for iostreams, it might be a gripe that will come up periodically. But it shouldn't be a showstopper. : - was the library's design flexible enough? If not, how would you : suggest it should be redesigned to broaden its scope of use? Too flexible in my personal opinion. This is my very first review, and this is the end of a long work day. I don't have the strengh to review what I wrote -- please forgive me. Kudos to Marcin Kalicinski, and to any others who have contributed to this excellent work. Only because it can be so important, this library is worth perfecting... Kind regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [boost] [Boost Review] Property Tree Library
by Trent Nelson 20 Apr '06

20 Apr '06

> 1. Values which are expanded statically during parsing > 2. Values which are fully dynamic - i.e. lookup is performed > everytime you access the value (so if you change the original, > the dependent changes as well). I use something in between the two. When a property is fetched, expand any ${inline.properties} or %ENVVARS% before returning the value. This is more flexible than 1, as you can refer to properties before they've been defined: product.home = ${common.home}\product ... common.home = c:\foo\bar > 2. Values which are fully dynamic Is that really a common requirement? Every time I need inline value expansion it's usually to do with file system paths, and they're usually values that will never change once the software's been installed, let alone dynamically at runtime. Trent.

1 0

[Boost-bugs] [ boost-Bugs-1473245 ] Boost fails to compile for MSVC 8.0 for CE
by SourceForge.net 19 Apr '06

19 Apr '06

Bugs item #1473245, was opened at 2006-04-19 13:42 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=1473245&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost fails to compile for MSVC 8.0 for CE Initial Comment: In boost 1.33.1 Visualc.hpp was modified to add evc 4.0 and visual studio 8.0. However the macro UNDER_CE is defined also for visual studio 8.0 for CE builds. The error "error unknown CE compiler" This is an invalid error because thre is a CE version for Visual Studio 8.0. spencer.vanroekel(a)siemens.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1473245&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Wave] FIx for Jamfile.v2
by Juergen Hunold 19 Apr '06

19 Apr '06

Hi ! The following patch corrects a typo in tools/wave/build/Jamfile.v2 which prevents wave to be built. It seems that the wave tool is broken because I get tons of errors frm cpp.cpp. Yours, Jürgen -- * Dipl.-Math. JÃ¼rgen Hunold ! Ingenieurgesellschaft fÃ¼r * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister StraÃe 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

3 5

Boost.org delivering empty pages?
by Marshall Clow 19 Apr '06

19 Apr '06

As of 8:00 PDT this morning: Al:~ marshall$ curl -v http://www.boost.org >* About to connect() to www.boost.org port 80 >* Trying 66.35.250.210... * connected >* Connected to www.boost.org (66.35.250.210) port 80 > > GET / HTTP/1.1 >User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 >OpenSSL/0.9.7i zlib/1.2.3 >Host: www.boost.org >Pragma: no-cache >Accept: */* > >< HTTP/1.1 200 OK >< Date: Tue, 18 Apr 2006 14:59:41 GMT >< Server: Apache/1.3.33 (Unix) PHP/4.3.10 >< Last-Modified: Wed, 22 Feb 2006 23:50:20 GMT >< ETag: "b981-0-43fcf8bc" >< Accept-Ranges: bytes >< Content-Length: 0 >< Connection: close >< Content-Type: text/html > % Total % Received % Xferd Average Speed Time Time >Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- >--:--:-- 0* Closing connection #0 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

Re: [boost] [statechart] - BOOST_ASSERTION in state_machine::send_eventif used by multiple threads
by Oliver.Kowalke＠infineon.com 19 Apr '06

19 Apr '06

Same happens if I install a exception_translator in the enclosing state: /opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: void boost::statechart::state_machine<MostDerived, InitialState, Allocator, ExceptionTranslator>::send_event(const boost::statechart::event_base&) [with MostDerived = iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = std::allocator<void>, ExceptionTranslator = boost::statechart::exception_translator<boost::statechart::exception_thr own>]: Assertion `get_pointer( pOutermostUnstableState_ ) == 0' failed. >Hello, >I've several threads running. Each thread has its own state_machine. >Sometime (not reproducible) I get following assertion: > >/opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: >void boost::statechart::state_machine<MostDerived, InitialState, >Allocator, ExceptionTranslator>::send_event(const >boost::statechart::event_base&) [with MostDerived = >iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = >iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = >std::allocator<void>, ExceptionTranslator = >boost::statechart::null_exception_translator]: Assertion `get_pointer( >pOutermostUnstableState_ ) == 0' failed.

1 0

[statechart] - BOOST_ASSERTION in state_machine::send_event if used by multiple threads
by Oliver.Kowalke＠infineon.com 19 Apr '06

19 Apr '06

Hello, I've several threads running. Each thread has its own state_machine. Sometime (not reproducible) I get following assertion: /opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: void boost::statechart::state_machine<MostDerived, InitialState, Allocator, ExceptionTranslator>::send_event(const boost::statechart::event_base&) [with MostDerived = iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = std::allocator<void>, ExceptionTranslator = boost::statechart::null_exception_translator]: Assertion `get_pointer( pOutermostUnstableState_ ) == 0' failed. What does get_pointer( pOutermostUnstableState_ ) != 0' indicate? Regards, Oliver

1 0

Re: [boost] Compile tests for headers
by João Abecasis 19 Apr '06

19 Apr '06

Emil Dotchevski wrote: > I need to test each header in my libs, to make sure that it compiles without > errors when included as the first header in a CPP. What is the easiest way > to accomplish this? > > I was thinking of writing a simple tool which takes the command line for the > complier, generates a CPP file which includes the specified header and then > runs the compiler, however this would have to interface somehow with > boost-build, to get the command line (depending on the toolset used, and the > configuration), and I don't know how to do that. > > Any suggestions? Incidentally, just yesterday I finally ported to bjam+BBv2 a shell script I've been using for the same purpose. See attached. You should put headers.jam file in the same directory as your Jamfile[.v2] or somewhere where Boost.Build can find it (e.g., in BOOST_BUILD_PATH). For example, to test the compilation of Boost.Spirit headers, in (boost-root)/libs/spirit/test/Jamfile.v2 one could have: import headers ; import testing ; test-suite "spirit.headers" : [ headers ../../../boost/spirit ] ; At this point the code is the documentation, but I added some comments explaining each function's purpose. Perhaps this, or something along the lines of it, could be added to the regression tests, to ensure that all headers compile independently. FWIW, my former bash script used to report lots of non-compilable files inside boost. What do others think about this? I'd like to hear your comments on the approach and implementation, as well as bug reports ;-) Best regards, João

1 0

Boost::any operator==
by Jorge Lodos 18 Apr '06

18 Apr '06

Hi It would be nice if operator== could be added to boost::any. A partial solution would be the following: template<typename ValueType> bool operator==(const ValueType & rhs) const { return content ? content->equal(any(rhs).content) : content == any(rhs).content; } bool operator==(const any &rhs) const { return content && rhs.content ? content->equal(rhs.content) : content == rhs.content; } equal is a pure virtual member of placeholder declared as: virtual bool equal(const placeholder *rhs) const = 0; and implemented as (in holder): virtual bool equal(const placeholder *rhs) const { return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } However, this will break existing code when the holded object class does no have operator== defined. Kevlin Henney proposed: namespace equality { template<typename Type> bool operator==(const Type &lhs, const Type &rhs) { return &lhs == &rhs; } } virtual bool equal(const placeholder *rhs) const { using namespace equality; return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } Thus providing a default operator== for everyone not having its own, which returns true if the object addresses are the same. This will prevent compiler errors when the operator== really needed to be there. What I think is needed is: 1. If operator== is not used there should be no need for holded classes to implement it. 2. If operator== is used, and the holded class does not define it, the code must not compile. Do you think this is possible to implement? Thanks in advance Jorge Lodos

5 7

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 18 Apr '06

18 Apr '06

Doug Gregor wrote: > On Apr 10, 2006, at 3:58 AM, Reece Dunn wrote: > > In terms of C++0x features, what is the current state of lambda > > support as I have > > seen several papers from Bjarne, et. al.? > > I don't think being the fourth of five authors on one lambda proposal > counts as "Bjarne et. al." :) I could only remember Bjarne as being one of the people involved with a wg21 paper on Lambda from www.open-std.org. Maybe I should have said Doug et. al. :) > The driving forces behind lambdas for C++0x are Jeremiah Willcock, > Jaakko Jarvi, and Valentin Samko. I'll keep an eye out for papers from them. > The lambda proposals are still in > an early state of development and will take a couple months to > mature. There are many unanswered questions about the scope of > lambdas (how much can/should they express?), various design features > (polymorphic vs. monomorphic, how to handle references to local > variables), etc. I have no doubt the authors will spiral in on the > right solution, but they could certainly use more feedback. Sure. I am interested in Lambda functions and have knowledge of Haskell (and more recently Python :)) and the Boost.Phoenix/Lambda libraries. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

19 43

Re: [boost] [intrusive_ptr] atomic ref counting?
by David Maisonave 18 Apr '06

18 Apr '06

"Eric Niebler" <eric(a)boost-consulting.com> wrote in message news:<443FF065.9020809(a)boost-consulting.com>... > > I'm thinking about replacing some uses of shared_ptr with > intrusive_ptr, > but I've got questions. One of the nice things about shared_ptr is the > lock-free thread-safe ref counting. I want my intrusive_ptr to have the > same safety and efficiency, but I don't see how to get it. I see > $boost_root/detail/atomic_count.hpp, but shared_ptr doesn't use it. Why > not? And why is it in detail/? Should I not consider using it? > > Taking in the bigger picture, intrusive_ptr requires people to write > their own add_ref and release functions, most of which will probably end > up using ++ and -- on a plain integer. This is totally broken in > multi-threaded applications, right? Isn't it dangerous to not provide > complementary utilities for correctly managing reference counts? It > seems to me intrusive_ptr is impossible to use safely and portably. What > have I missed? Check out the policy base smart pointer class in the following link: http://axter.com/smartptr/ This smart pointer uses an intrusive_lock_policy to synchronize both intrusive and non-intrusive smart pointers. Although intrusive_lock_policy uses intrusive logic, it still can work with any type by using the mutex_wrapper class. http://axter.com/smartptr/classmutex__wrapper.htm http://axter.com/smartptr/structintrusive__lock__policy.htm The mutex_wrapper class adds intrusive logic to any type. I believe the same can be done to the boost::intrusive_ptr class. It shouldn't be that hard to add a wrapper-class to boost that would give intrusive logic to any type. Example usage: boost::intrusive_ptr<intrusive_wrapper<vector<int> > > spVect = new boost::intrusive_wrapper<vector<int> >(); See following link for mutex_wrapper implementation: http://axter.com/smartptr/sync__wrapper_8hpp-source.htm

1 0

Property tree rev.5
by Marcin Kalicinski 18 Apr '06

18 Apr '06

Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree Major changes since revision 4: - basic_ptree no longer templated on character type, now templated on key type instead - get_b functions removed - get_o functions renamed get_optional - get_d functions renamed get, (resolution with throwing get through overloading) - enhancements to cmdline_parser - added more regression tests - updated docs and examples Marcin

8 8

Program Options: Allow long options without -- prefix?
by Olaf van der Spek 18 Apr '06

18 Apr '06

Hi, Is it possible to allow long options without -- prefix? The code doesn't seem to support it, but I think it's handy in cases where positional options aren't used.

1 0

[multi_index] Problems with chained pointers in multi index from 1.34 RC
by Alexei Alexandrov 18 Apr '06

18 Apr '06

Hi, my multi_index use case: * The container contains not objects themselves, but pointers (shared_ptr-s). * The objects are noncopyable - they are created by a factory and only smart pointers are copied between clients. * The container has 2 indexes. Indexes are built on const_mem_fn extractor. One of the indexes uses a function from a base class. It seems that in 1.34 problem with using member function from a base class is supposed to be solved, but it causes a regression that you cannot have pointers to noncopyable objects in the container. Is this a known issue? My compiler is MSVC 7.1/Intel Compiler 9.0. Here is a code snippet to demonstrate the problem. This code compiles well with boost 1.33.1, but fails to compile with RC 1.34. If you uncomment the second index, it won't compile neither with 1.33 nor with 1.34. #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/shared_ptr.hpp> #include <boost/noncopyable.hpp> #include <iostream> #include <string> using namespace boost::multi_index; /* A name record consists of the given name (e.g. "Charlie") * and the family name (e.g. "Brown"). The full name, calculated * by name_record::name() is laid out in the "phonebook order" * family name + given_name. */ class base_record : boost::noncopyable { public: int get_id() const { return id_; } protected: base_record() : id_(0) {} private: int id_; }; class name_record : public base_record { public: typedef boost::shared_ptr<name_record> Ptr; static Ptr create() { return Ptr(new name_record()); } const std::string & name() const { return name_; } protected: name_record() : name_("") {} private: std::string name_; }; typedef multi_index_container< name_record::Ptr, indexed_by< ordered_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(name_record, const std::string &, name) /**/> // , // ordered_unique< // BOOST_MULTI_INDEX_CONST_MEM_FUN(base_record, int, get_id) // > /**/> /**/> name_record_set; int main() { name_record_set ns; ns.insert(name_record::create()); return 0; }

2 4

[program_options] PATCH: fix VC8 runtime assertion error in options_description.cpp
by Trent Nelson 18 Apr '06

18 Apr '06

Hi, With regards to the following lines in the latest version (1.16) of program_options's options_description.cpp: 395: line_end = line_begin + line_length; 396: if (line_end > par_end) 397: { 398: line_end = par_end; 399: } Line 395 causes VC8 to throw a runtime assertion error when processing the last line of a multiline option description. This is because 'line_begin + line_length' will exceed the actual length of the string, and it seems VC8 is pretty intent on not letting that happen, despite the fact we correct it in following line. Following patch did the trick for me: --- options_description-1.16.cpp 2006-04-18 02:39:51.401147200 +0100 +++ options_description.cpp 2006-04-18 03:04:05.722358400 +0100 @@ -390,13 +390,13 @@ } } - string::const_iterator line_end; + string::const_iterator line_end = line_begin; + unsigned remaining = unsigned(distance(line_begin, par_end)); - line_end = line_begin + line_length; - if (line_end > par_end) - { - line_end = par_end; - } + // line_end will be determined by either the end of the + // current paragraph (remaining), or the current line + // length, which ever is less. + line_end += ((remaining < line_length) ? remaining : line_length); // prevent chopped words // Is line_end between two non-space characters?

2 1