- Boost - lists.preview.boost.org

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Works perfectly now. Thanks for your help guys!!! > Finally, Dirk, if you don't want to use shared_ptr<void> (and casts) > everywhere you can include boost/type_traits.hpp and use remove_pointer: > typedef shared_ptr<remove_pointer<HDC>::type> dc_handle; > typedef shared_ptr<remove_pointer<HWND>::type> wnd_handle; I take that as a christmas present :-) The compiler just started to complain about void* is not HDC and I was just starting to add the needed casts. This is really cool! Thanks a lot - you saved me from writing a lot of extra code... I wish you both all the best for the new year!! -Dirk

1 0

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Thanks - the custom functor works, but I don't understand why using boost::bind or std::bind1 fails: Does anybody know why the compiler complains about this? typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { handle spHandle( GetDC( hWnd ), bind( &ReleaseDC, hWnd, _1 ) ); return handle; } The compiler has problems with the return_value. I will attach the compiler output to the end of the mail. It is in german but you should get the idea anyway. c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2039: 'result_type': Ist kein Element von 'operator``global namespace''' c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'type' c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(62) : error C2955: 'boost::_bi::type': für die Verwendung einer Vorlagenklasse ist eine Vorlagen-Argumentliste erforderlich c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost 1.32\include\boost\bind.hpp(111): Siehe Deklaration von 'boost::_bi::type'

2 1

Re: [boost] Re: thoughts on a GUI component library
by Marcelo E. Magallon 29 Dec '04

29 Dec '04

On Tue, Dec 28, 2004 at 05:28:15PM -0500, Alan Gutierrez wrote: > > That's easy: you start with a vector description of *everything* > > and plug a rasterizer where needed. This vector description in > > Quartz is called DPS: Display PostScript. > > > This gives you the gimmicks you see on MacOS X, for example window > > minimization and maximization effects. You just need to start > > with a rectangle, and subdivide the edges, and apply some > > transformation to them. Then you can use algebraic grid > > generation to compute the inner grid. And now you only need to > > apply the grid transformation to the elements of the window. > > So where can I learn about algebraic grid generation? I'm not at the office now, I'll write this down and mail you a couple of references next week. I think they could be useful for getting you started if you have interest in the topic. It's nothing more than just careful interpolation. > I understand what you are saying architecure wise. Do you really > feel that it is easy? Could it be cross-platform? I'm of a mind > that you start with rendering soultions, rather than widgets. It's conceptually easy. The basic idea is that you need some sort of abstraction to display hardware, nothing new there. If you orient this abstraction towards raster devices like the screen, you basically tie both of your hands behind your back when it comes to dealing with significantly different devices like a printer or a text-based UI. If you start with vector graphics, rendering to the screen is easy, it's "just" rasterization (ok, it's full of pesky details, but that's a different thing). Rendering to a printer is either transforming your vector description to the printer's vector description (PostScript, ...) or rasterizing at a given resolution. There's still nothing new there. You could implement OS X's gimmicks on top of X11 or GDI, with some amount of pain involved. The problem is neither is particularly good at working with affine transformations or texture application or alpha blending or shading. Here's where Quartz shines. This is also what Cairo Graphics is trying to be. Could this be cross platform? It depends on what you mean by that. Would something like this work across platforms? Sure, why not? Would something like this work across platforms if you want to use the native widgets? Probably not. And yes, I tend to think about the rendering part of the problem because that's what I do and that's what interests me. It's also one of the spots that hinders portability: don't take it too far, think of something as simple as fonts. I would also like to see a nice event loop system (because that's one wheel I've reinvented many times already and I don't feel I've gotten it right yet), so if you start discussing that (from the Boost POV) I will pay closer attention :-) I my opinion GTK+ has got the whole UI thing right (or "as right as it can get"). They have clear boundaries between different parts of the system: rendering (with GDK as an abstraction on top of X11 and others), widgets (GTK+ itself), accessibility (ATK), text handling and rendering (Pango), themability. Where GTK+ sucks at is extensibility: it's a pain to write new widgets. The whole signaling business in GTK+ is also awkward to say the least. GTKmm is an improvement over GTK+, but there are some corners which still feel somewhat "wrong" (perhaps because GTK+ is "still underneath") On the other hand I think Qt got and still gets the whole thing wrong. (That and the fact that they reinvented wheels that didn't need reinventing in the first place). I'm getting way off-topic... Marcelo

1 0

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Thanks for your help and sorry for not looking carefully at the documentation: I tried the following for a Windows device context: The creation function is: HDC GetDC( HWND) The deletion function is: int ReleaseDC( HWND, HDC ); // Code like in the documentation... typedef shared_ptr<void> handle; handle make_dc( HWND hWnd ) { // The release function takes two arguments, so I tried an adapter functor...unfortunately it does not work handle( GetDC( hWnd ), bind1( ReleaseDC, hWnd ) ); } My problem is to bind the window handle to the custom delete function. My compilter spits aout a lot of error messages here. Can I use boost::bind here or boost::function? BTW: How does shared_ptr call the custom delete function? For a COM object it should call in the D'tor: raw_ptr->Release(); While in my case it should call ( what is the usual way in the C++ standard IIRC ): Release( raw_ptr ); Does the shard_ptr interface figures this out in some clever way and manage this internally? Regards, -Dirk

3 3

addressof with Metrowerks and Boost Function/Signal
by Reece Dunn 29 Dec '04

29 Dec '04

I am getting ambiguity errors on Metrowerks 9.2 when using Boost.Function and Boost.Signal. These errors can be corrected with the following patches: <boost/function/function_template.hpp> (470) - if (!detail::function::has_empty_target(addressof(f))) { + if (!detail::function::has_empty_target(boost::addressof(f))) { <boost/signals/trackable.hpp> (105) - add_if_trackable(addressof(t)); + add_if_trackable(boost::addressof(t)); Regards, Reece

2 1

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 29 Dec '04

29 Dec '04

In-Reply-To: <20041223171108.GB6938(a)maribor.izzy.net> alan-boost(a)engrm.com (Alan Gutierrez) wrote (abridged): > > That's okay for simple things, but for any serious printing work > > you need to know you're talking to a printer. For example, you > > may need to embed postscript in your output stream. > > I'd like to look at how OS X is able to make a PDF of everything. I can think of two ways. First, the PDF can reflect what would be printed if the printer did not support postscript (which not all printers do). Second, PDF can itself contain embedded postscript. -- Dave Harris, Nottingham, UK

1 0

smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Dear group, is it possible to use smart_ptr with handles ( e.g. HWND, HBRUSH, HDC, etc )? Wouldn't it be quite convenient to have something like a scoped or shared resource? The idea came when I looked my OpenGL initialisation code, where I have to free the resource explictly every time an error occurs, which make the code somehow a little bit more difficult to read and I though that it would be nice to have some kind of RAII mechanism here. Regards, -Dirk

5 4

Re: [gui] Concerning Scope (Was: thoughts on a GUI component library)
by brangdon＠cix.compulink.co.uk 29 Dec '04

29 Dec '04

In-Reply-To: <20041224050911.GA9037(a)maribor.izzy.net> alan-boost(a)engrm.com (Alan Gutierrez) wrote (abridged): > > I'm a bit concerned about the scope of this boost project. Our > > drawing framework is pretty huge. > > This is an important discussion to have sooner than later. > > 1) Is a GUI project a bad idea? > > 2) Is Boost the right place for the a GUI project? Supposing "yes" to both, that still leaves the question of scope. Possibly a "GUI" could just mean a high-level windowing system, and not a graphics drawing system. There is a lot to do just managing a tree of rectangles and dispatching events to and through them. The windowing system should arguably not care about the contents of the rectangles. It seems to me that adding a graphics system, with pens and brushes and polygons and text and bitmaps and wotnot, makes the project much bigger. Which isn't to say we shouldn't do it, and do all of it, but perhaps it is worth dividing it up into chunks or layers that are more or less independent. If that is possible. > I believe the time is ripe for a small, light-weight, XML + CSS > renderer to attack the new surge of RSS content on the web. OK. Perhaps my issue is that when I think of "GUI" I don't immediately translate that into "XML + CSS". -- Dave Harris, Nottingham, UK

6 6

thoughts on a GUI component library
by Reece Dunn 29 Dec '04

29 Dec '04

Hi All, I have been working on revising my GUI library that is currently in the sandbox. The motivation for doing this was Andy Little's comment that most GUI libraries start from a particular operating system and then abstract its interface, providing work-arounds for other GUI systems. There are several considerations to make with a GUI library. For insatance, it should be possible to support GUI interfaces on portable devices (e.g. Palm Pilot/PalmOS) and terminal devices (like is done with the VIM editor). With these devices, code needs to be written to provide common components such as buttons. Also, the target operating system places design problems on creating a generic interface. For example, Windows supports char * and wchar_t * versions of its API, but the version that should be used depends on whether you are targetting Windows 9x or NT based systems. Windows also requires each component type to be registered before you can create an instance of it. Each operating system has different arguments that it passes when an event is generated, containing data relating to that event. Consideration must be made to allow events to be written generically, but also allow you to hook into OS-specific events and get OS-specific data. With all this in mind, how do you design a GUI library for C++? Although a GUI component exists on the screen and is drawn on that screen, the components and graphics elements should be kept seperate, since it is primarily the OSs role to render a component. There are shared elements (mostly the position, size and area types) and the graphics layer should allow for graphics-based events to be handled by the components library. Taking a look at how C++ is designed, it is predominantly data orientated. That is, C++ allows you to create new data types that fit into the language via operator overloading. The STL provides collections of data and algorithms for manipulating those collections. Terminal-based applications are supported by I/O streams that allow you to send data out and read data in. I have taken this as the primary design feature when implementing the GUI components. Thus, each component has an event to signal user interaction (ondatachanged, onselectionchanged, onpressed) and data that is associated with the component. The first thing that comes to mind when reading "data that is associated with the component" is data binding. I think it is a mistake to build data binding directly into the component architecture. The reason for this is twofold: You would need to use templates to bind the different data objects to the control which makes it harder to implement the controls in a platform-independant way and can lead to code bloat. Also, consider having a textbox widget that you use to enter the age. Having: gui::textbox< long > age; How does the textbox perform the conversion? By storing the data as a string, the user can extract the information on data collection like this: long age = boost::lexical_cast< long >( age_input.get_text()); or long age = ::atol( age_input.get_text()); Another thing to take into account is when an input field has a validity based on other component values. For example, the valitity of a dates day field is dependant on month and year. In this instance, it is best to put all the validation logic in the base component and extract the data to a date class such as Boost.DateTime's date. A component has a size and position, as well as visibility (visible or hidden) and enabled/disabled states. The component should make it easy to interoperate with native API. The majority of the current proposals (mine included) have taken the approach of providing native interoperability with the OS-specific data structures. This is very difficult to maintain properly and support generic code because of the different names of the data elements, types used (long or float) and whether an area is (position + size) or (top-left + bottom-right). Also, most OSs have (0,0) being the top-left corner, but MacOS has (0,0) being bottom-left. With this in mind, I have taken a drastic approach: do not provide native interoperability for size, position and area. I have designed them as: struct position{ float x; float y; }; struct size{ float dx; float dy; }; struct area { float top; float left; float width; float height; }; This means that the interface must convert these to the native representations and vise versa. The current implementation (Windows specific at this time) can be found at: http://uk.geocities.com/msclrhd/gui/gui.zip Thoughts? Comments? Regards, Reece

14 36

[iostreams] New version avaiable
by Jonathan Turkanis 29 Dec '04

29 Dec '04

Dear All, The latest version of the Iostreams library is now available: http://home.comcast.net/~jturkanis/iostreams/ I'd like to thank everyone who sent me bug reports after I posted the previous version. I will include you in the acknowledgments when I rewrite the documentation. Contents: - I. Changes - II. Supported platforms - III. Remaining bugs. ----- I. Changes. There are two important changes. First, the code conversion component has been renamed "code_converter", and it now has an optional Codecvt template parameter. Example. #include <boost/iostreams/code_converter.hpp> #include <boost/iostreams/device/mapped_file.hpp> // Perform code conversion using the global locale: typedef code_converter<mapped_file_source> wide_mapped_file_source; // Perform code conversion using utf8_codecvt_facet: typedef code_converter< mapped_file_source, utf8_codecvt_facet<wchar_t> > utf8_mapped_file_source; code_converter has now been tested with all the codecvt facets from the Dinkumware CoreX library. Second, there is now an option to build the libraries zlib and bzip2 from the source, rather than linking to a pre-built version. To build zlib from the source, define the following variables: ZLIB_SOURCE - path to the .co files ZLIB_INCLUDE - path to the .he files, if different from ZLIB_SOURCE To link to a pre-built version, define the follwing variables: ZLIB_INCLUDE - path to the .h files ZLIB_LIBPATH - path to the library or archive file ZLIB_BINARY - name of the library or archive file If ZLIB_LIBPATH is not defined, it is assumed that the library file is in a location where it will be found automatically. If ZLIB_BINARY is not defined, it defaults to "z" on UNIX and Cygwin, and to "zdll" on windows (see http://www.gzip.org/zlib/DLL_FAQ.txt) Similar remarks apply for bzip2. ----- II. Supported platforms The tests have been run on the following platforms: VC7.1 with Dinkumware GCC 3.2 (MinGW) GCC 3.4.2 (MinGW) GCC 3.4.1 (Cygwin) CodeWarrior 8.3 (static runtime only) Intel 7.1 with Dinkumware (static runtime only) Intel 8.0 with Dinkumware Borland 5.6.4 with STLPort Failures: - GCC (MinGW, Cygwin): wide streams not supported - Borland 5.6.4: undiagnosed runtime errors in seekable_file_test.cpp, direct_adapter_test.cpp and code_converter_test.cpp III. Remaining bugs. Although the bzip2 tests pass on all the platforms in II, there is an outstanding problem reported by Michel Decima which I haven't been able to fix yet. Best Regards, Jonathan

1 1

Template Metaprogramming I/O (well, O anyway)
by David Greene 29 Dec '04

29 Dec '04

I asked this question a year or two ago on the list. Has anyone come up with a good way to dump template metaprogramming information at compile time? I'd like to be able to do this both in a "print" sense (compiler warnings) and an "error" sence (compiler abort). I hacked something together last week that sort of does the job. There's a print<Message, FileLine> class that has a constructor with an unused variable declared. gcc gives a nice warning with -Wall. I also have some hacked macros to pass file and line number information to the printer. The printer will dump a warning if its constructor is ever instantiated. The use of all this appears in my last post in the "Named Template Parameters" thread. But this is really terrible. I don't like it much so I'm hoping someone else has a better solution. In particular, it's almost useless if there are any errors in the code because compilation will stop before instantiation happens. Unfortunately, this is _exactly_ the case where one really wants to get this information and figure out what's causing the compiler abort. I know this is useful functionality, practically required for any large metaprogramming project. I'd like to see if Boost can make something really good. -Dave

3 6

Re: Interest in a fast lexical analyser compatible with Spirit
by Dave Handley 28 Dec '04

28 Dec '04

Hartmut Kaiser wrote: >Since tokens have to be copied around in a typesafe manner I'd have >expected >to have something similar to the boost::variant, but maybe I've got you >wrong... How do you plan to achieve this? Copying through a base class >won't >work AFAICT? In my experience, copying around tokens is a major source of slow-down in lexers. The last lexer I wrote, I had to abandon the token class and use a C style union containing ints, doubles and std::string pointers. At the time, I was a little restricted in the amount I could use boost by my company, so I couldn't use boost.variant. Since then I've been putting a lot of thought into this problem and come up with one solution. We haven't completed integration testing with Spirit and other libraries yet using this technique (and I can foresee some issues already :-( ). The solution uses flyweighted tokens. The actual token exists in the rule, and during parsing, if the token has an assigned value, this is copied into the flyweight, then the token is passed around by reference/pointer. When you come to use the token in the parser you have a number of options: 1) Use it and then throw it away as soon as you call the ++ operator on the token_iterator. 2) Get the data out and do something with it - for example put it in a list/deque, etc. 3) Copy the token and use the copied version. For this final option, the token supports a virtual clone function to create copies of the flyweighted version for use elsewhere. An implementation point here is that the iterators contain a pointer to the token so that the iterator can be copied, or have the equals operator called, etc. There are some other potential solutions. However, any other solution leaves the problem of how to allocate and deallocate tokens on the heap very fast. I considered using Alexandrescu's small object allocator from the Loki library, and have also briefly looked at a boost.pool, but I am not comfortable with either of these solutions, because I am convinced that it will add too much of a burden to token creation. In my last lexer I found one or two orders of magnitude of speed improvement when I removed the token class and replaced it with a union. Since our first priority on this project is speed, I do not want the framework to slow down the DFA at all. The critical path in execution should definitely be the DFA. Dave Handley

1 0

Re: Interest in a fast lexical analyser compatible with Spirit
by Dave Gomboc 28 Dec '04

28 Dec '04

> "The Hapy library would not exist if Spirit would generate correct > parsers by default..." > > Whoa. Them's fightin' words! I believe the author is referring to incomplete backtracking (not backtracking past an accepted token when there's a failure later on). It's something the Spirit gurus have taken into consideration for Spirit 2, AFAIK. Dave

2 1

Interest in a fast lexical analyser compatible with Spirit
by Dave Handley 28 Dec '04

28 Dec '04

Since I get the mailing list in a digest, it looks like I have a lot of questions to answer. Sorry for the long(er) post, but I'm answering them all in one post: Darren Cook wrote: >There seems some interest currently in alternatives/improvements to Spirit, >so I thought I'd mention Hapy: > http://hapy.sourceforge.net/ I'll have a look at Hapy and see whether we could interface to that as well. Joel de Guzman wrote: >Some more things to note: >* why use lexeme_d on the lexer stage? >* the comment rule can be rewritten as: > '#' >> *(anychar_p - eol_p) >> eol_p; >* stringLiteral can be rewriten similarly. >* word can be rewritten using chsets. I used lexeme_d because the VRML grammar uses whitespace to separate ints and floats. Without the lexeme_d, ints could merge into one. The other optimisations are all valid, but unfortunately, don't make any difference to the stopwatch. This is because comments, stringLiterals and words don't occur too often in a VRML file - most of the time is spent parsing floats and ints. Joel de Guzman wrote: >Sure, no problem. But watch out, Spirit-2 will have a speed improvement >in the 10X-20X range over classic Spirit ;-) I already have some test >cases, and this does not touch on predictive parsing and lexing. Joel, I would be really keen to try running my VRML test case through Spirit-2. Given that I've now got the Spirit-1 parser running at about 6-7 seconds, if you get a 10x speed improvement on this file, then it could make the case for separate lexing much harder to support! I may also need a bigger file to start doing test cases on - millisecond test timings don't make for accuracy in my view :-) Joel de Guzman wrote: >Anyway, as I said, I'm very interested with your lexer. >Would you be interested in a collaboration? Yes, we would be very interested in a collaboration. Hartmut Kaiser wrote: >How do you specify production rule's? Your above sample specifies how to >use >the recognition part only ;-) >The numbers are the token ID's, I assume? The production rules are wrapped up in the different (and extensible) concept of a token. The token_float for example will match a float, then store the matched number as a float inside the token. The normal token stores nothing since something like a keyword match you don't need the overhead of the original text, but the token_string stores the string that was matched. I am contemplating an interface that allows you to use a functor to perform some basic string manipulation before the token is stored - for example dropping the enclosing quotes or similar. Although this is clearly similar to functionality already available in Spirit. Yes the numbers are token IDs - I have contemplated using const char * template parameters as well, but at present I haven't done that because of the added difficulty of ensuring that your names have external linkage. Perhaps in the final version we can support both. >Is your token type a predefined one or is it possible to use my own token >types instead? >I'm asking, because Wave in principle allows to use any token type for its >work, but it requires the tokens to expose a certain (very small) >interface. In the system as stands, all token types must inherit from a base version. This base version provides lots of useful virtual functions that derived token types can work with. The iterator interface then returns the token_base from its de-reference function. You can define new token types, but accessing the specific interface on the derived token means doing one of: 1) Ensuring the interface is exposed in the token_base. 2) Using polymorphic despatch to get the correct type, through a visitor for example. 3) If only a single token type is used in the lexer then use a static_cast. 4) Using a dynamic_cast. You can also define new rule classes - at present we have written a rule class for conventional tokens, and another rule class for tokens that have a dynamic (run-time) ID rather than the static (compile-time) ID in the template parameter. Dave Handley

3 2

[GUI] some random thoughts on GUI libs
by Christopher D. Russell 28 Dec '04

28 Dec '04

Some random thoughts on GUI libraries: Message filtering, dispatch: Somewhere buried in Joel de Guzman's Spirit or Phoenix docs I recall mention of functional programming techniques being useful for working with graphical user interface library organization. This comment stuck in my head as I generally dislike the organization of message dispatch and filtering code in libraries like the MFC and the WTL. I've been interested in the idea of leveraging Spirit to implement event processing systems for some time (here we parse event streams - not characters, using Spirit's grammar to encode state machine transition logic, and dispatching specific state-bound actions via Spirit's semantic actions). In the context of a GUI library, it's occurred to me that Spirit might be employed to "parse" streams of mouse, keyboard, and graphic subsystem notification events via a custom Sprit scanner. This of course implies that mouse, keyboard, and graphic subsystem hooks are abstracted in some platform independent manner but that's doable. In essence, this is just another way to encode complex state machines. But I think it would be cool to encode the message filtering and dispatch logic in EBNF! Message routing: signals / slots? Window / subwindow hierarchy: Given that typical GUI applications have many "windows" that are typically created and destroyed in response to (a) user input (b) non-graphical subsystem events, a succinct mechanism is needed to keep track of parent / child windows hierarchies. This information is used to calculate / transform drawing coordinates, and affect changes to message dispatching / routing / filtering. I think this information should be modeled using the BGL so we can customize the overall behavior of the system using graph algorithms. One could go a step further even and use a top-level graph to model the windowing hierarchy and another graph associated with vertex properties to encode an arbitrary closed polyline to represent non-rectangular windows. Threads: It's useful to be able to associate a "window" with a thread for high-performance GUI drawing. This is somewhat of a pain under Windows for legacy reasons but it's possible (I've done it within the context of the WTL). Here you simply blast the video subsystem with draw requests from multiple threads and place the onus of optimizing the call sequence on the driver and the underlying hardware. It would be useful to take this into account explicitly and build multithread support directly into the library. Placing the burden of this on the library user will invariably limit the portability of any application written against the lib I think. Just my two cents worth - Chris

6 10

[gui] On Native Controls
by Alan Gutierrez 28 Dec '04

28 Dec '04

* I don't think it matters much, to the user, if the button they click is a Motif button or an Aqua button, so long as their form is processed. Go to Amazon. All the buttons there are images. * Dealing with Win32 GDI controls is pain. Because they consume a Win32 window they are not going to place nice a more complex layout like a grid or a document. They are so few an simple, it is trivial to replicate them. The Win32 GDI is going to be a real problem, and it will put unnecessary design constraints on the GUI library if its poor behavior is enabled. * It is an aspect of the View of MV[PC] and the developer must be able to choose the View that suits their application. I think native controls should be supported in the case of PalmOS, where you can't overlay them anyway. Or in the case of windowing libraries that allow their controls to be clipped, where the native controls will behave properly when overlayed, and thus can take part in a complicated layout. -- Alan Gutierrez - alan(a)engrm.com

7 11

RE: FYI Lambda Question
by Brian Braatz 28 Dec '04

28 Dec '04

> -----Original Message----- > From: Powell, Gary [mailto:powellg@amazon.com] > Subject: RE: FYI Lambda Question > > So I'm checking now but I believe we set a typedef for the use of > "boost::result_of" > http://www.boost.org/libs/utility/utility.htm#result_of > > > -Gary- Thank you for your help that looks like EXCATLY what the doctor prescribed :) We MIGHT have some missing files? I am about to convert to boost 1.32 I am still on 1.31. In the 1.31 zip file I downloaded (and am using), the header does not exist in the utility dir. I grepped the boost tree for result_of and only found one comment in transform_iterator.hpp which is stated as a question ("do we need to adjust the way function_object_result is computed for the standard proposal (e.g. using Doug's result_of)?") (line 64). The link to the web page you sent me points to a HPP file. This file does not seem to exist in utility. For experimenting, I copied the file referenced in the page below to boost\utility. It complained on the line #include <boost/mpl/has_xxx.hpp> That has_xxx.hpp does not exist. Is it possible the file got dropped somehow? (it would be a shame for such a useful template to be "lost") Thanks again for your help. Brian

2 1

Interest in a fast lexical analyser compatible
by Dave Handley 28 Dec '04

28 Dec '04

Hartmut Kaiser wrote: >I'd be willing to write the interfacing stub to plug your library into >Wave. Thanks - I think this should be relatively easy because we currently use a forward iterator across the tokens in order to generate suitable output for Spirit. Clearly one of the requirements for the Boost community to accept this library in general will probably be meeting the Standard requirements for forward iterators - and I note that this is one of your key requirements in Wave. >The two different lexers I was using in the Wave library were a re2c based >lexer (static switch based lexer, extremly fast and compact) and a SLEX >based lexer (runtime generated DFA). I haven't done serious speed >measurements, but the numbers I've got so far showed similar timings for >both with a slight advantage for re2c (as expected). I'd expect your >library >to be very similar in speed as well. But just out of curiousity I'm very >interested in seeing the static DFA generation version :-) Can these lexers be effectively used with any Spirit grammar? I'll download Wave over the next few days and have a look at how much overlap there is between our library and the lexers within Wave. My plan for the static DFA version (which we haven't fully discussed in our internal design discussions yet so may change significantly), is to use the memento pattern to reflect the internal state of the DFA, along with the production rules. These could then be saved or loaded, or serialised to a C++ file, in a rather similar way to flex. This would mean that the lextl classes would be both an inline and an offline tool. In principle this gives some very desirable advantages: 1) The API remains the same in both compile-time and run-time versions. 2) You can very easily swap between run-time and compile-time versions - for example during development you may use run-time creation to speed up the process of developing a complex grammar, then switch to compile-time for your production release. 3) You have a number of options for compile-time versions. The grammar can be in a configuration file, or compiled into the program directly. >at least you could have used the symbol parser ... <snip> I've changed the Spirit grammar to use the symbol parser, and dropped the time from 40-50 seconds to about 6-7 seconds. Thanks for the tip. >Is there any documentation available? No, I'm sorry, we don't have any documentation at present, because we are still only a little beyond a prototyping stage. We still have to refine the API a little, and complete some optimisation work before we publish an early Alpha. As I said in my original post, I'm trying to gauge interest at the moment, and I'm pleased to see that we are generating a little interest. As a flavour, the current API would result in some code looking like: syntax<> mySyntax; mySyntax.add_rule( rule<token<1> >( "Group" ) ); mySyntax.add_rule( rule<token<2> >( "Separator" ) ); mySyntax.add_rule( rule<token<3> >( "Switch" ) ); // Lots more symbols for the rest of VRML... mySyntax.add_rule( rule<token_float<69> >( "([-+]?((([0-9]+[.]?)|([0-9]*[.][0-9]+))([eE][-+]?[0-9]+)?))" ) ); mySyntax.add_rule( rule<token_string<70> >( "#[^\\n\\r]*[\\n\\r]" ) ); mySyntax.add_rule( rule<token_string<71> >( "\"[^\"\\n\\r]*[\"\\n\\r]" ) ); mySyntax.add_rule( rule<token_string<72> >( "[a-zA-Z_][a-zA-Z0-9_]*" ) ); mySyntax.add_rule( rule<token<73> >( "[ \\t\\n\\r]+" ) ); lexer<> myLexer( mySyntax ); std::ifstream fsp( "test.vrml" ); myLexer.set_source( fsp ); // Also it will have a char iterator interface lexer<>::token_iterator iter = myLexer.begin(); for ( ; iter != myLexer.end(); ++iter ) // Do something with the tokens... ; Essentially you create a syntax to which you add rules. These rules explain the token that will be created by the rule, and a regular expression to be matched. Special versions of tokens exist that will automatically generate a float, int or string from the matched expression. You then construct a lexer off the syntax, set a suitable source input, and then iterate over the tokens. The tokens are polymorphic so you can easily access the type and data, they are statically typed so you can use types to match the tokens, or you can dispatch tokens to functions through a visitor framework. You can also use dynamically typed tokens as well if you want - although you lose much of the benefit of strong typing. I especially like the idea of using visitors to distinguish between tokens. This means that in my example of a VRML file, the long float lists can be handled with a visitor that contains visit functions for a float token, a comma token (note that in vector lists in VRML the elements in a 3D vector are separated by whitespace, and the 3D vectors themselves separated by commas) and a list termination token (eg a "]"). The visitor would then automatically store the floats in a suitable data structure - like a list of 3D vectors. Dave

3 2

Interest in a fast lexical analyser compatible
by Dave Handley 28 Dec '04

28 Dec '04

Dick Hadsell wrote: <snip> >disappointed, because I was hoping to use Spirit or something like it, >to give me some independence from Lex/Yacc's dictatorial control of the >input source. >Your project sounds like it would solve the worst of the problems I have >in trying to move to Spirit. The current API we are working with templatises the input so that in theory it will work with any character like input, in much the same way as std::basic_string<>. We are still working on getting the DFA to work generically, rather than just explicitly with char and wchar_t, but I think we should have some success. At present the lexer is strongly typed from this character type in the same way as std::basic_string<> but I don't necessarily see that as a problem. >I broke up the problem into 3 steps. In the first phase the program >uses a Spirit grammar to generate a list of tokens with info similar to <snip> Depending on the type of grammar I think you should easily achieve a 6x or greater performance boost. If the input has long repetitive sections, you could probably further optimise the stage so that the lexer does most of the work - for example if you have long lists of numbers or similar. I'm not sure how well this would work with Spirit until I try it, but it should be possible to switch control part way through a parse to a very quick and efficient parser that just throws the tokens at a visitor until a particular section is finished. I'm sure this could probably be done by writing a new parser type in Spirit. The idea would be to process long lists of numbers or strings or similar, where those lists have a clearly defined end token. Dave Handley

3 2

Interest in a fast lexical analyser compatible with Spirit
by Dave Handley 28 Dec '04

28 Dec '04

Christopher Diggins wrote: >Would you please post the grammar productions you used for Spirit? Would >you >consider testing the yard parser as well, http://yard-parser.sf.net ? Are >there other advantages of your tool over Flex, other than providing a nice >interface to Spirit? The grammar for Spirit was (in a slightly cut down form): keyword = str_p( "Group" ) | str_p( "Separator" ) | //etc.; comment = lexeme_d[ ch_p( '#' ) >> * ( ~chset_p( "\n\r" ) ) >> chset_p( "\n\r" ) ]; stringLiteral = lexeme_d[ ch_p( '\"' ) >> * ( ~chset_p( "\"\n\r" ) ) >> chset_p( "\"\n\r" ) ]; word = lexeme_d[ ( alpha_p | ch_p( '_' ) ) >> * ( alnum_p | ch_p( '_' ) ) ]; floatNum = real_p; vrml = *( keyword | comment | stringLiteral | word | floatNum ); I've cut down the keywords because there are over 60 of them. I would be interested to know if there was any obvious ways to optimise the Spirit parser. Regarding writing a comparitive test for YARD, I will certainly consider it, although I have no experience of using YARD. I've written quite a lot of flex/bison parsers, written a number of Spirit based parsers, and hand coded a number in my time, but I would need to spend a little time learning the YARD framework first. There are a number of advantages over Flex (including a nice interface to Spirit). The key ones are: 1) An extensible object oriented approach to writing the entire system. This can be very useful if you want to handle something like say the parsing of a filename in the lexer. You can simply write a new token type that will split the incoming filename into path, extension, name, etc. This can massively simplify the production of a final parser - allowing you to deal with grammar issues at that stage. 2) DFAs can be created at run-time, or eventually compile-time. 3) The code is considerably less obfuscated than the code produced by flex. Don't get me wrong, I like flex a lot, but the pre-processor directives, and look-up tables in the generated code are pretty unreadable IMHO. Dave Handley

4 3

Interest in a fast lexical analyser compatible with Spirit
by Dave Handley 28 Dec '04

28 Dec '04

A colleague and I are working on a fast lexical analyser designed to work alongside Spirit. We currently have some working prototypes, and as such I thought that I would gauge interest in this library. We plan to produce a DFA based lexical analyser that provides output as a set of iterable polymorphic flyweighted tokens. These could then be provided as input to Spirit instead of character iterators (albeit with the addition of a token_p parser in Spirit). The objectives of our project are as follows: 1) As fast as lex/flex. 2) Simple to use 3) Rules to generate tokens can be provided both statically and dynamically. Static definition would be through an offline pre-process stage much like lex. 4) Easy to interface with Spirit. I understand from Joel's posts below (both on this group and on codeproject) that he is already planning some work to this end. My understanding of expression template based lexers is that they can outperform DFAs under some circumstances, but with other situations DFAs can provide the best performance. I am therefore recommending this in addition to Joel and Eric's work rather than instead of it. Finally, as a taster of the work we are doing, I have performed some rather unscientific and arbitrary performance tests on a 20Mb VRML 1.0 file. The performance of flex, Spirit, and our new library are as follows: flex: < 1 second new library: about 1 second Spirit: 40-50 seconds. These results were produced with no semantic actions to slow down any of the 3 solutions. They are also not conclusive, since we are almost an order of magnitude slower on an Athlon 64 bit machine at present. Dave Handley Relevant posts: Joel de Guzman wrote: >> I guess if you use string literals you'll have this >> problem no matter what, though I'm not sure the use of string literals >> should be a foregone conclusion. If you consider parser generators like >> YACC, they cleanly separate lexical analysis from parsing and the parser >> itself is never working with string literals. > >Again, true. However, one of the original intent of Spirit is to >be usable in micro parsing tasks. When parsing small grammars >like, say, a complex number, you do not want to write a separate >front end lexer. > >Anyway, I do plan to write an optional but separate lexer >sometime. Joel de Guzman wrote: > As for the lexer, I am working with Eric Niebler, author of Greta and >xpressive (google regular expression c++) with the hopes of developing >a powerful expresion template based lexer front end.

6 5

RE: [boost] Interest in a fast lexical analyser compatible
by Dave Handley 28 Dec '04

28 Dec '04

Hartmut Kaiser wrote: >I'm definitely interested to have a look at your library. Besides my >general >interest in Spirit I'd like to try it out as an alternative lexing >component >for Wave. I'm pretty sure this should is interesting for you as well, >because there are implemented already two different lexers, which gives a >good opportunity to compare them in a real environment. I have to confess to not knowing much about Wave, but I would be willing to look in more detail at using this library for Wave. Once we have our first stable version of the software we will be happy to let you have a look at it in more detail. I expect this to happen within the next month or so. >As for a dynamic DFA based lexer Wave already uses the Spirit based SLEX, >but a static DFA based solution is very interesting to look at. Is the DFA >generated at compile time? By static and dynamic, I am meaning compile-time and run-time. The system is designed to generate the DFA at run-time. But we are discussing a method at the moment whereby the same code base could be used to generate code-stubs for compile-time DFA creation. I am keen to support both. >We definitely should try the new upcoming Spirit-2 code base as well, since >it should be a lot faster then the current version. Is it possible to have >a >look at your test code as well? This way we could try to make a comparision >as soon as the Spirit-2 codebase evolves. I would be quite keen to see how Spirit-2 performs on similar tests. If the interest is there, then we will quite happily post the code into the boost yahoo group once we have completed a bit of tidying up in the New Year. We need to put some effort into writing more detailed test cases. At present, we are only directly comparing lexical analysis, and have not looked at the performance of the interface in real detail. We have a desire to properly test the system with a complete parse. To do this I think there are a number of useful test cases: 1) Flex and bison/lex and yacc. 2) Spirit - without any assistance from any lexer. 3) Spirit 2 once available. 4) Our library (called lextl at present) with yacc/bison. 5) Lextl with Spirit. 6) Lextl with Spirit 2. Case 1 would be the control - and the target performance for other cases to achieve. I am confident that case 4 should achieve the same speed, also I think there is a good likelihood of cases 5 and 6 achieving the same speed. The key question is whether 5 outperforms 2 and 6 outperforms 3. If this is the case, then I think we have a viable library. My current test file which is a 20Mb VRML1.0 file reduces to about 2e6 tokens when whitespace is stripped and the file is lexed. By using flyweighted tokens, we are hoping to reduce the overhead for Spirit to parse tokens instead of characters to a minimum, so the reduction from 2e7 to 2e6 input entities should give an order of magnitude speed increase to Spirit. At least that is my hope :-) Dave Handley

3 2

Interest in a fast lexical analyser compatible with Spirit
by Dave Handley 28 Dec '04

28 Dec '04

Christopher Diggins wrote: >Hi David, I will write the grammar for you. I am just finishing up version >2.0 of YARD, and then I will post the equivalent YARD grammar. Thanks. Hi Christopher - that would be excellent. I've had a quick look at YARD now, and consider it perfectly feasible to get our library to work with YARD as well. Essentially, all we require is a generic (ie templatised) interface that expects any form of forward iterator. It seems on first inspection that this is exactly what your library requires. Dave Handley

1 0

Re: [jamboost] Re: [boost] Re: #include <...> not in list of dependants
by Roland Schwarz 27 Dec '04

27 Dec '04

Rene Rivera wrote: > > Looking into this.. I don't see a problem on my setup. Specifically > Oops the thread got totally messed up. It is my fault I think, because I did not manage to subscribe to the correct list at the beginning. I crossposted to boost and jamboost. Sorry for this. This is the _last_ crosspost! Please every follow up to go to jamboost only! Back to the original problem: Steps to repduce the described behaviour: 1) Update boost tree from CVS 2) issuing SET TOOLS=vc-7_1 bjam --prefix=C: install 2) Editing the file boost/boost/thread/detail/config.hpp 3) issuing SET TOOLS=vc-7_1 bjam --prefix=C: install does not rebuild the threading library, altough I expected it to. Am I wrong with this expectation? Roland

1 0

[MPL] zip_view documentation bug?
by David Greene 27 Dec '04

27 Dec '04

I think I've found either a bug in zip_view with gcc or a bug in the zip_view docs. If I try to use a zip_view<> in which the sequences are not all of the same length, the compiler goes into "infinite" recursion instantiating at<> templates until it hits the instantiation limit. According to the MPL reference manual, the size<> of the sequence should be the minimum of the size<>es of all the participating sequences. At first I thought this was only a problem when one of the sequences is empty but I was able to reproduce it with populated sequences of varying length. Just two is enough to expose it. This is a problem with gcc 3.2, 3.3 and 3.4. I can work around the problem by using iterator_range<> and copy<> to truncate the sequences before feeding them to zip_view<>. What's supposed to happen in this case? -Dave

2 1

RE: [boost][regex] Bug in regex 1.32 ?
by Jan Hermelink 27 Dec '04

27 Dec '04

>> boost::regex re("x", boost::regex_constants::icase); > That should be: > boost::regex re("x", boost::regex::perl|boost::regex_constants::icase); Or boost::regex re("x", boost::regex::normal | boost::regex::icase) Ok, I have overlooked this statement in the documentation: "A valid value of type syntax_option_type will always have exactly one of the elements normal, basic, extended, awk, grep, egrep, sed or perl set". My fault - Thank you! Jan

1 0

Properties and boost::any / boost::program_options
by Dirk Gregorius 27 Dec '04

27 Dec '04

Dear group, I have a text file which defines several properties. For example: // Properties.txt "Position" "1.0 2.0 3.0" "Color" "1.0 0.0 0.0" "Intensity" "500" I wonder if it is possible to use the Property structure like defined in the boost::any example: // Property from boost::any help file struct Property { Property(); Property( const char* ) // Convinence c'tor for easy use with std::find Property( const std::string&, const boost::any& ); std::string Key; boost::any Value; } typedef std::vector<Property> Properties_t; // Operators for sorting and finding bool operator==( const Property& lhs, const Property& rhs ) { return lhs. Key == rhs.Key; } bool operator<( const Property& lhs, const Property& rhs ) { return lhs. Key < rhs.Key; } I want to do two things. First I like to parse through my text file and simply push_back() the parsed properties as pairs of strings: // The parse function - basically void ParseProperties( std::ifstream& is, Properties_t& properties ) { std::string key, value; while( is ) { is >> key >> value; properties.push_back( Property( key, value ) ); } std::sort( properties.begin(), properties.end() ); } Then later I would like to be able to process the properties like this: // Process the parsed properties... void ProcessProperties( const Properties_t& properties ) { typedef Properties_t::iterator PIter; PIter pos = find( properties.begin(), properties.end(), "Position" ); // Here we need the const char* c'tor if ( pos != properties.end() ) Vector3 position = any_cast<Vector3>( pos->Value ); } 1. Is it possible to use boost::any in this way? If yes - where and how do I have to implement the conversions? 2. If this is not possible could I use boost::programm_options instead for the value type? How and where do I have to implement the conversion here. 3. Would you suggest to define a simple Value class like this when I can not use any boost classes: class Value { public: Value(); Value( const std::string& ) template<typename T> T As(void ) const; private: std::string m_Value; } Are there any rules how to implement such a class? I have very, very few experience with template code. So do I need a traits class to look up the conversions in the As() function or how should a simple class like this be implemented in order to be nicely extendable by a client? I wish you all a nice christmas and a happy new year! Regards, -Dirk

2 1

[boost][regex] Bug in regex 1.32 ?
by Jan Hermelink 27 Dec '04

27 Dec '04

Hello, I think there is a bug in Boost.Regex 1.32.0 with regex_constants::icase. std::string s("xx"); boost::regex re("x", boost::regex_constants::icase); boost::regex_replace(s, re, "a"); The replace yields "axa"; should be "aa" I think. Without the icase flag the replace yields "aa". Thank you Jan

2 1

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 27 Dec '04

27 Dec '04

In-Reply-To: <cqcjii$hs0$1(a)sea.gmane.org> dave(a)boost-consulting.com (David Abrahams) wrote (abridged): > That's okay for simple things, but for any serious printing work you > need to know you're talking to a printer. For example, you may need to > embed postscript in your output stream. Not all printers support postscript, so you'd need to know not just that you were printing, but what kind of printer it was. Although there probably needs to be some kind of abstraction-busting pass-through mechanism, I see it as the exception rather than the rule. Another issue is transparency. My employer's drawing framework supports semi-transparency in the form of an alpha channel. This is used by us for things like anti-aliasing, and by users for subtle colour blends. Some printers can support transparency directly and some cannot. We found we needed a relatively elaborate architecture to hide that detail from application drawing code. I'm a bit concerned about the scope of this boost project. Our drawing framework is pretty huge. -- Dave Harris, Nottingham, UK

13 44

automatic garbage collecting algorithm and its implementation in c++
by yilin yang 27 Dec '04

27 Dec '04

hi, everybody i've just designed and coded a garbage collecting infrastructure named u_canforget. it was uploaded onto the news group at boost.yahoo. the main idea is that we count the reference to track the life-cycle of the given object. as the new operator was overloaded to statisfy this requirement. the other important concept was the reference object. with the syntax represented by the redefined macros, the codes may be written in a very simple way with relationships automatically constructed, objects are freed without delete operater can be realized as well. i would keep tracking this thread, if there are any thought about this algorithm. thx for your advices. your's yilin. --------------------------------- Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂美女明星应有尽有，搜遍美图、艳图和酷图 1G就是1000兆，雅虎电邮自助扩容！

1 0

Re: [boost] [gui] Shoulders of Giants
by brangdon＠cix.compulink.co.uk 26 Dec '04

26 Dec '04

In-Reply-To: <20041222211651.GD2616(a)maribor.izzy.net> alan-boost(a)engrm.com (Alan Gutierrez) wrote (abridged): > I'd like to take some time and study what has gone before. > [...] > I've advocated the use of a CSS layout component to render > the View-Controller aspect [...] Are you aware of the variations on MVC, in particular Model-View-Presenter? MVP has been so successful in Smalltalk that I consider MVC obsolete. Taligent's whitepaper is here: http://www.carfield.com.hk/document/software_design/MVP.pdf and there is more material at Object Art's Smalltalk site: http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.ht m -- Dave Harris, Nottingham, UK

3 3

spirit fileiterator always uses std_iterator on posix
by dieMumiee＠gmx.de 26 Dec '04

26 Dec '04

Hi, Found that code in boost/spirit/iterator/file_iterator.hpp template < typename CharT = char, typename BaseIterator = #ifndef BOOST_SPIRIT_FILEITERATOR_WINDOWS fileiter_impl::std_file_iterator<CharT> #else fileiter_impl::mmap_file_iterator<CharT> #endif > class file_iterator; BOOST_SPIRIT_FILEITERATOR_POSIX which is defined a few lines above is never used. Are there any issues with the posix-mmap code? It "worked" here, I modified the code to : template < typename CharT = char, typename BaseIterator = #if defined(BOOST_SPIRIT_FILEITERATOR_WINDOWS) || defined(BOOST_SPIRIT_FILEITERATOR_POSIX) fileiter_impl::mmap_file_iterator<CharT> #else fileiter_impl::std_file_iterator<CharT> #endif > class file_iterator; Regards, Andreas Pokorny -- +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl AKTION f�r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben

2 1

[Boost-bugs] [ boost-Support Requests-1091153 ] ublas extendability 2
by SourceForge.net 25 Dec '04

25 Dec '04

Support Requests item #1091153, was opened at 2004-12-25 10:21 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=1091153&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ublas extendability 2 Initial Comment: Hi. I want to multiplicate ublas matrices with custom (non- ublas) vectors. Is there some possibility ? Please see attached files and compilation messages. It seems that the job can be done with more knowledge of ublas tunning. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1091153&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Support Requests-1091151 ] ublas extendability1
by SourceForge.net 25 Dec '04

25 Dec '04

Support Requests item #1091151, was opened at 2004-12-25 10:18 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=1091151&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ublas extendability1 Initial Comment: Hi. I am using ublas with types other then built in scalars (like "double" or "int"). Typical jobs: prod(matrix<double>,vector<v3d<double> >) or triangular_solve(matrix<double>,vector<v3d<double> >). In order to be able to do it, I have made partial specialization of "promote_traits" template in namespace "boost::numeric::ublas" for my classes. This works. Is this technique good ? Or uBLAS intended only for built in types ? See attached files. Is it good to intervene to ublas namespace, like done in file "vnd.h" at the end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1091151&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Lambda Question
by Brian Braatz 24 Dec '04

24 Dec '04

Is is possible to, given a functor generated as a result of a lambda bind expression, pull the return type from the lambda functor? (still digging through the lambda bind code and have not found the answer to this yet. I sent a previous post with sample code that shows what I am trying to do) Any help or direction would be greatly appreciated. Thanks Brian

4 3

RE: [boost] Re: Lambda Question
by Brian Braatz 24 Dec '04

24 Dec '04

> -----Original Message----- > On Behalf Of Arkadiy Vertleyb > "Brian Braatz" <brianb(a)rmtg.com> wrote > > > Is is possible to, given a functor generated as a result of a lambda > > bind expression, pull the return type from the lambda functor? > > I am wondering if "result_of" may be something that you are looking for. > OTOH, I don't really know what the status of this library is. > > Regards Thank you for your thoughts- result_of looks like what I want - but I am having difficultly figuring out what the lamda factor LOOKS like after it is compile time generated. (I am (very very) slowly dissecting lambda bind to try to figure this out). IF ANYONE knows the answer to how you would GET TO result_of syntax wise help would be appreciated. (previous mail with sample code below) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brian Braatz Sent: Wednesday, December 22, 2004 8:03 AM To: boost(a)lists.boost.org Subject: [boost] Help \ Advice requested on getting the return type from aLambda fctor I wrote up the simple example that shows what I am trying to figure out Basically, I am trying to pull the deduced return type (or explicitly passed as a template param in lambda bind()) in my template. If I have a function that is receiving a functor, I would like to be able to take that functor and pull the RETURN TYPE out of it. Lets say I have a function that returns a string: std::string ReturnAString() { return "this is a string"; } And then here is my template function (code below does not compile) template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } Now here is my bind call std::cout << ( bind<std::string>(&ReturnAString)); Is there a way to GET to the return type in the Lambda fctor that was generated with a BIND call? I would like to be able to pull the <std::string> from the bind call and use it in the template function. It is not a problem for my template function to be dependant upon lambda bind. I have been going through the lambda code. And while it is brilliant, I am having a bit of difficulty figuring out what I am looking at (grin). Any help or direction is greatly appreciated FULL SAMPLE CODE HERE: template <typename CURRIEDTYPE> // Id class for currying type without creating the object class Id { public: typedef CURRIEDTYPE TYPE; }; // Explictly pass IN a return type template < typename TFUNCTOR, typename TRET> TRET CallFctorPassInRet ( TFUNCTOR & functor, Id<TRET> & ) { Id<TRET>::TYPE TRet; TRet = functor(); return TRet; } std::string ReturnAString() { return "this is a string"; } // try to get return type from the lambda fctor // Below does not compile- but it is along the lines of what I // WANT to do- note that I am trying to get from the Lambda functor the deduced return type template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } void Test_LambdaRetDeduction() { std::cout << "CallFctorPassInRet returns [" << CallFctorPassInRet( bind(&ReturnAString), Id<std::string>()) << "]" << std::endl; // below is what I want to make work std::cout << "CallFctorDeduceRet returns [" << CallFctorDeduceRet( bind<std::string>(&ReturnAString)) << "]" << std::endl; }

1 0

[logo] Happy Holydays...
by Rene Rivera 24 Dec '04

24 Dec '04

Boosters, Thought I'd give a tiny present for all... http://tinyurl.com/5kne3 http://boost-sandbox.sourceforge.net/vault/files/Boost%20Logos/Rene%20River… -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Problems compiling Boost.Test example with gcc under Linux
by Noel Llopis 24 Dec '04

24 Dec '04

I suspect the answer to this is going to be really simple, but I've been trying to figure it out for several hours and I'm ready to give up (I couldn't even find a mention of the problem in the mailing list archives). All I want to do is use the Boost Unit Test library with gcc under Linux. I have Boost 1.32 correctly installed (I've used other libraries successfully without any problems). Now I simply try to compile the simplest possible example: http://www.boost.org/libs/test/example/unit_test_example1.cpp This is what I get: gcc -o test boost_test.cpp boost_test.cpp:11: error: `boost::unit_test' has not been declared boost_test.cpp:11: error: expected nested-name-specifier before "test_suite" boost_test.cpp:11: error: `test_suite' has not been declared boost_test.cpp:23: error: expected constructor, destructor, or type conversion before '*' token boost_test.cpp:23: error: expected `,' or `;' before '*' token boost::unit_test has not been declared??? How is that possible? The compiler is correctly including the boost/test/unit_test.hpp file from the first line of the program. What am I missing? It must be something really, really stupid. I can tell :-) Happy holidays everyone! --Noel Games from Within http://www.gamesfromwithin.com

3 3

filesystem lib patch
by François Dumont 24 Dec '04

24 Dec '04

Find attached a patch for the filesystem library. remove and rename symbols are injected within the std namespace before being defined by the inclusion of cstdio header. The patch make the code less Standard library implementation dependent. Francois Dumont

2 1

Some observation re libraries as DLLS
by Robert Ramey 24 Dec '04

24 Dec '04

I'm making adjustments in the build and test Jamfiles to take into account changes made to permit the serialization library to be built and used as a DLL. This as raised a couple of questions in my mind. Re: the Jamfile for test a) It would seem to me that if the test is to be built and run with <runtime-link>dynamic - indicating the usage of C++ runtime dll, that the default build for the test should be to use the dll versions of all the libraries. I've managed to do this in sort of a kludgy way and it might be working. But I'm still working on it. b) the above raises the issue of how one should specifiy a target be built to use the dll vs the static library. <runtime-link>dynamic does something else. I was looking for a variant but I don't find it. I'm thinking that the way its done in the Program Options library is the way to go. c) when using the dll versions of boost libraries, the dll has to be on the path (at least with windows). It seems that bjam takes care of this automatically. So its only a problem when I want to debug the app with my VC IDE. It might be a good idea if the document mentioned this. d) The section on Testing Auto-linking in .../more\separate_compilation.html leaves me extremely confused. If I try to build the test without auto-linking by including the BOOST_???_NO_LIB then the libraries names searched for don't match the onces created by the build Jamfile. That its the above define doesn't get propogated to the build Jamfile and I don't know how it would. If I alter my Jamfile so that it doesn't include common-variant-tag as a target. The when the bjam stage is invoked, the libraries won't have the version specfic stuff. The situation is made even more compilicated by the fact that I have one dll (boost_wserialization.dll) which calls into another one (boost_serialization.dll). I've made it work by using the variant tags all the time - that is never using BOOST_???_NO_LIB. But now I'm concerned the the section at the end of the reference which seems to suggest that this won't work on platforms which don't suppor t auto-link. This seemed very simple when I started, but now I'm trying to get the details right and I'm having lots of nagging issues like the above. Its actually harder to figure out than the serialization library itself. Robert Ramey

1 0

mpl::inherit_linearly reuse to produce loki's tuple?
by Larry Evans 24 Dec '04

24 Dec '04

Could inherit_linearly be used to create something like loki's tuple? The name, inherit_linearly, and a very brief look at the code suggests it does something like loki's GenScatterHeirarchy, which was used to create the loki tuples as shown in: http://cvs.sourceforge.net/viewcvs.py/loki-lib/loki/Reference/HierarchyGene… If so, then I was wondering if it would be worth it to reuse inherit_linearly to implement boost's tuple?

3 14

typeof: what to register?
by Arkadiy Vertleyb 23 Dec '04

23 Dec '04

Hi all, Here is a question: besides primitive types, which types/templates should be registered as a part of typeof library? The first candidate is STL. The containers, functors, binders, etc. The STL iterators is a separate question. In most STL implementations they are typedefs, and therefore their template names are non-standard and different. In Dinkumware they are nested classes, and so are the subject to non-deduced context, which prevents them from being registered in a trivial way. Peder does have a solution for this, based on a bug in VC7.1 that allows to work-around non-deduced context (I am personally against using this, although I have to admit that it does the job). So, if we decide to put #ifdefs, based on STL implementation, and *if* we decide to use Peder's solution, it looks like we can take care of all the standard library (including iterators) on the typeof lib level. I have to note here that, if we decide against iterator registration, iterator instantiations can be always registered as needed, by the end user: BOOST_TYPEOF_REGISTER_TYPE(MyClass) BOOST_TYPEOF_REGISTER_TYPE(std::vector<MyClass>::iterator) I think if other libraries want to be supported by typeof (like Spirit, for example), those libraries should register their types/templates themselves (just because of synchronisation issue). Any help would be provided, of course. I would greatly appreciate any opinions on the subject. Regards, Arkadiy

2 2

boost::noncopyable and DLL usage
by Roland Schwarz 23 Dec '04

23 Dec '04

The thread class derives from boost::noncopyable. While this works for static library builds, there are some ugly warnings when compiling user programs that use the DLL version of the threading lib. I suspect noncopyable not having the appropriate __declspec(export) in a DLL being the culprit. I suspect any library will show this behaviour when doing a DLL build. Is this effect known? Are the warnings avoidable? Thank you, Roland

2 5

Status of VC++.NET 2005 Beta
by Loïc Joly 23 Dec '04

23 Dec '04

Hello all, I would like to know if anybody has successfully built boost with VC++.NET 2005 beta version ? I tried to look the regression tests, but the links from boost web site are broken (This site is defaced!!! NeverEverNoSanity WebWorm generation 25.). By the way, is there any document that explains how to create a new toolset for boost::bjam ? Regards, -- Loïc

3 3

Re: [boost] [gui] rectangles and the CSS box model
by brangdon＠cix.compulink.co.uk 23 Dec '04

23 Dec '04

In-Reply-To: <cqbhda$lq7$1(a)sea.gmane.org> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > However, for efficiency, it is a good idea to expose the > members of point and size. Is that because your compiler cannot inline member functions? -- Dave Harris, Nottingham, UK

1 0

X-Platforming Boost GUI
by Alan Gutierrez 22 Dec '04

22 Dec '04

I've spent quite a bit of time getting this Boost GUI code to build anywhere, but now it builds on both OS X and W2K. I'm using XCode to build on OS X, Jamboost is working on W2K. I'm feeling like I might as well add Linux to the mix, and work toward having an early integeration across these three platforms. It would teach me a lot about Boost and bjam. -- Alan Gutierrez - alan(a)engrm.com

3 3

[gui] rectangles and the CSS box model
by Reece Dunn 22 Dec '04

22 Dec '04

Hi All, In the "thoughts on a GUI component library" thread there have been various discussions about the layout of a rectangle and come relating to CSS. Note that point and size are stable. The CSS3 Values and Units module (http://www.w3.org/TR/2001/WD-css3-values-20010713/) defines various units (e.g. inches, picas and em). This is a good basis for a GUI library metric type. The type should store the values as a floating point to allow things like 2.71cm and also to support platforms that store coordinates as floating points (e.g. Cocoa). The CSS3 relative values (em and ex) are dependant on the inherited font-size property, so it is difficult to use these units as there is no associated font-size property. Another issue relating to this is how to resolve metric values between units that are not directly convertable. I have suggested using a device::resolve method that takes metric, point, size and rect types, but it may not always be possible to get access to a device. A further complication is the location of the origin. If we treat the origin as being in the top left corner (which is true for Windows, HTML/CSS and other document models such as text editors) this will simplify the design and for platforms that have a different model (e.g. Mac) then the implementation on that platform will need to map between the different representations. I personally like the CSS box model (http://www.w3.org/TR/css3-box/) which can be defined as: struct css::box_model { rect margin; rect border; rect padding; size dimensions; // width and height // T content; }; The problem with supporting it by default is that we would need: class component: public css::box_model; class graphics::object: public css::box_model; This clearly violates the don't pay for what you don't need rule of C++, so for a css_block_layout, it needs to contain the box model properties and a pointer to the component/graphical object. Obviously some level of support for the CSS box model should be provided, allowing an implementation of it to be written. There has been some discussion and disagreement as to what representation a rectangle takes. It is a good idea to hide the representation of a rectangle and provide accessors to the various values. This is because different people will want different things from it. However, for efficiency, it is a good idea to expose the members of point and size. In supporting the CSS box model and adoption of top-left as (0, 0) the representation becomes: class rect { point tl; point br; }; with: top() = tl.y; left() = tl.x; bottom() = br.y; right() = br.x; width() = br.x - tl.x; width( w ): br.x = tl.x + w; size() = ::size( width(), height()) center() = tl + ( size() / 2 ) An issue with this is: do we keep the width of the rectangle when setting left/right? In order to keep things simple, the answer has to be no. Construction of a rect should have the following variants: rect() = rect( 0, 0, 0, 0 ) rect( n ) = rect( n, n, n, n ) // This models the CSS "margin: 2px;" behaviour. rect( t, r, b, l ): tl( t, l ), br( b, r ) // This models "margin: 1pt 2pt 3pt 4pt;" rect( point p, size s ) = rect( p.x, p.y, p.x + s.dx, p.y + s.dy ) // This allows for support for traditional GUI representations Note that this model will change the nature of a program that uses the current model. We also have inflate/deflate operations that should take size *and* rect variants. This will allow easier box-model calculations: rect disp( point( 0, 0 ), size( 500, 700 )); rect margin( 1, 2, 3, 4 ); rect box = disp; box.deflate( margin ); // apply margin adjustments // ... Regards, Reece

3 8

Re: [boost] mailing lists archives stuck
by JOAQUIN LOPEZ MU?Z 22 Dec '04

22 Dec '04

----- Mensaje original ----- De: Douglas Gregor <dgregor(a)cs.indiana.edu> Fecha: Miércoles, Diciembre 22, 2004 9:02 pm Asunto: Re: [boost] mailing lists archives stuck > On Dec 22, 2004, at 7:22 AM, Joaquín Mª López Muñoz wrote: > > To whom it may concern, the archives of the mailing lists, > > (for instance, http://lists.boost.org/MailArchives/boost/bydate.php) > > have stopped collecting messages since almost a week. > > The archives should be working again now. Thanks for the report! > Thanks for fixing the thing :) BTW, the *users* mailing list is also stuck :( As for the announce list, ist' hard to know, because its volume is so low. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

mailing lists archives stuck
by Joaquín Mª López Muñoz 22 Dec '04

22 Dec '04

To whom it may concern, the archives of the mailing lists, (for instance, http://lists.boost.org/MailArchives/boost/bydate.php) have stopped collecting messages since almost a week. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Add conversion op doc to scoped_ptr
by cliffg＠codewrangler.net 22 Dec '04

22 Dec '04

This may already be known / in the queue / in CVS, but in case not ... The scoped_ptr synopsis and members does not document the unspecified-bool-type conversion operator that scoped_ptr provides (I didn't check scoped_array to see if the same issue is present or not.) I found this when a couple members of my team converted code from shared_ptr to scoped_ptr, with the original code relying on the conversion operator, and I was surprised when everything compiled cleanly (without adding the appropriate get() calls). Cliff

1 0

Help \ Advice requested on getting the return type from a Lambda fctor
by Brian Braatz 22 Dec '04

22 Dec '04

I wrote up the simple example that shows what I am trying to figure out Basically, I am trying to pull the deduced return type (or explicitly passed as a template param in lambda bind()) in my template. If I have a function that is receiving a functor, I would like to be able to take that functor and pull the RETURN TYPE out of it. Lets say I have a function that returns a string: std::string ReturnAString() { return "this is a string"; } And then here is my template function (code below does not compile) template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } Now here is my bind call std::cout << ( bind<std::string>(&ReturnAString)); Is there a way to GET to the return type in the Lambda fctor that was generated with a BIND call? I would like to be able to pull the <std::string> from the bind call and use it in the template function. It is not a problem for my template function to be dependant upon lambda bind. I have been going through the lambda code. And while it is brilliant, I am having a bit of difficulty figuring out what I am looking at (grin). Any help or direction is greatly appreciated FULL SAMPLE CODE HERE: template <typename CURRIEDTYPE> // Id class for currying type without creating the object class Id { public: typedef CURRIEDTYPE TYPE; }; // Explictly pass IN a return type template < typename TFUNCTOR, typename TRET> TRET CallFctorPassInRet ( TFUNCTOR & functor, Id<TRET> & ) { Id<TRET>::TYPE TRet; TRet = functor(); return TRet; } std::string ReturnAString() { return "this is a string"; } // try to get return type from the lambda fctor // Below does not compile- but it is along the lines of what I // WANT to do- note that I am trying to get from the Lambda functor the deduced return type template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } void Test_LambdaRetDeduction() { std::cout << "CallFctorPassInRet returns [" << CallFctorPassInRet( bind(&ReturnAString), Id<std::string>()) << "]" << std::endl; // below is what I want to make work std::cout << "CallFctorDeduceRet returns [" << CallFctorDeduceRet( bind<std::string>(&ReturnAString)) << "]" << std::endl; }

1 0

boost.sourceforge.net hacked?
by Joaquín Mª López Muñoz 22 Dec '04

22 Dec '04

Please take a look at http://boost.sourceforge.net/regression-logs/ ??? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 6

RE: [boost] Unzipping the Boost distro
by Stefan Seefeld 22 Dec '04

22 Dec '04

> From: Richard Peters [mailto:r.a.peters@student.tue.nl] > If some boost authority certifies the released packages, and > users correctly > verify that the certificate is issued by the boost authority, and the > certificate is valid on the package, then certified executables can be > trusted as well. You are right, providing certificates is one thing. Whether or not to distribute executable self-extracting packages is different question. Regards, Stefan

1 0

RE: [boost] Unzipping the Boost distro
by Stefan Seefeld 22 Dec '04

22 Dec '04

> From: Richard Peters [mailto:r.a.peters@student.tue.nl] > Another argument that I thought of this morning: suppose we > do not publish a > self-extracting executable. What is going to stop an attacker from not > uploading his own self-extracting look-alike? If he can > change existing > archives, he probably can add other archives as well. right, but if some boost authority certifies its released packages, everybody is free to ignore such look-alikes. Isn't that the whole point of certification ? Regards, Stefan

2 1

automatic garbage collecting algorithm and its implementation in c++
by yilin yang 22 Dec '04

22 Dec '04

hi, everybody i've just designed and coded a garbage collecting infrastructure named u_canforget. it was uploaded onto the news group at boost.yahoo. the main idea is that we count the reference to track the life-cycle of the given object. as the new operator was overloaded to statisfy this requirement. the other important concept was the reference object. with the syntax represented by the redefined macros, the codes may be written in a very simple way with relationships automatically constructed, objects are freed without delete operater can be realized as well. i would keep tracking this thread, if there are any thought about this algorithm. thx for your advices. your's yilin. --------------------------------- Do You Yahoo!? 注册世界一流品质的雅虎免费电邮

1 0

[gui] Representation of graphical objects
by Reece Dunn 22 Dec '04

22 Dec '04

Hi All, A GUI library can be thought of as having two distinct, but related, units: components (GUI widgets) and graphical objects/operations. A GUI component consists of data and events (e.g. a push button has a title and an onpressed() event). The question is: how do we represent the graphics unit? There are clearly two views: high level and low level. You can represent a graphics library as a series of objects (lines, circles, polygons, images, text, etc.) each of which having a set of properties (color, background/fill color, etc.). This is a high-level view and is based on the vector graphics model. Consider you are writing an application that draws a fractal object on the screen such as a Hilbert curve. You decide to represent it as a list of line objects. What happens when you redraw the curve? For large numbers of lines (easy when you have a fractal depth of 5+), the redrawing process is going to be slowed down. This is because you will be changing the colour on each line drawing operation. This becomes more apparent if you are using images to fill polygons and are using the same fill pattern across several objects. There are various graphics primitives (font, pen, fill (i.e. brush), etc.). Each primitive operates on a canvas and some can be used to query information on a device (e.g. the area occupied by a text string). In Windows a device and canvas are represented the same (as a HDC), but it makes sense to distinguish between them: you draw to a canvas and query information about a device. These graphical primitives should form the core of the graphics unit, with the high-level graphical objects being viewed as an extended unit. With the discussion on using CSS and Andy Little's comment about what difference is there between GUI components and graphical objects in terms of them both being objects that have position information and are drawn onto a canvas, it makes sense to allow both types to share a common interface. The main question is really what happens on the redraw phase? Ideally, components should not be drawn on the ondraw event, but rather be controlled by the behaviour of the operating system. For owner drawn components, do we handle the drawing event here or on the request of the OS (I think the latter is best). What about lightweight components (i.e. components that do not take up OS resources w.r.t. component representation, but that do support an event model)? Should we treat lightweight controls as graphical objects with an event model? Do graphical objects support an event model? Should graphical objects be treated as lightweight components? Regards, Reece

1 0

Unzipping the Boost distro
by David Abrahams 22 Dec '04

22 Dec '04

I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute. I'm thinking we should stop distributing raw .zip files without an extractor... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

11 24

regex library design (was: any interest in finite automata-based regex engine?)
by Vladimir Pozdyayev 22 Dec '04

22 Dec '04

John Maddock wrote: > This is an area I want to explore though, if I can get this next lot of code > out the door, then I'll create a cvs branch to experiment with this, if you > want to suggest / experiment with a design for the abstract creator in the > meantime, then go for it. Finally I got down to refactoring the ANFA code. Take a look at http://groups.yahoo.com/group/boost/files/anfa-regex/anfa091.zip (once again, this is not a fullscale regex library... yet) The DESIGN file content is appended to this message. -- Best regards, Vladimir Pozdyayev. ---------------------------------------------------------------------- -= Regex Design Issues =- The core classes. * charset Provides "bool operator( character )". Nothing much to say apart from that, but do see the Charset Issues section. * charset creator Supports arbitrary charset expressions (within the limits of a given set of possible operations). Implementations, however, are not required to provide _all_ the declared functionality; calls for unsupported features should result in appropriate exceptions. Also provides the "void create( charset & )" function which is used to initialize a charset newly created by "matcher creator". The "abstract_charset_creator" class provides stubs for all expression elements possibly to be requested by regex parsers. Implementations with limited functionality can inherit them and redefine only those functions that should actually do something useful. * matcher Provides the low-level matching functionality, say, finding the first occurrence of bla-bla-bla. On the other hand, replacing all occurrences is a high-level action, for it consists of (1) finding them and (2) creating a modified string---so it should go into the "regex" class. (On the other other hand, if it is possible to do replacement on the fly while searching, this becomes a low-level action. I don't know if it can be done in a sufficiently general way, however.) * matcher creator Like charset creator, only for matchers. * parser The syntax parser. Takes the input string in the form of begin-end iterators, and issues a sequence of charset/matcher creator calls ending with "matcher_creator::create" (or an exception). In essence, simply provides the function "void parse( matcher &m, iterator begin, iterator end )". A parser must be consistent with the properties of "creator" classes. * regex A wrapper for the "matcher" class. Provides the high-level creation & utilization routines. How they are connected. A sample from "regex.cpp": typedef basic_regex< basic_simple_parser< basic_charset_creator< wchar_t >, basic_anfa_matcher_creator< basic_charset< wchar_t > >, basic_anfa_matcher< basic_charset< wchar_t > > >, basic_anfa_matcher< basic_charset< wchar_t > > > regex; On "creators" and "create" functions. The name is somewhat misleading, since they fill target objects with compiled data rather than create them. Still, "charset compiler" sounds a bit weird... or does it? Anyway. The "creators" are subject to the following uses and requirements. They must be able to destruct themselves gracefully even if the expression they are being feeded with is only halfway done (in case someone has thrown an "unsupported" exception). The "create" function must do an implicit "pop" from the expression stack, so that the "creator" object could be reused. The "create" function can assume there's only one top-level expression tree node on the stack. -= Charset Issues =- (Should I rename them to "character sets" for consistency with the full-names style?) All the above templates have quite a freedom in intermixing different character types, let alone different character encodings. E.g., the sample program has all regex templates instantiated with wide characters, but the regex string itself is char-typed. This clearly needs to be controlled.

1 0

Retry: merging all utf8 files
by Vladimir Prus 22 Dec '04

22 Dec '04

Seems like the discussion about how to merge copies of utf8 code used by serialization and program_options has died. I'd like to revive it again, given that I've recieved yet another patch for that code, and the longer we have two versions, the harder it will be to merge them later. The basic question is whether to have a new compiled library in libs/detail, or just source files which will be included by serialization and program_options. The problem with compiled library is that users will have to know that in addition of -lboost_program_options they'll have to add -lboost_utf8, which is inconvenience. I've mentioned this in http://article.gmane.org/gmane.comp.lib.boost.devel/106047/ The proposed course of action is documented in: http://article.gmane.org/gmane.comp.lib.boost.devel/106122 Now: 1. Are there any objections? 2. Who does it? I can do it soon. Robert, what do you think? - Volodya

3 8

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cpsv4p$foa$1(a)sea.gmane.org> michaeltoksvig(a)yahoo.com (michael toksvig) wrote (abridged): > you might consider adding operator[] to point and size > > also, consider defining area in terms of 2 points, and adding > operator[] to that, too I was about to say the same thing :-) I'd go further, and expose the array. class box { point data_[2]; public: point *data() { return data_; } static size_t size() { return 2; } point &operator[]( size_t i ) { assert(i < 2); return data_[i]; } // Maybe begin/end too. const point &top_left() { return data_[0]; } const point &bottom_right() { return data_[1]; } float top() { return data_[0][1]; } float left() { return data_[0][0]; } float bottom() { return data_[1][1]; } float right() { return data_[1][0]; } size extent() const { return bottom_right() - top_left(); } float width() const { return right() - left(); } float height() const { return bottom() - top(); } point centre() const { return top_right() + extent()/2; } // ... void set_top_left( const point &p ); void set_top( float f ); void set_centre( const point &p ); // ... }; This is because you will almost certainly want transforms that act on arrays of points, and it will sometimes be convenient if they can act on rectangles too. I would provide get/set methods which are independent of representation. I'd consider allowing things like ++box.top() too. Currently I think the convenience is not worth the loss of purity. ++box[0][1] should work, though. On naming... I think "area" is the wrong name. To me an area can be any shape, or alternatively, every shape has an area. I would expect circle.area() to return pi*r*r. "Rectangle" is better, but what we actually have here is a special kind of rectangle which is aligned with the axis. A rotated rectangle needs more than 2 points. So conceptually we need two rectangle types. I suggest "rectangle" is reserved for the general case, and the aligned one is called "box". As in "bounding box". It has the benefit of being short. I see no benefit in using "position" instead of the usual "point". "Point" is shorter. It's hard to improve on "size" :-) I would seriously consider replacing float with a typedef, perhaps with another typedef for distances and offsets. Even without type checking, I think using more exact type names helps to clarify thought. [Later...] I've looked at the code in the zip file now. I see it doesn't match the email. It uses a different representation and adds several member functions, although not as many as me. I am surprised to see things like size*size and size/size. I see the design is being driven by the needs of a windowing system, when I am being driven by the needs of a graphics/drawing system. That has led to different results, which I suspect is a bad thing. At any rate, it has convinced me that exposing raw member variables (like area.pos) is a mistake. -- Dave Harris, Nottingham, UK

4 4

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cq90bq$r7v$1(a)sea.gmane.org> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > > This is because you will almost certainly want transforms that act on > > arrays of points, and it will sometimes be convenient if they can act > > on rectangles too. > > Translation: a.pos += gui::size( 5, 7 ); > Scaling: a.size += gui::size( 10, 20 ); > Rotation: n/a since you are assuming that each side has an angle of 90 > degrees (allowing for two point representations). I'd expect to have a family of transform objects, and in particular a general 2d affine transform represented by a matrix of 6 numbers, along the lines of: x' = x * a + y * b + c; y' = x * d + y * e * e; which can represent scales, shears, rotations, translations or any combination of them. Rotations come into play even for axis-aligned rectangles, although they may be constrained to 90 degree angles. For example, if I want to print a card that will be folded in half horizontally, the top half must be drawn upside-down relative to the bottom half. We probably want to treat it as 2 pages, draw both pages right-way-up and side-by-side in the UI, and then draw the second page upside-down and above the first one to the printer. This kind of thing is useful for 2D graphics. General affine transforms are powerful abstraction. This is an area where I have experience; my only doubt is whether the windowing system can or should use different conventions to the graphics system. And I think you will eventually want everything to be consistent and uniform. > If you have point high, low; then which corner is "high"? Likewise, > using top_left, bottom_right is bad. The same issue arises using (point, size). Which point? It could reasonably be any of the four corners, or the middle. > Having a (point, size) notation, similar to the Cocoa representation, > you remove the need for platform dependancy (except when mapping > between the native type and the independant type). You still need to know whether: r.pos += gui::size( 0, 1 ); moves the rectangle up or down. So you still need to know whether (0,0) is top-left or bottom-left. You have to pick a convention for axis orientation and stick with it, and translate where the native model differs. The orientation of rectangles drops out of the orientation of the axis. Actually, you can sometimes allow a rectangle to be specified by any pair of (diagonally opposite) points, in effect taking their bounding box. This is what PDF does. Usually, though, you normalise the rectangle so that the first point contains the smaller values and the other the larger. Incidently, the conversion from top-left to bottom-left axis orientation is an example of a general transform. It involves both a scale and a translate. > Also, this representation simplifies translation and scaling > (see above). Not really. You have some transforms applied to one member and other transforms to other members. You have to know whether a transform is a scale or a translate before you can apply it. It's not a regular, uniform system; not simple. Also, the code you show for scaling doesn't actually scale. Let's say I have two rectangles side by side: rect a( point(10, 10), size(10, 10) ); rect b( point(20, 10), size(20, 10) ); I want to scale this to double the size. What do I do? gui::size scale( 10, 10 ); a.size += scale; b.size += scale; But that didn't do the job. It made the rectangles overlap, and b's size didn't double. If we actually want that operation, the (point[2]) code is just as simple; you increment the second point. For most operations it makes no difference; neither representation has an advantage. There are probably operations for which (point,size) is slightly easier, and there are other operations for which (point[2]) is easier. I believe (point[2]) is easier for more of the important ones. Testing for point inclusion, and rectangle union, intersection etc, for example. rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.point[0].x, rhs.point[0].x ); double y0 = max( lhs.point[0].y, rhs.point[0].y ); double x1 = min( lhs.point[1].x, rhs.point[1].x ); double y1 = min( lhs.point[1].y, rhs.point[1].y ); return rect( x0, y0, x1, y1 ); } versus: rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.pos.x, rhs.pos.x ); double y0 = max( lhs.pos.y, rhs.pos.y ); double x1 = min( lhs.pos.x+lhs.size.dx, rhs.pos.x+rhs.size.dx ); double y1 = min( lhs.pos.y+lhs.size.dy, rhs.pos.y+rhs.size.dy ); return rect( x0, y0, x1-x0, y1-y0 ); } The (point,size) version has 6 extra additions or subtractions. > On review, I have removed size/size, size*size. As for the > representation change: this is an evolving library, but the essence > remains the same, so discussion here is still valid. I do not intend on > posting the full member function list as these e-mails are long enough > already! If you are interested, take a look at the code (as you have > done). I appreciate the feedback. The big questions are, should the underlying representation be exposed in the form of public member variables at all? And, does a windowing library need to pay any attention to the needs of a hypothetical drawing library? My answers are "no" and "yes". -- Dave Harris, Nottingham, UK

1 0

Review Request: BOOST_FOREACH
by Eric Niebler 21 Dec '04

21 Dec '04

BOOST_FOREACH is a macro which makes it simple to iterate over a sequence. It is concise, and clearly expresses the programmer's intentions. For example: short array_short[] = {1,2,3}; BOOST_FOREACH( short & i, array_short ) { ++i; } // array_short contains {2,3,4} here Recent changes I have made to the macro have greatly increased its safety and usefulness. It gracefully handles both L-value and R-value sequence expression, and evaluates its arguments only once. It now works (to a greater or lesser extent) on a wide range of compilers, even VC6. The current implementation, documentation and tests can be found in the Boost Sandbox File Vault. You can download the Zip file here: http://tinyurl.com/57oyp Tinyurl link redirects to: http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&fi… -- Eric Niebler Boost Consulting www.boost-consulting.com

7 7

[integer] Solaris integer_traits.hpp #error and general Solaris wchar_t issues
by Caleb Epstein 21 Dec '04

21 Dec '04

The crc library is failing regression tests on Solaris + gcc 3.3.4 (http://tinyurl.com/6qq3y) because of the #error statement on line 112 of integer_traits.hpp (see below). If one includes <wchar.h> before <boost/integer.hpp>, all is well, but if not an error is triggered. Solaris + gcc seems to be a bit of an oddball platform w/r/t wchar_t. It is natively supported and there is a <wchar.h> header, but enough of the C99 wide-character IO routines are missing that gcc does not provide <cwchar>, std::wstring or other related wide features on this platform. The config library sets BOOST_NO_CWCHAR but in integer_traits.hpp I see: 24 #if !defined(BOOST_NO_INTRINSIC_WCHAR_T) && !defined(BOOST_NO_CWCHAR) 25 #include <wchar.h> 26 #endif There is a <wchar.h> but no <cwchar>. Perhaps there ought to be a config macro BOOST_NO_WCHAR_H that could be used instead of BOOST_NO_CWCHAR in this case, or perhaps just the second part of the #if should be dropped. Here's the section of integer_traits.hpp that is generating the error when <wchar.h> is not first included: 85 #ifndef BOOST_NO_INTRINSIC_WCHAR_T 86 template<> 87 class integer_traits<wchar_t> 88 : public std::numeric_limits<wchar_t>, 89 #if defined(WCHAR_MIN) && defined(WCHAR_MAX) 90 public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> 91 #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32_ _) || (defined(__BEOS__) && defined(__GNUC__)) 92 // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: 93 public detail::integer_traits_base<wchar_t, 0, 0xffff> 94 #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0 x400))\ 95 || (defined __APPLE__)\ 96 || (defined(__OpenBSD__) && defined(__GNUC__))\ 97 || (defined(__NetBSD__) && defined(__GNUC__))\ 98 || (defined(__FreeBSD__) && defined(__GNUC__))\ 99 || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defi ned(__SGI_STL_PORT)) 100 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. 101 // - SGI MIPSpro with native library 102 // - gcc 3.x on HP-UX 103 // - Mac OS X with native library 104 // - gcc on FreeBSD, OpenBSD and NetBSD 105 public detail::integer_traits_base<wchar_t, INT_MIN, INT_MAX> 106 #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !define d(__SGI_STL_PORT) 107 // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigne d int. 108 // - gcc 2.95.x on HP-UX 109 // (also, std::numeric_limits<wchar_t> appears to return the wrong v alues). 110 public detail::integer_traits_base<wchar_t, 0, UINT_MAX> 111 #else 112 #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits< > for your compiler. 113 #endif 114 { }; 115 #endif // BOOST_NO_INTRINSIC_WCHAR_T -- Caleb Epstein caleb dot epstein at gmail dot com

2 5

question re autolink
by Robert Ramey 21 Dec '04

21 Dec '04

"These macros will be undef'ed at the end of the header, further this header has no include guards - so be sure to include it only once from your library!" What is the rationale for the above? What happens if its violated. I'm sort of struggling implementind a dll version of the serialization library with autolink. The basic difficulty is that I would like to have the dlls mirror the structure of the the static libraries. That is libboost_serialization.lib libboost_wserializaton.lib depends on theabove wserialization.dll is both autolinked and uses serializaton.dll so Its kind of confusing. Robert Ramey

2 1

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <877e9a1704121705302ac4bce4(a)mail.gmail.com> > Not sure. In computer graphics you specifically talk about > "axis-aligned bounding boxes". To me, "box" is the 3d version of > "rectangle". "Axis-aligned bounding boxes" reflects the importance of being explicit about whether your rectangles are axis-aligned, so I approve, but it's also a bit of a mouthful. I think a shorter name is needed. Some people use AABB, but I'm not keen on acronyms. I'm not keen on abbreviations, too, otherwise using Rect for the axis-aligned case and Rectangle for the general case might work. "Box" was an arbitrary suggestion, in that it does not say "axis aligned" of itself, but I can't think of anything better. For me, in a graphics application, "box" is a term of art which can be either 2d or 3d. Just as points and offsets can also be 2d or 3d (or 1d or 4d). If we care about conflicts with 3d stuff, then maybe we need to be explicit about this, perhaps by using namespaces. Arguably we shouldn't care, because a windowing system is pretty far away from a 3d graphics drawing system. As I realised towards the end of my previous post, perhaps we shouldn't care about 2d graphics, either. It's not so clear-cut because windowing is also 2d; it's easier to see a continuum between them. -- Dave Harris, Nottingham, UK

2 1

boost::noncopyable
by Dirk Gregorius 21 Dec '04

21 Dec '04

Does inheriting from boost::noncopyable has the same effect like making the copy c'tor and the assignment operator private without implementing them? The authors of the smart_ptr library suggest the following for the use of the smart pointers with interfaces: class Interface { public: virtual void f() = 0; virtual void g() = 0; protected: ~Interface( void ) {}; // non-virtual } // #1 class Implementation : public Interface { public: void f() { /* Implementation */ } void g() { /* Implementation */ } private: // Not to be implemented Implementation( const Implementation& ); Implementation& operator=( const Implementation& ); } Does inheriting from boost::noncopyable has the same effect: // # 2 class Implementation : public Interface, /*public or private*/ boost::noncopyable { public: void f() { /* Implementation */ } void g() { /* Implementation */ } } 1.) Are #1 and #2 equivalent? 2.) When should I derive public and when private from boost::noncopyable? 3.) Is the use of noncopyable correct in this context and what are other scenarios when to use it? Regards, -Dirk

6 9

www.boost.org has release information for version 1.33.0
by Douglas Gregor 20 Dec '04

20 Dec '04

It looks like the index.htm from the CVS trunk got pushed to the public web site, but the Version 1.33.0 changes did not get removed. Doug

2 1

Re: [boost] [config][gcc 3.4.2] Request for test about functiontemplate ordering
by JOAQUIN LOPEZ MU?Z 20 Dec '04

20 Dec '04

----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Sábado, Diciembre 18, 2004 10:10 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test about functiontemplate ordering > JOAQUIN LOPEZ MU?Z wrote: > > Hi, I've got the hunch that GCC 3.4.2 (specifically, > > the mingw version) might have some problems with > > function template ordering. Could somebody with > > access to that compiler please run the code below > > and report the results? Many thanks in advance. > > "bar-specific" for gcc 3.4.0, gcc 3.4.2, gcc 3.4.3, > gcc 3.3.5, gcc 3.2.3, gcc 3.1 on Linux. > Hi Martin. Well, seems my snippet does not capture the problem, but defiintely there's some difference wrt function template ordering handling between GCC 3.3.x and GCC 3.3.4: the issue is shown here: http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression machine) This is a test for serialization capabilities of Boost.MultiIndex, and it works for GCC <3.4.x. In GCC 3.4.4, hoeever, a user-provided overload of boost::serialization::load_construct_data is not picked up. I guess you have the current CVS downloaded at your machine, since you're publishing regressions. Could you please do me a favor? If so, please define BOOST_NO_FUNCTION_TEMPLATE_ORDERING and rerun Boost.MultiIndex test_serialization for GCC 3.4.4. Boost.Serialization has some machinery to overcome fto problems. Thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

#include <...> not in list of dependants
by Roland Schwarz 20 Dec '04

20 Dec '04

Sorry for posting to the developer list. I intended it to go to jamboost but I did not manage to get through. I would be glad if someone could instruct me how to subscribe to the jamboost list. --------------------------------------------------- I observed the following behaviour: When building the library, files that are included by e.g. #include <<boost/config.hpp> obviously are not in the list of dependant files. Consequently when one of such files has been edited no recompilation is beeing triggered. While this behaviour is fine with user programs it is unfortunate when compiling (and working) on the library itself. I even suspect that updating such files from sourceforege will render the following compile meaningless. I tried this on windows with MSVC 7_1. Any hints? Roland

2 1

[config][gcc 3.4.2] Request for test about function template ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi, I've got the hunch that GCC 3.4.2 (specifically, the mingw version) might have some problems with function template ordering. Could somebody with access to that compiler please run the code below and report the results? Many thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo #include <iostream> namespace A { template<typename T,typename Q> void foo(T&,Q&) { std::cout<<"default"<<std::endl; } } struct bar{}; namespace A { template<typename T> void foo(T&,bar&) { std::cout<<"bar-specific"<<std::endl; } } namespace B { inline void f() { int x; bar b; A::foo(x,b); } } int main() { B::f(); return 0; }

3 2

Re: [boost] Re: boost::noncopyable
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Diciembre 19, 2004 2:58 pm Asunto: [boost] Re: boost::noncopyable > JOAQUIN LOPEZ MU?Z wrote: > > >> >> 2.) When should I derive public and when private from > >> boost::noncopyable?> > >> > Given what I said, I think that deriving from boost::noncpyable > >> > must be avoided if multiple inheritance is present and you > >> > expct your class to be allocated on the stack. > >> > >> "Must be avoided" is a bit strong. One extra byte usually > makes no > >> difference for a class that will be allocated on the stack. > > > > My fault: I meant "allocated on the heap". > > But the same argument applies. One extra byte usually makes no > difference. Well, yes, certainly. Possibly, the cases were it matters are not that common. In my work at Boost, I use noncopyable nodes to build data structures, and here deriving from boost::noncopyable is a no-no. In many other situations, as you say, it doesn't make any serious difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

serialization: remove_whitespace compilation fix for RW STL
by Graham Bennett 19 Dec '04

19 Dec '04

Hi, I needed to make a change to boost/archive/iterators/remove_whitespace.hpp in boost 1.32.0 to get it to compile using the Roguewave standard library implementation on linux. A patch is attached. The problem is that on glibc 2.2-based systems /usr/include/wctype.h defines the isw... functions as macros. The gcc standard library undefs all these macros but RW does not, and they are not willing to change that. A similar fix was already made in boost/regex/config/cwchar.hpp for 1.31.0. cheers, Graham. -- Graham Bennett

1 0

Two small tools to make things more static
by Stefan Slapeta 19 Dec '04

19 Dec '04

Hi all, there are 2 very small utilities I wrote a long time ago and that I use very often. I wonder if something like this has already been provided somewhere: The first is a small class template static_ which create a singleton of a class "from outside". It can be either instantiated: struct AnyClass { void f() {} }; static_<AnyClass> s; s->f(); ...or used completely statically: static_<AnyClass>::get()->f(); AnyClass must be default constructible; it's guaranteed that all static_<AnyClass> instances will only create one single instance of AnyClass. static_ has a second (defaulted) template parameter to specify an "owner" type. You can specify it if you want a single instance for exactly one owner type; (so, if A and B are classes, static_<AnyClass, A> and static_<AnyClass, B> would produce one static instance for A and one for B). The purpose of the second utility ("call") is to make a "static call" (=call once); it does nothing else then to call a functor in its constructor so that you can write static call c(functor); See attachements! Cheers, Stefan #ifndef STATIC_TOOLS_H_INCLUDED #define STATIC_TOOLS_H_INCLUDED /* Some ideas for static tools ... (c) Stefan Slapeta 2004 */ //////////////////////////////////////// // class template static_ //////////////////////////////////////// template <typename T, typename OwnerT = void> struct static_ { T* operator -> () const { return &member; } static T* get() { return &member; } private: static T member; }; template <typename T, typename OwnerT> T static_<T, OwnerT>::member; //////////////////////////////////////// // class call //////////////////////////////////////// struct call { template <typename T> call(T& t) { t(); } }; #endif /* Some ideas for static tools ... (c) Stefan Slapeta 2004 */ #include "static_tools.h" #include <boost/bind.hpp> #include <iostream> struct Test { void f() { std::cout << "called!" << std::endl; } }; int main() { static_<Test> s; s->f(); static_<Test>::get()->f(); Test t; static call c(boost::bind(Test::f, t)); }

3 2

Re: [boost] Re: boost::noncopyable
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Diciembre 19, 2004 2:10 am Asunto: [boost] Re: boost::noncopyable > Joaquin M Lopez Munoz wrote: > > Dirk Gregorius <dirk <at> dirkgregorius.de> writes: > > > > >> 1.) Are #1 and #2 equivalent? > > > > In a broad sense, yes. The problem is that many compilers > > don't do EBO (empty base optiimzation) in the presence > > of multiple inheritance, which might end up (in #2) > > with sizeof(Implementation) being greater than strictly needed. > > Correct. > > >> 2.) When should I derive public and when private from > boost::noncopyable?> > > Given what I said, I think that deriving from boost::noncpyable > > must be avoided if multiple inheritance is present and you > > expct your class to be allocated on the stack. > > "Must be avoided" is a bit strong. One extra byte usually makes no > difference for a class that will be allocated on the stack. My fault: I meant "allocated on the heap". Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi Peter ----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Sábado, Diciembre 18, 2004 11:15 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > JOAQUIN LOPEZ MU?Z wrote: > > Hi Martin. Well, seems my snippet does not capture > > the problem, but defiintely there's some difference > > wrt function template ordering handling between > > GCC 3.3.x and GCC 3.3.4: the issue is shown > > here: > > > > http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression > > machine) > > > > This is a test for serialization capabilities of > > Boost.MultiIndex, and it works for GCC <3.4.x. > > In GCC 3.4.4, hoeever, a user-provided overload of > > boost::serialization::load_construct_data is not > > picked up. > > It's probably two-phase lookup related; have you tried putting the > user > overload in the user class' namespace, where it belongs? Indeed it is a 2-phase lookup issue, as Robert has pointed out. > > Don't automatically jump to conclusions that partial ordering is > broken; > more often than not, it is the code that is broken. How I wished that was true :) more often than not, making my library work for a wide range of compilers had nothing to do with my code compliance. This particular case is, to my delight, an exception. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi Martin ----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Domingo, Diciembre 19, 2004 1:28 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > > > http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression > > machine) > > > > This is a test for serialization capabilities of > > Boost.MultiIndex, and it works for GCC <3.4.x. > > In GCC 3.4.4, hoeever, a user-provided overload of > > boost::serialization::load_construct_data is not > > picked up. > > > > I guess you have the current CVS downloaded at your > > machine, since you're publishing regressions. > > Could you please do me a favor? If so, please > > define BOOST_NO_FUNCTION_TEMPLATE_ORDERING and rerun > > Boost.MultiIndex test_serialization for GCC 3.4.4. > > Boost.Serialization has some machinery to overcome > > fto problems. > > I feel a bit confused now. There is no gcc 3.4.4, > do you mean 3.4.3? > I'm sorry, I wrote my previous post in a rush and got the version numbers messed up. Yes, I meant 3.4.3, but anyway the problem seems to be solved, or at least identified, please read Robert's answer. Thank you for your help, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [config][gcc 3.4.2] Request for testaboutfunctiontemplate ordering
by JOAQUIN LOPEZ MU?Z 19 Dec '04

19 Dec '04

Hi Robert ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Domingo, Diciembre 19, 2004 0:20 am Asunto: [boost] Re: [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering > This is an issue regading two-phase lookup which was implemented > for the > first time in gcc 3.4+ > > Its discussed in the serialization documentation under "Namespaces > for free > function overrides" > That's it! Thank you very much for the pointer, I'll change my stuff according to that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

typeof and ODR
by Arkadiy Vertleyb 18 Dec '04

18 Dec '04

Hi all, Does anybody have an access to an EDG-based compiler, and willing to help me to figure out whether a certain typeof test reports an ODR violation? I would very much appreciate this... Thanks in advance, Arkadiy

4 8

std::string <-> std::wstring conversion
by Stefan Slapeta 18 Dec '04

18 Dec '04

Hi all, there have been many discussions (and proposals) on this topic in the last years, but was there any result and is there _anything_ in boost today that can be used to convert between std::string and std::wstring? Stefan

8 15

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 17 Dec '04

17 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >I noticed that Boost.Filesystem doesn't use readdir_r to iterate over >directories, even if it is available, making that non-thread-safe. >There is a comment to this effect in operations_posix_windows.cpp. > >I've attached a patch that I believe will allow it to detect whether >readdir_r is available and to use it iff it is. I have only tested this >on Linux with g++ 3.3, but I tried deliberately breaking the declaration >of readdir_r and verified that the code continues to work without it. I started to look at this in detail this afternoon. Using overload resolution to adjust to feature absence is an interesting technique, and new to me. But is it really needed? POSIX specifies a feature test macro, _POSIX_THREAD_SAFE_FUNCTIONS, which would seem to be sufficient. Was there a reason you didn't use it? Is it not reliable on some systems? Thanks, --Beman

1 0

Re: [boost] Re: [multi_index] announce: added serialization support
by JOAQUIN LOPEZ MU?Z 17 Dec '04

17 Dec '04

----- Mensaje original ----- De: Bruno Martínez Aguerre <br1(a)internet.com.uy> Fecha: Jueves, Diciembre 16, 2004 9:50 pm Asunto: [boost] Re: [multi_index] announce: added serialization support > Can serialization for iterator types be added? > Ummm... yes, this can be done. It'd be trivial except that it interacts badly with Boost.MultiIndex safe mode. Let me think it over, I guess I can have something done after Xmas. Do you have the actual need to serialize iterators or is this more of an academic request? Have you tried the serialization capabilities in some compiler? Did you find any problem? Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

thread_pool
by Timothy Ritchey 17 Dec '04

17 Dec '04

I downloaded, and am getting ready to try out the thread_pool.zip implementation off the yahoo groups site by Dave Moore. I noticed that the file drop was dated 2002, and was wondering if there was a latest and greatest in the CVS tree, or whether I should use the implementation in the zip file. Cheers, tim

2 1

[signals] trackable not disconnecting
by Neal Coombes 17 Dec '04

17 Dec '04

I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors. I'm having a very hard time making a small example program to demonstrate this behaviour (but I am working on it :). In the meantime if anyone else has experienced this kind of behaviour or has any information that might help, it would be greatly appreciated. TIA Neal

2 11

STLPort linking error
by Kenny Chamber 17 Dec '04

17 Dec '04

I am in the middle of moving our development from the std STL to STLPort and I am having a problem with two Athlon boxes. SuSE Linux 9.0 gcc 3.3.1 STLPort 4.6.2 Boost 1.31 I am changing an existing application to use STLPort and I have successfully completed the transition on a number of Intel boxes. When I try to build on an Athlon box I get the following error message: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I'm linking against libboost_thread-gcc-mt-p-1_31 and libboost_date_time-gcc-mt-p-1_31. I can't see an obvious solution so I'm hoping someone has solved this problem already. ----------------------- Kenny Chamber http://gem-hs.org/contact.html

4 3

[BGL] Patch for detail/adjacency_list.hpp
by Jürgen Hunold 17 Dec '04

17 Dec '04

Hi ! The last commit from Doug Gregor (Revision 1.130) broke compilation with gcc-3.4.1 for me. The attached patch fixes this by moving the implementation of remove_directed_edge_dispatch to a place _before_ it is used. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

3 4

PhD position (generic software libraries)
by Sibylle Schupp 17 Dec '04

17 Dec '04

*** PH.D. POSITION (GENERIC SOFTWARE LIBRARIES) *** Boost inside your Volvo?! In a joint project between Chalmers University and industrial partners from the automotive industry, there is an opening for a Ph.D. position specifically in the area of generic library design. The successful candidate will have the rare opportunity to earn a Ph.D. with a dissertation in which software is not just of "academic" value and interest, but really matters. Booster are encouraged to apply, to get back to me with recommendations, or to pass this advertisement on to others---this project is a big chance to implant generic programming in the (not just Swedish) car industry! Note that PhD positions in Sweden are regular jobs, with social benefits, paid vacation, parental leave, etc. I attach the entire announcement below; CEDES/4 is the position of interest. For further details, please get in touch with me. Sibylle ------- Sibylle Schupp, Assoc. Prof. Dept. Computing Science Chalmers Univ. of Technology SE-41296 Gothenburg http://www.cs.chalmers.se/~schupp ========================================================================= Open Ph.D. positions at Chalmers University of Technology (Sweden) Chalmers University of Technology is seeking outstanding Ph.D. candidates for 5 open Ph.D. positions within the newly started CEDES (Cost-Efficient Dependable Electronic Systems) initiative. CEDES is a joint project of Chalmers Univ. of Technology, Volvo Car Corporation, AB Volvo, Autoliv, and the Swedish National Testing and Research Institute, sponsored by the Swedish Road Authority. All Ph.D. positions are in the School of Computer Science and Engineering. Successful applicants hold a degree in computer engineering or computer science and can demonstrate their capability to conduct research. Additional requirements and deadlines vary among the different positions. Knowledge of the Swedish language is not required; both the School of Computer Engineering and Computing Science and the City of Gothenburg, Sweden's second-largest city, are characterized by a friendly, international atmosphere. Applicants should state explicitly for which of the positions they apply. -------------- Ref.Nr CEDES/1-2 (Software processes) Application: See http://chalmersnyheter.chalmers.se/chalmers03/svensk/ext_ledigatjansterarti… Deadline: Dec. 31, 2004 Contact: Peter Ohman, X(a)ce.chalmers.se, where X=peter.ohman -------------- Ref.Nr CEDES/3 (Fault tolerance) Deadline: Feb. 15, 2005 Contact: Johan Karlsson, X(a)ce.chalmers.se, where X=johan -------------- Ref.Nr CEDES/4 (Generic software libraries) Application: See http://www.cs.chalmers.se/Cs/Grad/ Deadline: Feb. 15, 2005 Contact: Sibylle Schupp, X(a)cs.chalmers.se, where X=schupp -------------- Ref.Nr CEDES/5 (Verification and validation) Application: See http://www.cs.chalmers.se/Cs/Grad/ Deadline: Feb. 15, 2005 Contact: Reiner Hahnle, X(a)cs.chalmers.se, where X=reiner

1 0

Boost 1.32.0/SUN CC shared_ptr/weak_ptr test failure in shared_ptr_basic_test.cpp
by Timo Geusch 17 Dec '04

17 Dec '04

Ah yes, the neverending saga of the SUN C++ compiler, version 5.5 in this particular case. My apologies if this information is already well-known, I have been off the list for a couple of months, but a quick check of the mailing list archive didn't show any discussion regarding this subject. I had been trying to figure out what's breaking the simple shared_ptr to weak_ptr assignments and copies on this particular compiler. The code shown below is based on the code in the above file, around line 260. Anyway, for reference, the following test fails using the default settings for sunpro-tools.jam: weak_ptr<X> wp2 = static_pointer_cast<X>(p5); BOOST_TEST(wp2.use_count() == 1); as the reference count is 2, not 1 as expected. After looking at the source code for static_pointer_cast<> and a bit of experimentation with different types of scoping produced the following code instead: weak_ptr<X> wp2; { wp2 = static_pointer_cast<X>(p5); } BOOST_TEST(wp2.use_count() == 1); Interestingly, this code works as expected - it appears that this particular compiler doesn't clean up the temporary shared_ptr<X> that's being generated inside static_pointer_cast<> until it hits a closing '}'. Digging around the web confirmed that originally the SUN C++ compilers destroyed temporaries as described above and the newer compilers are still backward-compatible. In order to get standard-compliant behaviour one needs to specify -features=tmplife. One updated boost jamfile and the compiler appears to be much happier - all the smart_ptr appear to pass now, apart from shared_ptr_assign_fail.cpp which I assume isn't supposed compile in the first place. A quick test suggests that the 5.3 also supports the above compiler flag so it may be worth including this setting in the sunpro-tools.jam file, however I haven't tested this yet.

1 0

[multi_index] announce: added serialization support
by Joaquín Mª López Muñoz 16 Dec '04

16 Dec '04

The version currently commited to the CVS includes serialization support, docs, examples, etc. I'll be happy to know about your usage experience, as well as general comments on the new feature. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 16 Dec '04

16 Dec '04

In-Reply-To: <BAY101-F20FDD5860C530B8D6ADE17A0AC0(a)phx.gbl> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > struct position{ float x; float y; }; > struct size{ float dx; float dy; }; > struct area > { > float top; float left; > float width; float height; > }; Why float rather than double? I'd want to avoid unnecessary conversions, so I'd want to use the same units all the way through. At the moment my document model uses integers, scaled not to 96 dpi pixels but to logical units which are 72,000 dpi. With 32-bit ints that gives a drawing area of about 30,000 inches. Using floats would give only 23 bits of precision, which reduces the drawing area to around 60 inches, which is getting a bit small. I'd prefer to avoid using fractional units because of exactness issues with 1/3 etc. I don't have a strong opinion on floating point generally. Sometimes I want to use pixel rounding, and sometimes I want to transform coordinates without losing accuracy. Adobe's PDF is an example which uses a floating point coordinates, albeit at 72 dpi rather than 72,000. I do know that most of the time, using integers works fine. You don't lose precision because you only ever transform the coordinates once. For bounding box transforms you round left/top with floor and right/bottom with ceil. For anti-aliasing you transform, eg, from 72,000 dpi to 384 dpi to get 1/4 pixel precision. -- Dave Harris, Nottingham, UK

1 0

MPL Book is on the way!!!
by Jody Hagins 16 Dec '04

16 Dec '04

I recieved notification that it shipped yesterday, and according to the UPS website, it will be here tomorrow, Dec 15!

6 6

[Boost-bugs] [ boost-Bugs-1086305 ] incorrect conditions to #define DISABLE_WIDE_CHAR_SUPPORT
by SourceForge.net 16 Dec '04

16 Dec '04

Bugs item #1086305, was opened at 2004-12-16 11:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1086305&group_… Category: lexical_cast Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergej Zagursky (seza) Assigned to: Kevlin Henney (kevlin) Summary: incorrect conditions to #define DISABLE_WIDE_CHAR_SUPPORT Initial Comment: I think absence of BOOST_NO_INTRINSIC_WCHAR_T isn't a requirement for DISABLE_WIDE_CHAR_SUPPORT definition. Suggested fix: //old code #if defined(BOOST_NO_STRINGSTREAM) || defined(BOOST_NO_STD_WSTRING) || defined(BOOST_NO_STD_LOCALE) || defined(BOOST_NO_INTRINSIC_WCHAR_T) #define DISABLE_WIDE_CHAR_SUPPORT #endif //new code #if defined(BOOST_NO_STRINGSTREAM) || defined(BOOST_NO_STD_WSTRING) || defined(BOOST_NO_STD_LOCALE) #define DISABLE_WIDE_CHAR_SUPPORT #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1086305&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Cross Builder, v1.0
by John Torjo 16 Dec '04

16 Dec '04

Dear boosters, I thought this might be of interested in this, even if it's Windows-only for now. I'm happy to announce the first version of "Cross Builder": http://www.torjo.com/cb/ In short, Cross Builder allows you to build C++ projects very easy. In addition to that, it allows you to modify various compiler settings in a simple and straightforward way. Cross Builder's purpose is to make it as easy as possible for you to build your projects with *any* C++ compiler. Or, put in other words, *one click*. Compiler settings apply hierarchically. This is a very powerful mechanism, and once you see it at work, you'll simply love it! When you modify a setting, you modify it for: * a HDD directory or file * a configuration (such as "Debug", "Release", etc.) * a compiler (such as "All compilers", "MSVC" (all MS compilers), "VC 7.1", etc) From then on, this setting will apply to all: * it sub-configurations * its sub-compilers * its HDD sub-directories ...until it's overridden. Screenshots and possibility to download: http://www.torjo.com/cb/ As a side-node, in the near future, I will also post the source-code for the first version of CB. Feedback is welcome. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- http://www.torjo.com/cb/ - Click, Build, Run!

8 17

program_options & VC6: internal compiler error?
by Olaf van der Spek 16 Dec '04

16 Dec '04

Hi, I was trying to use the program_options library and used the following example. However, I got an internal compiler error. I reduced the example to this minimum. The library build fine, so I assume it's compatible with VC6. What went wrong? Code: #include "stdafx.h" #include <boost/program_options.hpp> #include <iostream> int main(int ac, char* av[]) { boost::program_options::variables_map vm; std::cout << vm["compression"].as<int>(); // line 8 return 0; } Output: Configuration: Program Options Test - Win32 Release Compiling... StdAfx.cpp Compiling... Program Options Test.cpp C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : error C2679: binary '<<' : no operator defined which takes a right-hand operand of type '' (or there is no acceptable conversion) C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : error C2062: type 'int' unexpected Error executing cl.exe. Program Options Test.exe - 2 error(s), 0 warning(s) Configuration: Program Options Test - Win32 Debug Compiling... Program Options Test.cpp C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Error executing cl.exe. Program Options Test.exe - 1 error(s), 0 warning(s) -- Olaf van der Spek http://xccu.sf.net/

2 2

Re: Nasty bug in Boost 1.32.0 bind]
by Peter Dimov 15 Dec '04

15 Dec '04

Sean Parent wrote: > On Dec 6, 2004, at 12:10 PM, Peter Dimov wrote: >> >> This is not a bug. Bind was deliberately changed to return by value >> because of a bug report similar to the following: >> >> pair_t make_pair( int, int ); >> >> bind( &pair_t::first, bind( make_pair, 10, 20 ) )(); >> >> The inner bind returns by value (because make_pair returns a value) >> and the outer bind returns a reference to a temporary. >> >> A similar, but rare, situation can arise when bind is invoked on an >> rvalue: >> >> pair_t const make_pair(); >> >> bind( &pair_t::first, _1 )( make_pair() ); >> >> I'm more interested in the actual code that was broken by this >> change, because the assert() above was never required to pass. >> By-value or by-reference was (and probably still is) an open >> question. Of course I should have gotten it right in the first place. > > The documentation explicitly states that it will return a const > reference: > ----- >> bind(&X::f, args) >> >> is equivalent to >> >> bind<R>(mem_fn(&X::f), args) >> >> where R is the return type of X::f (for member functions) or a const >> reference to the type of the member (for data members.) > ----- Yes, you are right. I missed that. > The actual failure was in conjunction with boost::function() where it > fails silently because of a cast to result type inside boost function. > Here is a snippet that was my first attempt at isolating the problem: > > ---- > #include <boost/bind.hpp> > #include <boost/function.hpp> > #include <utility> > #include <cassert> > > int main() > { > typedef std::pair<int, int> pair_t; > > pair_t pair(10, 20); > > boost::function<const int&(const pair_t&)> > function(boost::bind(&pair_t::first, _1)); > > const int& x = function(pair); > > assert(&pair.first == &x); > > return 0; > } I get warning C4172 from VC++ 7.1, "returning address of local variable or temporary", on this example (in function_template.hpp:111). The example can be further simplified to: #include <boost/function.hpp> int f() { return 5; } int main() { boost::function<int const & ()> g( f ); int const & r = g(); } which produces the same warning. A static_assert in boost::function would probably help on compilers that don't emit a warning. [...] >> The explicit version: >> >> const int& x = boost::bind<int&>(&pair_t::first, _1)(pair); >> >> should work on conforming compilers. > > Good to know - I will review my code and try to be explicit where > possible - however, I use bind() a lot within templates and rely on it > not making an additional (often expensive) copy of my members. I don't > think there there is a correct answer for the default behavior > (between returning a const& and a value) but the docs need to be > consistent - and a change of this nature needs to be called out in > the release notes. Yes, you are right. I underestimated the impact of this change; the new behavior was supposed to eliminate this sort of bug, not introduce it. Breaking existing code is never pleasant. The change has been in the CVS for some time, but unfortunately most real-world testing occurs on the actual releases.

4 4

Cross Builder and pkg-config discussions
by David Abrahams 15 Dec '04

15 Dec '04

These discussions should probably move to the Boost.Build mailing list now. They've drifted a little far from library development issues. http://www.boost.org/more/mailing_lists.htm#jamboost -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[PATCH]Enhancing any_cast
by Mikhail Glushenkov 15 Dec '04

15 Dec '04

This is an enhanced version of Unai Uribarri's patch (see http://lists.boost.org/MailArchives/boost/msg42284.php ). Adds support for the following syntax: boost::any a = 7; int& i = any_cast<int&>(a); Current syntax for reference extraction is int& i = *any_cast<int>(&a); Old syntax is preserved. On compilers without support for partial template specialization users are required to provide explicit specializations of boost::remove_reference for their classes (usually via BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION) if they want to use the new syntax. Patch was tested on msvc 6 and 7.1, intel 8.1 and gcc 3.3.1. If this patch will be accepted, I'll write tests/update documentation. --- any.hpp Thu Sep 16 11:23:30 2004 +++ new_any.hpp Fri Dec 10 19:47:45 2004 @@ -15,6 +15,12 @@ #include "boost/config.hpp" #include <boost/throw_exception.hpp> +#include <boost/type_traits/remove_reference.hpp> + +#ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION +#include <boost/type_traits/is_reference.hpp> +#include <boost/static_assert.hpp> +#endif namespace boost { @@ -168,12 +174,39 @@ } template<typename ValueType> - ValueType any_cast(const any & operand) + const ValueType any_cast(const any & operand) { - const ValueType * result = any_cast<ValueType>(&operand); + #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Please use BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro + // to generate specialization of remove_reference for your class + // See type traits library documentation for details + BOOST_STATIC_ASSERT(!::boost::is_reference< + boost::remove_reference<ValueType>::type >::value); + + #endif //BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + + typedef typename boost::remove_reference<ValueType>::type Type; + const Type * result = any_cast<Type>(&operand); if(!result) boost::throw_exception(bad_any_cast()); return *result; + } + + template<typename ValueType> + ValueType any_cast(any & operand) + { + #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Please use BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro + // to generate specialization of remove_reference for your class + // See type traits library documentation for details + BOOST_STATIC_ASSERT(!::boost::is_reference< + boost::remove_reference<ValueType>::type >::value); + + #endif //BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + + typedef typename boost::remove_reference<ValueType>::type Type; + Type * result = any_cast<Type>(&operand); + if(!result) + boost::throw_exception(bad_any_cast()); + return *result; } }

2 3

RE: [boost] Re: Re: feature wish for boost 1.32.1 or 1.33.0: pkg- config support
by Stefan Seefeld 15 Dec '04

15 Dec '04

> From: Neal D. Becker [mailto:ndbecker2@verizon.net] > So, do you mean you want to use pkg-config to record the > settings that were > used to build boost? If so, I misunderstood. This might be useful. Indeed, that's how pkg-config is used. However, as a full-blown boost build process will result in quite a number of different configurations, the pkg-config approach would need to reflect that. For example, boost would need to generate one pkg-config script for each configuration that has been built. Regards, Stefan

2 1

Web typography
by David Abrahams 15 Dec '04

15 Dec '04

While Rene was wrangling fonts I forgot that I went through this whole process with Bill Venners of Artima. We ended up with a very different answer, because Bill abhors the idea of specifying a font size; he wants to respect peoples' preferences. I would appreciate it if everybody would check out: http://www.artima.com/cppsource/metafunctions.html and see how it compares with Rene's page at http://redshift-software.com/~grafik/boost/index.htm on your sundry browsers. I don't have an idea of which one is better, but we should at least get the benefit of that research. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 8

RE: [boost] Re: Cross Builder, v1.0
by Ferdinand Prantl 15 Dec '04

15 Dec '04

Hi Hajo, > From: Hajo Kirchhoff > > I am trying to decide on a build tool for the Lit Window > Library and am considering bjam, cmake, bakefile and would > just like to get an opinion about your tool before delving > deeper into it. BTW, I need linux support as well as VC6++ > and .NET project creation, meaning the tool should create > .NET project/solution files rather than acting as a build tool. I wanted the same - just generate makefiles/projects. I use tmake (1.11 with some tweaks of me) from Trolltech (predecessor of qmake written in Perl). It generates makefiles/projects from templates and creates them for a platform from a couple of lines in a file.pro. You must run the build afterwards manually. Doxygen uses tmake, for example and Qt uses qmake, which has the same principle and configuration. The discussion gets a little off-topic... ;-) Ferda

1 0

Front page, one last time.
by Rene Rivera 15 Dec '04

15 Dec '04

Boosters, OK, I haven't heard anything in the way of further comment on the new front page design. I've put in a version of the current logo while we work that out. And done some minor cleanup of the css and xhtml: http://redshift-software.com/~grafik/boost/index.htm Boost C++ Libraries If there aren't any serious objections, I'll go ahead and commit this to CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

16 33

RE: [boost] Re: Re: rational with finite precision
by Michiel Salters 15 Dec '04

15 Dec '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: zondag 12 december 2004 22:48 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: rational with finite precision ... > Finally, it would be nice if someone would actually submit > infinite precision number types ... Are you aware of N1692? There will probably be two follow-ups to it, one (N1718) by the same author who will be proposing a rational class as well, and one by me ( currently still in MSWord form, and I'm waiting for a number) which proposes standardese for an <integer> header/class. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Config library public or not?
by Ulrich Eckhardt 15 Dec '04

15 Dec '04

Hi! The documentation says the lib is not intended for users of boost, but only to aid implementing boost itself. I asked the question some time ago (long before 1.32) and the consensus was that it was in fact public and the documentation was wrong/outdated, but even with this release it didn't change. What's the deal? Did I miss anything? Uli

4 4

[Boost-bugs] [ boost-Support Requests-1085691 ] Boost-1.30.2 and gcc-3.4.2
by SourceForge.net 15 Dec '04

15 Dec '04

Support Requests item #1085691, was opened at 2004-12-15 02:08 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=1085691&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost-1.30.2 and gcc-3.4.2 Initial Comment: I cannot build the boost-1.30.2 with the new compiler gcc-3.4.2 on RH and EM64T machine. Does this version support the new compiler? The last boost version - 1.32 passed compilation with gcc-3.4.2 without problems. Thanks, Genia ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1085691&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Language Binding API
by Brian Braatz 14 Dec '04

14 Dec '04

A few months ago I recall David Abrahams sent a quick mail that referenced a Language Binding API for hooking in dynamic languages into C++. It looked like something he was brewing on. I was just curious if anything became of that. (or is it like those 1,000 things I have on my plate and have not been able to finish :) ) Dave?

3 2

is_abstract update
by John Maddock 14 Dec '04

14 Dec '04

Following on from the recent discussion, we now have: BOOST_NO_IS_ABSTRACT added to the config system, this is likely to cause some new failures with config_test.cpp until we get the macro added to those compiler config files that need it (although Gcc, Visual C++, Borland C++ are already taken care of). is_abstract no longer uses SFINAE when BOOST_NO_IS_ABSTRACT is defined, instead it defaults to the same value as is_polymorphic: the rationale is that "true" is the safe default (if there is one), but since non-polymorphic types obviously can't be abstract, we can safely evaluate to false for those. Users wanting some other behaviour should check for BOOST_NO_IS_ABSTRACT. Robert, is this enough for you to fix the ODR problem in the serialisation lib for is_abstract? John.

4 5

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? Good catch! I can confirm that it is indeed a problem. Should have a fix in a day or two. The last error code is set to ERROR_FILE_NOT_FOUND in the particular case you are talking about, and something else otherwise, so it is possible to distinguish it from other conditions. --Beman

1 0

patch: Boost.Jam: PATH_MAX not defined in SCO 5.0.5
by Davlet Panech 13 Dec '04

13 Dec '04

Added default for PATH_MAX as it isn't defined on my system (sco3.2v5.0.5/gcc2.95.2) --- tools/build/jam_src/pwd.c.orig 2004-12-13 14:58:32.362510600 -0500 +++ tools/build/jam_src/pwd.c 2004-12-12 17:32:07.000000000 -0500 @@ -21,7 +21,9 @@ #endif #endif - +#ifndef PATH_MAX +# define PATH_MAX 4096 +#endif LIST* pwd(void)

1 0

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >I noticed that Boost.Filesystem doesn't use readdir_r to iterate over >directories, even if it is available, making that non-thread-safe. >There is a comment to this effect in operations_posix_windows.cpp. > >I've attached a patch that I believe will allow it to detect whether >readdir_r is available and to use it iff it is. I have only tested this >on Linux with g++ 3.3, but I tried deliberately breaking the declaration >of readdir_r and verified that the code continues to work without it. Interesting approach! I guess the alternative is hand configuration, and that isn't very attractive. So let me take a look at your patch in detail and get back to you. >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? I've got some code that should serve to check that out. I'll let you know. > Unfortunately it's impractical to test >automatically, as empty volumes are hard to generate on demand! That's one of the difficulties of the library; there are quite a few test cases which are difficult and/or expensive to create on demand for testing. Thanks for you help, --Beman

1 0

patch: Boost.DateTime wide string conversion in MSVC6
by Davlet Panech 13 Dec '04

13 Dec '04

Added missing int64_t to wide string conversion for MSVC6. --- boost/date_time/posix_time/time_formatters.hpp.orig 2004-12-13 14:52:15.054188600 -0500 +++ boost/date_time/posix_time/time_formatters.hpp 2004-12-12 17:42:54.000000000 -0500 @@ -6,7 +6,7 @@ * Boost Software License, Version 1.0. (See accompanying * file LICENSE-1.0 or http://www.boost.org/LICENSE-1.0) * Author: Jeff Garland, Bart Garst - * $Date: 2004/11/04 12:28:49 $ + * $Date: 2004/10/29 06:27:24 $ */ #include "boost/date_time/gregorian/gregorian.hpp" @@ -26,6 +26,20 @@ namespace boost { namespace posix_time { + +#if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0 + namespace detail { + template <typename charT> struct convert_int64; + template <> struct convert_int64<char> { + static char *convert (char *buff, boost::int64_t i) + { return _i64toa(i, buff, 10); } + }; + template <> struct convert_int64<wchar_t> { + static wchar_t *convert (wchar_t *buff, boost::int64_t i) + { return _i64tow(i, buff, 10); } + }; + } +#endif // template function called by wrapper functions: // to_*_string(time_duration) & to_*_wstring(time_duration) @@ -69,7 +83,7 @@ date_time::absolute_value(td.fractional_seconds()); // JDG [7/6/02 VC++ compatibility] charT buff[32]; - _i64toa(frac_sec, buff, 10); + detail::convert_int64<charT>::convert(buff, frac_sec); #else time_duration::fractional_seconds_type frac_sec = date_time::absolute_value(td.fractional_seconds()); @@ -138,7 +152,7 @@ date_time::absolute_value(td.fractional_seconds()); // JDG [7/6/02 VC++ compatibility] charT buff[32]; - _i64toa(frac_sec, buff, 10); + detail::convert_int64<charT>::convert(buff, frac_sec); #else time_duration::fractional_seconds_type frac_sec = date_time::absolute_value(td.fractional_seconds());

1 0

patch: Boost.DateTime with MSVC6/STLport IOStreams
by Davlet Panech 13 Dec '04

13 Dec '04

Workaround for an internal compiler error in VC6 when compiled with STLport iostreams. --- boost/date_time/date_formatting.hpp.orig 2004-12-13 14:09:35.404548400 -0500 +++ boost/date_time/date_formatting.hpp 2004-12-12 17:42:53.000000000 -0500 @@ -27,7 +27,16 @@ template<class month_type, class format_type, class charT=char> class month_formatter { - public: +// Workaround for ICE in MSVC 6 when building with STLport IOstreams +#if defined (BOOST_MSVC) && BOOST_MSVC <= 1200 && \ + (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) && \ + !defined (_STLP_NO_OWN_IOSTREAMS) + private: + typedef std::basic_ostream<charT> _ostream_type; + public: + static _ostream_type &format_month(const month_type& month, _ostream_type &os) +#else + public: //! Formats a month as as string into an ostream /*! This function demands that month_type provide * functions for converting to short and long strings @@ -35,6 +44,7 @@ */ static std::basic_ostream<charT>& format_month(const month_type& month, std::basic_ostream<charT>& os) +#endif { switch (format_type::month_format()) {

1 0

RE: [boost] Re: Unzipping the Boost distro
by Ferdinand Prantl 13 Dec '04

13 Dec '04

> From: David Abrahams > Ferdinand Prantl wrote: > >> From: boost-bounces(a)lists.boost.org > >> [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > >> > >> I just downloaded boost-1.32.0 and started to unzip it with the > >> built-in facilities in Windows XP; the OS reported it was going to > >> take 50 minutes and it was *crawling*. Using cygwin's > unzip tool it > >> was done in under a minute. > >> > >> I'm thinking we should stop distributing raw .zip files without an > >> extractor... > > > > Hmm, I have never tried it. I always use Info-Zip's unzip or the > > That's what I mean. I used the built-in unzipper in the Win > XP file manager. OK, I tried it with the WinXP extractor in the explorer (I used the copy&paste files method). It estimated at first 25 minutes, after a minute only 9 minutes and it finished after 20 minutes, wonderful... ;-) My machine is P4 2 GHz with 80 GB seagate / 2MB cache Norton antivirus and unbelievably messed up Windows installation ;-) Just to display the archive content (like a folder content) takes relatively long. I am not sure why but I would guess that it could be in the implementation of the shell namespace extension for archives in windows xp. It can be quite expensive to build the structure of shell item nodes for every file/folder in the archive, if the archive contains so many items. They should be created on demand, I faced the problem in my shell extension too. But without the source code I cannot guess. For example WinRAR shell extension "Extract Here" extracts the zip file quick - 2 minutes (it has no explore option, it is only a context menu shell extension) and I believe WinZIP or 7ZIP will have similar results. Btw., rd /q/s xxx is also faster that deleting using the explorer. I understand, that the zip distribution is primarily for the windows users and such slowness is painful. Nevertheless, a crappy implementation of some plugin in OS would annoy only the users who use it, the others can follow the recommendation from the boost download page, and download an alternative unzipping tool, for example from the info-zip site. There is no problem in the zipped file, it's just too big :-) An alternative would be a self-extracting archive, which can be produced by some free tools as well. Ferda

1 0

[Boost-bugs] [ boost-Support Requests-1084615 ] spirit: run-time error
by SourceForge.net 13 Dec '04

13 Dec '04

Support Requests item #1084615, was opened at 2004-12-13 20:40 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=1084615&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alessio Marchetti (bnf) Assigned to: Nobody/Anonymous (nobody) Summary: spirit: run-time error Initial Comment: I am using the Spirit library v1.8.1, part of Boost 1.32. Here is a test case which fails at run-time: I get a VC++ Debug Library Error in file core\non-terminal\impl\rule.ipp at line 173. My compiler is VC++ 7.1 on Windows XP SP2. In particular I get a Run-Time Check Failure #2: Stack around the variable 'context-wrap' was corrupted. Any idea about what can be the problem? Please note that with the following I don't get any error: definition(const JSIGrammar& self) { Rule_T pp_token = real_p r = ch_p('#') >> str_p("line") >> +(pp_token); } struct JSIGrammar : public grammar<JSIGrammar> { template <typename ScannerT> struct definition { typedef rule<ScannerT> Rule_T; definition(const JSIGrammar& self) { Rule_T pp_number = real_p; Rule_T pp_token = pp_number; r = ch_p('#') >> str_p("line") >> +(pp_token); } const Rule_T& start() const { return r; } Rule_T r; }; }; int main(int argc, char* argv[]) { string str; { ifstream in(argv[1]); ostringstream out; out << in.rdbuf(); str = out.str(); } typedef parse_info<string::iterator> Info; JSIGrammar g; Info pi = parse(str.begin(), str.end(), g, space_p); if ( pi.hit ) { cout << "Match" << endl; cout << "Full: " << (pi.full ? "Yes" : "No") << endl; cout << "Length: " << pi.length << endl; } else { cout << "No match" << endl; } return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1084615&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Unzipping the Boost distro
by Ferdinand Prantl 13 Dec '04

13 Dec '04

> From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > > I just downloaded boost-1.32.0 and started to unzip it with > the built-in facilities in Windows XP; the OS reported it was > going to take 50 minutes and it was *crawling*. Using > cygwin's unzip tool it was done in under a minute. > > I'm thinking we should stop distributing raw .zip files > without an extractor... Hmm, I have never tried it. I always use Info-Zip's unzip or the built-in unzipper in some file manager. A notice about this strange behavior on the download page with a link to some good unzipping tool (preferably without the cygwin dependency) would do, for example the official Info-Zip site: http://www.info-zip.org/UnZip.html#Win32 Links to unpackers for the downloadable files are also on other sites. And you may consider submitting a feature change request to Microsoft ;-) Ferda > Dave Abrahams

2 1

Some Boost.Filesystem problems
by Ben Hutchings 13 Dec '04

13 Dec '04

I noticed that Boost.Filesystem doesn't use readdir_r to iterate over directories, even if it is available, making that non-thread-safe. There is a comment to this effect in operations_posix_windows.cpp. I've attached a patch that I believe will allow it to detect whether readdir_r is available and to use it iff it is. I have only tested this on Linux with g++ 3.3, but I tried deliberately breaking the declaration of readdir_r and verified that the code continues to work without it. On a visual inspection some time back I also noted that there's no special handling for empty root directories on Windows. The problem with these is that while even an empty directory normally has entries for "." and "..", so that FindFirstFile can return something, root directories on FAT volumes (and I think NTFS as well) do not have these and Windows doesn't fake them, so FindFirstFile on an empty root returns INVALID_HANDLE_VALUE. Note that this only applies to real root directories, not to the roots of drives that are mapped to sub-directories using subst or file sharing. I never got round to checking whether the Boost code actually handles this or not, as I only use Windows at work and we don't use Boost.Filesystem there. Perhaps someone could check that out? Unfortunately it's impractical to test automatically, as empty volumes are hard to generate on demand! Ben. -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either.

1 1

A replacement to any_cast
by Yuval Ronen 13 Dec '04

13 Dec '04

Hi, I've checked the 'any' library, and I have a suggestion. Wouldn't it be nicer if class any will have a member method like: template <typename T> T get() const; or maybe even: template <typename T> const T& get() const; template <typename T> T& get(); In my humble opinion, that would look better of the current 'any_cast' way of doing it. Thanks, Yuval Ronen

9 15

Re: [boost] Re: [iostreams] Version of Iostreams compatible with1.32available
by JOAQUIN LOPEZ MU?Z 13 Dec '04

13 Dec '04

Hi Jonathan ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Domingo, Diciembre 12, 2004 1:10 am Asunto: [boost] Re: [iostreams] Version of Iostreams compatible with1.32available > Has this been tested on Borland 5.x? No, it hasn't. This utility is a spin-off of multi_index, which does not compile in BCC (for many other reasons.) > I get errors (see end) unless > I make the > following change at line 132 > > template<typename Type> > struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> > { > }; > > ==> > > template<typename Type> > struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> > { > typedef typename Allocator::BOOST_NESTED_TEMPLATE > rebind<Type>::other other; > }; Well, your fix is kinda redundant. I guess every compiler will be happy with this instead: template<typename Type> struct result { typedef typename Allocator::BOOST_NESTED_TEMPLATE rebind<Type>::other other; }; If this works for BCC and you could do a quick check that it doesn't break the others (GCC, MSVC), please go ahead and commit to the CVS (thank you!) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[logo] slightly OT: about the FedEx logo
by JOAQUIN LOPEZ MU?Z 12 Dec '04

12 Dec '04

I can't resist posting this delightful article about a little-known hidden surprise in the FedEx logo: http://www.thesneeze.com/mt-archives/000273.php This is IMHO the kind of elegance we should strive for when building our Boost logo. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[range + string algos] bug with Intel C++ 7.0 on Windows
by Pavel Vozenilek 12 Dec '04

12 Dec '04

This 2-liner: --------------------------- #include <boost/algorithm/string.hpp> #include <boost/range/iterator_range.hpp> --------------------------- produces error with Intel C++ 7.0 for Windows (plugged in VC6 IDE, old Dinkumware): P:\N\src\boost_1_32_0\boost/range/iterator_range.hpp(78): error: class template "boost::algorithm::iterator_range" may not be redeclared in the current scope class iterator_range ^ P:\N\src\boost_1_32_0\boost/range/iterator_range.hpp(78): error: class template "boost::algorithm::iterator_range" has already been defined class iterator_range ------ Comment on this from Eric Niebler: it's a compiler bug, algorithm/string.hpp causes iterator_range to be declared in boost::algorithm namespace, and range/iterator_range.hpp causes a different iterator_range to be defined in the boost namespace. That's fine, but your compiler doesn't seem to like it. The fix is probably to make the string algorithms use boost::iterator_range instead of defining its own version. ------ /Pavel

2 3

filter_iterator bidirectional traversal patch
by Bob Bell 12 Dec '04

12 Dec '04

Hi boosters- A couple of days ago I started a thread asking about the rationale for making filter_iterator only a forward traversal iterator. I presented some arguments for making filter_iterator bidirectional instead. As some people seemed to be convinced that this was OK, I took the liberty of creating a patch. Oddly enough, the work had almost been completed already -- all that was needed was to make the category bidirectional. Here's the patch: *** filter_iterator.hpp.orig Thu Aug 12 10:13:06 2004 --- filter_iterator.hpp Sun Dec 12 11:24:05 2004 *************** *** 33,39 **** typename iterator_traversal<Iterator>::type , bidirectional_traversal_tag > ! , forward_traversal_tag , use_default >::type > type; --- 33,39 ---- typename iterator_traversal<Iterator>::type , bidirectional_traversal_tag > ! , bidirectional_traversal_tag , use_default >::type > type; Here's the test program I used to verify it: #include <iostream> #include <list> #include <boost/iterator/filter_iterator.hpp> #include <boost/iterator/reverse_iterator.hpp> // simple filter that returns true for even numbers: struct filter { typedef int argument_type; bool operator()(argument_type iArg); }; bool filter::operator()(argument_type iArg) { return (iArg & 1) == 0; } // Simple functions that traverse a sequence and print them: template<typename It> void traverse_forward(It iBegin, It iEnd) { while (iBegin != iEnd) { std::cout << *iBegin << "\n"; ++iBegin; } } template<typename It> void traverse_backward(It iBegin, It iEnd) { while (iBegin != iEnd) { --iEnd; std::cout << *iEnd << "\n"; } } // Show that boost::filter_iterator won't make a forward iterator into a // bidirectional one. typedef boost::filter_iterator<filter, std::istream_iterator<int> > ii; enum { result = boost::is_convertible< boost::iterator_traversal<ii>::type , boost::bidirectional_traversal_tag >::value }; BOOST_STATIC_ASSERT(!result); int main (void) { std::list<int> l; for (int i = 0; i < 10; ++i) l.push_back(i); typedef boost::filter_iterator<filter, std::list<int>::iterator> fi; fi b, e; b = boost::make_filter_iterator(filter(), l.begin(), l.end()); e = boost::make_filter_iterator(filter(), l.end(), l.end()); std::cout << "Using filter_iterator:\n"; std::cout << "\nEven numbers forward:\n"; traverse_forward(b, e); std::cout << "\nEven numbers backward:\n"; traverse_backward(b, e); // Show that filter_iterator works with reverse_iterator: typedef boost::reverse_iterator<fi> ri; std::cout << "\nUsing reverse_iterator with a filter_iterator:\n"; std::cout << "\nEven numbers backward:\n"; traverse_forward(ri(e), ri(b)); std::cout << "\nEven numbers forward:\n"; traverse_backward(ri(e), ri(b)); } Here's the expected output: Using filter_iterator: Even numbers forward: 0 2 4 6 8 Even numbers backward: 8 6 4 2 0 Using reverse_iterator with a filter_iterator: Even numbers backward: 8 6 4 2 0 Even numbers forward: 0 2 4 6 8 Bob

1 0

Solaris 10 x86 - Compiling libboost_python
by Johan Carlstedt 12 Dec '04

12 Dec '04

Hello, I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 3.4.1 and Python 2.23. The compilation fails for libboost_python with the error message below. It seems to be a problem with the Boost.Graph library, used by Boost.Python. I have tried with and without "-fpermissive". I would be grateful if anyone was able to advice. With friendly regards, Johan Carlstedt bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install ....found 11612 targets... ....updating 32 targets... gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable- true/inheritance.o In file included from /export/home/johan/boost_1_32_0/libs/python/build/../src/object/inherit ance.cpp:11: /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `Tag' has not been declared /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: error: expected `,' or `...' before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `g' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `Value' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: In function `void boost::set_property(int&, int, int)': /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: `m_property' has not been declared /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: request for member of non-aggregate type before ',' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: warning: there are no arguments to `Tag' that depend on a template parameter, so a declaration of `Tag' must be available /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: `value' undeclared (first use this function) /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: (Each undeclared identifier is reported only once for each function it appears in.) /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: At global scope: /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `Tag' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 1 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 2 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected init-declarator before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected `;' before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `Tag' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 1 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 2 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected init-declarator before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected `;' before '&' token

2 1

Re: [boost] Re: boost::filter_iterator Model
by JOAQUIN LOPEZ MU?Z 12 Dec '04

12 Dec '04

----- Mensaje original ----- De: Sylvain Pion <Sylvain.Pion(a)sophia.inria.fr> Fecha: Domingo, Diciembre 12, 2004 11:23 am Asunto: Re: [boost] Re: boost::filter_iterator Model > On Sun, Dec 12, 2004 at 02:46:12AM +0100, JOAQUIN LOPEZ MU?Z wrote: > > Admittedly, this quote does not state against which > > sequence the complexity must be amortized. From my > > point of view, the intended meaning is that the > > amortization is done wrt to full traversal: otherwise, > > even STL iterators cannot be compliant, as your > > example prove. > > My example prooves it for rb-trees, but they could be made > compliant : > just add a doubly-linked list linking the tree leaves, in parallel > to the > rb-tree, and use it for traversing. > Good catch. This is plain constant time, which leaves the question of what "amortized" meant in the first place. (Incidentally, you can get this in Boost.MultiIndex if you combine an ordered and a sequenced index.) > > > PS: I think the std is rather sloppy in this issue. > > I agree. > > -- > Sylvain > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: boost::filter_iterator Model
by JOAQUIN LOPEZ MU?Z 12 Dec '04

12 Dec '04

----- Mensaje original ----- De: Sylvain Pion <Sylvain.Pion(a)sophia.inria.fr> Fecha: Sábado, Diciembre 11, 2004 11:25 pm Asunto: Re: [boost] Re: boost::filter_iterator Model [...] > > I can't find anything in the standard that says that the cost > should be > amortized over the full traversal of the std::set. The only reference I'm aware of about complexity guarantees for iterators is in [lib.iterator.requirements], 24.1.8: "All the categories of iterators require only those functions that are realizable for a given category in constant time (amortized). Therefore, requirement tables for the iterators do not have a complexity column." Admittedly, this quote does not state against which sequence the complexity must be amortized. From my point of view, the intended meaning is that the amortization is done wrt to full traversal: otherwise, even STL iterators cannot be compliant, as your example prove. When working with infinite sequences, "full traversal" does not make sense, but it's obvious how to cover this case with limit considerations. Maybe this is a good question for comp.std.c++? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: I think the std is rather sloppy in this issue. > And it's possible to find sub-ranges which take non-bounded > average time > to traverse, when the size of the std::set increases : > - take the range [ (begin+end)/2 - n ; (begin+end)/2 + n ] in an > std::set of size() = 2^(2^n). This is a sequence of ranges of > size 2n, and which > take at least O(2^n) to traverse, and so definitely not constant > time amortized [over the length of the range]... > > When considering an amortized cost/complexity, it refers to sequences, > whose lengths grow to infinity, but here nothing specifies which > sequenceswe are considering. And if you allow any kind of > infinite sequences, then > set::iterator does not have the required complexity, from the > example above :( > > What am I missing ? > > -- > Sylvain > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Boost-bugs] [ boost-Bugs-1083760 ] Error in msvc in building inheritance.obj to build hello.pyd
by SourceForge.net 12 Dec '04

12 Dec '04

Bugs item #1083760, was opened at 2004-12-12 01:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1083760&group_… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: AIM (andre_mikulec) Assigned to: David Abrahams (david_abrahams) Summary: Error in msvc in building inheritance.obj to build hello.pyd Initial Comment: Error in msvc in building inheritance.obj to build hello.pyd Hello, I am trying to build the boost 1.31.0 sample extension hello.cpp. I can not compile the file inheritance.cpp because the two files containing some templates: adjacency_list.hpp and mem_fn.hpp can not compile. Does anyone have any solutions? Instead of Visual C++ 6.0 should I use a different compiler? Anyone have any success on any other compiler? Did anyone manage to build a hello.pyd? Thank you very much. Here is my script below (with embedded results). rem I have MSVC 6.0 Service Pack 5 on Windows 2000 Service Pack 3 default installs on F: rem Python is located in F:\Python23 rem Boost is located in W:\boost_1_31_0 rem MSVC stlPort 4.6.2 installed, compiled and rem VC studio include dirs and libraries dirs configured to use it. rem build boost.jam (so I have a bjam.exe for all below) W: vcvars32.bat cd W:\boost_1_31_0\tools\build\jam_src rem below since I have multilple toolsets installed I will always be specific. .\build.bat msvc rem result: 2 minutes later: NO WARN NO ERRORS dir W:\boost_1_31_0\tools\build\jam_src\bin.ntx86\* rem result: OK I have *jam*.exe executables: bjam.exe jam.exe mkjambase.exe yyacc.exe rem build boost (using boost.jam (bjam from above)) W: vcvars32.bat set PYTHON_ROOT=F:\Python23 set PYTHON_VERSION=2.3 set PATH=%PATH%;W:\boost_1_31_0 \tools\build\jam_src\bin.ntx86 rem APPEND THE BJAM PATH ABOVE TO THE SYSTEM ENVRONMENT VARIABLE PATH cd W:\boost_1_31_0 rem below since I have multilple toolsets installed I will always be specific. bjam "-sTOOLS=msvc" install rem about 90 minutes later ERROR RESULTS FOLLOW: <<< errors.txt contents below >>> cl /Zm800 -nologo -GX -c -DNDEBUG -DNDEBUG - DBOOST_PYTHON_DYNAMIC_LIB - DBOOST_PYTHON_SOURCE /Ogity /O2 /Gs /Ob2 /GX /GR /MD -I"bin\boost\libs\python\build" - I"W:\boost_1_31_0" -I"F:\Python23\include" - I"F:\Program Files\Microsoft Visual Studio\VC98 \Include" - Fo"bin\boost\libs\python\build\boost_python.dll\msvc\rele ase\inheritance.obj" -Tp"W:\boost_1_31_0 \libs\python\build\../src/object/inheritance.cpp" rem error below results below ... F:\Program Files\Microsoft Visual Studio\VC98 \Bin>cl /Zm800 -nologo -GX -c -DNDEBUG -DNDEBUG - DBOOST_PYTHON_DYNAMIC_LIB - DBOOST_PYTHON_SOURCE /Ogity /O2 /Gs /Ob2 /GX /GR /MD -I"bin\boost\libs\python\build" - I"W:\boost_1_31_0" -I"F:\Python23\include" -I"F:\Program Files\Microsoft Visual Studio\VC98 \Include" - Fo"bin\boost\libs\python\build\boost_python.dll\msvc\rele ase\inheritance.obj" -Tp"W:\boost_1_31_0 \libs\python\build\../src/object/inheritance.cpp" inheritance.cpp W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1055) : error C2244: 'bidirectional_graph_helper_with_property<Config >::remove_edge' : unable to resolve function overload W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1057) : error C2954: template definitions cannot nest W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of '_mfi' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';' before '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2501: 'dm' : missing storage-class or type specifiers W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : ';' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or namespace name W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2645: no qualified name for pointer to member (found ':: *') W:\boost_1_31_0\boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';' before '}' W:\boost_1_31_0\boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block scoping error F:\Program Files\Microsoft Visual Studio\VC98\Bin> W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1055) : error C2244: 'bidirectional_graph_helper_with_property<Config >::remove_edge' : unable to resolve function overload W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1057) : error C2954: template definitions cannot nest rem the problem area in adjacency_list.hpp is here ... template <class Config> inline void bidirectional_graph_helper_with_property<Config>::remov e_edge(typename Config::edge_descriptor e) { typedef typename Config::graph_type graph_type; graph_type& g = static_cast<graph_type&>(*this); boost::remove_edge(source(e, g), target(e, g), *this); } // O(E/V) or O(log(E/V)) template <class EdgeOrIter, class Config> inline void remove_edge(EdgeOrIter e, bidirectional_graph_helper_with_property<Config>& g_) { g_.remove_edge(e); } W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of '_mfi' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';' before '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2501: 'dm' : missing storage-class or type specifiers W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : ';' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or namespace name W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2645: no qualified name for pointer to member (found ':: *') W:\boost_1_31_0\boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';' before '}' W:\boost_1_31_0\boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block scoping error rem The problem area in mem_fn.hpp is here ... creating a template class at the end of mem_fn.hpp template<class R, class T> _mfi::dm<R, T> mem_fn(R T::*f) { return _mfi::dm<R, T>(f); } } // namespace boost rem build hello world W: vcvars32.bat set PYTHON_ROOT=F:\Python23 set PYTHON_VERSION=2.3 set PATH=%PATH%;W:\boost_1_31_0 \tools\build\jam_src\bin.ntx86 rem APPEND THE BJAM PATH ABOVE TO THE SYSTEM ENVRONMENT VARIABLE PATH cd W:\boost_1_31_0\libs\python\example\tutorial bjam -sTOOLS=msvc The results are as follows W:\boost_1_31_0\libs\python\example\tutorial>bjam - sTOOLS=msvc ...found 1978 targets... ...updating 7 targets... vc- C++ ..\..\..\..\bin\boost\libs\python\build\boost_python.d ll\msvc\debug\inheritance.obj inheritance.cpp W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1055) : error C2244: 'bidirectional_graph_helper_with_property<Config >::remove_edge' : unable to resolve function overload W:\boost_1_31_0\boost/graph/detail/adjacency_list.hpp (1057) : error C2954: template definitions cannot nest W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of '_mfi' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';' before '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2501: 'dm' : missing storage-class or type specifiers W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : ';' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : '<' W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or namespace name W:\boost_1_31_0\boost/mem_fn.hpp(315) : error C2645: no qualified name for pointer to member (found ':: *') W:\boost_1_31_0\boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';' before '}' W:\boost_1_31_0\boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block scoping error "cl" /Zm800 -nologo -GX -c - DBOOST_PYTHON_DYNAMIC_LIB - DBOOST_PYTHON_SOURCE /Z7 /Od /Ob0 /GX /GR /MDd -I"..\..\..\..\bin\boost\libs\python\build" - I"W:\boost_1_31_0" -I"F:\Python23\include" - I"F:\PROGRA~1\MICROS~3\VC98\include" -Fo"..\..\..\.. \bin\boost\libs\python\build\boost_python.dll\msvc\debug \inheritance.obj" -Tp"W:\boost_1_31_0 \libs\python\build\../src/object/inheritance.cpp" ...failed vc- C++ ..\..\..\..\bin\boost\libs\python\build\boost_python.d ll\msvc\debug\inheritance.obj... ...skipped <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.CMD for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>inheritance.obj... ...skipped <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.dll for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.CMD... ...skipped <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.lib for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.CMD... ...skipped <@boost!libs!python!example! tutorial\hello.pyd\msvc\debug>hello.CMD for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.lib... ...skipped <@boost!libs!python!example! tutorial\hello.pyd\msvc\debug>hello.pyd for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.dll... ...skipped <@boost!libs!python!example! tutorial\hello.pyd\msvc\debug>hello.lib for lack of <@boost!libs!python! build\boost_python.dll\msvc\debug>boost_python.dll... ...failed updating 1 target... ...skipped 6 targets... W:\boost_1_31_0\libs\python\example\tutorial>dir hello*.* rem results: ALL hello.CMD hello.pyd hello.lib NOT FOUND Any Ideas about a possible solution? AIM Andre_Mikulec(a)Hotmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1083760&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[thread] Why is there a restriction for the runtime libraries?
by Stefan Slapeta 12 Dec '04

12 Dec '04

There are two restrictions in the thread jamfile I don't understand: - the thread lib must be built with static runtime libraries - the thread dll must be built with dynamic runtime libraries What is the reason for that? Why can't I use the shared rt and link boost.thread statically (and vice versa)??? Stefan

5 19

Re: [boost] Re: boost::filter_iterator Model
by JOAQUIN LOPEZ MU?Z 11 Dec '04

11 Dec '04

Hi Dave, ----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Sábado, Diciembre 11, 2004 9:01 pm Asunto: [boost] Re: boost::filter_iterator Model [...] > Is that the right way to understand the complexity guarantee? > I'm really asking. Consider std::set. As the size of the set > grows, the > average cost of incrementing an iterator grows without bound. This is not correct, IMHO. Consider a set::iterator doing a full traversal from begin to end. From the rb-tree point of view, this is equivalent to visiting the whole tree in an inorder fashion. And it is easy to see that every node will get hopped from at most three times: - when visiting its left subtree. - when visiting its right subtree. - when leaving to an upper level. So the total number of hops is bounded by 3*N, and the average cost of incrementing is constant, which is the same as to say that increment complexity is amortized constant, as required by the std. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: boost::filter_iterator Model
by JOAQUIN LOPEZ MU?Z 11 Dec '04

11 Dec '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Sábado, Diciembre 11, 2004 9:01 pm Asunto: [boost] Re: boost::filter_iterator Model [...] > > >> Is that stretching the definition of an iterator? I'm not sure. > > > > That's too much for me. > > I tend to think that it's stretching what users might expect > when they see > > "constant time amortized operation". > > This is tricky territory. It certainly warrants a note in the > documentation, but I'm not exactly sure what to say. I'm afraid that, generally speaking, filter_iterator<> cannot just guarantee the std-required complexity, and you cannot do anything about it (consider for instance filter_iterator<is_prime<int>, counting_iterator<int> >) To say it bluntly, not all instantiations of filter_iterator<> are iterators. I'd just say it so: "std-mandated complexity guarantees are provided only if the number of skipped elements divided by the length of the base range remains constant in average." Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

boost::filter_iterator Model
by Bob Bell 11 Dec '04

11 Dec '04

Hi- I was wondering what the rationale was for boost::filter_iterator not modeling anything more than a forward traversal iterator. Recently I was trying to use filter_iterator in a situation where I needed bidirectional traversal, but got stymied by this. Is there something about the notion of filtering that precludes bidirectionality? Or is this something that could be made to work? Thanks, Bob

4 8

Sandbox file vault.
by Rene Rivera 11 Dec '04

11 Dec '04

As I mentioned in some earlier post.. I set up file vault are in the Boost-Sandbox web space: http://boost-sandbox.sourceforge.net/vault/ It works much like the Yahoo files area used to work. It's read only for everyone, and read-write if you "register". Registration is not closed or anything and is only there to verify that it's a real person, or as close as email verification can get, uploading files. NOTE: It seems a bit sluggish. Don't know if it's SF or the scripts. But I would suspect the scripts. If you need admin access email me. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 6

logos
by David Abrahams 11 Dec '04

11 Dec '04

For a while there, we were having such fun posting proposed logo designs; there were easily 20 posts a day on the topic. I requested that the local posting stop so we could run a contest "for real," that would include the wider C++ community, and solicited a contest manager, but so far nobody has stepped forward. It would be a real shame if Boost ended up with no new logo or an inferior logo just because of that. Really, for some of you who've been very involved with the previous flurry of posts, this job shouldn't occupy much more time than you were already going to spend on it. Someone just has to: 1. write up a voting system 2. modify the wiki page to reflect recent requirements consensus 3. post an announcement 4. tally the results Rene has already established a great "head start" by setting up the Wiki page. Isn't there anyone out there who's willing to perform this valuable service to the Boost community? Don't make me start emailing individuals to prod them ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 5

[smart cont.] Const semantics in boost::ptr_map vs. std::map
by Eelis van der Weegen 11 Dec '04

11 Dec '04

Two issues: (1.) I stumbled upon a strange inconsistency in boost::ptr_map's iterator interface. I've attached some demonstration code that shows the problem. (2.) Given a (nonempty) const std::map<X, Y*> object, it is possible to retrieve a Y& from it. Given a const boost::ptr_map<X, Y> object, it is not possible (without casting) to retrieve a Y& from it. Thus, it is not possible (in general) to refactor code which uses a std::map<X, Y*> combined with manual ptr_map-like lifetime/ownership management to use a boost::ptr_map<X, Y> without changing const semantics. Was this effect intentional? If so, why was this approach chosen? It seems like ptr_map attempts to "hide" the level of indirection that a standard container of pointers has. While this may be desirable, I think it should be mentioned in the documentation since it can come as a surprise to people (like me) who actually try to perform the refactoring mentioned above. Eelis #include <map> #include <boost/smart_container/ptr_map.hpp> typedef std::map<int, int *> M; typedef boost::ptr_map<int, int> N; void f (M & m) { M::iterator i = m.begin(); M::iterator const ci = i; int & a = *(i->second); // ok int & b = *(ci->second); // ok } void g (N & n) { N::iterator i = n.begin(); N::iterator const ci = i; int & a = *i; // ok int & b = *ci; // error: invalid initialization of reference of type 'int&' from expression of type 'const int' }

2 4

auto-link, DLLS and exported constants
by Robert Ramey 11 Dec '04

11 Dec '04

I'm trying to implement auto-link and build static versions of the serialization libraries. It seems I'm making progress but I'm sort of stuck on one point right now. one my header files now contains: extern BOOST_SERIALIZATION_DECL const char * ARCHIVE_SIGNATURE; extern BOOST_SERIALIZATION_DECL unsigned int ARCHIVE_VERSION; while the corresponding implemenation file contains: /////////////////////////////////////////////////////////////////////// // constants used in archive signature //This should never ever change. note that is not an std::string // string. BOOST_SERIALIZATION_DECL const char * ARCHIVE_SIGNATURE = "serialization::archive"; // this should change if the capabilities are added to the library // such that archives can be created which can't be read by previous // versions of this library // 1 - initial version // 2 - made address tracking optional // 3 - numerous changes - can't guarentee compatibility with previous versions BOOST_SERIALIZATION_DECL unsigned int ARCHIVE_VERSION = 3; When I link an executable with the static library things work fine. When I link with the dll import library I get errors indicating undefined symbols for these const variables. What is recommended here? Robert Ramey

2 1

[Boost-bugs] [ boost-Support Requests-1083024 ] Boost Library Unknown compiler version
by SourceForge.net 10 Dec '04

10 Dec '04

Support Requests item #1083024, was opened at 2004-12-10 08:47 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=1083024&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost Library Unknown compiler version Initial Comment: I have used the Boost Library (boost_1_32_0) until this afternoon, when my system was updated. Now the c++ version 3.4.2 is installed and I'm not able to compile anymore. I tried to run ./configure script and move the user.cpp file in the config directory, but I din't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1083024&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

typeof integrated
by Arkadiy Vertleyb 10 Dec '04

10 Dec '04

Hi all, Peder and I have put together a combined version of our typeof implementations. The integrated library supports both compliant and vintage compilers, and can be found in the Boost sandbox CVS (boost/typeof, libs/typeof) or at: http://groups.yahoo.com/group/boost/files/typeof_integrated.zip As always, any comments are most welcome. Regards, Arkadiy

6 38

missing regression tests?
by John Maddock 10 Dec '04

10 Dec '04

What's happened to most of the regression tests? The Tru64, SGI, AIX etc test results have all disappeared. Thanks, John.

3 2

boost::shared_ptr<> uses mutex rather than CAS methods
by Dayton 09 Dec '04

09 Dec '04

Shared_ptr<> down deep uses a light-weight mutex to protect the increment and decrement of its reference count. A mutex isn't needed here. A mutex may yield the context of execution. This seems silly to protect a single instruction. To support threads, all modern processors offer some form of interlocked operation or atomic compare-and-swap instruction. On SPARC cpus, it is the CAS instruction, which acts much like a spin-lock. Windows offers InterlockedIncrement() and InterlocledDecrement() functions, which in the newer Microsoft compilers may be compiled as an intrinsic. I'm a bit allergic to context yielding synchronization objects thrown randomly into my server code. Does anyone know of any reasons to not use CAS-style programming here before I propose using it for smart_ptr<>? Glen

6 7

[Boost-bugs] [ boost-Support Requests-1082491 ] Linker error
by SourceForge.net 09 Dec '04

09 Dec '04

Support Requests item #1082491, was opened at 2004-12-09 13:52 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=1082491&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Linker error Initial Comment: Hi, Does anyone know why I get this linker error? fatal error LNK1104: cannot open file 'libboost_regex-vc7- sgd-1_32.lib'. I search my system for the file but no luck. I'm on Windows XP, using C++ .Net 7.0. Thanks in advance. Ken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1082491&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: Re: Re: Re: typeof integrated
by Jason Shirk 09 Dec '04

09 Dec '04

> From: Arkadiy Vertleyb [mailto:vertleyb@hotmail.com] > Sent: Wednesday, December 08, 2004 1:16 PM > Subject: Re: Re: Re: Re: typeof integrated > > "Peder Holt" <peder.holt(a)gmail.com> wrote > > > Then again, the following compiles with VC7.1, so maybe there is hope > > after all :) > > Wow... > > The reason it compiles is that you are using "class" where I used > "typename". The following does not work: > > template<typename A0> > void deduce_container(*typename* std::_Tree<A0>::iterator) > { > std::cout << "map" << "\n"; > } > > I don't think this is a legal standard usage, though... Probably a > Microsoft - specific "feature"... Any comments from language experts? > Should the following work according to the Standard? > This is definitely a compiler bug, not a feature. -- Jason Shirk VC++ Compiler Team

1 0

Re: Problem with boost.iterator II
by David Abrahams 09 Dec '04

09 Dec '04

Bob Bell wrote: > Dave- > > I was looking over my "sent" items and I think something was wrong with > my return address, so I'm resending this with the right address. Sorry > for any confusion it may have caused. Bob, Please post Boost questions to one of the Boost mailing lists (unless you want to hire us for consulting services, that is!) > I've been using the boost iterator adaptor library, and first let me say > thanks; it's really a great library. You're welcome :) > Having said that, however, I'm having a problem. I'm trying to build an > iterator that uses both boost::filter_iterator and > boost::transform_iterator, but what happens is that when I combine these > two adaptors, it seems to lose the iterator category of the original > iterator. That is, say I build an iterator like this: > > boost::transform_iterator<SomeTransform, > boost::filter_iterator<SomeFilter, int*> > > > The resulting iterator only seems to be a forward iterator. My > understanding is that the iterator category of the base iterator (int*), > should become the category of the resulting composite. So my first > question is: is this a correct understanding on my part? Not according to http://www.boost.org/libs/iterator/doc/filter_iterator.html#filter-iterator… A filter iterator is never more than a forward iterator. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[Variant] Binary visitation and return type
by Hartmut Kaiser 09 Dec '04

09 Dec '04

Hi all, is there a means of using the binary visitation pattern provided by the Boost.Variant library and make the return type of the visitation process dependent on the types currently stored inside the visited variant object instances? I.e. I'm looking for some way to do the following: typedef boost::variant<unsigned long, long> variant_type; struct add_visitor : public .... { long operator()(long t1, long t2) { return t1 + t2; } template <typename T> unsigned long operator()(unsigned long t1, T t2) { return t1 + t2; } template <typename T> unsigned long operator()(T t1, unsigned long t2) { return t1 + t2; } }; variant_type term1 = 1L; variant_type term2 = 2UL; variant_type term3 = -2L; variant_type unsigned_result = boost::apply_visitor(add_visitor(), term1, term2); variant_type signed_result = boost::apply_visitor(add_visitor(), term1, term3); Is this possible with the current implementation? Regards Hartmut

3 6

logo contest?
by David Abrahams 09 Dec '04

09 Dec '04

Are we actually going to publicize a logo contest or are we going to be doing it all here? I think it should be the former, and I think we should get most of the logo announcements and commentary off this list so it can return to its regularly scheduled programming. But first I guess someone has to volunteer to manage the thing at least (make up the announcement, settle voting procedure, etc.) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

9 15

RE: [boost] shared_ptr, interface and dlls,
by Dirk Gregorius 09 Dec '04

09 Dec '04

> extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > and then construct an InterfacePtr( DLLCreate(), DLLDestroy ). You'll need a public virtual destructor in this case, > though. I changed my code to this: void DLLCreate( Interface& rInterface ) { // Implementation option #1: rInterface.reset( new InterfaceImple ); // Implementation option #2: rInterface = InterfacePtr( new InterfaceImpl ); } Is this a valid solution as well? At least it compiles - but with the first solution I have the feeling that I could run into the boundary problem, since the actual pointer is not constructed on the DLL side. But as I said - I can only guess here... Is there a difference between both solutions? > Yes, it's allowed. Since you are using the DLL runtime, you probably don't need to interoperate with different C++ > compilers so you probably need to just omit the extern "C" from DLLCreate. But how can I load the function than after it got mangled? -Dirk PS: Sorry for the wrong post...

2 2

porting to realtime platform
by Harald Haspl 09 Dec '04

09 Dec '04

Hello list, To use the realtime features of my hardware I need to link against a special library instead of rt. How can I replace the -lrt linker flags by -lrealtime when compiling the boost library? Harald Haspl

2 2

memory mapped containers?
by Neal D. Becker 08 Dec '04

08 Dec '04

I recall there was some discussion here about containers with memory-mapped storage? There was as I recall some interest. What is the status of this?

2 1

Re: Boost Digest, Vol 935, Issue 2
by Dirk Gregorius 08 Dec '04

08 Dec '04

> extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > and then construct an InterfacePtr( DLLCreate(), DLLDestroy ). You'll need a public virtual destructor in this case, > though. I changed to this: void DLLCreate( Interface& rInterface ) { // Implementation option #1: rInterface.reset( new InterfaceImple ); // Implementation option #2: rInterface = InterfacePtr( new InterfaceImpl ); } Is this a valid solution as well? At least it compiles - but with the first solution I have the feeling that I could run into the boundary problem, since the actual pointer is not constructed on the DLL side. But as I said - I can only guess here... Is there a difference between both solutions? > Yes, it's allowed. Since you are using the DLL runtime, you probably don't need to interoperate with different C++ > compilers so you probably need to just omit the extern "C" from DLLCreate. But how can I load the function than after it got mangled?

2 1

[Range] bugs in legacy compiler support
by Eric Niebler 08 Dec '04

08 Dec '04

In range/detail/begin.hpp: template<> struct range_begin<array_> { template< typename T, std::size_t sz > static T* fun( T BOOST_ARRAY_REF[sz] ) BOOST_ARRAY_REF is not defined anywhere I can see. This should probably be: template< typename T, std::size_t sz > static T* fun( T BOOST_RANGE_ARRAY_REF()[sz] ) ---------------------------------- In range/detail/end.hpp: template<> struct range_end<char_array_> { template< typename T, std::size_t sz > static std::size_t fun( T BOOST_RANGE_ARRAY_REF()[sz] ) { return boost::range_detail::array_end( array ); } }; template<> struct range_end<wchar_t_array_> { template< typename T, std::size_t sz > static std::size_t fun( T BOOST_RANGE_ARRAY_REF()[sz] ) { return boost::range_detail::array_end( array ); } }; The return types of these two functions are wrong. They should be T* instead of std::size_t. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

RE: [boost] shared_ptr, interface and dlls
by Stefan Seefeld 08 Dec '04

08 Dec '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > Is your advice > > above simply due to a limitation with MSVC ? > > It seems so. From a quick test, g++ and bcc32 do return C++ > classes from > extern "C" functions, only MSVC emits an error. I'm not sure > whether such a > function makes sense, though. If you suppress name mangling, > presumably > because two different compilers mangle names differently, > what are the > chances that the object layout will be the same? Oh, ABI compatibility is an entirely different issue, I agree. However, if you want to write your own component model you have to use an entry point with extern C linkage, even though the whole thing will be compiled with the same toolchain. Regards, Stefan

1 0

RE: [boost] shared_ptr, interface and dlls
by Stefan Seefeld 08 Dec '04

08 Dec '04

> > extern "C" InterfacePtr DLLCreate( void ) > > { > > return InterfacePtr( new InterfaceImpl ); > > } > > > > At the moment this code doesn't compile because VS7.1 complains that > > it a function with extern "C" linkage can't return a > > shared_ptr<Interface> instance. How could I implement the desired > > behavior? > > Either omit the extern "C" or, if you must use a C-style > interface, do this: > > extern "C" Interface* DLLCreate() > { > return new InterfaceImpl; > } > > extern "C" void DLLDestroy( Interface* p ) > { > delete p; > } > > and then construct an InterfacePtr( DLLCreate(), DLLDestroy > ). You'll need a > public virtual destructor in this case, though. When writing plugins under linux (i.e. with 'dlopen' etc.), I believe I have already used a function returning a std::auto_ptr as entry point for the loader. What is wrong with that ? Is your advice above simply due to a limitation with MSVC ? Regards, Stefan

2 1

shared_ptr, interface and dlls
by Dirk Gregorius 08 Dec '04

08 Dec '04

Hi, is it possible to return a shared_ptr to an interface from a dl?. I thought of the following what unfortunately doesn't work: // Interface.h - exe project class Interface { public: vitrtual void f( void ) = 0; virtual void g( void ) = 0; protected: ~Interface( void ) {} } typedef shared_ptr<Interface> InterfacePtr; InterfacePtr Create( void ) { // Load a special create function from the dll //.... return DLLCreate(); } // InterfaceImpl.h - dll project #include Interface class InterfaceImpl : public Interface { public: void f( void ) { /* ... */ }; void g( void ) { /* ... */ }; private: // No copy operations } extern "C" InterfacePtr DLLCreate( void ) { return InterfacePtr( new InterfaceImpl ); } At the moment this code doesn't compile because VS7.1 complains that it a function with extern "C" linkage can't return a shared_ptr<Interface> instance. How could I implement the desired behavior? Some other related questions regarding this topic: 1.) I link to the multithreaded C run-time dll - is this allowed? I read in an older post that only static CRT linking is allowed. 2.) Does the above code - loading the factory from the DLL as well and (hopefully) constructing the instance there - solve the boundary problems? I read some articles regarding this issue, but to be honest I haven't completly understood the problems that may occure in this case so far. Any help is greatly appreiciated.. -Dirk

2 1

[Boost-bugs] [ boost-Support Requests-1081415 ] isdigit, problem with namespace
by SourceForge.net 08 Dec '04

08 Dec '04

Support Requests item #1081415, was opened at 2004-12-08 07:41 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=1081415&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: isdigit, problem with namespace Initial Comment: Hi! In one of my projects I use the regex library, and it works great. But unfortunately it seems to mess up my namespaces, or something like that. I included #include "boost/regex.hpp". Using the boost library I am to call functions from the std namespace (memset, isdigit, ...) like ::isdigit(). Without the namespace-operator the compiler seems to have two functions called isdigit. Now it happens that I am to use another library along with regex (one of my company), which uses an isdigit() call (without namespace- operator), and which i must not alter. Honestly, I'm a little bit puzzled at all that the regex- library forces me to use the namespace-operator with functions from std-namespace. Is this the way it was ment, or did I somethig wrong? Thanks for your help, Markus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1081415&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[date_time] Sunpro wide test errors should be marked expected
by Caleb Epstein 08 Dec '04

08 Dec '04

-- Caleb Epstein caleb dot epstein at gmail dot com

2 1

[external_allocators] any interest?
by Thorsten Ottosen 08 Dec '04

08 Dec '04

Dear all, I have sometimes spoken with people here that had an interest in allocators that could be reset within containers. For example, some have wanted a allocator& container::get_allocator(); member function. One way to solve that problem could be a class like this: template< class Allocator > class external_allocator { public: // forward to Allocator* member }; And then it can be used like this typedef external_allocator< std::allocator<T> > ex_allocator; std::allocator<T> alloc; ex_allocator ex_alloc(alloc); std::vector<T,ex_allocator> vec(ex_alloc); and can now control the allocator from the outside. There seems to only be a small overhead with this approach. One usage scenario I can see would be to use a stack-based allocator on performance critical paths. (because we need the copy-semantics of the container's allocator to be shallow) If there is interest, I can also add the specified member function to the smart containers. or an appropriate member to external_allocator<>. Feedback is welcome -Thorsten

2 2

[ublas] matrix.hpp doesn't compile with Borland bcc32 5.6.4
by Nicola Musatti 08 Dec '04

08 Dec '04

Hallo, A translation unit that only includes #include <boost/numeric/ublas/matrix.hpp> from Boost 1.32.0 doesn't compile with Borland's bcc32 5.6.4 (BCB6 with Update 4), but it used to with Boost 1.31.0 . I get the following error messages: Build [C++ Error] traits.hpp(349): E2285 Could not find a match for 'std::abs(const _STL::complex<float>)' [C++ Error] traits.hpp(354): E2285 Could not find a match for 'std::sqrt(const _STL::complex<float>)' [C++ Error] traits.hpp(419): E2285 Could not find a match for 'std::abs(const _STL::complex<double>)' [C++ Error] traits.hpp(424): E2285 Could not find a match for 'std::sqrt(const _STL::complex<double>)' [C++ Error] traits.hpp(486): E2285 Could not find a match for 'std::abs(const _STL::complex<long double>)' [C++ Error] traits.hpp(491): E2285 Could not find a match for 'std::sqrt(const _STL::complex<long double>)' [C++ Error] vector.hpp(813): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(804): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(819): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(805): E2344 Earlier declaration of 'T' [C++ Error] vector.hpp(1030): E2356 Type mismatch in redeclaration of 'T' [C++ Error] vector.hpp(1022): E2344 Earlier declaration of 'T' Cheers, Nicola Musatti

1 0

Solaris+gcc regression errors should be marked expected
by Caleb Epstein 08 Dec '04

08 Dec '04

Sorry, I think I sent an empty message just before this one. Please ignore it. There are several test failures for date_time and other Boost libs on sunos5+gcc (see for example http://tinyurl.com/4y6tx) that are due to incomplete wide character support on that platorm. This situation appears to be similar to a number other configurations (e.g. win32+mingw) which have a similar or identical tests marked as expected failures in the test matrix. I think sunos5+gcc should be treated similarly. Here is the relevant section of boost/config/stdlib/libstdcpp3.hpp: #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Name checking in filesystem
by Walter Landry 08 Dec '04

08 Dec '04

Greetings, I have come across an annoying problem with the filesystem library. I have wrapped filesystem with Swig so that I can call it from python. I had to rewrite the filesystem::path implementation a little because Swig can't handle nested classes. In any case, once I got that sorted out, I wanted to do something like p=path(".bar") which doesn't work because filenames starting with a period are not allowed by the default name checking routine. Argh. Unfortunately, I can't figure out how to change the default name checker from python. If I worked at it long enough, I could probably work it out. But I am sure that I don't want to have to run something like path.default_name_check(no_check) at the beginning of every 10 line script. It is a particular piece of functionality (name checking) that just gets in the way. I would wager that most people using boost::filesystem from scripts would not want to have to deal with it, since it is completely different from every other portable, cross platform filesystem API. So to make a long story short, I think the default for boost::filesystem should be not to check for "portable" paths. This is different from a position I took earlier, where I thought that it is ok if I only have to set it once at the beginning. That is acceptable for large programs, but not for small ones. Regards, Walter Landry wlandry(a)ucsd.edu

6 14

[review-results] Smart Container Library
by Pavol Droba 08 Dec '04

08 Dec '04

Hi, I hereby announce that the Smart Container library is ACCEPTED into Boost. Congratulations and thanks to Thorsten Ottosen for providing us with this library. Most of the reviewers were in favor of acceptance, but there were several requests for improvements. I have consulted them with Thorsten and he proposed to do following changes. I consider them sufficient for acceptance. 1. add support for boost.range in insert functions, constructors etc 2. use void* implementation 3. improve docs as discussed during the review 4. add support for null values: - remove preconditions - add functions is_null( size_t idx ); is_null( iterator ); 5. add more debug checks after access to ptr_begin(), ptr_end() 6. reconfigure policies: ptr_vector<T,clone_manager> becomes ptr_vector<T,clone_allocator = something, std::allocator<T*> = std::allocator<T*> > or perhaps ptr_vector<T,clone_allocator = something< std::allocator<T* > > 7. improve tests I also suggest, that before the inclusion of the library into the boost distribution, the library should be brought in the discussion to verify, that all issues above have been addressed. Best Regards, Pavol Droba Review Manager

2 1

[date_time] SunPRO patch for date_names_put facet
by Caleb Epstein 07 Dec '04

07 Dec '04

The following patch is required to build date_time using the Sun Workshop C++ compiler. I mentioned this previously in another thread, but I fear it has been lost. --- boost/date_time/date_names_put.hpp~ 2004-12-01 08:58:32.846228000 -0500 +++ boost/date_time/date_names_put.hpp 2004-12-01 08:59:38.334228000 -0500 @@ -52,6 +52,11 @@ typedef std::basic_string<charT> string_type; static std::locale::id id; + +#if defined (__SUNPRO_CC) && defined (_RWSTD_VER) + std::locale::id& __get_id (void) const { return id; } +#endif + void put_special_value(iter_type& oitr, special_value_enum sv) const { do_put_special_value(oitr, sv); -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Two more logos...
by JOAQUIN LOPEZ MU?Z 07 Dec '04

07 Dec '04

...to add to the bunch. Variations on a previous theme. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

duplicate source files in boost- utf8_codecvt_facet
by Robert Ramey 07 Dec '04

07 Dec '04

We now have a at least one set of files more or less duplicated in boost. Ron Garcia's utf8_codecvt_facet is included in: boost/utf8_codecvt_facet.hpp boost/detail/utf8_codecvt_facet.hpp boost/libs/serialization/src/utf8_codecvt_facet.cpp boost/libs/program_options/detail/utf8_codecvt_facet.cpp boost/libs/doc/serialization/utf8_codecvt_facet.html boost/libs/serialization/test/test_utf8_codecvt_facet.cpp Leaving aside how this came to be, I would like to do the following: boost/detail/utf8_codecvt_facet.hpp boost/libs/detail // new directory boost/libs/detai/src/utf8_codecvt_facet.cpp boost/libs/detail/test/test_utf8_codecvt_facet.cpp boost/libs/detail/doc/utf8_codecvt_facet.html This would make both the serialization and program options libraries that much smaller and server our needs until a reviewed version of codecvt facets in added to boost. Robert Ramey

7 11

Program Options Custom Notifier Function Order of Execution
by Tony Han Bao 07 Dec '04

07 Dec '04

Hi all, Can anyone tell me the precise definition or behaviour of the order of execution of the user supplied functions to handle command line options defined in boost program options library. For example, my option menu was defined as follows boost::program_options::options_description menu("Valid Options"); menu.add_options() ("help,h", "Display this menu.") ("time,t", boost::program_options::value<double>(&time_arg_value) -> notifier(&my_function1) "Description of option") ("memory,m", boost::program_options::value<double>(&memory_arg_value) -> notifier(&my_function2), "Description of option") ("file,f", boost::program_options::value<std::vector<std::string> >(&file_arg_value) -> composing() -> notifier(&file_arg_handler<std::vector<std::string> >), "Something"); boost::program_options::variables_map menu_map; boost::program_options::store(boost::program_options:: parse_command_line(argc, argv, menu), menu_map); boost::program_options::notify(menu_map); Question is: Will the following two calls to the program result in different behaviour? >./Test --time 76 --memory 97 --help >./Test --memory 97 --time 76 --help I want my two functions for time and memory be independent of each other but I would like the function be called in the same order as the options specified on the command line. Sure I can test but can someone guarantee that what I discovered will remain valid in the future release of the library. Another question: What will happen if this program was called on the command line with the following options. >./Test --file myfile1 --time 87 --file myfile2 Will the file_arg_handler be called first with composed arguments and then time function (my_function1) or will the time function (my_function1) be called first and then the file_arg_handler function. Can I count on it that what happens will always happen in the future? Is there definitions for the order of execution guarantee by the library? Thanks in advance for your help! Best Regards, Tony Han Bao tonybao(a)mac.com

3 8

[named_params] member function overload autogen macro
by Cromwell Enage 07 Dec '04

07 Dec '04

It turns out that class member function definitions that take in named parameters will not compile with BOOST_NAMED_PARAMS_FUN. The first two lines of this macro, meant to generate the function prototype so that free function overloads can call it, cause a "duplicate definition" error when the macro is used in a class body. Fortunately, removing those two lines to create the BOOST_NAMED_PARAMS_MEMBER_FUN macro was all that was needed to eliminate the error. Sooo...here's yet another patch, along with a two-file program illustrating both macros in action. Cromwell D. Enage P.S. I better start adding my middle initial, to match with the name I use in my licensing info. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

no auto-link for serialization
by Martin Slater 07 Dec '04

07 Dec '04

Posted before but being a lemon I put filesystem in the subject instead of serialisation, please see No auto-link for filesystem message from yesterday. sorry Martin

2 1

No auto-link for filesystem
by Martin Slater 07 Dec '04

07 Dec '04

Is there a reason for this or is it just an oversight? cheers Martin

2 3

[BUG] Missing method in gregorian::greg_year
by Joel Reed 07 Dec '04

07 Dec '04

the class gregorian::greg_year in the date_time library is missing a method implemented in greg_day and greg_month. the method is: unsigned short as_number() const {return value_;} i checked cvs, on 12/6/04, to confirm this is still an issue. http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/date_time/gregorian… we have been very impressed with this library and wanted to report this minor inconsistency as a small, small way to say thanks. jr -- ------------------------------------------------------------ Joel W. Reed 412-257-3881 ---------- http://home.comcast.net/~joelwreed/ ----------

2 1

Boost Sandbox layout?
by Rene Rivera 06 Dec '04

06 Dec '04

I'm looking at how things are placed in the sandbox and wondering about something... Currently the sandbox mirrors the layout of the main Boost CVS. That is: boost-sandbox /boost/... /libs /libs/<library>/... That layout has a few drawbacks when dealing with a single isolated library... 1) It makes it harder to package as one has to filter out the rest of the stuff there. 2) One can get conflicts when something in another library's code gets accidentally used. I ran into this when evaluating named_params as some MPL related files got picked off from the sandbox instead of from the Boost CVS. 3) Makes finding things much harder when someone mentions to look in the sandbox for their library. Was there ever a discussion as to the layout? (A cursory search did not reveal anything) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 8

Bug: thread_exception returns ref to local variable
by Ulrich Eckhardt 06 Dec '04

06 Dec '04

Cheers! The code in question is this: // boost/thread/exceptions.hpp class thread_exception { ... const char* message() const; }; // libs/thread/src/exceptions.cpp std::string system_message(int sys_err_code){..} const char* thread_exception::message() const { if (m_sys_err != 0) return system_message(m_sys_err).c_str(); return what(); } If message() is called and m_sys_err is set, it will return a pointer to storage of a temporary, which is bad, as we all know. I did some research on that, and I think this whole method can be removed completely because: - it is not decumented - it is not used - it never worked (probably, at least not with 1.32) Further, one could then remove <string> from the includes in the header and some more includes in the sourcefile. An alternative approach would be to change the returntype to std::string, of course, or (and I think that's an interesting alternative!) derive all those classes from std::runtime_error, which can hold a std::string natively. Uli

1 0

wiki spam
by Max Khesin 06 Dec '04

06 Dec '04

The CAPTCHA technology might be helpful: http://weblog.infoworld.com/udell/2004/12/01.html#a1124 There are apparently open-source implementations of CAPTCHA, might be something to consider. Another suggestion would be boost-specific CAPTCHA that asks you to enter a result of some enable_if statement as the answer to the question - guaranteed to stop spammers AND newbies! (an unexpected benefit?) regards, max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Novelty: autmatically assigning unique integral type ids
by Jonathan Turkanis 06 Dec '04

06 Dec '04

Hi all, Attached is some non-conforming code which automatically assigns a unique integer id to an arbitrary type. It's based on this post by Daniel Wallin: http://lists.boost.org/MailArchives/boost/msg69842.php Example: #include <boost/static_assert.hpp> #include <boost/unique_id.hpp> int main() { BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(void) == 0); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(bool) == 1); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(char) == 2); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(void) == 0); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(bool) == 1); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(char) == 2); } Obviously the ids assigned will be different depending on the order in which types are passed to BOOST_UNIQUE_ID. It's a novelty not just because it's non-conforming but also because after assigning ids to about fifty types it slows down to a deadly crawl, and maxes out at about 110 types (on VC7.1, using over 300MB RAM). I tried several forms of loop unrolling, and they don't help much. I'm posting this now because yesterday I figured out how to make it work on EDG (except for Comeau). It now works on VC7.1, VC8.0 (beta), GCC 3.2 (MinGW), GCC 3.4.1 (Cygwin), Intel 7.0 and 8.0 for Windows (in strict mode), and on the preview of the Borland EDG-based compiler I downloaded about half a year ago. I still need conforming-compiler workarounds for Comeau and Metrowerks. ;-) Best Regards, Jonathan begin 666 unique_id.zip M4$L#! H``````'%R@S$````````````````/````;&EB<R]U;FEQ=65?:60O M4$L#!!0````(`!AP@S&5>-46[ ```+(&```7````;&EB<R]U;FEQ=65?:60O M=&5S="YC<'#MTT]/PC 8!O![DWZ')ERV"SB4?T%,4#GL`M&-<U/6RIJ4%M?6 MB_&[.SM%PHEW5^AQW2_/F_1Y.U(7RG-![C?&6->SCCE94&:MJ%RWW.\?,.J< M_..U?/>"2OY[CY'4CNR8U%&,T2=&I#Z/JU66TRR?Y^D3G6?9XC6/FF_K9?JR M7M#T.?HPDL=D-B,W\?1\50^A@DH@JBA9%50?HJS<:L')`=]"L->G_ Z479K* M!39HE?KOAQ!?OV5 HU:A?WH,T<KH;5"35ID'GH!Z]*8,:X9-0$WBQF^4:""H M3#]SDF,-:M-U6:[+<O'+\H71-U!+`P0*``````"<<H,Q```````````````` M!0```&QI8G,O4$L#!!0````(`$-O@S'*X)&D;@,``*,+```3````8F]O<W0O M=6YI<75E7VED+FAP<*5638^;,!"]K[3_8:1>8)M"4O7D4J0V&ZFI*K95V%XM M+PR)56*H,=VF5?][;2"$+!\;J3XA_&;FS;-G/*X+UM*&998?)-_N%'S*!%,[ M)B LY7<F> &OY_,WSO65Z\(M+Y3D#Z7"&$H1HP2U0_B0986"39:H1R81/O,( M18$S^(:RX)F A3-WP-H@`HNB;)\S<>!B6SE,>*H-ULM5L%G1!9T[ZI>"3$*D MZ0!3L%,J)Z[[^/CH/)@H3B:W[A.\8U]?'=E%*>-[E 2"3 %KF*7\03)Y< SL M!4\T[P0^W-UM0GH?K+_>K^CZEG[\\H6N@^7G^]O5K49I"!?X#,IX$U%:Q@A> MQ<Z-,I'PK;/+<[^_N<]3%W^RE/)D`L%C%(JKPQ1$J(G=G'$YLJT..5(E&5>% M&Z-B/'4/6%"14;-S@1$OZ,^,QR/(4O%4,W=1L(<43VF.ZFF%-A!2&1-2"OZC MU%:Q!R'XA)BXA&B]2C0N!-MCD;,(H<+#G_.?=3KF+_37]95"+0U3Z!FOQ@I" MMM74.LD1TN(a)`+1.ZPS1':6GL#!S'L=^:H .^M"==&&6D.K9<HXY\!L//0!\D M!'X-:>WW3'[7Y=7)I%9M$[X/UTNZO OT5Q!:1H=T!I5 \.X\[X+_QBRQAA*Q M[!E8F(a)TA.CKU`O_&GMMV7[9WPRZ'!+/!"',$FC^FPJH8AB/U*HY^M=,`_U9* M5O">-/<S:+^?J"/PEZ)#$AV#'@W[^51TFO+S!F])J[UWDF?NSR!H;J$_&S:K MT4W9CKAN<:8Z)S MKCZ<)C+<P.NQZ'VKN3^.'-F:3&U:-+,&A%M<()Q9EXK7 M8B\0L,7V1(27L'A.R'/KQ8289DUI?7':IJ>.G4S_=],;06)1IFJ@\OZK")H6 M[]7>QW(X*T3/E.R X$;LZ:O5*M!$&T]VN'<\2?@IK;!+:^ZWSLZEZWFI=PE) MN-0/S?CJ<!KU4:">">()'VS[]MCBF.*1GGR$#FI>AJ:S0^<AG.B:]7M6.ZIZ M98QZ&))($\E1##9+$Z23@UD-^*S+FQ&ADNT$&WXA3UI;-?=7AE5#W79U#[NQ MGS_#<]Z>%J@]MK/%M4Y,WQZF,JF]U1[_@IX#5SH#XRHO3I.!<_G+7?,BG71J M%YT1I7K<O= _-KC:Y \,D*C&DZ(>6NH)5&?%$P.Y;!:]OOH'4$L#! H````` M`)ER@S$````````````````&````8F]O<W0O4$L!`A0`"@``````<7*#,0`` M``````````````\````````````0`````````&QI8G,O=6YI<75E7VED+U!+ M`0(4`!0````(`!AP@S&5>-46[ ```+(&```7``````````$`( ```"T```!L M:6)S+W5N:7%U95]I9"]T97-T+F-P<%!+`0(4``H``````)QR@S$````````` M```````%````````````$ ```$X!``!L:6)S+U!+`0(4`!0````(`$-O@S'* MX)&D;@,``*,+```3``````````$`( ```'$!``!B;V]S="]U;FEQ=65?:60N M:'!P4$L!`A0`"@``````F7*#,0````````````````8````````````0```` @$ 4``&)O;W-T+U!+!08`````!0`%`"H!```T!0`````` ` end

5 11

[thread] SunPRO: test_mutex hangs when run via regression.py
by Caleb Epstein 06 Dec '04

06 Dec '04

The Boost.Threads test program test_mutex, when built with the SunPRO C++ compiler, always hangs when I run it on a Solaris machine under regression.py. The same binary finishes in short order with status 0 when run on the command line, but under regression.py it never exits. If I attach to it with the debugger, or with strace or truss, it finishes successfully. I'm unclear what could be going wrong here and expect it is either a bug in the code produced by SunPRO or a really subtle bug in the test program. Perhaps someone could take a look? I am stumped. Here's the output of a program I found called "thrstack" which produces a stack trace for each thread w/o attaching to it: status for pid 13551 (6 LWPs) -- LWP 1 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23da10: libthread.so.1:_reap_wait_cancel + 0x40 ff23fc9c: libthread.so.1:_thrp_join + 0x344 ff33d0d8: libboost_thread-sw-mt-d-1_32.so:void boost::thread::join() + 0x18 000334a4: test_mutex:void __unnamed_lpburfiEtB2zM::indirect_adapter<void(*)()>::operator()()const + 0x44 000333b4: test_mutex:boost::detail::function::unusable boost::detail::function::void_function_obj_invoker0<__unnamed_lpburfiEtB2zM::indirect_adapter<void(*)()>,void>::invoke(boost::detail::function::any_pointer) + 0x1c ff330748: libboost_thread-sw-mt-d-1_32.so:void boost::function0<void,int>::operator()()const + 0x78 ff33cd4c: libboost_thread-sw-mt-d-1_32.so:thread_proxy + 0x44 ff24b01c: libthread.so.1:_thread_start + 0x40 ff33cd08: libboost_thread-sw-mt-d-1_32.so:thread_proxy + 0x0 -- LWP 2 -- ff19eddc: libc.so.1:__signotifywait + 0x4 ff23e950: libthread.so.1:_dynamiclwps + 0x1c ff241c2c: libthread.so.1:_thr_yield + 0x8c -- LWP 3 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23ada0: libthread.so.1:_mutex_adaptive_lock + 0x160 ff23aab4: libthread.so.1:_cmutex_lock + 0x84 ff141cd0: libc.so.1:malloc + 0x18 ff136174: libc.so.1:calloc + 0x54 ff243e2c: libthread.so.1:_thr_setspecific + 0x38 ff2e54bc: libCrun.so.1:__Cimpl::ex_thread*__Cimpl::ex_thread::get_thr_data() + 0x118 ff2e4160: libCrun.so.1:__Cimpl::xstack*&__Cimpl::get_cur_xptr() + 0x4 ff2e41b0: libCrun.so.1:void*__Crun::ex_alloc(unsigned) + 0x14 0007c338: test_mutex:int boost::detail::catch_signals(boost::execution_monitor&,bool,int) + 0x310 0007ac38: test_mutex:int boost::execution_monitor::execute(bool,int) + 0x28 00076e40: test_mutex:boost::unit_test::ut_detail::unit_test_monitor::error_level boost::unit_test::ut_detail::unit_test_monitor::execute_and_translate(boost::unit_test::test_case*,void(boost::unit_test::test_case::*)(),int) + 0x60 0005c1b0: test_mutex:void boost::unit_test::test_case::run() + 0x498 0005cbc4: test_mutex:void boost::unit_test::test_suite::do_run() + 0x7c 0005c3e0: test_mutex:void boost::unit_test::test_case::run() + 0x6c8 00062208: test_mutex:main + 0x458 0002cbb0: test_mutex:_start + 0x108 -- LWP 4 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23ada0: libthread.so.1:_mutex_adaptive_lock + 0x160 ff23aab4: libthread.so.1:_cmutex_lock + 0x84 ff142b64: libc.so.1:free + 0x18 ff2e6260: libCrun.so.1:void operator delete(void*) + 0x4 00031c24: test_mutex:__SLIP.DELETER__H + 0x2c 00031ba0: test_mutex:void boost::detail::sp_counted_base::destruct() + 0x40 00030a5c: test_mutex:void boost::detail::sp_counted_base::weak_release() + 0x6c 0002f9cc: test_mutex:void boost::detail::sp_counted_base::release() + 0x8c 0002f6ec: test_mutex:boost::detail::shared_count::~shared_count #Nvariant 1() + 0x24 0002ef58: test_mutex:boost::shared_ptr<boost::basic_wrap_stringstream<char> >::~shared_ptr() + 0x10 0002e540: test_mutex:boost::test_tools::extended_predicate_value::~extended_predicate_value() + 0x10 0002e2dc: test_mutex:bool boost::test_tools::tt_detail::equal_and_continue_impl<int,int>(const __type_0&,const __type_1&,boost::basic_wrap_stringstream<char>&,boost::unit_test::basic_cstring<const char>,unsigned,boost::unit_test::log_level,unsigned) + 0x37c 0002d6ac: test_mutex:boost::xtime __unnamed_lpburfiEtB2zM::delay(int,int,int) + 0x10c 0002d110: test_mutex:bool __unnamed_lpburfiEtB2zM::execution_monitor::wait() + 0x20 ff25c000: libthread.so.1:?? + 0x0 -- LWP 5 -- ff2491fc: libthread.so.1:private___lwp_cond_wait + 0x4 ff238998: libthread.so.1:_co_timerset + 0xa0 ff24b01c: libthread.so.1:_thread_start + 0x40 ff2388f8: libthread.so.1:_co_timerset + 0x0 -- LWP 6 -- ff19c980: libc.so.1:__door_return + 0xc ff2467c8: libthread.so.1:_sc_door_func + 0x54 ff23a358: libthread.so.1:_lwp_start + 0x18 ff241c2c: libthread.so.1:_thr_yield + 0x8c -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

variant==dependent pair, dependent function possible?
by Larry Evans 06 Dec '04

06 Dec '04

IIUC, the variant library is similar to a "dependent product" which can be thought of as a pseudo_pair<Index,TypeList>. where an instance: pseudo_pair<I,T> dpIT; is a pair of values (i,t) where: I i; T<i> t; IOW, there is only one value, but it can be one of many types depending on the valid values of I. BTW, would variant be made for readable by making variant take an enumeration: enum I{i0, i1, ...., in-1} as the discriminator? Anyway, back to the original question. Is there any interest in a "dependent function" where: dependent_function<I,T> df; where: T<i0>& df<i0>(); T<i1>& df<i1>(); ... T<in-1>& df<in-1>(): IOW, this would be like a regular struct (a record type), however, instead of: df.ix there would be: df<ix>(); BTW, this idea comes from Nuprl: http://www.cs.cornell.edu/Info/Projects/NuPrl/nuprl.html and I've recently had a need for it because I've got a template which is specialized on an enumeration; hence, this would come in handy if I wanted to have a structure containing all instances of the specializations.

1 1

Unexpected behaviour of boost::filesystem::equivalent
by Daniel Krügler 06 Dec '04

06 Dec '04

Hi booster, its quite a long time ago since I could follow the threads here more thoroughly :-( , so the following information might not be new one. During tests of the current Win32 implementation of boost::filesystem::equivalent I observed that the function unexpectingly fails (my test environment was Win XP SP 1 with MSVC7.1) if it compares a "soft link" created via the DOS command "subst" (or its API analogon ::DefineDosDeviceA/W) with the corresponding mapped path object (Lets say I map M: to the existing directory C:\temp). To get an understanding of the test failure I debugged the implementation and found that actually the first test part (getting the handles and comparing the VSN's + further data) gave the expected positive result, but that the very last step, i.e. the comparison of both st_dev values, gave a final unequality. Did others also observe this failure and don't you think that the expected result should show the identity of the underlying path objects? Of course there might be legitimate arguments for the decision for the current behaviour, but I would like to know about them. I am not an expert to argue about the comments in the source code which say that "In theory, volume serial numbers are sufficient to distinguish between devices, but in practice VSN's are sometimes duplicated, so device id is also checked.[..]" The question now is: Should different (MS DOS) device names pointing to the same underlying (Windows NT) device not be compared equivalent? I could think of the following test extension (at least under Windows, regrettably I am not a posix expert to provide a similar solution): If the VSN' and further data have returned a positive result, but the check of both st_dev values fails, one should try to check whether the underlying devices are actually the same, e.g. using the ::QueryDosDeviceA/W API function. What do you think? Greetings, Daniel Krügler

3 8

3D logo
by Joaquín Mª López Muñoz 06 Dec '04

06 Dec '04

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

! Wiki Spam
by Christopher D. Russell 06 Dec '04

06 Dec '04

I just found the start page of the Wiki completely replaced with xanax drug spam. I removed the offending content and left a note in its place. Sorry - I'm not sure where the original content is archived or I would go fix it myself right now. Perhaps we need a password mechanism on the Wiki? This seems to work well over at http://www.program-transformation.org/ where you need to register and login to edit. - Chris

7 14

[Review Results] Named Parameters Library
by Doug Gregor 06 Dec '04

06 Dec '04

The Named Parameters Library has been accepted into Boost. Congratulations to the authors, David Abrahams and Daniel Wallin. The vast majority of reviews were positive, although most reviewers requested additional documentation. Here is a list of the most important/commonly-requested changes or additions to the library: - More documentation! Specifically, + Automatic overload generation should go into the tutorial + Document operator, + Performance data (what's the cost?) + Reference section + "Best practices" section. - Add a metafunction for getting the type of a parameter, e.g., param_type<Params, width_t>::type. - Add test cases for the automatic overload generation macros. - Fix the BOOST_NAMED_PARAMS_MAX_ARITY bug; Cromwell Enage provided a solution. Doug Gregor Review Manager

2 1

Anyone interested in a virtual constructor lib?
by Roland Schwarz 06 Dec '04

06 Dec '04

As a byproduct of my current work I factored out a small utility library that implements a virtual constructor. The implementation is based on boost::any and typeid(...).name(). It features dynamic creation of objects by name (string), and allows for default and custom constructors beeing called. It could be used as the basic step to object deserialization from a file, creation of operating system dependent implementations, or allow a library to instantiate user-pluggable classes. The design is inspired by the Io_obj example from Stroustrup's book on C++ programming. A small example to show the usage: #include <string> #include <iostream> #include "dynanew.hpp" using namespace dynanew; // a simple class hierarchy with abstact base class struct shape { virtual void draw() = 0; }; struct square : public shape { virtual void draw() { std::cout << "I am a square" << std::endl; } }; struct circle : public shape { circle() : radius(0) {} circle(double dr) : radius(dr) {} virtual void draw() { std::cout << "I am a circle of radius: " << radius << std::endl; } double radius; }; // create the type map TYPE_MAP(shape); // square with default constructor TYPE_REGISTER(shape, square); // circle with custom constructor taking a double parameter TYPE_REGISTER1(shape, circle, double); // circle with default constructor TYPE_REGISTER(shape, circle); int main(int argc, char* argv[]) { std::string type; type = "square"; shape* ps1 = dynamic_new<shape>(type); shape* ps2 = dynamic_new<shape>("circle", 20.0); shape* ps3 = dynamic_new<shape>("circle"); shape* ps4 = dynamic_new<shape>("square", 10.0); if (ps1) ps1->draw(); // prints: I am a square if (ps2) ps2->draw(); // prints: I am a circle of radius: 20.0 if (ps3) ps3->draw(); // prints: I am a circle of radius: 0.0 if (ps4) ps4->draw(); // does nothing since no ctor available delete ps1; delete ps2; delete ps3; delete ps4; return 0; } regards, Roland

5 14

date-time out of whack?
by Victor A. Wagner Jr. 06 Dec '04

06 Dec '04

The program that causes this error used to compile (until a few days ago) I'm using the cvs HEAD c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(326) : error C2664: 'boost::implicit_cast' : cannot convert parameter 1 from 'const std::string *__w64 ' to 'boost::mpl::identity::type' with [ T=boost::detail::operator_arrow_result,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::value_type,boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference,boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer>::type ] Conversion loses qualifiers c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(325) : while compiling class-template member function 'boost::detail::operator_arrow_result::type boost::detail::operator_arrow_result::make(Reference)' with [ ValueType=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::value_type, Reference=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference, Pointer=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer ] c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(642) : see reference to class template instantiation 'boost::detail::operator_arrow_result' being compiled with [ ValueType=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::va lue_type, Reference=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference, Pointer=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer ] c:\boost\include\boost-1_32\boost\token_iterator.hpp(41) : see reference to class template instantiation 'boost::iterator_facade' being compiled with [ Derived=boost::token_iterator,std::basic_string,std::allocator>::const_iterator,std::string>, Value=std::string, CategoryOrTraversal=boost::detail::minimum_category::type>::type, Reference=const std::string & ] c:\boost\include\boost-1_32\boost\date_time\date_parsing.hpp(119) : see reference to class template instantiation 'boost::token_iterator' being compiled with [ TokenizerFunc=boost::char_delimiters_separator, Iterator=std::basic_string,std::allocator>::const_iterator, Type=std::string ] c:\boost\include\boost-1_32\boost\date_time\gregorian\parsers.hpp(24) : see reference to function template instantiation 'date_type boost::date_time::parse_date(const std::string &,int)' being compiled with [ date_type=boost::gregorian::date ] Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

6 12

Boost.FileSystem, problem with exists()
by Martin Slater 06 Dec '04

06 Dec '04

Hi, I've been using boost.filesystem and have come up on a problem with exists(). Basically on a windows system it will return true if asking whether a file exists on a non-existent share. The problem is at, operations_posix_windows.cpp:327. There should (?) be an additional check against ERROR_BAD_NETPATH as well. The fuzziness of this function is quite disturbing as shown by the following comment in the code return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) The windows docs don't really help that much by not specify exactly what the failures can be though. Personally I think it should always return false on GetAttributes() error to avoid false positives and the expense of the possible false negatives, but we need a list of all possible errors to be sure that this is the right thing to do. Oh and any chance you can put in serialization support for boost::filesystem::path? I've done it locally and the code is trivial but it would be nice to have it out the box. Anyhow, thanks for a great library (filesystem and the rest of boost). cheers martin

2 2

A few more filesystem documentation corrections
by Edward Diener 06 Dec '04

06 Dec '04

Here are a few more grammatical corrections to the excellent filesystem documentation. Default Name Check mechanism Dangers second sentence: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function can be set only once, and only before the first use." should be: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows that the default name check function can be set only once, and only before the first use." or "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function to be set only once, and only before the first use." Rationale Const vs non-const returns last sentence: "A requirement that path::iterator not be a non-class type was added to eliminate errors non-const iterator errors." should be: "A requirement that path::iterator not be a non-class type was added to eliminate non-const iterator errors." or better: "A requirement that path::iterator be a class type was added to eliminate non-const iterator errors." Finally, in operations.hpp, links on "class directory_iterator" and "other functions" to their explanations further down the page do not work using IE, Netscape, or Opera, so I imagine some HTML error.

2 1

Filesystem documentation error
by Edward Diener 06 Dec '04

06 Dec '04

The documentation to filesystem is outstanding. Congratulation Mr. Dawes ! I did find an error, however. In the class documentation to path.hpp there are two default_name_check member functions. In the specific documentation for default_name_check, there is only a single default_name_check mentioned and the return value in the declaration of the specific documentation has 'void' even while the "Returns:" says otherwise and correctly matches the return value given for either one of the default_name_checks given in the class documentation.

2 1

BOOST_FOREACH questions
by Vladimir Prus 05 Dec '04

05 Dec '04

Eric, I've some questions about BOOST_FOREACH (which is pretty cool, BTW). 1. Is it possible to use typeof on gcc, to avoid any possible overhead? While you've posted some results which show that gcc generally can optimise it very well, I'd like to be 100% sure). Something like: #define FOR_EACH(var, container) \ for(typeof(container.begin()) _for_each_i = container.begin(),\ _for_each_e = container.end();\ _for_each_i != _for_each_e; ++_for_each_i)\ if(bool _for_each_continue = false) {}\ else\ for(var = *_for_each_i; !_for_each_continue; _for_each_continue=true) which works perfectly for me. 2. Any chance that BOOST_FOREACH((pair<int, int> p), container) will work? I don't know how to make it work without require paranthethis in all cases, but maybe there's a smart trick. 3. Is it possible that you place this to sandbox, for easier access? - Volodya

7 31

[Boost-bugs] [ boost-Bugs-1079444 ] type_traits headers use #include ""
by SourceForge.net 05 Dec '04

05 Dec '04

Bugs item #1079444, was opened at 2004-12-05 08:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1079444&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: type_traits headers use #include "" Initial Comment: The various type_traits headers (as of boost 1.32.0) use #include "" directives while the rest of boost headers uses #include <>. For example the use of #include "" in boost/type_traits/ add_reference.hpp compared to the use of #include <> in boost/ mpl/bool.hpp . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1079444&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Deserialization issue
by Jared McIntyre 05 Dec '04

05 Dec '04

I have a class that I am serializing using the non-intrusive method. It serializes just fine, but when I code the input stream, the compiler complains that the class doesn't implement the serialize function (which is, of course, true since I'm am doing the non-intrusive method on this class). Any idea what could be going wrong? The class I'm wrapping is being serialized as part of another class (if that helps at all). Visual Studio 7.1 Boost 1.32.0 tar ball Wide character XML output Jared McIntyre

2 7

Front page redesign...
by Rene Rivera 05 Dec '04

05 Dec '04

Fellow Boosters, Well I must say I've been smiling all day :-) Thanks for the encouraging feedback. And I've been putting finishing touches on my design hopefully coming up with something everyone can enjoy. I have two different sample for you to gander at. The first is the simple clean version... http://redshift-software.com/~grafik/boost/index.htm The second adds some background flair to the page... http://redshift-software.com/~grafik/boost/index_code.htm And for those with CSS switching browser, there's an alternate CSS on each of those which displays the page without any CSS. Just to show that everything is done in thee CSS ;-) Enjoy. Have a good weekend, and all that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

17 64

[1.32] SunPRO build failures
by Caleb Epstein 04 Dec '04

04 Dec '04

% CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-20 2004/03/19 Sorry, I should have been testing this toolset earlier in the release process, but now that the official 1.32.0 is out and I've tried building it with the crufty old Sun CC, I've encountered a handful of errors and perhaps two valid warnings. The first is in date_time. It appears that Rogue Wave's std::locale::facet has an undocumented abstract virtual method __get_id. Attached is a patch which adds this method when building with SUNPRO_CC and RWSTD. This may be better done with some BOOST_* config macros, I'm not sure. There are several other errors in filesystem, program_options, serialization, and signals which manifest themselves as errors resolving overloads of iterator_traits. I'm attaching the output from my build as I'm unsure how to address these issues. Also, in archive/impl/basic_xml_grammar.hpp, the compiler warns that the StringType typedef is not accessible from the public interface of basic_xml_grammar (e.g. in the return_values struct). Making this one typedef public fixes this issue. Finally, the compiler warns about the "static" being anachronistic in boost_1_32_0/boost/smart_cast.hpp, lines 264 and 292 (the free functions smart_cast and smart_cast_reference). I think the compiler may actually be correct - what purpose does "static" serve here? I know this is a crufty toolset, but this code (at least date_time and filesystem) used to build with 1.31.0. -- Caleb Epstein caleb dot epstein at gmail dot com

8 28

"Expect" exactness from your input
by Daryle Walker 04 Dec '04

04 Dec '04

I added a file "iomanip_expect.hpp" to the Sandbox CVS. It provides manipulators to read an exact string from an input stream. This gives functionality from std::scanf that C++ I/O never had. Changed files "iomanip.hpp", "iomanip.html", and "iomanip_test.cpp" give additional tips. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Questions re Jamfile for testing
by Robert Ramey 04 Dec '04

04 Dec '04

I've been making adjustments to the serialization library to permit it to be used as a DLL and I have a couple of questions. As an example, I looked at the Jamfile for testing the filesystem. It contains: test-suite "filesystem" : [ run libs/filesystem/test/path_test.cpp <lib>../../../libs/filesystem/build/boost_filesystem : : : <define>BOOST_ALL_NO_LIB=1 ] ... a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation of the libraries. Is this correct? b) the requirements included <lib> ... but not <dll>. Does this test Jamfile EVER test the dll version of the filesystem library? Now suppose the test is built with runtime-link/dll . I believe that would indicate that the msvc dll version of the C++ libraries will be used and the compiler will compile code accordingly. On the other hand the <lib> above suggests that this test should be built with static linking. This raises a couple of questions: a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used? By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used. Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries. c) ideally, if we had nothing but time I would like to be able to test all combinations debug/release <runtime-link>static/dynamic, <filesystem library>static/dynamic. What would be the most convenient way to do this. Robert Ramey

3 6

Intel toolset / library names
by Stefan Slapeta 04 Dec '04

04 Dec '04

I've just found out that there is still something wrong with the intel configurations (also in 1.32). The libraries (I build them using bjam stage) have the name "....iw81...lib" but the names referred to by auto link are "...iw...lib". One has to rename them manually. I got the feeling that the Intel toolsets should undergo a substantial review anyway; I hope I've enough time to do that one day (any other volunteers?? :) ) Stefan

4 11

Autolink: Override compiler?
by Stefan Slapeta 04 Dec '04

04 Dec '04

Hi, is there any way to override the compiler autolink uses to create the import library names? This really makes sense when compilers/libraries are binary compatible (e.g. Intel+VC) and could save 100 MBs of disk space! Stefan

2 4

Wait for multiple boost::condition(s)
by Steve Hartmann 04 Dec '04

04 Dec '04

I am about to port some Windows code which does a lot of WaitForMultipleObjects(), waiting for several signals at a time. I was wondering if there was some way to wait for multiple boost::condition(s) at the same time. Thanks, Steve

3 2

Logo: And now for something completely different
by Jonathan Turkanis 04 Dec '04

04 Dec '04

Hi All, I've posted a new logo on the Wiki under the "abstract" category (attached). I'm not sure it's a good candidate itself, but it may give some ideas for new directions. Jonathan begin 666 logo16_4.gif M1TE&.#EA.0%D`.8``````/___P!4I@L!`Q,!!1T'&B(-)%E76RXB/W-NBF=C MA#0R89B8P%17A#U'ACY%<G>"J&EZLT!&63Y5F%=OL3]?JTIDIU)LL%)KJ5YV MM6B O7"$MTMJLWB-N7",P'N6OG27QE-\L'>?R@%5IQ%?K2URMU6-Q6>9RWV@ MQ8NPU<W=[46#OT9WHV"*L6>.LMWI\RE=@5R(IKG,V>_U^4^ H&&,J%:&H4=[ MEF:1J*.WOD)TA$Z$EHBFK9BPM#IL<7*=H5&$?V.5CUZ6@D)$05I3,G9J8Q04 M% T-#0<'!P,#`P$!`?___P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````"'Y! $``$L` M+ `````Y`60```?_@$E(@T>%AH>(AH.+28V-2I `DI.4E9:7F)F:FYR=GI^@ MH:*CI*6FIY*+B$:LK(F(BTB.29!*J+>XN;J[O+V^N(2%K</$KK",CI&_R\S- MSL_0MTB%/M750$ [VMC</MS?0D'B03CB/^?HZ><\/SSN[_ \/?(]]?;W/3GY M.?S]_O__)@482+"@P8,($RI<R+"APX<0(TJ<2+%B@$F&?,"XAFV'D&S?0F+[ M&(Y<D',FU:U;QR[>NWGUZ.';EX\FP)O^DDBRR+.GSY] @PJ%B)$:1R!"M'G< MP8VDD*=/N8TCIU)=2Y?PYLF<64^?5W[[</J3D<,6@*%HTZI=RY9GT2/6_[Y- M18H4JMT@)8/LF#I.'8Z_.&H`!OP#QU687&M^#2L6H,"VD"-+GOP3(ZMJ.IKJ M#5+7+E2^H*?:L!'#!@W3-%*?#F$C1(P6KUNX</'AQX>M714S;NQX)^7?P(,+ MMVSDZ,>IGI_R+8GCA\G1.VY(GZZ:1HC3K4F[CO$Z]NS;6[W:Y-V/; Z=9X6K M7\]>*/&-F:6*2YX7^3@<T*?KI[X:>VGNKK4@8&P"=N!.;F"1=Y,,C[7GX(,0 M,D2<1CI46"$V>-T%6EXUV! ="].!*"*(_+&V'7>PI2C@B@*Z8" /^H2U&WD- M1FCCC0Z^AYF%V7AFSCAY91/=?B32P$)UJD67&O]IK]50`XM0MDC;!S+Z,^-- M->*HY9:330B#A3HHT%%]H7UT@PXAZH?DDDN.5AV3`C[YI NRT6GG=[C=DX(] M*>30IY]^FL7EH(2RI:,./B#JS9@GA99-A?M1=\.;I_W'W:6CC<;=G'?.1B>+ M)GR 0@\HE&KJJ:B:BEZAK+9:F21'7(:9-_$IM1Q>0(")IG1%3HIDIII>&H.3 MPE[*:90MA*!L""U\T$$'&WBP0;34>F#MM1YDZ>JVW$H(JZR(`K$H2-$MI^NN M:OJJ&K#%#NNDDX&Y4,.PPK(8P@HA<*#OOAIL`.VS``<,\ ?:=FOPP1=]6]RL MW"@UW5YFGJL#B=+1H*[_:9FV^ZZ3GM;@*6P`TG#!OB3OFT&_`C_K+ ,=,/#! M!ZOVE,+,--=L<\TRR# #PCS[-.$UXS(5785+28QNQ>IBIRF3&V^,@PM//[VB MLA=88$$%5Y?,`047G-PR`V"'S;+8!4LDP-EHIZTVVB.T/8(`*Z3P0L]T1_2S M#P>(V]&09QIMH7Y*IK8#L$RZ^^Y@?\D[=0@C[ULU!A9@<,$%%%2>`049^"OV MYF&7'=':H*_]MMHKJ%#WZ0O=K;>0TEGXI=&1"DYXX88'9OO3BB?;. <C3U[Y M[Q1@`'P&Q#_+^>:>0Q3Z\LR/D +JT!MT=]!#5PC#]7Y3MP,-(a)\]N[.&(M_"D M_[+[2D[Y[\2G?SGPEAM_/-B"]L3\_* ['_W]Q$D0%Q#2#:G#]=B36/^X1T / M`6M>34.<DY*5+PM<P'SHRT $B#=!"5IP?;^#P/O@YQN>T.^#;!N!#.X7F9N9 M, 4C]!FL8F6-1.G ?_\#X.MT!3AM&)!PFP+?7^1$OL@]T'(3C( 0@WC!"U:0 M>!2(@ :/E[R'@/")`BC!SDC(EA70SWXJ!$"LX,(1_]U A@&DX0VVMSVE'1!> M@@',NV*0+PY@0'*62Z($ATC!(=*Q@D>,P 88L$2R== B4'SB\ZBX%BO2;Y ] M*<K":(4FUX%18M%1"O<(5X,@Z'"'3E)6Y-YHN3G:\?^3GYSCR4:I`:\=+WX> M#.0'24#(0GX0D6Y9(1<3U3?K@7&&?]-&`7'(I-FEA@4LJ$ %.&"!3H+RF';4 M0 24R4Q29N!KR/MC150)PA2V<BB&G!\L+?*6:^S*EH\\5_^4TKW1= @U1C(2 M,(,IS'9N$IGP7*8\EZF!>I*R7YQKHD.H>4417!,MV63>-BNB2!<V,H:W%"<Y M9^>A7Z[SH>V,*-;>^$8E(G,#=IP6,YE)3WMJX -@RP'8]-D0?M)O!?_$YBM? MI45J0,J1"043_\(a)XN.X-3IWK# %$)8HUJ[E1>'.$(a)$7U*,1I+1.C&ZAG1SU: M2@^(K2S2I @(43H#&91@=//_BX@,1+""$J2M!'&S)D^VVM6OAG6L*2@KVDBP M`A.DP'0.">CR!DJ124P#+F"Z)0"MD4NEW'![#PTL.WEJ-0NX<7*<E*!0,:K' M:3G6J$E5:CTG.UF0BI0!,4OE20DR`Q)\<&X,F4$*2-"VT+6-!"F8HD1$2UJL MJNVTJ8W("T1 6OJ5(+8+D6OHZ#H1NQ;B7'I]``*&FZB9VK![.!7L.@GK4Q_Z M\(<2="P$'DO=?D66LM@-*0-(RI"I%N0$5Q0K0F3@V2>B5B+DA>)Y'9("`;AV M?B,@@7@'PM45E'=^8%U!W+B9BD%\Z;]ZW0@""( `6A+0AA9;YPV4*\P)5,#! M/8W<_W,G1^$'%G6ZU,VP=;%+6:<R`*KIT>S\4$J0]L)WOM_EYPI4RQ#P4G/% M"YF!5U79MA,<1+<@Y*U#[#H-"@7X2SX8;H''Z%</*3>P/(TP,1'[P I3.+H9 MCG)2K\MARZ(2D!\D\4!D\%[0Z=C%_)1B0\!,33$C1,9=AJ*-"X+CE1*TOTC8 M"(!E"":^DO.F(P+F@G<*86$6%G)OK+#Y?$<Y*#L66HZ5UK2D)2T.:P`$8,LL MEC=+$"X?,B$F-FD4&9)IDY8@(2)(<R!AV>9+OQD`@D""1C023G&.TT-[UK-@ M(^K@PFXRT)(;]/DJ5VA_/<M?OD:THAMM+0Y_F+L+\6ZEW?]LD!?<5],Z=K:F MT3;0%TP[;: -0*FUR5]4RR(S",6E3(DLR5@?N9U]MAI%*>KDWU%NUTG<P'3_ M)6P/=,!:T?* !O2M[\E"&MD*4?:619TVNI)YVMDVR,$UG? `+-RD:]8V/W7< MD$DXXB.YVI$`[_PA!3,XW>J^M?ERS6OV80YS$0A8L/^5[T7S>]_[]@`*)#W- M+!>$RP0_6[6OG;:(%\3:/#^;SP/P[&N#=ML"[;8CD&(AC8][H0LV=YX?/(&J M^UG=@ XTA4W.OLME+F4`LS>V8@[S>LK\RC6G],!-79!0!_UL#0^ V]^>;16\ M7><#0?I<E2X(;/RO0AK/U0`1'/7_"4B=!1. 0=47_V=<Y_J')D=B^D)0/+ _ MR][0PA:_^TVPJ$Y$X &0`;,),F/FD<!TG=Z[04J_O-,'(/6[7?:E7X!T+.H] M]J=^Q$=TY?0Q<J^FR171@G60> <8WP%5Q_JZX2B\KDO^<I0GWLK#?N][7\L% MFK\6P!,"^A3DW+WBG<'W1^#/(a)=B$.*';_D#</[7TR_BHF_>^O,^^FXKH1&Y M.A=F?._7[4E]SU4'`\;W`,?7`!,@<IP4/)%W<AD0?<1#>2B3,LYR>=8W=OR& M=E+5?NY'/^)E:=PV$*RW/ ;A@4D'@A]48AQ($"_P?5I&?VP72P!0"_EG4& R M3C9D&K*F_V 3H /&MP`^N `$Z `&N'P*6(0,^(#J,WD9X"(=X"POHS)-*'85 M.'88^'D:J'<C<!"P!SK6='L)MX5KTX6?Y8+,(U9J1X8EF$B2((.P0S1D9$#F MMF<WD'@/\(,_2( 3T "W1DR&95B^<X1*Z(!>XX1-^(1.*';99RW;AQ "!X9J M8P('(0+A11!8*%:2>&*4.(D2MSQM8X8C9A"W1W%$L8;W!WABU#K'A8."M6 " MZ(-"A@`^^ `&:#5)YF=NA#E(F(0/V"^&6(B&Z $?D(@GD"V>9S:KI%^M!5\# M58F9B(G-V#QBZ(RUYXG,TX*;^(%J2 GY]S</@XJ9L@-'5G5UN/\`"% `Y@B+ M#_ `BU>+[?13R[=NN)@!P/@R]$B(P.@!(("/V5>%QGAW<(,0MQ>-V'B-9?B, M):AWL'2&!*EZV3@)U@,I-30DW?-0YE9\KE@`25 `Z&A\?99D'$!U>=@`(CF2 M(JEN%. O3EB/*GDM^8@M_/@Y_@AC!Q&"]2.0:1@`-"DZ-JEZM3=_"AF*+.60 M$+D?QQ5)";:*$^ `/X@`!E `!@"+"\"1'2E,'TEUQX=$&F )!DY$*"27ODR M^IB/PTB,(39I/'=;`0=?(F20#,E^:KF3N%=[)*!:/UE_IS8)9Q(I9#1)'M)Q M4O=@#@`#2SE<L8A\4XEN27F5QI>5C-G_``D``;[HE2 PF1^0CRU)EC[!<R1P M`BA6$!^TEFC8EI\)EUY&7Q\$B14!E%F$E['#?\"R`Q/S<0*HE';H@\<WE1^9 MF(I9@(VIAPV@`(\9F?0(`L,9EAYP`HMX$$%7`B(0=Y[Y0:2Y-@D)G6R)>X[X MB"P&$:K9D)*0)@]S8!ES)K-FE0,(A.EXFSQ5=;NIF+TYDAB0`(_9E9)9F96) MCRV9G ;ACR*0G00QFM59FOVIB0N)>R2(7W 5$=L)@Y- ,4BS2QEC,1. 9 ZV M>%<9A(8I4>JYGNS9GL )GQ @GU\YF98YC/CYG'=7`@=JHIP(F@,*H.;WEO\I MG0,Q`Z,F$0G:_VVLR:#K<D"JB"; 1&L6D(<AF916EYX:Z@`$F(ZRR*'PZ:%- MB (O0YQ2:IF66:(!ZH]SJ9P"FJ#^&9JXAY.!5 *="9!V65>5P*"3,BGEE"E! M@%,6L& /%J>V%J3K:*3KJ:1X^@`'T ![FI4=VJ3R":6"6IDB.IG(68PPZ8\" M,'1NF8)>ZJ*-.C_1J3:(Y'V!- (FX)PW5J:]50GZ<22^<D/F% /)5:17UWA7 MDV2ZJ9A)FJ=ZRJ=[VJ>_^:<>^C*#.J63B8]6^J***@`-UZ4M*J-7"HTQ2JF< M570@M%ZYQ:D280D48S$[FBD=TB&!E7ARJGP8P(YWBJ2N*@%Z>@"Q&O^KO]FD M@-H!I2(JHD*9A;JKD5J-`: ",G![`C!_[5H_+,JE,/JHPKIEGJ:I^FJLJ]F= MO)(TP!($-N DR54"5!=ARY>J&*JA>.JM$C"QX%JQXGH`"D"KM7JN(DJH(LJN MH)>3K_5I*LJ)DUIP)6M:)TMM!G&=S:.LF_J".-J=(/(K[/(NJCA8R8> D)-D MN]FM#S"Q0FNQ%ON;14"N3BJH@EJH('"H99EVGXB"5Y2?U/FO*#NL!6FU+-NR M)H5%,3N0,PL`(K(F!^0N;+1<$)9\RW<!JOJS>2JT0CL$1&NQ"G"T&@L!I@(" M**"N'XNHRJ.!ENJHO$JL6HMW6*NRQ7JU+?O_?:;EM6S&K'9SIFD:K<&R1NHD M459S@.LV.7;*JD$;M' [!')+!$1P`*5KL460NDC[F+:ZMWO+M""K@?'GC(/; MN"MKN+5KK[<K`+R57OPT7S=ZEY*P)F;T/8&A4X,58<I'83SEMDH:NJ(KNJ4[ MO:A[M$5 JY"YMZ+RNNOJMTXDNXSKN,"*K[0;O)QE`OR4I8\KL$+`$9R,1F3 M0VED).C64V\4I,Q7->VXJ@/XO'$;O4- N@)\NN"JND>+M.::MTSKM)D)OHP[ MG8)+OI*:N%NK$*-%3=MDOIU*">AT&OXA+/""'S_J3EB'=96C+^AVI^GXO]$[ MP"Y\`*FKNJN+M]OK_[K=^[09>(9V-WKCR\-;"KDSBKYA"HI _!"60+;!8CAI M5 /)VUP49<(CD\(5&K$L', N3+JF&\,QC+1X>RIZ*P(B,)FQ>X:S.Y!7=*\^ MW#QHS+Z8AJSSDW :W*R5$ -'TB:64CL[U,02]D!/W'R-(TS."[W2>\4"#,-: MO+H;X,5@S+UC'+5K]X(]#,D_S,8)07M0)%9Q'+F4@ -OPAK&XBYJ% (1U8=: MQ\>1PVO#Q+]O*P$`3,B%K,5VB\"G(@+<&\:-[*Z55EIF7+7!"K"Y&SJ[*XI: M*$CK"[;MR\EM0AJ%$\*!40.B3,*XAECPF $CP[_<"KH3.\BN3+I%0 2'?/_ M$G(J +&?8O#5DC&C,N[*5N3%(R[]<K.A:O.[ZI?]%S/]#Q(*N#&:^-SF3R* MFTRJUI'$>!P8;)2JMD9A<!0\%$4\5>.\V*S-VPS+X RH7KRWY P"M[P\+5C& M-WG&P;S.K[7&'\C1HH-(.^S(O:RX"BH)/U #`9W$3O,7L,$"D--<"/V'E;/0 M&1"DGKO"K&RZV\S-WKS%$_V8ID++81S&8NR]^P2^:4RX*5W![ZR3[2S/!0JI M(ILV+=C/1EP)/( #U]$:=ZQ#SGR+A<5D6W<^E_-&&8 !(RF$LIB.1!O4WCS4 M6\S%"7S42AW&+_FWZ/S (!V&54V-$QS/*81S-_G_<*13S#<9ME_-1@+M-%"3 M+#]UP@YT6%L71R% 4;T9KA4;U!(MP^4ZSF"<U'W]O>@\>EG--KLK5JM]-B*= MM5>]KQN(R_$LS#OFU2V=&IZLQ"T(a)TV4M/!.$`3]585P306W]1B&9E7-[`%8\ MP-T<W8?,Q:5"RRA0VN2<`AD=.BWHLE)=>[&MNXPMWEK;B?PZD-Z]U46<VY3@ M#CC 1B ,/HH3`J=L013@0&D=1]#7UITMDI]MND MU*$]PUVLU^0L`MK-U"5U MA3DVWO <U>X%QY/</*"E`M\'2^GMX)#JV.S '84C/H(Q&SB0+#1=.7;$-<8] M/.KCUIW=W!4KW;"<`+&<_[35C=T@`,8YL-V@HV7>+=676-@0+@`&\>-9&^2! MC38^Y]WSQ]7L/0GOX,S%(C[R,AM/HB] =>(ICC[QN--"R-S^/=>&'-K7B\BD M?> HI.-K<ULF\-IJ(U;>[;5L3K)2VSR(%.='?C8MJ-@J?7N,:J;M[0X_`"!- M$B=0,SZWB &(a)=#GOAMP-B$0-T.5>#JLO+N;6B[TU?-W7C=UGKN#=U:O@=W/] M-*,?-'0D+3KE1Z/O5Q"OS4JDIXP:OC;6V+[PX (!$AM/@CN4_4">)$1"-4$E M1P$A`.Q)R.*->;&4+MKD^J%'G>FE#0)]PB"<GFR>/(a)(LEG[SXWI$;EK;9.VF M9_\ZV5X_L"3$22=:`BIWJR0WW D`\/ #*B(^+3+BE-U\H,18OL[H*_[HG5VW M8DZN15W@-8[=")XS:'YMK*[J3\2XZFOP((3P+-;C4,2UGSDZ'/X.=$(@'O,Q M^5)HQX1A=(0^E!=]]]V8&5NW,E[RUFORB)S7S-[LSP[MYMR/BHJ:!>'P(-3G M-#_JS79W,C\0-W\V,ZL$+\$#'S @+#(;`I+QOY-1%^98S:0^T0<Y(SGR?PJ< M)U_4>+WL`(_C.>/R#=RK`X7J0>><8,]S<2>O5[1-I9Y5P@OT,3$/[%[T1I_K M&+#K&?58OS9EDT4M$4 !"C"NJ_OW@)^]U?T!61_P6S__\-/&G^;.<SKV[1,W M7LMY$&,/0F&K%0?"`Y_2(K)Q]+QCXO-N]],B@?7XH0F0L7_?H1H+J!MPZ=<] MF<TN`CF0,[&/^"9%K\=Z;7)^9OH,1;FO<#R'8GH>.HYM#_0P]'#/^5N31)]O M]Y8W@4_XH:8/^('O[YA^T3=N^(<?[6GICV8V7NG<>O[ZR.GKKS(V;7T>`)WU M\.W;]C#!`QVP(A^3ZR9.]XV580)#B*,/`:4O_5P,"!L=*(2%*"*((B @(BDR M,CF/,@"4`9:7F)F:EP*=GI^@H:*=)3.;F"DDHZN>)2JGF:FLK*ZPEC,FLZPG MMBJJNIVVPI3$`#T\/<G*/"XM_\XNS2TA'!<4UA'8V1L1&]V"@AWAXA\='^;G MY!$)$ GM[NX0$(*&A8GV(BB1DH_$POX!P (*()'"E#\5)01Z,F'P'T*%G1C^ M"R!+(<&#*P).W%2,DK*/R9A%BS:-PS4*&;)A\\:R`[APY-#)_!!O@[R;W6#2 M(X3/'B-&CO1!DJ&DTL93$$&56+&BD8RCEE)D!&;B*52*4W55A3HC14)=!!OZ MDR&"*:NKESH:`_GQ0S-HSDI62QF!KC:6W\3!+#?3'(IP*#[LW(F/YSU$CAX) M)6H4K>/'MEZD*/NU$XD5)PI"#B"9\J?+F<5>E7QBQ2]2*QQM7JU)+5N0;ITY MXT#;6O^&VRJYX17D06^YWWW-=7 1N+A@0X5[)F*$>*AB2?U82Y].O;KUZQ/5 M(GNMS&TS$W)1UE6I81M+#]YZCP,^,_#PXB &)S_L=)^D2-&QZ]_/O[]_2]IQ MUQ9)M,UUFUT1:%!>>=V@%XX'O<7$ETR!"3;<<2C$=X@BAS"G2"(IZ+,8=(W] M9^*)**9XBG;;L95##LF@T QMM1TXG@;:,-B@@Q ^^($'Z(!@CI 6NB!8?$@2 M$M]R((XX8GXJ1BGEE-9UI,0Q+BH#8P\?@$>C;;C1I>"".F[0HWHQG4.DD!4* M::0('RS"H2*+_%2?<_;Q4R*5?/;IYS]68ID,C(3V\**A7&K_\"5*-J:$XY@- MFHG>F1#^Z,&::F8(@@<N7$KG3W;B$Z)](^H)P)^HIJIJ`*YA26BA@\+(`P@E M<7"@C6/F6MZDO +9`9!"7AIGG4(6ZP*Q&7[:B%"EXEG4J:M&*VV*K6HY**(O M'LJ#!U_>&B:."6Z0JZ00EOMKI<$N,BRQG1);)SZE-OO(L]/6:^]^5FZIY:N' M'IKH;6#>ID$&`^NJH)D:]%KNI>5NJJZ[G%[Z+@J)#27O/E#>J_'&CP7Z(C+] M%IIM,C]VH*"WN.J*,+D+M[R(Q.[6V2Y0D=2<YW/V9<SQSCP/TQ&B'V4[<K8I MH.!@. ,?6/#2NGHP9LL-0QASG2> 9W!"PBF,FJ>(-\^[9\]@APV@E0`H8;;9 M5CYK91)LMWVVVI2\73;:Q)P=MUIX/YL$W'$/4/8`9K/]-M]X%V[XX8@GKOCB EC#?N^..01R[YY)17;OGEF&>N^>:<=^[YYZ"'+OKHI)=.>B `.P`` ` end

2 1

Initial bits of tr1/type_traits @gcc.libstdc++.dev
by Neal D. Becker 03 Dec '04

03 Dec '04

This post might interest some of you: Subject: Initial bits of tr1/type_traits Newsgroups: gmane.comp.gcc.libstdc++.devel

2 2

boost 1.32.0 program_options does not compile with VC7.1 + stlport 4.6.2
by Ralf Juergensen 03 Dec '04

03 Dec '04

Hi, when I compile program_options using VC7.1 and STLport 4.6.2 I get the following errors: <snip> ...found 672 targets... ...updating 14 targets... vc-C++ bin\boost\libs\program_options\build\libboost_program_options.lib\vc-7_1-stlport\release\threading-multi\utf8_codecvt_facet.obj utf8_codecvt_facet.cpp E:\work\CommonLibs\test\boost_1_32_0\boost_1_32_0\boost\program_options\detail\utf8_codecvt_facet.hpp(70) : error C2039: 'codecvt' : is not a member of 'operator``global namespace''' E:\work\CommonLibs\test\boost_1_32_0\boost_1_32_0\boost\program_options\detail\utf8_codecvt_facet.hpp(70) : error C2873: 'codecvt' : symbol cannot be used in a using-declaration </snip> when STLport is used, BOOST_NO_STDC_NAMESPACE is defined on my machine. and then the following code fails (from program_options\detail\utf8_codecvt_facet.hpp around line 70): #elif defined(BOOST_NO_STDC_NAMESPACE) typedef std::mbstate_t mbstate_t; namespace std{ using ::codecvt; } // namespace std #endif But STLport 4.6.2 puts codecvt correctly under std... Would be great if this can be fixed for STLport users :-) Regards Ralf

