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

RE: [boost] Re: New design proposal for boost::filesystem
by Bennett, Patrick 03 Sep '04

03 Sep '04

Er, sorry, I mean Dave (I'm sure people knew who I meant). You. :) Anyway, hopefully I didn't misrepresent a statement of yours. I was referring to your message to Carlo Wood where you stated: "...I'm among them. However, I have a hard time articulating what I found difficult about the library, other than that the path portability checks seemed to get in my way. If there's something deeper going on, I'd like to hear your opinion of what it is..." It was this message that I believe I originally replied to stating that internationalization support was an issue (for my company at least). Cheers... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, August 24, 2004 5:00 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: New design proposal for boost::filesystem > > "Bennett, Patrick" <Patrick.Bennett(a)inin.com> writes: > > > My real issue with boost::filesystem is that as currently defined, it's > > unusable in an application that will be used around the world. My > > initial response to this whole thread was just to point out to David > > that there *are* issues preventing people from using the library. He > > didn't think there were any, so I was compelled to point out what one of > > the issues was for me at least. > > David who? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

6 21

RE: [boost] Re: IOStreams formal review start
by Reece Dunn 02 Sep '04

02 Sep '04

Jonathan Turkanis wrote: >"Daryle Walker" <darylew(a)hotmail.com> wrote: > > On 8/28/04 8:09 PM, "Jeff Garland" <jeff(a)crystalclearsoftware.com> >wrote: > > 2. This library does what a lot of other text-I/O libraries do, try to >fit > > in "kewl" compression schemes. The problem is that the types of >compression > > here are binary oriented; they convert between sets of byte streams. > > However, characters are not bytes (although characters, like other >types, > > are stored as bytes). > >Are you saying there are problems with the implementation of the >compression >filters, e.g., that they make unwarranted assumptions about 'char'? If so, >please let me know. I'm sure it can be fixed. If you want to read a bzip2 file (for example), the bzip2 file will be a binary stream and the resulting stream will be either binary or text depending on what the compressed file stores. You can tell std::ifstream to read the stream as binary, so what is the problem? Also, you might want to convert between text and binary modes: file > bzip2 (binary) > text > (process) > bzip2 (binary) > file > > 1. Actual code using this library is very slick and easy to set up. >This > > ease of use/set-up also applies to the plug-in filters and/or resources. I also like the ability to chain filters. I have a program that uses a similar mechanism on a character tape stream that allows text to be split to a certain character length and/or merged back into one block. It would be interesting to compare the performance of using my program verses an implementation using this library. >Can I rephrase this as follows: InputFilters and OutputFilters are a useful >addition to the standard library, but Sources and Sinks just duplicate >functionality alread present? If this is not your point please correct me. > >There are two main resons to write Sources and Sinks instead of stream >buffers: > >1. Sources and Sinks and sinks express just the core functionality of a >component. Usually you have to implement just one or two functions with >very >natural interfaces. You don't have to worry about buffering or about >putting >back characters. This is similar to what iterator adaptors and flex_string do for iterators and std::strings respectively. This makes it easy to write standard conforming components. For example, if you wanted to add support for a COM-based IStream, it would be easy to implement a source and/or sink. I will post a more detailed review once I have had a better look through the documentation and library, but at the moment it looks good. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

4 14

another bjam question
by Robert Ramey 02 Sep '04

02 Sep '04

When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport. When I investigate the bjam output I find (for another test) I find that the following is being used for the command line: "cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp" This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage. Can someone tell me what I should be doing differently? Robert Ramey Microsoft Visual C++ version 6.0 _CPPUNWIND =1 __cplusplus =1 _M_IX86 =500 _WIN32 =1 _WCHAR_T_DEFINED [no value] _CPPRTTI =1 _DLL =1 _MSC_EXTENSIONS =1 _MSC_VER =1200 _MT =1 __BOOL_DEFINED =1 ********************************************************************* Dinkumware standard library version 1.x ********************************************************************* Detected Platform: Win32 Type char is signed Type wchar_t is unsigned byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long =0 8 16 24 sizeof(wchar_t) =2 sizeof(short) =2 sizeof(int) =4 sizeof(long) =4 sizeof(size_t) =4 sizeof(ptrdiff_t) =4 sizeof(void*) =4 sizeof(void(*)(void)) =4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =8 CHAR_BIT =8 CHAR_MAX =127 WCHAR_MAX =((wchar_t)-1) SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =2147483647L ********************************************************************* Boost version 103100 BOOST_USER_CONFIG =<boost/config/user.hpp> BOOST_COMPILER_CONFIG ="boost/config/compiler/visualc.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/dinkumware.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/win32.hpp" BOOST_BCB_PARTIAL_SPECIALIZATION_BUG [no value] BOOST_DEDUCED_TYPENAME [no value] BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL [no value] BOOST_HAS_DECLSPEC [no value] BOOST_HAS_FTIME [no value] BOOST_HAS_MACRO_USE_FACET [no value] BOOST_HAS_MS_INT64 [no value] BOOST_HAS_THREADS [no value] BOOST_HAS_WINTHREADS [no value] BOOST_MSVC =1200 BOOST_MSVC_STD_ITERATOR =1 BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NESTED_TEMPLATE =template BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP [no value] BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS [no value] BOOST_NO_CV_VOID_SPECIALIZATIONS [no value] BOOST_NO_DEDUCED_TYPENAME [no value] BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS [no value] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS [no value] BOOST_NO_FUNCTION_TEMPLATE_ORDERING [no value] BOOST_NO_HASH [no value] BOOST_NO_INCLASS_MEMBER_INITIALIZATION [no value] BOOST_NO_INTEGRAL_INT64_T [no value] BOOST_NO_INTRINSIC_WCHAR_T [no value] BOOST_NO_LONG_LONG_NUMERIC_LIMITS [no value] BOOST_NO_MEMBER_TEMPLATE_FRIENDS [no value] BOOST_NO_MEMBER_TEMPLATES [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_PRIVATE_IN_AGGREGATE [no value] BOOST_NO_SFINAE [no value] BOOST_NO_SLIST [no value] BOOST_NO_STD_ALLOCATOR [no value] BOOST_NO_STD_ITERATOR [no value] BOOST_NO_STD_ITERATOR_TRAITS [no value] BOOST_NO_STD_MIN_MAX [no value] BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN [no value] BOOST_NO_STD_USE_FACET [no value] BOOST_NO_STDC_NAMESPACE [no value] BOOST_NO_SWPRINTF [no value] BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION [no value] BOOST_NO_TEMPLATE_TEMPLATES [no value] BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS [no value] BOOST_NO_USING_TEMPLATE [no value] BOOST_NO_VOID_RETURNS [no value] BOOST_STD_EXTENSION_NAMESPACE =std BOOST_UNREACHABLE_RETURN(0) [no value] EXIT STATUS: 0

4 8

name mangling scheme for tru64cxx65
by Markus Schöpflin 02 Sep '04

02 Sep '04

Hello! Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example: ---%<--- #include <iostream> using namespace std; template <typename T> void foo(T const &x) { cout << "1" << endl; } template <typename T> void foo(T * const &x) { cout << "2" << endl; } int main() { foo("abc"); return 0; } --->%--- This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed. Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change? Markus

7 36

RE: Serialization questions
by Robert Ramey 02 Sep '04

02 Sep '04

> Hello again, > > I have started using your serialization library. It is working pretty > well, but I have run into a few small problems: > > 1) No serialization for bitset: No big deal, because I can just > convert to ulong, but I was surprised it wasn't there. Feel free to add it in along with a test. I would like to see people adding serialization bit by bit to the existing data structures as the need becomes apparent. We're coming to the view that these things should be added to the data structures themselves rather than the serialization library. I'm trying to get myself out of the business of serializing things. > > 2) I have a text archive with a bunch of pairs of strings. I want to > append another pair. There doesn't seem to a way to append items > to an archive. LOL - an interesting question that only recently - (in the last couple of months) occurred to me. There is no reason that you can't create an archive and just append to it as many times as you see fit. Oa << t; ... Oa << t; EXCEPT that the t (and its constituents) should have its serialization trait set so that memory tracking is turned off. Otherwise, copies subsequent to the first one won't copy any data - just a pointer to the original. I have considered making and testing an example of such a thing, but I've been busy. To support this and make a good example what is really needed is: a) another archve construction flag - "no_tracking" to suppress memory tracking for the archive regardless of the setting for each individual type. b) serialization added to boost::any and/or boost::variant. Probably doable but maybe a little tricky. In this way one could just save willy-nilly anything to the archive and load later. This would be very interesting for things like database transaction logs which want to implement rollback/rollforward and things like that. It would also make a dynamite log for debugging. Again, feel free to explore this at your leisure. > 3) similarly, if I'm reading items from an archive, there is no simple > way to keep reading until the end of the file. I have to catch the > exception, which seems wrong for such an unexceptional > circumstance. Setting a fail bit as with streams would be nicer. Checking the fail bit on the stream before reading the next archived item should work. It's intended to anyway. If it doesn't work it's a bug. There might be a little tweaking required as I didn't test for this specifically. If you try this and it doesn't work and you find the oversight let me know and I'll add the fix. Better yet, make and test a small test and submit it to me and I'll add it into the test suite. > However, you could take the view that you should always know what > is in the archive, and to have a method of failure that does not > throw an exception would invite errors. That suggests that a > constructor flag might work (e.g. throw_on_eof default to true). I recently discovered that one can set a flag on an input stream so that an attempt to read past eof will throw an exception. This would leave all options open. After learning ths I'm considering removing the code that checks the fail bit as I would like to leave the flexibility for the user and make the serialization library smaller. BTW the fail bit means - "the next operation is expected to fail", NOT "the last operation failed". This confused me for quite a while until I actually carefully read the documentation for stream rather than presuming what I thought was obvious. > 4) A minor point: It would be nice to be able to construct an archive > with a boost::filesystem::path, instead of creating an fstream and > then using that to create the archive. It is certainly nice that I > can attach an existing stream to an archive, but directly using a > path would reduce some clutter. It would also make it a little > safer, because I couldn't accidently insert something into the > stream that was not serialized. Feel free to make your own - it should be trivial exercise. It should be easy to do deriving from any of the current archives. Polymorhphic archive works this way. Its one template that "adapts" any archive it's applied to. Also the current setup is specifically designed to permit serialized data to be embedded within some other data stream if the user requires it. I haven't specifically tested this either. > I have read large parts of the discussions when you were submitting > your library, but not all. If I have missed something, you can just > point me to it. Seems like you've pretty much got it. The thing that takes special care is the serialization of pointers through abstract base pointers. This works fine but there are a couple of non-intuitive aspects that can trip you up. The manual is pretty complete. This is mostly because I kept adding to it as questions kept coming up on the list. So I would hope that one can understand and use the package without going back and trolling through the list. If you don't mind, I'm posting this to the list. Your questions are interesting, good grist for the list, and help diminish the frequency of the same questions getting asked multiple times. Robert Ramey

