- Boost - lists.boost.org

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 14 Apr '06

14 Apr '06

David Abrahams wrote: > Valentin Samko <boost(a)digiways.com> writes: > > > DA> auto(x){ x->first < 0 } > > > > This is quite similar to what we are considering for polymorphic > > lambdas, > > <>(x) { return x->first < 0; } > > Except 1/3 longer, and, I guess for some people, there's a huge > difference in aesthetics Yes. Looking at the current paper by Doug Gregor and others, I don't like the syntax: <>( int x ) -> bool { return x == 10; } It is too different from "normal" function declerations. Dave's auto(x) is closer and given a choice I would prefer that one. Lambda functions and expressions should scale well, for example, in a GUI application: copy( range( 0, listbox.get_length()) | transform( auto( item ) { QtString str; listbox.get_item_text( item, str ); return std::wstring( str ); } ), v.begin()); where you need to do a conversion inside the lambda function before returning it. Here, it might be easier to define that transformation function externally, but this doesn't work all of the time. It also makes the code harder to follow if you have a lot of similar functions/ function objects that vary very slightly. Another example would be manipulating pair/tuple objects and doing a transform on them before returning from the lambda function. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[type_traits] is_convertible<noncopyable,To> crashes
by JOAQUIN LOPEZ MU?Z 14 Apr '06

14 Apr '06