2 1

Support for MS embedded Visual C++ 4
by Ulrich Eckhardt 03 Dec '04

03 Dec '04

Hi! I'm currently porting our codebase to eVC4 and was wondering if someone already had done so. For the curious, the development environment is mostly similar to VC6, which the same compiler -err- features, though the C++ standardlib is even more limited (I won't even try without STLport, which already works). thanks Ulrich Eckhardt

2 2

casting smart pointer
by Dirk Gregorius 03 Dec '04

03 Dec '04

Hi, how can I upcast a shared_ptr? class Base { /* ... */ } class Derived : public Base { /* ... */ } shared_ptr<Base> Get( const char* pName ); shared_ptr<Derived> spDerived = *_cast<*>( Get( "Derived" ) ); // What do I need to write instead the * ? Depending on the passed name I like to upcast the returned pointer to a pointer to the derived class. I used a static_cast with raw pointers before. What do I have to use with shared_ptr? Do I need to enable RTTI? Regards, -Dirk

2 1

question re has_trivial_contructor type trait
by Robert Ramey 03 Dec '04

03 Dec '04

The documentation for has_trivial_constructor has some cryptic note: Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a class or struct has a trivial constructor; this is always safe, if possibly sub-optimal. What does this mean - it sounds like its of new use - then why is it there? Robert Ramey

