- Boost - lists.boost.org

Pointers to member function templates as template arguments
by Jonathan Turkanis 02 Jun '05

02 Jun '05

Hi, Consider the following code: template<typename T, void (T::*) (int)> struct MemFn; struct Foo { template<typename Int> void bar(Int) { } }; typedef MemFn<Foo, &Foo::bar> type; This compiles with VC7.1, GCC 3.4, Intel 8.0 and Comeau 4.3.3 in strict mode, but CodeWarrior 9.4 fails with the message: Error : illegal implicit member pointer conversion example.cpp line 9 typedef MemFn<Foo, &Foo::bar> type; Looking at 14.3.2/1, I notice while the third bullet, on function pointers, explicitly mentions templates, the fourth bullet, on pointers to members, doesn't. But perhaps pointers to function templates are covered implicitly. Looking at 14.3.2/5, bullet 6, I see that no conversions are applied to pointers to members. But no conversions are needed in the above example. What's needed is overload resolution, which is explicitly allowed. So who's right -- Metrowerks or everyone else? Jonathan

2 5

[iostreams] failure do build zlib.cpp in cvs HEAD
by pedro.lamarao＠mndfck.org 02 Jun '05

02 Jun '05

It seems the declaration of zlib_base::reset in zlib.hpp doesn't agree with the definition in zlib.cpp. After applying the following trivial patch everything compiles fine. -- Pedro Lamarão Index: boost/iostreams/filter/zlib.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/filter/zlib.hpp,v retrieving revision 1.18 diff -r1.18 zlib.hpp 194c194 < void reset(bool compress); --- > void reset(bool compress, bool realloc);

2 1

PyQt and Boost.Python working together
by thor.arne.johansen＠ibas.no 02 Jun '05

02 Jun '05

I found a long thread discussing this topic, but the conclusion escaped me... Is it possible to use an extension created with BPL in a program using PyQt to provide a GUI? -- Thor Arne Johansen Technical Director Ibas AS

2 1

[Boost-bugs] [ boost-Support Requests-1213620 ] Configure options (CCFLAGS, LDFLAGS) ignored in build ?
by SourceForge.net 02 Jun '05

02 Jun '05

Support Requests item #1213620, was opened at 2005-06-02 09:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1213620&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: Configure options (CCFLAGS, LDFLAGS) ignored in build ? Initial Comment: Hi, on our Red Hat Enterprise Linux 3.0 Opteron Machine the g++ is configured to produce 64-bit binaries. When trying to build 32-bit objects via the "-m32" compiler and linker options, the boost build mechanism simply seems to ignore the option provided. Interestingly one can provide this option to the configure script but in it's output (the user.hpp file) the option only appears as a comment. It seems to get completely ignored in the subsequent build and test stages ! Is this true or am I missing some way to configure things here ? How can I supply special compile/link options to the build/test stages of the boost build process ??? Thanks in advance Frank-Oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1213620&group_… ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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