2 1

Boost::Python exception translation not working?
by Dan 01 Sep '04

01 Sep '04

I attempted a simple exception translation that was almost an exact copy of the examples in the docs. struct MySQLException : public std::exception { MySQLException( const char * what = "MySQL Exception" ) : std::exception( what ) {} }; And then in a class's default constructor I throw this exception. I tried exposing it as both a function and a functor: void mysql_translate( MySQLException& e ) { PyErr_SetString( PyExc_RuntimeError, e.what() ); } BOOST_PYTHON_MODULE(pymysql) { // regular expression translation py::register_exception_translator< MySQLException >( &mysql_translate ); } And... struct mysql_translate { void operator ()( const MySQLException& e ) const { PyErr_SetString( PyExc_RuntimeError, e.what() ); } }; BOOST_PYTHON_MODULE(pymysql) { // regular expression translation py::register_exception_translator< MySQLException >( mysql_translate() ); } Both had the same result when I created the exported object. "RuntimeError: unidentifiable C++ exception". What am I doing wrong? Thanks, -Dan

2 4

tuple and std::set question
by Trey Jackson 01 Sep '04

01 Sep '04

All, I was trying to use the tuple in a set, and the STL complained about not having an operator&() - I think. My question is, is tuple supposed to be usable in a set? I read the STL docs: no mention of operator&() required. I tried both STLport and gcc's stl. I'm using gcc 3.2.2, and the snippet of code is real easy: ,---------------- | #include <boost/tuple/tuple.hpp> | #include <set> | | using namespace std; | | using namespace boost; | | int | main(int, char *[]) | { | typedef tuple<int, int, int> Things; | | std::set<Things> mySet; | | Things oneThing(1,2,3); | mySet.insert(oneThing); | | return 0; | } `---------------- tia, TJ -- Trey Jackson tjackson(a)ichips.intel.com "Nobody can give you wiser advice than yourself." -- Cicero

