August 2011 - Boost - lists.boost.org

Query for interest in including a shim class converting between char*, wchar_t, string, wstring
by Tan, Tom (Shanghai) 25 Aug '11

25 Aug '11

As a C++ programmer, often times there's a need to widen or narrow a string to match some 3rd APIs. After writing similar code again and again, I decided to have a wrapper to simplify this trivial but frequent work, hence the TR and TR2 class. Features include: - Each class serves as a shim between wide-char and marrow-char string types. It accepts a std::basic_string type or C-style literal, returns a std::basic_string type or streamming to std::basic_ostream according to the context(e.g. type on the left side of '=' operator): - 2 classes o Non-template class TR: convenient and intuitive interface, e.g. std::string s = TR(L"hello"); std::wstring s = TR("hello"); o template class TR2<SourceRange>: more verbose but faster e.g. std::string s = TR2<const wchar_t*>(L"hello"); std::wstring s = TR2<const char*>("hello"); - Many Boost libraries (e.g. Boost.Test) that output plain English (ASCII) message literals can be easily extended to support both wide-char version with this class. - The 2 classes do not involve any encoding/decoding. - The name TR is inspired from QT' tr() macro. If there's enough interest, I am ready to improve the code, including renaming, style cleaning, documenting and compiler testing etc, for a final inclusion. And I also would like to have a mentor to guide me through as I've never submitted any code to boost before. This class started as some test code snippet for boost.chrono while exchanging ideas with Vicente J. Botet Escriba. One major improvement since then is that the conversion is bi-directional now..

3 2

[type traits] Extension to operator detection -> choose your preferred naming
by Brent Spillner 25 Aug '11

25 Aug '11

On 8/24/2011 07:23 Frederic Bron wrote: > Please give your preference between A, B and C before Sept. 5th. Of these three choices, I think C is easiest to live with. However, if you're going to have has_unary_plus I think the symmetry of has_unary_minus is preferable to has_negate, and I continue to believe that an additional has_operator<Tag, TypeA, TypeB> (or can_call_operator<>) should be provided for use in more generic code (e.g. forwarding ETs from a higher level without caring exactly which operators are involved.) Brent

1 0

[Conversion] Practical applications
by Phil Endecott 25 Aug '11

25 Aug '11

Dear Vicente & others, Would anyone like to share any practical or motivating applications for the proposed Boost.Conversion library? It seems to me that there are practical applications for particular types of conversion, e.g. T-to-string and string-to-T, and numeric casts, and serialisation. Apart from that, I am having trouble seeing practical reasons for generic conversion. A motivating case would be if a generic algorithm required conversion, but in the cases that I can think of either (a) the generic algorithm takes a functor, so the caller can pass the currently-required conversion as part of a lambda expression, or (b) you might need to select one of several possible conversions between a pair of types, which this library can't do, or (c) the algorithms are std:: ones which won't work with this library anyway. Example: struct person { string firstname; string surname; }; vector<person> people; // sorted by firstname // Try to find everyone with firstname "John": std::equal_range(people.begin(),people.end(),"John"); That doesn't work. Making it work has always struck me as more difficult than it should be. Can this library make it easier? If not, what similar problems can it help with? Regards, Phil.

6 12

[gsoc] Final evaluations
by Andrew Sutton 25 Aug '11

25 Aug '11

Mentors, Please don't forget to submit your final evaluations. You must submit the evaluation before August 26. Thanks, Andrew

1 0

Re: [boost] [Containers] Marshalling deques
by Brian Wood 25 Aug '11

25 Aug '11

Ion Gazta?aga: El 24/08/2011 20:06, Brian Wood escribi?: >> >> If I could get the number of elements in the first chunk and the >> size of the chunks, that would be sufficient. (I believe the size >> of the chunks is constant within a deque instance.) > > Not necessarily, but I think all implementations do that. The question > is whether we should have a standard-friendly and implementation > agnostic interface or an interface just for boost::deque implementation. How about both? First a boost::deque implementation and then if someone is inclined to delve into this further a more general implementation that might replace the earlier implementation. Since this wasn't addressed by C++11, I'm not sure how long it will take to get attention. If the interface we come up with has weaknesses, someone else will figure out how to improve upon it. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[interest] underlying type library
by Julian Gonggrijp 25 Aug '11

