- Boost - lists.boost.org

RE: [boost] Re: [filesystem] Generic path grammar corner cases
by Simon Li 02 Jun '05

02 Jun '05

> From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > A fix for both issues would be to introduce an escape > sequence which means "slash and I really mean it", or an > escape path prefix which means "don't modify this path in any way." > > Both of those seem like ugly warts, and I've been avoiding > them until someone comes up with a compelling use case. I > would hate to do something ugly that may have no practical > use whatsoever. > > Hum... Gears clank in brain for awhile... > > In the past, whenever I thought about escape sequences, I > assumed we would have to invent a new escape sequence, and > that would be quite messy. But what about hijacking one of > the existing escape sequences? > > Of all the C++ escape sequences, '\a' stands for BEL, and > would seem to have the least probability of ever being a > valid character in a path. It isn't valid at all for some > OS's. If Boost.Filesystem hijacked it as an escape sequence > meaning ""slash and I really mean it", we could use option > (2) with all its advantages, yet if someone desperately needs > more slashes for whatever reason, they have a way of doing so. > > Thoughts? In the unlikely event that there is a filename with a BEL in it, is there a way of "unescaping" the \a so that it isn't converted into a slash? If anyone's wondering about BEL being a valid filename character, I've just done a quick test on Linux: [0 simon@cstux test]$ mkdir `echo -e 'foo\abar'` # The stuff with echo ensures the argument passed to mkdir is a BEL char [0 simon@cstux test]$ ls foo?bar [0 simon@cstux test]$ ls | od -a 0000000 f o o bel b a r nl 0000010 # od -e converts its raw input into ascii chars, or their equivalent Simon This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. VMS does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated. While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.

1 0

RFC: various utility classes (factory, plugin, parser iterator)
by Simon Richter 02 Jun '05

02 Jun '05

Hi, as probably everyone in here, I have written many factory implementations and plugin managers in various projects, and decided to throw them all together into a set of template classes. My current approach looks like this: - class registrable base class for objects that can be registered somewhere - class registry : public registrable base class for objects that need to register some other objects. inherits from registrable, so there can be a registry of all registries (I think that can be made optional, but haven't found a compelling reason to do so). defines a set of abstract functions that registries need to implement (register/unregister of const/non-const objects), and static functions to register/unregister objects (by going through the list of registries and passing the object to each). - template<typename obj> class creator : public registrable base class for objects responsible for instantiating a concrete class and providing an object to match the factory argument against. - template<typename obj> class factory : public registry<creator<object_type>> factory. registers creators and can be asked to instantiate objects. - template<typename obj, typename stream> class parser base class for parsers. holds a stream reference and an object of "obj" type, defines some abstract functions and knows how to create proxy objects for the postincrement operator. - template<typename obj, typename stream> class parseiterator holds and owns a pointer to a parser<obj, stream> object, behaves like an iterator. can be instantiated on the stack, uses parameters to instantiate parser by using factory<parser<obj, stream>>. I believe these things are fairly generic and was surprised that they weren't already there. Would it make sense to add these to boost (after properly specifying and documenting them, of course)? Simon

2 2

Boost.Filesystem path iterators
by Jordan DeLong 02 Jun '05

02 Jun '05

First; pre-emptive apologies if this should be sent to boost-users instead of here (or I guess the Mod can nuke it and tell me). I figured I should send it here because it's more of a design issue than a "how do I use this" issue... path::begin() is defined as returning an 'iterator' (not a const_iterator), so I figured I'd be able to write to it. I wrote some code which did something like: fs::path p; /*...*/ for (fs::path::iterator it = p.begin(); it != p.end(); it++) if (*it == "FOO") *it = "BAR"; This errors because operator* on the iterator type returns a const string&. So: was this a deliberate design decision? I don't see anything about this in the design rationale stuff in the docs for Boost.Filesystem. Is there a good reason not to allow people to use the iterator to modify individual path elements? -- Jordan DeLong fracture(a)allusion.net

3 3

Tagged typedef
by Maksym Motornyy 02 Jun '05

02 Jun '05

Hi all, It is know that typedef in C++ is actually an alias, i.e. it doesn't create new distinguishable type. Sometimes this causes problems. Consider following example: typedef int handle; template < typename Value > void write( const Value &value ); void write< int >( const int &value ) { // do processing for int } void write< handle >( const handle &value ) { // we wanted to have separate processing for handle, // but we get only compilation error :( } In my projects I resolve such situations as the following: class handle_tag { }; typedef tagged< int, handle_tag > handle; Then everything works as expected. "tagged" class is actually a wrapper that mimics fundamental type behaviour. Also I have specialization for pointers. Is anyone interested in such solution of given problem? Is it worth to be part of Boost? Sincerely, Maksym Motornyy.

3 4

[filesystem] Windows DLL causes invalid bad path exception
by David Daeschler 01 Jun '05

01 Jun '05

was: [filesystem] WIN32 Can not use drive name in directory I found posts on boost-users from January that describe the problem that I am having. Was there ever a resolution to this? Mr. Dawes, you mention a re-work in the next version of the library ( http://lists.boost.org/boost-users/2005/01/9607.php ) that would fix this problem. Is that rework complete, or not yet? Should I just use the static version for now and not worry about this problem? Comment reference for January 2005 http://lists.boost.org/boost-users/2005/01/9560.php http://lists.boost.org/boost-users/2005/01/9581.php http://lists.boost.org/boost-users/2005/01/9583.php http://lists.boost.org/boost-users/2005/01/9584.php http://lists.boost.org/boost-users/2005/01/9586.php http://lists.boost.org/boost-users/2005/01/9607.php http://lists.boost.org/boost-users/2005/01/9610.php http://lists.boost.org/boost-users/2005/01/9639.php Thank you, - Dave

2 2

Typeof documentation
by Arkadiy Vertleyb 01 Jun '05

01 Jun '05

Hi all, The typeof documentation has been significantly changed. We tried to reflect all the suggestions that came so far during the review. If we missed something please let us know. Please download at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip Also thanks to everybody who helped me to cope with the quickbook/Boost.Book-related issues. Regards, Arkadiy

4 14

Typeof: Review result
by Andy Little 01 Jun '05

01 Jun '05

Hi All, I am pleased to formally announce that the Typeof library has been accepted into Boost. There were 3 reviews, all in favour of accepting the library. This has been a slightly odd review in that the implementation and documentation changed during the review period. However as modifications to the implementation were mainly to improve compile time performance, which is the major weakness of the library, I feel that this should not affect the result. Overall there was a feeling that the documentation could be improved. Following are some of my comments, though views of others would be welcomed.As I understand it the documentation is being reworked, so some of these points may be out of date. 1) The STL support section would be better later. Should there be a formal list of the stl registration libraries, with their headers. The STL headers would also be useful as useage examples with links? 2) A note regarding closing namespaces when registering a type (cited by David Abrahams). and an example in a namespace just to clarify this. 3) Separate examples of each useage with types, templates and values etc (also cited by David Abrahams). . This section of the documentation is slightly short IMO. 4) More information regarding incrementing-registration-group. How will separate inclusions ( eg different order) affect it. eg the index of each type registered cannot be relied on. In fact a statement regarding anything in the implementation being subject to change might also be 5) More information regarding the differences from decltype. e.g. is there a way for the user to simulate decltype more closely, eg by use of remove_reference. Finally.. Thanks to Arkadiy Vertleyb and Peder Holt for all their work. regards Andy Little

