- Boost - lists.boost.org

[boost] [Important] Mailing list downtime this Saturday, February 19
by Doug Gregor 16 Feb '05

16 Feb '05

The Open Systems Lab, which hosts most of the Boost mailing lists, will be migrating to new hardware this Saturday. The outage will be this Saturday, February 19 starting at noon Eastern Standard Time and should not last more than 8 hours. lists.boost.org will be unavailable during the outage as will the mailing lists themselves. Thanks, Doug Gregor

1 0

RE: [boost] Re: Re: Profiling Library suggestion
by Brian Braatz 16 Feb '05

16 Feb '05

Christopher, Just wanted to send out a note so you know I have not lost interest in the profile library. I was fairly active in this conversation up until the weekend. My main computer died and had to be reinstalled. I am back running again (and back on mail). I am re-arranging the project I am working on so that I can spend the next 5 days to actually use your library as is to profile a million line application. I will keep you posted as to my progress. (considering the structure of the application, the "hard part" here is going to be adding the library in after the fact). This should be a fairly useful experience. Thank you for staying with this library and responding to all of the suggestions from myself and others. Brian

2 1

void * with boost::python
by Preston A. Elder 16 Feb '05

16 Feb '05

I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg: std::string str("This is a test"); hexdump(str.data(), str.length()); std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t)); I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it). Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class). Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures. Also, on another note, is there somewhere that has all of boost already pythonized? I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 8

Wave review
by Joel de Guzman 16 Feb '05

16 Feb '05

Hi Hartmut, I wanted to try out the examples. I encountered some problems: + Read the quikstart to get me started immediately. "Do not instantiate the main, preprocessing iterators yourself." --> not enough context here. "main" is undefined at this point. + when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good. + Now, I'm able to build the samples using bjam V2. A little hickup: bjam complains: error: Unable to find file or target named error: '/boost/program_options//boost_program_options' error: referred from project at error: 'cpp_tokens/build' Looking at program_options, it seems that the library name is program_options (without the boost_ prefix). + Got this fixed and. Now got into a link error: gcc.link ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.exe ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\release\ cpp_main.o(.text+0x50):cpp_ ain.cpp: multiple definition of `_main' ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.o(.text+0x7eb0):ins ect.cpp: first defined here Any clues? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 12

Const-incorrect constructor inprogram_options::basic_command_line_parser?
by Lars Iversen 16 Feb '05

16 Feb '05

I assume that the constructor for program_options::basic_command_line_parser (and function program_options::parse_command_line) in boost/boost/boost/program_options/parsers.hpp revision 1.11 could accept pointers to const char instead of non-const pointers?! Regards, Lars

3 3

Smart mutex pointer?
by Raz 15 Feb '05

15 Feb '05

Why doesn't Boost have any smart pointers that automatically lock a class when a member is used? The code isn't that hard. #include <iostream> struct Dummy { int a; } class Lock { private: Dummy &_d; public: Lock( Dummy &d ) : _d(d) { std::cout << "Locked." << std::endl; } ~Lock( void ) { std::cout << "Unlocked." << std::endl; } Dummy *operator->( void ) { return &_d; } }; class Ref { private: Dummy &_d; public: Ref( Dummy &d ) : _d(d) { } Lock operator->(void) { return Lock(_d); } }; int main( void ) { Dummy d; Ref x(d); x->a = 1; std::cout << x->a << std::endl; } I get: Locked Unlocked Locked 1 Unlocked on my system (g++ 3.3.3 and g++ 3.4.0). Has there been any reason not to do this? -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 5

overloads-20050207.tar.gz
by Alexander Nasonov 15 Feb '05

15 Feb '05

https://sourceforge.net/project/shownotes.php?release_id=303009 This package has been tested on gcc 3.4 and linux-intel 8.0. Two kinds of overload sets are currently implemented: natural sets and range sets, that is, overloads::set<X> and overloads::set<X, mpl::range_c<int,1,3> > where X is (I call its concept OverloadsHolder, feel free to suggest better name): struct X { void operator()(overloads::id<1>, int, char) const; // void(int,char) bool operator()(overloads::id<2>, long) const; // bool(long) }; mpl::end for natural set is not constant time but fast. The following MPL algorithms work: - has_key - order - find - size - empty - equal

4 33

Re: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts)
by JOAQUIN LOPEZ MU?Z 15 Feb '05

