- Boost - lists.boost.org

Boost.Strings
by Martin 01 Oct '04

01 Oct '04

The fixed_string is already in the review schedule and a proposal for immutable strings was published recently. Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library. That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.

5 6

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 01 Oct '04

01 Oct '04

David Abrahams writes: > Yeah. It's hard to imagine how "compile-time multimethods" would be > any different from what C++ already provides in terms of overload > resolution and partial ordering. The main difference is that they work when particular types of participants are unknown at compile time. It is just like trying to implement unary virtual method using overloading. Jesse Jones writes: > Can a static library do better type > checking? In particular can it figure out, at compile time, if there > are no applicable methods or no unambiguous method? Yes. The compile-time library detects ambiguity and absence of proper method. It is compile-time error. P.S. It is looks like this post was lost.

1 0

can emacs cc-mode be made to do boost-style preprocessor indents?
by Jonathan Graehl 01 Oct '04

01 Oct '04

The Boost style of nested indenting for preprocessor directives is nice. I'm using cc-mode for emacs (the sourceforge version), and it doesn't seem to directly support this: #if 1 # if 2 # define A 1 # else # endif #endif I found this cc-mode mailing list discussion that confirmed the lack of support: http://sourceforge.net/mailarchive/forum.php?thread_id=5382045&forum_id=6827 Anyone already got some working elisp for preprocessor autoindent?

2 1

Portable test_and_set, please...
by no_carrier 01 Oct '04

01 Oct '04

Hi all, I see some atomic operations in atomic_count.hpp (usable only by the atomic_count class unfortunately, and not directly) for incrementing and decrementing, but the most important atomic operation seems to be missing: the test_and_set. Without that one it's not possible to create lockfree algorithms in MT. Also, atomic incrementing, decrementing etc. can be performed having the test_and_set but not vice versa. Would anybody please make a wrapper for that? On Windows it's the InterlockedCompareExchange, on Gcc and Linux I think they are called __test_and_set and atomic_test_and_set respectively. I don't know if they would better go in the Boost.Threads or in the atomic_something header files... Thanks

1 0

[Signals] slot/trackable object disconnection question
by Dave Deakins 01 Oct '04

01 Oct '04

I have a question about the disconnection of slots in the signals library. I couldn't find any information about it in previous message threads, but if I missed one you guys can just direct me to the appropriate discussion. In my project I have a serial port communications queue that allows various other objects to transmit a command over the serial port and then have the response routed to a designated callback function. Each command request can specify a different response callback function and often the object posting the command will ask the queue to pass the response data back to one of its member functions for interpretation. I use the automated connection management feature of signals to insure that the response member function is not called if its target object is destroyed before the serial port response is received. This queue typically handles about 10-15 command/response transactions per second and I noticed that, after about 15-20 hours of continuous operation, the system began to run low on available memory. I spent a fair amount of time trying to track down the source of the excessive memory usage and it appeared that it was coming from the trackable object base class. Each time a command is added to the communications queue, a new queue entry is created and we connect the response handling function to the signal in this queue entry. If I understand correctly, signal's connect function will create a temporary slot object to adapt the boost::bind(&AClass::ResponseFunction, pAClass, _1, _2) object that is passed to it. When this temporary slot is created, it uses visit_each to enumerate the bound trackable objects and then uses trackable::signal_connected(...) to have each bound trackable object save a 'controlling' connection to the slot in its connected_signals list. So if any of the bound trackable objects are destroyed, the 'controlling' connection will deactivate the slot and tell all of the bound trackable objects used by the slot that they can erase their connections to this slot. So my question is this: When a slot object (not a signal object) is destroyed, what tells the trackable objects that are used by the slot that they can release their connection to this slot? Signal objects make the connections in their internal slot map 'controlling' so these connections would do the clean up when the signal is destroyed. As mentioned above, trackable objects also make the connections in their internal connected_signals list 'controlling' to enable deactivation and clean up of standalone slots or slots connected to signals when the trackable object is destroyed. But the watch_bound_objects connection in the slot object is not 'controlling' (as far as I can tell) and thus a slot does not seem to have any way to indicate to the bound objects that this connection needs to be cleaned up if the slot is destroyed. The following program roughly illustrates the behaviour I see in my application: #include "boost\bind.hpp" #include "boost\signals.hpp" class CommunicatingObject : public boost::signals::trackable { public: void ProcessResponse() {} }; int main(int argc, char* argv[]) { CommunicatingObject Obj; while (true) { boost::signal0<void> NewResponseData; NewResponseData.connect( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); NewResponseData(); } return 0; } Obj would represent the object making a request on the queue and NewResponseData would represent the signal contained in the queue entry. When I run this test program on my system, the system runs out of memory in fairly short order. I have the same memory draining situation if the while(true) loop is changed to the simpler case of: while (true) { boost::signal0<void>::slot_type( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); } Can someone please confirm if this behavior happens on other systems or if maybe there is some pecularity with my system/compiler? If this situation is not peculiar to my system, should there be a: watch_bound_objects.set_controlling(); statement at the very end of the slot_base::create_connection() procedure (after the safe_connection.release() statement) in slot.cpp? Thanks in advance for your help, -Dave