25 Aug '11

Dear Boost developers, std::swap is commonly implemented by copying the arguments. For non-POD types this can be very inefficient. Two solutions are available. The first option, which is commonly employed, is to manually override std::swap for every non-POD type, making use of the implementation details of the type. The other option is to provide a library which makes it possible to implement the swap algorithm once, in a way that is efficient for any type (POD or non-POD), and which works even if a type isn't copyable. The latter is what I'll be proposing here. Back in March, Vicente Botet posted a link to the highly inspiring 'Notes on Programming' by Alexander Stepanov [1]. Lectures 4 and 5 cover the (hypothetical) move_raw algorithm and the (hypothetical) UNDERLYING_TYPE type function, as well as their relevance to the swap algorithm. I'll try to reproduce the essential points of this discussion below. move_raw(s, t) moves the value of s to t. t is guaranteed to be left in a valid state but s isn't. In particular, the destruction of s might corrupt t because they point to the same additional resources. Another move operation into s, say, move_raw(r, s) will however restore s into a new valid state. UNDERLYING_TYPE(T) represents a type which is (conceptually speaking) a POD-type with the same member data (and hence the same alignment) as T. The underlying type can be used to allocate space for a T object and to temporarily store the state of a T object. Using move_raw and UNDERLYING_TYPE, a swap algorithm can be implemented which works and is efficient for any type: template <class T> void swap (T& x, T& y) { UNDERLYING_TYPE(T) temp; move_raw (x, temp); move_raw (y, x); move_raw (temp, y); } The benefits of an underlying type library go far beyond the swap algorithm. For a start, any algorithm which moves values around without an inherent need to copy them could use the same mechanism as the swap algorithm above. Apart from that, it can help to simulate rvalue references and move semantics in pre-C++11 compilers in an efficient way. Concluding, a library which provides these tools has an immense potential for improving efficiency and convenience anywhere C++ is used. After reading the lecture notes, I came up with an idea on how to realise such a library in a fully generic way. Alexander Stepanov and Sean Parent have been so kind to review my idea. The idea seemed feasible and they encouraged me to submit something to Boost. In the meanwhile I have successfully managed to implement my idea, so here I am. :-) Apart from its fundamental nature in general, my library might bear special relevance to Boost.Swap and Boost.Move. Is your interest piqued? Kind regards, -Julian [1] http://www.stepanovpapers.com/notes.pdf

16 72

[proto] Problems with operator <<
by John Maddock 24 Aug '11

24 Aug '11

Folks, I'm having no end of problems with operator<< and proto. In the beginning, operator << was overloaded for stream output and everything worked OK, then I added the left shift operator<< to the list of protoized operators in the grammar and everything broke. The strange thing is that: std::cout << a+b; correctly finds my stream out overload: template <class Exp> inline std::ostream& operator << (std::ostream& os, const big_number_exp<Exp>& r) But std::cout << a; no longer calls: template <class Backend> inline std::ostream& operator << (std::ostream& os, const big_number<Backend>& r) But calls the proto << operator instead. I'm at a complete loss to explain this, both of my overloads are in the same namespace as their respective types, and as far as I can see both should be preferred to the proto versions. Before I start tearing my hair out, anyone any ideas? Thanks, John.

2 1

Re: [boost] [Boost-users] [Containers] Marshalling deques
by Brian Wood 24 Aug '11

24 Aug '11

Ion Gazta?aga: > >El 22/08/2011 19:44, Brian Wood escribi?: >> Would you be willing to add a function that gives that? Tia. > > Yes, I think we need to think about a useful interface for that, maybe > something like local_iterator in unordered containers or something like > segmented iterator described by Matt Austern in his "Segmented Iterators > and Hierarchical Algorithms" paper If I could get the number of elements in the first chunk and the size of the chunks, that would be sufficient. (I believe the size of the chunks is constant within a deque instance.) I find it disappointing that the latest version of the standard doesn't have anything related to this and would rather just get something working than figuring out what would be a flexible, general interface. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