15 Feb '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Martes, Febrero 15, 2005 8:41 pm Asunto: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts) > David Abrahams wrote: > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > >> On Feb 15, 2005, at 9:49 AM, David Abrahams wrote: > >> > >>> You don't need any storage for rebalancing. Typical map nodes > have>>> 3 pointers: parent, left child, and right child. > >> > >> If it is a red-black tree, you need to store the color of each > node.>> This information requires 1 bit, which can easily be > padded to a > >> word. > > > > Oh, I didn't understand that he meant color info. I guess that is > > only for rebalancing, isn't it? > > > > /me crawls back under rock > > > >> If it is a AVL tree, each node needs to store its tilt. This > >> information requires 2 bits. > >> > >> Or is there a new technique I'm about to learn about? :-) > > > > /me burrows several inches down into dirt under rock > > You could have pretended that you had in mind an implementation > where > pointers are always even and one of the least-significant bits is > used as a > color bit. ;-) > > Are there std::maps that store a next and previous pointer to > optimize > traversal at the expense of per-node overhead? > > (Of course my original point was that most people don't care about > the > per-node overhead and those that do just use a different data > structure.) I'm pretty certain no commercial STL implementation exists that does this, precisely because of the overhead. Users might not care, but implementors surely do. Incidentally, a multi_index_container with an ordered index and a sequenced index pretty much mimics the kind of data structure you've got in mind. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo.

1 0

Re: [boost] Re: Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >>>> I wanted to create a very simple AutoPtr that was essentially the >>>> same as the STL auto_ptr (and backwards compatible with it). >>> >>> Unfortunately, you haven't (see below). Furthermore, auto_ptr is >>> widely recognized as unsafe because it is too easy to transfer >>> ownership unintentionally. >> >> Of course you can unintentionally transfer ownership if you don't >> know what you're doing. ;) > > The problem is that the code which transfers ownership appears innocuous on the > surface, because auto_ptr allows transfer of ownership with the same syntax > ordinarily used for copying: > > void f() > { > auto_ptr<int> ptr(new int); > auto_ptr<int> ptr2(ptr); // ptr is now empty. > } Why would anyone in their right mind do that? >> I believe that's why you're not supposed to pass an auto_ptr to a >> function -- instead you pass the pointer itself with .get(). You >> can't stop everyone from shooting themselves in the foot. > > Declaring a function to take an argument of type auto_ptr<...> is one way to > signal that ownership is being transfered to the function. It also ensures that > the managed object will be deleted, unless the function takes explicit steps to > cause a leak. Passing raw pointers defeats this system. Yes, this is true if you're calling a function that you wrote and compiled yourself, but if you're calling a 3rd party API that you didn't compile yourself, that can be dangerous (or so I've been told). >> How? If you pass a pointer to a function, you shouldn't be deleting >> it inside that function anyways (so pass it with .get()), > > What if you want to transfer ownership to the function, as is often the case? Then pass ptr.release() to the function. >> and if you >> return a pointer from a function, you can save it in a new AutoPtr so >> it will get deleted automatically... > > This depends on the calling code to do the right thing. If you return an > auto_ptr, the managed object will be freed even if the calling code choses to > ignore the return value. I agree, if it's your own code, return an auto_ptr, but if you're an API, you must return a raw pointer. >> I don't set my pointer to NULL when I release() it, I just set >> m_Owner = false. > > This behavior is not compatible with std::auto_ptr. I could change it to set the pointer to NULL, but this is what Microsoft's auto_ptr does, and it looked safer. > move_ptr has the same overhead as auto_ptr. Thanks, when I get some time I'll take a look at those. As you might infer from some of my comments, I'm dealing mostly with API component code myself, which integrates some older sub components, so I have no choice but to pass raw pointers most of the time. Chris Just __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Re: Re: Re: Re: Re: Querying the Interest in a new AutoPtr class
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >> I'm not an expert with compilers so I'll tell you how it was >> explained to me. Different compilers could take the same C++ code >> and compile it into different machine code, causing function pointers >> to shift. When you pass an object that was compiled on one machine >> to a function that was compiled on another machine, you can't be sure >> that the object will be deleted properly. > > I guess you're talking about passing objects between modules compiled with > compilers having incompatible ABIs. In general this is a recipe for disaster. If > you restrict yourself to a C language interface you often have more flexibility, > but in that case you can't use smart pointers. > > Is this what you mean? Yes, that's exactly what I mean, and probably explained a little better too. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0