Hello, In a post from yesterday (see http://tinyurl.com/hzk5w) Alexei Alexandrov found a rather serious problem with is_convertible in at least MSVC 7.1 and Intel 9.0, namely that is_convertible<From,To> fails to compile when >From is non-copyable, emitting an error message like this: boost/boost/type_traits/is_convertible.hpp(254): error: class "XXX" has no suitable copy constructor BOOST_STATIC_CONSTANT(bool, value = ... where XXX is the From argument. Needless to say, some fix for this issue would be most welcome. I'm sorry I cannot provide any more help than a mere report of the problem. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 14 Apr '06

14 Apr '06

Gennadiy, my computer time is too limited these days to allow me to write an elaborate answer. Let me return to you by the end of this week or the beginning of the next one. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Jueves, Abril 13, 2006 5:35 pm Asunto: Re: [boost] [multi_index]terminology/design concern > > > Essencially. The same way as book index allows to jump to proper > > > page based > > > on keyword. Could you show some code example? What I want is to > > > iterate > > > through all persons with last name "Smith". All operations should > > > have > > > contant complexity. > > > > So, if your multi-index container is defined like this: > > > > typedef multi_index_container< > > address, > > indexed_by< > > ordered_non_unique< // (last_name,first_name) index > > composite_key< > > address, > > member<address,std::string,&address::last_name>, > > member<address,std::string,&address::first_name> > > > > > > > > ... // other indices > > > > > > address_book_t; > > > > address_book_t b; > > > > then you can write the following: > > > > void list(const std::string& last_name) > > { > > std::pair<address_book_t::iterator,address_book_t::iterator> p= > > b.equal_range(last_name); > > std::copy( > > p.first,p.second, > > std::ostream_iterator<address>(std::cout)); > > } > > > > You require that all ops are constant complexity, which is > > not entirely fulfilled by my example, since equal_range is > > O(log n). On the other hand, I cannot see why your indexing > > concept must guarantee constant complexity and not only fast > > lookup. > > That's the primary reason I would need an Index. Aa Order may have > have > different complexity guarantees. But in some cases I need > partucular search > to be performed much faster then it is guaranted by order search > complexity. > Essentially I am looking for an ability to do something like this: > > address_book_t ab; > typedef address_book_t::order<2>::type full_name_order; > > // this operation is compile time > full_name_order fno = ab.get_order<FullName>(); > > // this operation has constant complexity, since Last name Index > provide > direct access > std::pair<full_name_order::iterator,full_name_order::iterator> > p = fno.get_index<LastName>::equal_range( "Smith" ); > > ... > > In some cases Index could have non-constant complexity, but still > could be > used to significantly speedup orderred collection search. Lets say > I have > Input messages log ordered sequencially (meaning that the order is > just > natuaral order messages where comming in). And I have int64 number > of theses > comming in every day. Now for this order I want to define Time > index to > speedup lookup for messages in partucilar time interval. This > operation most > probably wont be constant (due to continues nature of time) but > still could > be implemented much faster then global serach through messages > collection. > In addition for the same collection I may want to define Symbol > (some > attribute in a messages) order. And for that order I need first > letter > index. > My primary point in above examples is that both Order and Index > are first > class citizents and current desing doesn't account for the latter. > > > > IMO we need another level of indirection that would support Index > > > within an > > > Order concept. I do not see how existing design could handle this. > > > If the need for the kind of bookmarking (allow me to use this term > > so as to not mix the different meanings we're giving to the > > word "index") you describe is sufficiently general, such a facility > > can be built separately from B.MI itself (like a standalone > > view-like library) or integrated into B.MI as an index decorator: > > > > typedef multi_index_container< > > element, > > indexed_by< > > bookmarked< > > ordered_unique<...> > > > > > ... > > > > > > > > > > So, the bookmarked<...> construct can embed any preexistent index > > ("order" in your terminology) type and supplement it with > > bookmarking facilities, provided we had a precise definition of > > what bookmarking boils down to. This kind of stuff can be done > within> the current design, but then again I yet fail to see how > what you > > describe is a general need not sufficiently covered by current > > facilities, like for instance compatible keys in ordered > > indices --clarification here most welcome. > > I am not really crazy about the term Bookmark. IMO Order/Index is > much > better reflect the nature of the concepts we are trying to model. > But above > is step in right direction IMO. > > Gennadiy > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

darwin missing clock_gettime (causing problems in shmem)
by Ian Fasel 14 Apr '06

14 Apr '06

I was trying to use the shmem library on darwin and ran into errors because darwin does not have a clock_gettime function. I believe there needs to be something like a BOOST_HAS_CLOCK_GETTIME in config.hpp -- either there, or in shmem. Then the following patch for shmem would probably be appropriate: --- shmemlib-0-orig/boost/shmem/sync/xtime.hpp 2005-12-30 19:32:02.000000000 +0000 +++ shmemlib-0/boost/shmem/sync/xtime.hpp 2006-04-11 22:24:09.000000000 +0000 @@ -102,12 +102,19 @@ #else - + + #if defined BOOST_HAS_CLOCK_GETTIME timespec ts; clock_gettime(CLOCK_REALTIME, &ts); xtp->sec = ts.tv_sec; xtp->nsec = ts.tv_nsec; - return clock_type; + #else + struct timeval tv; + if (gettimeofday (&tv, 0) == 0) { + xtp->sec = tv.tv_sec; + xtp->nsec = tv.tv_usec*1000; + } + #endif #endif return clock_type; With this patch, I am able to get the examples in shmem to build. Unfortunately, it then fails in boost::shmem::detail::mutexattr_wrapper::mutexattr_wrapper because pthread_mutexattr_init fails. I can go into more info about the problems with shmem on darwin if this is useful to anyone. I realize this may be the wrong list for this post since shmem is still in 0.9 development, so please point me in the right direction if so. -Ian Fasel

3 4

[thread] Poll for users of MPtasks
by Roland Schwarz 14 Apr '06

14 Apr '06

I am intending to drop support for MPTasks on the Mac platform in the thread rewrite. Since there currently are also no regression test builders available for the Mac platform I am polling the list if there are any objections against this plan. Background: I contacted the original contributor of the mac code in boost and got the below information: >> These days, Mac OS 9 is obsolete, and anyone building on Mac OS X can just use the pthreads implementation. Therefore, I think that it's safe to move these old files. << and >> The lowest-level threads on Mac OS X are Mach Threads (Mac OS X is based on BSD with a Mach kernel). pthreads sit directly above Mach Threads. The old Boost Threads implementation was based on MP tasks. MP tasks still exist on Mac OS X, but on top of TS Threads, which are on top of pthreads. << and >> As I noted above, I don't believe the the Mac needs much special attention anymore, given the move to POSIX-based OS X. << This makes me believe, that it is safe to drop support for MPTasks entirely. However in the thread rewrite it will be possible to get both, a default build that relies on pthread being available and native support if possible. So if anyone thinks boost thread on Mach Threads is meaningful, please contact me at the thread devel list. BTW.: Possibly the 1-34 release should write out a message that informs users of MPTasks that support will be dropped? Roland

2 1

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Powell, Gary 14 Apr '06

14 Apr '06

> On Apr 13, 2006, at 3:20 AM, Andy Little wrote: > > A major reason given > > by the committee AFAICS (in GUI case) was that the committee doesnt > > have enough time to deal with it. > > This is not exactly correct. The committee does not have > enough time to *design* a GUI library, nor any other library. > Besides, you wouldn't want a library designed by committee, would you? > > If someone steps up with a proposal for a GUI library, the > committee will review it. > Having used at least 7 or 8 GUI, and written maybe 2 or 3 libraries for various employers I think I can safely say, its not a good canidate for a standard. Why? For production/shrink wrap software you generally need a very platform specific look and feel. And most companies which have a multiplatform product have either written their own, or bought one and therefore have too much money invested to switch. In addition, they have no desire to lower the bar to entry by providing what they perceive as a competative advantage to anyone else. In addition complier/platform vendors have no desire to help you move your product off their platform onto one of their competators. For one off type stuff you usually can just use the native GUI. Why bother with a platform independent tool when you can use the one that's provided by the OS? Thirdly, its a real bicycle shed issue. Everybody knows what the GUI should look like. Endless arguments of whether it should be pixel/character/some other unit based. Whether it needs a button with independent art, or supplied by?? What format that art should take, do you supply a 'facet' which tells the GUI how to understand the art. Whether the art should know its relationship to the window or should that be a property of the GUI object? What do you do with art that doesn't display well on the platform its trying to be rendered on. Do you need the almost infinite states for every button? (depressed, undepressed, highlighted pressed, highlighted undepressed, rollover depressed, rollever undepressed) and art for all of them? Should the GUI objects be in an 'absolute' position based on the window? Or should the whole thing reorganize itself based on shape and size of the window? It's a huge coding problem and if I ever wrote it (again), I'd probably want some monitary compensation for my time. After all everyone else in the GUI business is getting a piece of the pie, why not me? So if you want a "std" GUI, you need to define who your clients are, and what problems it solves. I think you'll find that one size fits no one. Yours, -Gary-

2 1

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Sohail Somani 13 Apr '06

13 Apr '06

> and with concepts do I have to specify the concept it > satisfies as well? > > bool concept(pointerType(x),LessThanComparable(??::first)) > (x) { x->first > 0; } > > So how do I specify the type of "x" to the concept stuff for > concept checking? Oh gosh I hope not... Couldn't you do it in the containing function?

1 0

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Powell, Gary 13 Apr '06

13 Apr '06

> So, > auto(x){ x->first < 0 } > returns bool, and > auto(x){ x->first < 0; } > returns void? > > I think it is very confusing and error prone to change the > return type when user misses (or accidently types) a semicolon. > > Valentin Samko > http://val.samko.info void (x) { x->first < 0; } for a void return? or (x) { x ->first < 0; } And does a lack of a type denote a "auto" type? and if I specify one it over rides it? bool (classT * x) { x->first < 0; } and with concepts do I have to specify the concept it satisfies as well? bool concept(pointerType(x),LessThanComparable(??::first)) (x) { x->first > 0; } So how do I specify the type of "x" to the concept stuff for concept checking? -Gary-

1 0

[Boost-bugs] [ boost-Bugs-1470041 ] regex linking error with VC 7.1
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1470041, was opened at 2006-04-13 12:38 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=1470041&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex linking error with VC 7.1 Initial Comment: I see this error when linking against libboost_regex-vc71-mt-1_33_1.lib: msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: static unsigned int __cdecl std::char_traits<unsigned short>::length(unsigned short const *)" (?length@?$char_traits@G@std@@SAIPBG@Z) already defined in libboost_regex-vc71-mt-1_33_1.lib(usinstances.obj) libs/regex/src/usinstances.cpp appears to have problems. Steps to reproduce: - Create a console project with VC7.1. - Set Character Set to "Use Unicode Character Set" - Use a Multi-threaded DLL - Link against libboost_regex-vc71-mt-1_33_1.lib - wchar_t should NOT be set as a native type - Use the following code: #include "stdafx.h" #include <string> #include <boost/regex.hpp> int _tmain(int argc, _TCHAR* argv[]) { #if _UNICODE std::wstring strCurLine(L"sdfsdfggg"); std::wstring strMatchExp(L"lsdfkjsflk"); boost::wcmatch Matched; boost::wregex regex(strMatchExp.c_str()); #else std::string strCurLine("sdfsdfggg"); std::string strMatchExp("lsdfkjsflk"); boost::cmatch Matched; boost::regex regex(strMatchExp.c_str()); #endif boost::regex_search(strCurLine.c_str(), Matched, regex); return 0; } There are no linking errors if you build with wchar_t as a native type or build with character set as "Use Mutli-Byte Character Set". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1470041&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Powell, Gary 13 Apr '06

13 Apr '06

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov > I was looking at the lambda papers recently and I came to the > conclusion that what we actually need is local functions. To > pick an example from > N1958: > I would like local functions in addition to lambda's as well. There is a very old paper that proposed it. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/ X3J16/93-0088 WG21/N0295 [PS] [PDF] A proposal for Nested Functions John Max Skaller & Fergus Henderson It's a slightly different need though than the current C++ lambdas. The main difference is that with the current library lambda implementations you by default get access to all of the surrounding function's local variables mentioned in the lambda statement. With a nested function you have to bring them in via arguments etc. It's still a nice feature and you should check out this paper. -Gary-

2 1