- Boost-users - lists.boost.org

ptr_container: ptr_map.insert() not compiling?
by Duane Murphy 19 Dec '06

19 Dec '06

I'm trying to use boost::ptr_map<> and cannot get calls insert to compile. I'm on Mac OS X using gcc 3.3 with Xcode. Even the most basic code fails to compile: boost::ptr_map< in, int* > my_map; int * val = new int( 22 ); my_map.insert( 1, val ); This fails with: error: no matching function for call to `boost::ptr_map<int, int*, std::less<int>, boost::heap_clone_allocator, std::allocator<std::pair<const int, void*> > >::insert(int, int*&)' error: candidates are: std::pair<typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator>::iterator, bool> boost::ptr_map_adapter<T, VoidPtrMap, CloneAllocator>::insert(typename boos t::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator>::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator>::value_type) [with T = int*, VoidPtrMap = std::map<int, void*, std::less<int>, std::allocator<std::pair<const int, void*> > >, CloneAllocator = boost::heap_clone_allocator] This looks like it's recommending the function that should be working. I've been poking at this for quite a while and cannot find a clue why this is not working. Thank you for the help, ...Duane ...Duane

4 6

[variant] make_recursive_variant and std::map
by Richard Crossley 19 Dec '06

19 Dec '06

I would like to be able to use a recursive variant similar to the way it's shown in the documentation but using a std::map instead of std::vector. i.e. boost::make_recursive_variant< int,std::map<float,boost::recursive_variant_> >::type var; Is there a way to do this? VC8.1 complains with: utility(54) : error C2079: 'std::pair<_Ty1,_Ty2>::second' uses undefined struct 'boost::recursive_variant_' with [ _Ty1=const float, _Ty2=boost::recursive_variant_ ] Regards, Richard.

2 2

Problem with multi_index and shared_ptr
by johneddy101＠comcast.net 19 Dec '06

19 Dec '06

I'm running into a problem while using hashed indices in a container storing shared_ptr's. The problem is occuring in the hashed_index::erase(key) method in both the 1_33_1 release and the CVS head version. This is what the problem seems to be: It is possible that the call to erase (or final_erase_) occurring within the do loop causes destruction of the passed in key object. The key object (k) is then used in a comparison in the while portion of the loop (y!=x&&eq(k, key())). The default predicate uses == in this comparison but one of the items (the left hand side) will have already been destroyed. I'm afraid that I don't know a good solution to this problem. I see from your commit logs on this file that there is a problem using something like is done in the ordered_indices (deleting equal_range items) whereby it increases the complexity. I can see from the implementation of equal_range on hashed indices that this is a potentially expensive operation for non-unique collections with many collisions. However, since speed is a secondary consideration for me, this is the solution I'm using for now. Thanks, John

1 0

Re: [Boost-users] Boost Serialization make_binary & XML/ASCII
by Javier Estrada 19 Dec '06

19 Dec '06

Terence, We use Spirit in a similar way to SAX: we read binary data from a serial port, assemble it into discrete units (messages) and push them through parser generated by Spirit, which in turn calls a function upon finding a match. Some of our messages are multi-part, so we need to keep some form of state that allows us to assemble the final message. I would imagine that there would be a way to break from the parsing. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Terence Wilson Sent: Saturday, December 09, 2006 2:55 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Boost Serialization make_binary & XML/ASCII Robert, XML is normally parsed using a DOM or SAX parser. DOM reads the whole file into memory, SAX behaves like a recursive descent parser with callbacks to the client application. By placing the data block at the start of the file I should be able to get good performance from SAX or Spirit. Both would be good choices, however, I want to write some 'reference' code using standard tools since my work will be part of an SDK. Regards, Terence > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Robert Ramey > Sent: Saturday, December 09, 2006 2:10 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost Serialization make_binary & XML/ASCII > > Well, now I'm out of my depth. Some have commented that the spirit > parser is slower than other xml parsers.I don't know. I would have > hoped that since spirit does a lot of the heavy lifting at compile > time, it would be pretty fast. I haven't seen too much data on this so I really don't know. > Any parser has to scan every character in the file so its not clear to > me that a SAX parser or any other can be know a priore to be faster > than any other one. > > My reason for using spirit was > > a) it was already part of boost > b) it was - after some learning curve - a good fit with what I wanted > to do. > c) well documented. > d) customizable - serialization only uses a portion of the full xml so > it seemed the most efficient. > e) all done at compile time so it wouldn't include dead code. > f) portability to all compilers boost supports. > g) By exercising a little care in code organization I was able to > arrange things so that the module containing the parsing didn't depend > on the rest of the program. So the long compile time is not an issue. > It is in the library and is only recompiled when the grammar changes. > > It is the last feature that suggests that you can easily use this to > do your own actions upon parsing the serialization library. > > After some initial pain figuring out how to use it, I have to say I > have been extremely pleased with this application of spirit. I never > wanted to do xml serialization as I felt it was a pain in the neck and > of relatively little utility in my view. I had anticipated a > maintainence nightmare so more and more obscure corners of xml syntax > were touched. I'm pleased to say this thing has been fantastic as far > as I'm concerned. After the intial one time pain - I haven't had to > touch it since 2002 - and this (through spirt 1.6x - still available) > is still compatible with Borland 5.51. And all the hacks required to > make this so portable are only compiled into the platforms that need > them. > > This has been one of the most significant implementations in making > the serialization library possible. (the other one would probably be mpl). > > So if this were my problem I would: > > a) Include the xml grammar and parser from the serialization library - > add my own actions. > b) finish my code. Really this I would expect it would be 100 lines. > c) If its too slow - and if profiling suggests that the spirit parser > is the bottleneck - then I would look at tweaking the grammar to speed > up parsing or replacing the spirit parser with a faster one. This is > my rule: "First make it work ASAP - then make it faster if necessary" > > But I already am somewhat familiar with spirit so it might not be an > interesting option for you. But then yo might be able to use the > current parser unchanged. Of course this would bring the huge benefit > that if the xml_archive parser is tweaked for some reason (there are a > couple of issues with special characters), you would automatically > inherit these changes and still be in sync. > > I made the choice to invest the effort to figure out spirit rather > than write my 10,000th file parser. Of course that was my decision and > may not be everyone's preference. > > > Good Luck > > Terence Wilson wrote: > > Robert, > > > > The utility I am writing needs to be able to extract a small portion > > from a large XML file generated by your library. Since it is > > performance sensitive I chose to use a SAX parser in order to avoid > > reading the whole file. Would it be much work to do this with the > > Spirit parser? > > > > As always, thanks for the super-fast response. > > > > Best regards, > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Boost.thread] Desire to check mutex locked state for debug builds
by Kai Brüning 19 Dec '06

19 Dec '06

Hi, I am new to this list, although not completely new to using Boost. When working with mutexes and locks, it is common to have functions which are part of critical sections but do not lock themselves. A typical example for this is the thread safe interface design pattern, which moves all locking to the publicly available interface functions of a class and all implementation to internal functions which expect to be called with a lock in effect. I would feel much more confident if I could check "expect to be called with a lock in effect" in debug builds. That is, if I could test whether a mutex is locked for a specific thread (in my case, "current thread" would suffice). Especially if some functions need locking and others don't and the goal is to minimize locking for performance's sake, pure convention and documentation without runtime checks seems to me dangerously error prone. Is there any way to do this test which I overlooked? Is my desire sensible? Or are there other/better ways to make sure necessary locking is done? Best regards, Kai Brüning -- RagTime GmbH Tel: [49] (2103) 9657-0 Neustraße 69 Fax: [49] (2103) 9657-96 D-40721 Hilden mailto:kai@RagTime.de Deutschland http://www.RagTime.de/

1 0

Re: [Boost-users] format: show uint8_t as a number, not a char?
by Phil Endecott 19 Dec '06

19 Dec '06

>> This does what I want: >> >> uint8_t i = 65; >> printf("i = %d\n",i); [snip] >> uint8_t i = 65; >> cout << boost::format("i = %d\n") % i; >> >> But it seems to have the same, unwanted, behaviour as cout<<i. [snip] >> At the moment I have to write things like >> >> cout << "i = " << static_cast<unsigned int>(i) << "\n";> > You can just cast the value to an int Yes, as I mentioned towards the end of my message. But I find that obfuscated. It's particularly problematic when the value is a field in a struct whose type I don't exactly remember, and I forget the need to cast it; the result is control characters being written to the terminal, which can be hard to debug. Surely, since I have asked for %d in the format string, format() can do the cast? i.e. something like (PSEUDOCODE) template <typename T> operator%(T val) { .... if (format_char='d') int val1 = static_cast<int>(val) ... } or have I missed some additional complexity? Phil.

3 2

format: show uint8_t as a number, not a char?
by Phil Endecott 18 Dec '06

18 Dec '06

Dear All, This does what I want: uint8_t i = 65; printf("i = %d\n",i); It prints "65". This doesn't: uint8_t i = 65; cout << "i = " << i << "\n"; It treats i as a char, since uint8_t is a typedef for char deep in some header file somewhere, and prints "A". I was hoping that boost::format would do what I wanted: uint8_t i = 65; cout << boost::format("i = %d\n") % i; But it seems to have the same, unwanted, behaviour as cout<<i. Is there anything that I can do to my code to get the effect that I want? If not, is there anything that can be changed in boost::format to make it do what I want? At the moment I have to write things like cout << "i = " << static_cast<unsigned int>(i) << "\n"; which is a lot of typing and obfuscates what is actually going on. Any suggestions would be much appreciated. Cheers, Phil.

2 1

vertex descriptors
by Luis Quesada 18 Dec '06

18 Dec '06

Dear all, Sorry for the newbie question! Given the index of a vertex, how can I get its descriptor? I guess function vertex (page 225 of The Boost Graph Library) does that but the function is not defined. In fact, what I want to do is to check whether an edge belongs to a graph in a context where descriptors get invalidated after vertex removals? Suppose I have done this: // create a typedef for the Graph type typedef adjacency_list<vecS, vecS, bidirectionalS> Graph; // Make convenient labels for the vertices enum { A, B, C, D, E, N }; const int num_vertices = N; const char* name = "ABCDE"; // writing out the edges in the graph typedef std::pair<int, int> Edge; Edge edge_array[] = { Edge(A,B), Edge(A,D), Edge(C,A), Edge(D,C), Edge(C,E), Edge(B,D), Edge(D,E) }; const int num_edges = sizeof(edge_array)/sizeof(edge_array[0]); // declare a graph object Graph g(num_vertices); Then I remove some vertices. Now I want to check whether edge <A,B> is still there. Calling edge(A,B,g) would not be OK because the descriptors are no longer referring to the same vertices.... Thanks in advance for your answer, Luis

6 15

[GIL] Add a constant value to an image
by Sylvain Berlemont 18 Dec '06

18 Dec '06

Hi, I would like to know what is the most readable way to write in GIL: Y = X + t, where X, Y are 2 gray32f images and t is a bits32f constant value. Best regards, Sylvain

1 0

[Announce] Mailing list outage on December 19th
by Doug Gregor 18 Dec '06

18 Dec '06

Due to a scheduled power outage at Indiana University, all of the Boost mailing lists hosted at lists.boost.org will be unavailable at the following times on December 19th, 2006: - 5:00am-9:00am Pacific US time - 6:00am-10:00am Mountain US time - 7:00am-11:00am Central US time - 8:00am-12:00pm (Noon) Indiana time - 8:00am-12:00pm (Noon) Eastern US time - 1:00pm-5:00pm GMT Doug Gregor Open Systems Lab @ Indiana University

1 0