June 2005 - Boost - lists.boost.org

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

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