2 2

[type_traits] function_pointer_traits extension
by Tobias Schwinger 31 Aug '04

31 Aug '04

I'll continue this discussion (previously in private email) on the boost mailinglist, in order to allow others to join in. Any critiques (i.e. having a look at the (comparatively small) submission and dropping me a couple of lines) are still very welcome, in fact ! Alexander Nasonov wrote: >>>[... char array in struct as sizer for type classification via overload resultion ...] >>> >>Good point. This will be changed. >>By the way: the same hack is in the current boost release >>[boost/type_tratis/function_traits.hpp:177]. >> >> >> This has been changed [ref. 5.3.3]. >>> // tester returns a reference to an array >>> template< /* ... */ > >>> char (& tester( /* ... */ ) ) [size]; >>> >>> This would have been my personal preference. Unfortunately this causes bcc to fail with an 'Internal compiler error'. >>>or making it a meta-function >>> >>> template<std::size_t Size> >>> struct sized_type >>> { >>> typedef char (&type)[Size]; >>> }; >>> >>>and using typename sized_type<Size>::type in place of sized_type<Size>. >>> >>> >>> This is the current, but not necessarily the best implementation. Comments ? I believe this could be a common issue - for that matter: What about a type synthesizer like 'type_with_size<size_t>::type' or a 'BOOST_TYPE_WITH_SIZE(n)' macro ? Or even: BOOST_SIZED_RESULT_TYPE_OVERLOAD_PROTO(template_args,function_args,size_expression). Is there something like this in boost somewhere, already ? >>>The example compiles fine on g++ 3.2.2, g++ 3.4.0 and Intel 8.0 under linux. >>>I didn't check that BOOST_STATIC_ASSERT covers all cases but non-empty >>>output looks suspicious for metaprogramming library ;-) >>> >>> >>> The static assertion just aids keeping the errors where they belong. If it doesn't work there is a more obscure error message and one has to read the manual for proper usage. The documentation has been updated (Intel 8.0 is listed as tested and your work has been acknowledgeded). >>>I appreciate your efforts in boostifying function traits. Keep doing! >>> >>> >>I sure will ! >> >>Thanks a lot for your work, ideas and the very nice mail - despite the >>fact of having no time, that is ! >> >> > >Have you considered wrapping function signature into mpl sequence? > > Currently function_signature<T>::type is an mpl::vector and therefore a model of sequence. I believe I don't understand you correctly. In general, I aim to keep it as 'pure' as possible, so any conveniene feature should outweigh its cost in terms of code complexity , compilation time and maintainability. Tobias