[Locale] On Mac OS X 10.6 fails to find iconv
by Artyom Beilis 24 Aug '11

24 Aug '11

Hello, I need a help from Mac OS X users, I have many faults on Darwin: http://beta.boost.org/development/tests/trunk/developer/locale.html Where all GCC's are related to inability to find iconv for some reason. On my darwin 8.01 x86 I have no problems to compile this simple program: has_iconv.cpp #include <iconv.h> int main() { iconv_t d = iconv_open(0,0); (void)(d); } With g++ has_iconv.cpp -liconv Also BBv2 script of Boost.Locale finds the iconv without a problem, so I'm quite lost. So if anybody that uses Boost from svn-trunk can check why has_iconv test fails (if it is on their machines) and see if ./bjam libs/locale/test prints ....... - iconv (libc) : no - iconv (separate) : no ....... And for what reason (if the sample code above compiles) I would be grateful. Because I have no idea what happens there and I don't have Mac only Darwin 8 which handles it properly. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 5

[Boost.Interprocess] Chronic performance on Win7
by Gav Wood 24 Aug '11

24 Aug '11

Hi, we're using the Boost Interprocess layer to do some shared-memory-based IPC and after getting awful performance characteristics out of sync primitives (in particular the condition variables, but similar results with semaphores) decided to do some profiling. Our platform is a (dual-core) Intel Core 2 Duo, running 64-bit Windows 7 and a 64-bit build environment in MSVC 10. One thing we wished to see was the performance of process hand-offs; i.e. getting one process to block as it unblocked a second symbiotic process and vice versa. To this aim we made a tight loop looking like: boost::interprocess::named_mutex m(boost::interprocess::create_or_open, "ProfileCache-Mutex"); boost::interprocess::named_condition c(boost::interprocess::create_or_open, "ProfileCache-Condition"); scoped_lock<named_mutex> l(m); for (int i = 0; i < 1024; ++i) { c.notify_all(); c.wait(l); } and another, running in another process with the wait & notify_all() reversed. It was checked to make sure that hand-offs were happened properly (no spurious wakeups &c.). I don't have any graphs to hand (though they would be quite easy to create), but as a rough figure, assuming a relatively unfettered execution environment - no browsers running/music playing - we were getting about 45 second run times. That's approximately 40ms per round-trip between the processes or 20ms per forced context switch. I suspect it's no mere coincidence that the Windows scheduling timeslice happens to be 20ms in duration; for Windows the sched_yield call is implemented by a Sleep(1); this, on Windows 7 at least, has the effect of putting the thread to sleep for the rest of its timeslice. Not ideal for low-latency IP-hand-offs. The obvious way to gain far higher performance is to Sleep(0). This has had the meaning since Vista of "run any other thread that's ready to run" (it used to mean any other thread of equal priority that's ready to run, hence priority inversion could ensue and people favoured the more aggressively passive Sleep(1)). Changing to a Sleep(0)-based sched_yield gave appropriately speedy results; of the order of 600us for the 1024 roundtrips, about 300ns per forced context switch. Though the loop around the Sleep(0) is a nice, yielding spin loop, if all processes are waiting (perhaps on an external event), then it will needlessly use 100% of each of the used cores. Also far from ideal. My proposed solution, for which I have attached a draft patch, introduces an argument to sched_yield ("_iteration"), in order to allow sched_yield to customise its behaviour depending on how long it has been waiting so far. All loops around sched_yield() (yield-loops) have been changed to track the number of iterations and pass it as an argument to sched_yield(). Ideally we would like to Sleep(0) in the case that the yield-loop's exit condition will be satisfied within the next 20ms and Sleep(1) in all other cases. As a completely unknown prior, we can use an exponential PDF with the 0.5 point occuring at the duration that we have already been waiting for. Optimising for this model, we Sleep(1) once we have already been waiting 20ms, which puts it at around 50000-100000 Sleep(0) calls. The was tested empirically and gave a simple Sleep(0)-yield performance, but while reducing the CPU consumption to near 0 on indefinite wait()s. We tested to make sure performance wasn't hindered should the threads be of unequal priorities; this indeed wasn't the case. Comments? Regards, Gavin -- Save Ferris!

4 7