7 8

Re: Customer Friendlier Boost Installation
by David Abrahams 01 Jun '05

01 Jun '05

"Johan Nilsson" <r.johan.nilsson(a)gmail.com> writes: > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > news:uhdgi971q.fsf@boost-consulting.com... >> David Abrahams <dave(a)boost-consulting.com> writes: >> > > [snip] > >>> No! It's supposed to check %HOMEDRIVE%%HOMEPATH% first, then %HOME%, >>> then %BOOST_BUILD_PATH%. I'll look at this. >> >> Should be fixed now. >> >>> Just out of curiosity: why weren't HOMEDRIVE and HOMEPATH set in your >>> environment? Aren't they set up for you by Windows? >> >> Still curious, though. > > Me too. I've tried googling as well as searching the MS Knowledge Base but > couldn't find any reference to a similar problem. I'll try the MS > newsgroups. > > FWIW, I can reproduce the problem on both of my XP SP2 machines. ?? I thought Eric was the only one with the problem. Is it fixed now? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[shmem] New Shmem snapshot available in boost vault
by Ion Gaztañaga 01 Jun '05

01 Jun '05

Hi to all! After some busy weeks, I've been working again on Shmem library. This is what you get in the new snapshot I've just placed in Boost Vault: Documentation: -> Ported all documentation to QuickBook. Very little has changed and the real Documentation work starts now. But Quickbook allows direct source file inclusion for examples, syntax highlighting and some other nice features. Suggestions are welcome. -> Apart from the documentation zip in boost.vault, I've put the documentation online in this address (there are banners, but nothing is free...): http://ice.prohosting.com/newfunk/boost/libs/shmem/index.html Bugfixes: -> shmem set-map family iterator bugfix in operator->() -> shmem vector fix in size() -> Added some missing typedefs in STL-like containers New features: -> shmem assoc_vector has died, long live to flat_set/flat_multiset/flat_map/flat_multimap! Based in an ordered vector, the flat associative ordered container family is born as an extension of Loki's AssocVector. shmem_assoc_vector.hpp is provided for backwards compatibility. If you don't like flat_* name, suggestions are welcome for this new classes. Any comment, suggestion or help is welcome. Regards, /Ion

3 5

Google Summer of Code Stipends for student programmers
by Eric Ford 01 Jun '05

01 Jun '05

Might Boost be interested in becoming a "mentoring organization"? That would allow a student to get a summer stipend from Google to write code to contribute to boost. I'd guess that we probably have a few student programmers on the list who have already demonstrated their capabilities and enthusiasm. If so, see below. The deadline is June 14. http://code.google.com/summerofcode.html Cheers, Eric Ford

3 2