April 2006 - Boost - lists.boost.org

Re: [boost] [Property_tree review] Summary of enhancements proposed so far
by JOAQUIN LOPEZ MU?Z 23 Apr '06

23 Apr '06

----- Mensaje original ----- De: Marcin Kalicinski <kalita(a)poczta.onet.pl> Fecha: Sábado, Abril 22, 2006 2:48 pm Asunto: [boost] [Property_tree review] Summary of enhancements proposed so far > I created a brief summary of enhancements/changes to property_tree > which > were proposed so far. > > 1. Make path a class in its own right and overload / (division) > operator to > concatenate path objects efficiently. This removes need for ugly > default > separator, and half of the get/put overloads. It also boosts > performance (no > more string operations on path), and IMHO will generally improve > interface > of the library. Most importantly, it largely does maintain > compatibility > with existing interface. Although a proper path class seems so much neater, I think you should still keep some API to specify a path as a single string, maybe something like: boost::property_path::path p("Dante/Divina Commedia/Inferno"); Why? Because this way you retain the ability to store a path as a program resource outside the code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[Property_tree review] Summary of enhancements proposed so far
by Marcin Kalicinski 22 Apr '06

22 Apr '06

I created a brief summary of enhancements/changes to property_tree which were proposed so far. 1. Make path a class in its own right and overload / (division) operator to concatenate path objects efficiently. This removes need for ugly default separator, and half of the get/put overloads. It also boosts performance (no more string operations on path), and IMHO will generally improve interface of the library. Most importantly, it largely does maintain compatibility with existing interface. 2. Split Traits into smaller policy classes. For example KeyPolicy and DataPolicy. Indeed, these two are mostly orthogonal, and it should be possible to replace one without touching the other. 3. Allow use of other data types as keys/paths (for example a vector of ints). Initial support is in the library, but key is still required to support string-like interface. 4. Add possibility to disable indexed lookup, if not required 5. Add possibility to specify names of "special" keys in parsers (<xmlattr>, <xmlcomment> etc.). Add whitespace-handling flags to XML reader. 6. Add "set" function. "set" will work in a similar fashion to put, except that it will always replace existing key if it exists. Extra boolean parameter to put functions will be gone. Alternative approach is to replace bool parameter to put with enum to improve readability. 7. Add "del" function. Del will erase existing keys from the tree, while presenting get/put/set style interface. This is clearly missing, although not immediately obvious. 8. Add support for array-style indexing in paths. This will probably work well with #1. 9. Add support for serialization of ptree objects 10. Add possibility to iterate over the whole tree in one go 11. Use multi_index internally for indexing 12. Make get/put functions freestanding 13. Add more docs on customizing key/data types. 14. Improve docs grammar/style in places. Break large index into smaller files. Additionally there were proposals to use runtime polymorphism to distinguish between leaf and branch nodes. I think this idea strays so far from current implementation/interface of the library, that it is not feasible to do. I hope this will serve as a basis for continued discussion. Best regards, Marcin

2 1

Serialization and Editing Archives
by Robert Ramey 22 Apr '06

22 Apr '06