6 7

Issue with G++ 3.4.3
by Curtis Spencer 03 Dec '04

03 Dec '04

Hi, I am able to compile a program of mine with gcc 3.3.4 with absolutely no problems, but when I compile it with gcc 3.4.3, I get this issue. Is there something I need to do when installing the boost library to have it use libstdc++.so.6? c++ -I. -I. -I/usr/include/libxml2 -g -O2 -c testActivity.cc c++ -g -O2 -lboost_date_time -lssl -o testActivity Activity.o testActivity.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libboost_date_time.so, may conflict with libstdc++.so.6 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN5boost10posix_time16to_simple_stringENS0_5ptimeE' referenced in section `.rodata' of testActivity.o: defined in discarded section `.gnu.linkonce.t._ZN5boost10posix_time16to_simple_stringENS0_5ptimeE' of testActivity.o Thanks, Curtis

2 1

[logo] plus B
by Rene Rivera 03 Dec '04

03 Dec '04

Both in short and long form. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Re: Nasty bug in Boost 1.32.0 bind
by David Abrahams 03 Dec '04

03 Dec '04

Sean Parent wrote: > The version of bind() for pointers to data members no longer returns a > const & - rather it returns a copy (the correct code appears right at > the bottom of bind.hpp but is commented out). This just blew my whole > day to hunt it down - I had a bind function attached to a boost function > object at it was returning a reference to a copy on the stack with not > so much as a peep from the compiler! > > I've got a couple more minor bugs in the latest release I'll pass on > shortly to Dave. Don't pass these on to me, pass them to the boost mailing list. I am not the maintainer of that library and can't respond nearly as usefully as the person who is. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[logo] Abstract 2
by Rene Rivera 03 Dec '04

03 Dec '04

OK, so I may have gotten carried away with the number of logos tonight... But I'm just trying to expand the space of logo possibilities. Hopefully this will inspire others to play with more variations ;-) g'nite.. or g'morning.. depending on which side of the world you are on. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2

Somewhat abstract
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 3

Another Logo (simplistic B/W)
by Daniel Frey 02 Dec '04

02 Dec '04

OK, my first try. If anyone likes it, I'll add it to the Wiki... :)

3 3