3 6

Review Wizard Status Report
by tom brinkman 31 Aug '04

31 Aug '04

Review Wizard Status Report 1) Summary 2) Review Managers Needed 3) Review Schedule 4) Libraries under development //////////////////////////////////////////////////////////////////// 1) Summary //////////////////////////////////////////////////////////////////// Daryle Walker's library "More IO" is currently under review, starting August 21, 2004. Download the library at: http://boost-sandbox.sourceforge.net/more_io_4.zip. Please post a review of this library if you have not already done so. For information about submitting a Formal Review, see http://www.boost.org/more/formal_review_process.htm. The next library to be reviewed is Jonathan Turkanis "IOStreams" library. The "Iostreams" library allows the easy creation of standard C++ streams and stream buffer classes for new data sources and sinks. Download the library at: http://home.comcast.net/~jturkanis/iostreams. Be prepared to review this library in the next few days. If there are no objections, starting with the "More IO" library, I will attach an ID number to each reviewed library. Please reference this ID number in any postings to the group. This will help in organizing the reviews and assist in searching for related postings. I've also added a permanent section to this status report, called "Libraries Under Development". The purpose of this section is to prevent duplication of effort and support collaberation between library authors. Please contact me to add libraries to this section. Note: If you have any suggestions about how I could improve the Review Wizard's status report, please email me at reportbase(a)yahoo.com. //////////////////////////////////////////////////////////////////// 2) Review Managers Needed //////////////////////////////////////////////////////////////////// If you would like to volunteer to be a review manager, please contact me at reportbase(a)yahoo.com. The following libraries still require review manager volunteers: 10006 - Named Parms 10007 - Policy Pointer 10008 - Wave 10009 - Finite State Machine (FSM) 10010 - Fixed Strings //////////////////////////////////////////////////////////////////// 3) Review Schedule //////////////////////////////////////////////////////////////////// August 21, 2004 10001 - More IO (Currently Under Review) August 28, 2004 10002 - Iostreams September 7, 2004 10003 - Output Formatters September 15, 2004 10004 - Mini-Review wiki algorithims September 17, 2004 10005 - Smart Containers September 27, 2004 10006 - Named Params October 6, 2004 10007 - Policy Pointer October 16, 2004 10008 - Wave October 26, 2004 10009 - Finite State Machine (FSM) November 4, 2004 10010 - Fixed Strings 10001 - August 21, 2004 More IO (Currently Under Review) Author - Daryle Walker - darylew(a)hotmail.com Review Manager - Tom Brinkman - reportbase(a)yahoo.com Download: http://groups.yahoo.com/group/boost/files/more_io_4.zip [or] http://boost-sandbox.sourceforge.net/more_io_4.zip Description: Provides a multitude of I/O-oriented extensions. Some are extra manipulators; variants of "std::endl", a resetting manipulator, and a configurable manipulator. The library includes a set of base class templates for wrapping a new stream-buffer type around a stream class. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements 10002 - August 28, 2004 Iostreams Author - Jonathan Turkanis - turkanis(a)kangaroologic.com Review Manager - Jeff Garland - jeff(a)crystalclearsoftware.com Web-Page: http://home.comcast.net/~jturkanis/iostreams Download: http://home.comcast.net/~jturkanis/iostreams Description: The Iostreams Library serves two main purposes: To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files (based on work of Craig Henderson), for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. 10003 - September 7, 2004 Output Formatters Author - Reece Dunn - msclrhd(a)hotmail.com Review Manager - John Torjo - john(a)torjo.com Download: http://cvs.sourceforge.net/viewcvs.py/ boost-sandbox/boost-sandbox/boost/outfmt/ [or] http://cvs.sourceforge.net/viewcvs.py/ boost-sandbox/boost-sandbox/libs/outfmt/ Description: The I/O formatters library provides an easy and customizable way to input/output arrays, STL arrays, STL collections, sub-arrays from/to STL streams. It allows you to configure how each element in such an array will be written to the stream or read from the stream, while providing reasonable defaults. 10004 - September 15, 2004 Mini-Review wiki algorithims Author - Various Review Manager - Tom Brinkman - reportbase(a)yahoo.com Download: to be determined Description: not available 10005 - September 17, 2004 Smart Containers Author - Thorsten Ottosen - nesotto(a)cs.auc.dk Review Manager - Pavol Droba - droba(a)topmail.sk Download: the boost sandbox: ptr_container Description: The Smart Container Library consists of several container classes that are capable of storing heap-allocated objects in an exception-safe manner. The interface of the container classes effectively hides the underlying pointers so one can work on objects directly; this indirection is done to make the classes safer and easier to use. The library can also be customized to allow, for example, that a container does not rake ownership of the stored objects. 10006 - September 27, 2004 Named Params Co-Authors - David Abrahams - dave(a)boost-consulting.com) & Daniel Wallin (dalwan01(a)student.umu.se) Review Manager - to be determined Download: Boost sandbox boost/named_params.hpp [and] libs/utility/doc/named_params.html Description: This library is an attempt to address the problems of positional parameters by associating each parameter with a keyword identifier. Using this library, users can identify parameters by name instead of just argument position, and pass them in any order: window* w = new_window("alert2", movable = movability, opacity = 50); 10007 - October 6, 2004 Policy Pointer Author - David Held - dheld(a)codelogicconsulting.com Review Manager - to be determined Download: available via boost CVS Description: Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 10008 - October 16, 2004 Wave Author - Hartmut Kaiser - hartmutkaiser(a)t-online.de Review Manager - to be determined Download Boost-sandbox Description: The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It uses the Spirit[4] parser construction library to implement a C++ lexer with SO/ANSI Standards conformant preprocessing capabilities. It exposes an iterator interface, which returns the current preprocessed token from the input stream. This preprocessed token is generated on the fly while iterating over the preprocessor iterator sequence (in the terminology of the STL these iterators are forward iterators). 10009 - October 26, 2004 Finite State Machine (FSM) Author - Andreas Huber - ah2003(a)gmx.net Review Manager - to be determined Download: http://boost-sandbox.sf.net/fsm.zip Documentation: http://boost-sandbox.sf.net/libs/fsm Description: The boost::fsm library is a framework that allows you to quickly transform a UML state chart into executable C++ code, without needing to use a code generator. Thanks to support for almost all UML features the transformation is straight-forward and the resulting C++ code is a nearly redundancy-free textual description of the state chart. 10010 - November 4, 2004 Fixed Strings Author - Reece Dunn - msclrhd(a)hotmail.com Review Manager - to be determined Download: boosts-sandbox/boost/fixed_string [or] boost-sandbox/libs/fixed_string Description: The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. //////////////////////////////////////////////////////////////////// 4) Libraries under development //////////////////////////////////////////////////////////////////// 10011 boost::xpressive - Under Development Author: Eric Niebler (eric(a)boost-consulting.com) Download: Boost sandbox at sourceforge.net Description: Advanced regular expression template library that allows regexes to be written as expression templates (statically bound) or as strings (dynamically bound) and allows regexes to nest and call each other recursively (like perl6) and bind to semantic actions (like Spirit). Development status: Under active development. Basic functionality in place. 10012 boost::geometry2d - Under Development Author(s): Aleksey Gurtovoy Description: simple cartesian geometry classes (point<>, rectangle<>, etc.) Download: yahoogroups files section, geometry2d/ Development status: basic functionality working Tom Brinkman Boost Review Wizard reportbase(a)yahoo.com