2 6

Re: [boost] [Random] GCC 2.95.3 regressions
by Michael Stevens 01 Oct '04

01 Oct '04

> Aleksey Gurtovoy writes: > > > > Given that the code compiles with the latests versions of the > > compiler, the following (from http://tinyurl.com/58lll) is most likely > > to be a compiler bug, but since the test used to pass some time ago, I > > was wondering if anyone is interested in making it work again or simply > > commenting on it before I mark it green: > > [snip errors] > > OK, seems like nobody is interested in these, marked up as expected. I took a quick look. It seems like gcc-2.95 has namespace problems when BOOST_USING_STD_MIN/MAX Since Random never worked on systems without min/max in std I have simplified and use std::min/max instead. This fixes gcc-2.95 and should not regress on any of the good compilers. If this looks good in the tests tomorrow I will remove the failure markup. Michael

2 1

use of strcpy, strcat, etc in Boost libraries
by Reece Dunn 01 Oct '04

01 Oct '04

Hi All, In my post on the "vc8.0 toolset (bjam)" thread, I commented that VC8 also warns when using the str[n]xxx APIs, because MS declares them deprecated. There are several issues here: [1] How does this impact Boost code that uses the <cstring> API? Especially since they deprecate the strn variations as well, which are safer, and considering that the "safe" versions are not yet a part of the standard. Would it be possible to put this in the Boost <cstring> header? I.e. using the safe versions for VC8 and using the C9x API for the other compilers/libraries. [2] Does this affect the Intel compiler using the Dinkumware libraries because Intel does not like how the library declares items deprecated. (This is already an issue using the <locale> header and <hash_xxx> extensions). [3] What are the wider security issues of using strcpy, etc in Boost code? The libraries should use the strnxxx variants for better protection against buffer overrun attacks, but I found several instances where strcpy was used (I haven't checked for strcat, strcmp and others) instead of strncpy: boost/regex/v4/regex_cstring.hpp (104): use of strcpy [via re_strcpy] libs/regex -- various files using strcpy libs/serialization/test/test_tools.hpp (69): use of strcpy [via STRCPY] libs/smart_ptr/test/smart_ptr_test.cpp (139/223): use of strcpy tools/build/jam_src -- execnt.c; regexp.c; variable.c [4] Doing this, I found that regex was using re_strcpy as a workaround for Borland using strxxx as macros when using intrinsics. Serialization uses STRCPY for a similar workaround, and my fixed_string library uses the following: # if defined(__BORLANDC__) && defined(strcpy) // replace Borland instrinsic string function # undef strcpy inline char * strcpy( char * dest, const char * src ) { return( __strcpy__( dest, src )); } # endif So: should the workarounds be placed in <cstring> and affected libraries use the Boost version. NOTE: I suggested telling Boost.Build to disable the deprecated API warning for the upcoming release and then address these issues for the next (1.33) release. Thoughts? Comments? Regards, Reece

4 6

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 30 Sep '04

30 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: <snip> > But now, by looking again at atomic_conditional_increment. I'm not a > threading expert, but it seems pretty costly as it is implemented > now. Could it not go multiple times (n>=2) thorughout the for? Yes. > Current implementation: > > inline long atomic_conditional_increment(long volatile & value) > { > for(;;) > { > long tmp = value; > if(tmp == 0) return 0; > if(InterlockedCompareExchange(&value, tmp + 1, tmp) == tmp) > return tmp + 1; > } > } > > > Couldn't it become: > > inline long atomic_conditional_increment(long volatile & value) > { > long tmp = value; Suppose we read the count as 2 here... > if(tmp == 0) return 0; ...and that another thread decrements the count to 1 around here... > long new_val = InterlockedCompareExchange(&value, tmp + 1, tmp); > if(new_val == tmp) return tmp + 1; ...so that InterlockedCompareExchange fails and returns 1, so this doesn't return; and suppose that another thread decrements the count to 0 around here... > else return InterlockedIncrement(&value); ...then this increments the count to 1, which is wrong. > } The increment has to be conditional on the count being non-zero, and neither the Win32 API nor the x86 processor (AFAIK) can perform that atomically. So the loop is unavoidable. There is room for a slight optimisation in that the value returned by InterlockedCompareExchange can be used the next time round: inline long atomic_conditional_increment(long volatile & value) { long old = value, older; do { if (old == 0) return 0; older = old; old = InterlockedCompareExchange(&value, old, old + 1); } while (old != older); return old + 1; }

2 1

Output formatters: different approaches
by Vladimir Prus 30 Sep '04

30 Sep '04

During the review of the output formatters library, there were suggested several alternative approaches. For example, Gennadiy thinks the library is too complicated, and Hartmut suggests creating a library dual to Spirit -- which would be extra powerfull. That's not all. Independently, I've talked with Vaclav Blazek, who's the author of the Teng text template engine (http://teng.sourceforge.net/) which is also a similiar domain -- it's too about formatting objects. It would be great if we had some common foundation, so that I could output ptr_vector<Function> using both a simple formatter, or a flexible one, or even some template engine. Such foundation can be pretty simple: 1. A fixed set of type "categories" (sequence, map, tuple, something else) and a mechanism to obtain the category for a specific type. The current library even has some mechanism, but I'm not sure if's as simple as possible and is extentable. 2. A mechanism to iterate over elements of composite type. After some though, I believe that the mechanism should be boost::serializaton. Take, for example, sequences. The reviewed version of the library contains the code to handle boost:array, vector, list, and pair. The amount of code devoted for this is significant. If serialization library were used (it provides 'save' and 'load' functions for those types), the implementation would be simpler: The basic formatter could look like: class formatter { template<class T> void write(T &t, is_primitive) { os << t; } template<class T, class Category> void write(T &t , Category { os << start_delimiter<Category>(); os << t; os << end_delimiter<Category>() } template<class T> formatter& operator&(const T& t) { write(t); } }; The idea of the library, as I see it, is to provide object serialization, but - without the overhead serialization library has - with extra layout tweaks I don't see why it's necessary to reinvent the object traversal code which is already in boost::serialization. For example, boost::serialization support scoped_ptr. It would not make sense to add separate support for scoped_ptr in outfmt. And, as I've already mentioned I'd like the 'serialize' approach even for class members. Even if serialization headers which provide support for vectors, lists and so on drag too many dependencies, I think this is fixable. On the top of this, it's easy to provide various output facilities. - A simple multi-line indenting formatter. No customization at all, no overhead - A more advanced solution which uses nested formatters (like the revieved version), and stores formatting information in iword/pword - An interface with template system: e.g. Template t(...); vector<Function> f; t["functions"] = f; would traverse 'f' creating a tree of values which can be used in template. Thoughs? - Volodya

3 2

RE: [boost] Re: Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 30 Sep '04

30 Sep '04

Peter Dimov <pdimov(a)gmail.com> wrote: > Ben Hutchings wrote: <snip> > > I feel the naming of functions may give a false sense of generality > > and encapsulation when they actually only work in the way they are > > being used currently. > > I'm not sure which functions do you have in mind here. I'm perhaps overstating the case, but still: Firstly, atomic_read. I think people generally expect atomicity and ordering to go hand-in-hand - though I realise they don't have to - and the other functions whose names begin with "atomic_" do prevent reordering of their memory accesses, so this name could be misleading. Secondly, use_count's return values can only be used in very specific ways (e.g. the comparison with 0 as an optimisation in weak_ptr<>::lock). I realise that the use_count functions in shared_ptr and weak_ptr are documented as "only for debugging and testing purposes", but I was kind of thinking the name ought to suggest that. (Also the documentation fails to point out that return values can immediately become incorrect in multithreading systems, and has postconditions based on use_count() that won't necessarily be true if tested in real code, though this perhaps ought to be obvious.) > http://66.102.9.104/search?q=cache:1ZQ1uXtFUEIJ:www.pdimov.com/cpp/ > shared_count_x86_exp2.hpp Thanks for that.

1 0