I've been looking at the posts regarding the Property Tree Library. I haven't had the time to give it a proper review. Fortunately it seems that there are a good number of people willing to help with this. I would like to make some observations regarding the serialization library and the creating of "editable" archives. This seems to me the central issue being discussed. The fundemental notion that the serialization library is meant to address is the deconstruction of an arbitary set of C++ data structures into a series of bytes in such a way that the original set can be restored at another time and place. The requirements for such a library were a) completeness - basically no constraints on the C++ data structures to be saved/restored. b) factoring out the actually storage of the bytes in such a way that this could be changed by the user to suit his application. c) minimal effort - the the library has to leverage on the structure of the data as described by the C++ code itself rather than than requiring some extra specification as to how all the data is organized and related. This goal has been in large part achieved with the help of many people on this list, The set of requirements was demanding, and required lots of code to implement. Much of that code had to relie on more demanding techniques such as template metaprogramming. Also, in some cases, extra information had to be be appended to "reflect" information necessary for the implementation. BOOST_CLASS_EXPORT is an example of this. In addition a number of user customizable attributes had to be defined to permit the library to be applied as widely as was reasonable to expect. I know not everyone is totally happy with the library but all in all I'm satsified that a good balance has been struck. The goal and requirements dictate that the resultant archive (however it is stored is dependent on the C++ data structure defined at compile time and invoked at runtime. In general, one cannot expect that any changes in an archive will possible without changing the C++ data structures and code to which the changes correspond. Note this is an entirely reverse situation to the most common one exemplified by doing something like parsing an XML file. In this case one will load the data into some dynamic data structure which will reflect the structure of the data being loaded. At that point some code will have to traverse the structure to extract or set the data in memory. Note that there is no requirement that the C++ data structures map in any special way to the file. Also the file doesn't have to include as much "detail" because it doesn't have to reconstruct an arbitray set of C++ data structures. And of course we see and will continue to see a proliferation of file formats and programming modules to support them. Some attempts have been made to map serialization to some formats which permit arbitray data - XDR and a couple of others. I don't think they've been successful because part of the file format is really held in the C++ code which saves and loads the archives. The requirement to be able to arbitrarily edit an archive is clearly not possible. But then ... it seems tantalizingly close - I meant hell its XML I can read it!. So could anything be done? I haven't spent too much time on this but I can speculate some. Suppose one wanted to create and editable XML format. First of all on will have to accept the fact that not all editing is going to be possible. One won't be able to make a new class which the C++ code doesn't implement. I might be possible to do something like the following; a) parse the whole XML file with a standard parser b) as the serialization algorithm visits each data structure, ratther than just presuming that all the data is there in sequence, it would check to see if the tag has been loaded.. This would permit the following types of editing: i) deletions ii) changing data A little more work would permit expanding / contracting collections. I really don't know how much work this would end up being but no one has had sufficient interest to undertake it - or perhaps they have but it hit a dead end. To summarize I see two almost irreconciliable paths a) Archive formats reflect the set of C++ data structures which generate them b) A format for arbitrary data (e.g. XML) is defined and a general- not application specific - data strucure (e.g. tree) is defined. Then the application walks the tree in an application dependent manner. Basically only one thing can be boss - either the C++ data strucures in the app or the file format. one can drive the other but they can't be varied independently. It seems to me that the property tree library is driven by the need to be able to edit one's "serialized" data out side the main application. My personal view is that if one feels that he needs to do this - he should be rethinking his application. A huge portion of applications are really variations on just this theme: Load some data, edit it, save data. And its not just word processors or things like that. Machines startup, run, and shutdown. a customer recored is accessed, updated, and saved. etc. So I think many more applications can be considered in terms of serialization than in fact are. The applicatons edit data. There can also be the case where different applications edit the same data. I might make an application which loads configuration, runs a machine and save the data from the run. Someone else needs and application to browse and/or annotete the the data. One could say - oh then we need the data in some application independent manner such as XML. Well that's one way - but then we have to recode all over again to get and save the data. Or we can use something like a text editor but then we are casting aside all the facility of using a computer in the first place. Finally we can make a new application which used the original C++ serialization code and data structures - which hopefully have been compiled into a library. Now we just use our special editor for that "other" applicaion. To me - definition of a file format independent of the C++ code which is going to use has wasted billions of man years of human brain time just trying to keep things in sync. So, I see the whole XML approach as a misguided attempt to separate the fundementally inseparable - data and code - they are one now. I predict that XML will be made continually more elaborate and spawn ever more variations in vane attempts to reconcile the unreconcilable. Remember you heard it here first - XML and is progeny is destined for the ash heap of history! (hmmm - like COBOL?) For someone who has nothing else to do there are interesting things to look at here. What would be very interesting would be a xml_archive which created in parallel an (XML?)_schema which would be used by a generic editor to edit the xml (and maybe other) data in the archive within the bounds of what is permitted. I see this as quite doable. Another idea would be a generic editor which could be compiled from the serialization code which would exploit the "reflected" data about the C++ and perhaps define a little bit more. For example I could imagine a template for each datatype which would invoke a functino to edit it. On a GUI, just compile the generic editor with your own serializtion code. and BAM you've got an application specific editor which runs at full runtime speed. Just a couple of misceleaneous observations a) It seems there is a perception that the serialization library is large, cumbersome and inefficient. I believe it can be used inefficiently (like all libraries) and it can be made faster (and incremental improvemetns are being made). But I don't think this is true in general. When I compile with release mode, make sure I haven't included in the debug symbols, and use the DLL (which isn't all that big), a program which saves and loads 4 different types of archives with several classes only takes 30 KB. So if you're not getting similar results, take a closer look. b) much has been made of things like - you can't turn off tracking etc and the difficulty of modifying the library. I believe that most of these difficulties comeabout by tyring to implemnent some external requirement - which I've called about trying to reconcile the irreconciable. If one turns off tracking- then how is one going to recoveer pointers. By default, someting track only if its used as a pointer somewhere. And why would one have pointers in something like configuration parameters. And if tracking is turned off and somethng is duplicated - then what if one edits only one of the copies. etc. Its not so much that I want to dicuss tracking- its more that I think these kinds of questions reveal that things originally thought to be almost identical e.g and XML archive and general XML file are more different than they first appear. So when this occurs its time to step back and look at the big picture (BTW I believe it would be easy to suppres the object_id etc in he xml archive just be overridding with stubs the serialziations for these types - but then how would one read the archve?) Anyway - I'm sorry if this is a little rambling and off topic Robert Ramey

1 0

Re: [boost] Do really property_tree and program_options overlap?
by Matt Doyle 22 Apr '06

22 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcin Kalicinski > the lot. You can use BOOST_FOREACH on it. You can use > algorithms on it (just keep in mind it is not sorted by key > unless you do that explicitly). Are you talking about basic_ptree::sort? Or pre-sorting the keys before populating the tree? Scanned by McAfee GroupShield {X3BTB534}

2 1

[Property tree review] Error in docs
by Marcin Kalicinski 21 Apr '06

21 Apr '06

I just noticed there is a serious error in docs, it states that parsers are in namespaces of their own, (e.g. read_xml is in namespace boost::property_tree::xml_parser). This is correct, but they are also all imported into boost::property_tree namespace by means of using declarations. And they should be used from there. Their presence in other namespaces should be considered an implementation detail, and obviously not documented. I will fix that after review completes. In the meantime please bear in mind that there's not so much namespace bloat as the docs purport ;-). One reason that parser functions _must_ be in property_tree namespace is Koenig lookup, e.g.: boost::property_tree::ptree pt; read_xml("x.xml", pt); // Koenig lookup here Lookup above obviously relies on read_xml being in the same namespace as ptree. Marcin

3 3

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