7 12

RE: [boost] Re: Re: Review of Daryle Walker's "More IO" librarybeginstoday, August 21, 2004.
by Reece Dunn 31 Aug '04

31 Aug '04

Jonathan Turkaniswrote: >"Rob Stewart" <stewart(a)sig.com> wrote in message >news:200408262114.i7QLEOP14442@lawrencewelk.systems.susq.com... > > From: "Jonathan Turkanis" <technews(a)kangaroologic.com> > > > - multi_skipper: I'm not sure I see why this is needed; how > > > often do you need to skip a sequence of repeated characters? Id rather > > > > When parsing, it is often useful to ensure that there were > > exactly 10 spaces between one token and the next, for example. > >I'll take your word for it, but an example would help. I am used to just >worrying about whitespace. Haskell uses whitespace to associate code on the right of the whitespace with the code on the left. e.g. [haskell.hs] factorial x = fimpl x where fimpl 0 = 1 fimpl x = fimpl ( x - 1 ) * x power (x:xs) = power xs * x power [] = 1 [end] where [] is an empty list and (x:xs) is a list with x as the head and xs as the tail. In this example, fimpl is associated with factorial and is only visible in its scope. factorial and power (both patterns) are in global scope. When writing a Haskell lexer, you need to be aware of the number of space characters after a given new-line. Therefore, something like multi_skipper would be useful, but it would need to: [1] reset an internal nspace variable on recieving a new-line character, allowing read access to it by the lexer; [2] incrementing by n (where n=3,4 or 8) upon recieving a tab character; [3] incrementing by 1 when recieving a space character I am not sure how the above could be implemented using multi_skipper, but this is an example where the number of spaces is important. Another example would be in padding. For example, the TAR file format ensures that each file fills a number of blocks of 256 bytes, so you need to skip the remaining bytes at the end of each file. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 3