April 2006 - Boost - lists.preview.boost.org

[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

[Boost-bugs] [ boost-Bugs-1469792 ] segm. fault during std::string (STLport 5.0.2) serialization
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469792, was opened at 2006-04-13 12:51 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=1469792&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: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: simmeone (simmeone) Assigned to: Robert Ramey (ramey) Summary: segm. fault during std::string (STLport 5.0.2) serialization Initial Comment: There is an segmentation fault during STLport5.0.2 std::string object serialization. It is probably caused by new implementation of std::string. Now, one of possible implementation of _String_base class contains members: _M_buffers - union, wich holds dynamic char buffer _M_Finish - pointer to end of string in dynamic buffer In this case it represents our string, as a chain of chars, which is not ended with null separator. For example in my debbuger string "Un." is represented as: +_M_buffers._M_dynamic_buf 0x00378958 "Un.' 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃWhen 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃ`Å 7" char * -_M_finish 0x0037895b "' 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃWhen 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃ`Å 7" char * During serialization, there is used std::copy algorithm, which use template class escape, as an iterator, to iterate through the string. in file: ../boost/archive/iterators/escape.hpp we see function: void increment(){ if(++m_bnext < m_bend){ m_current_value = *m_bnext; return; } ++(this->base_reference()); m_bnext = NULL; m_bend = NULL; m_current_value = (static_cast<Derived *>(this))->fill(m_bnext, m_bend); } When iterator points to last char in string, and then is incremented, it points to next char in dynamic buffer _M_buffers._M_dynamic_buf - in our example with string "Un." it points to apostrof character '\''. Then function "fill" modifies "m_bnext" and "m_bend", because of character '\''. In the next step, function "equal" is called, to check if copy algorithm should be stopped or not. bool equal(const this_t & rhs) const { return NULL == m_bnext && NULL == m_bend && this->base_reference() == rhs.base_reference() ; } And because of m_bnext and m_bend are not NULL's, copy algorithm is not stopped and goes on. It leads to segmentation fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1469792&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

Support for reading/writing binary 'streams' (asio?)
by Olaf van der Spek 13 Apr '06

13 Apr '06

Hi, When reading/writing binary streams, you often need to read/write an (unaligned) integer in big, little or native endian. Is there support for this in Boost? I think iostreams isn't usable as 'zero-copy' is required. What do other Boost developers/users use/recommend? Wouldn't this make a nice additional to the new asio library? Olaf

7 11

[shmem-interprocess] New Shmem bugfix version in cvs and Boost Vault and Interprocess is on the way
by Ion Gaztañaga 13 Apr '06

13 Apr '06

Hi to all, Thanks to all people sending bugfixes for the good old Shmem library. I've uploaded a new version (0.91) with the bugfixes. I would like to thank specially Peter Johnson and Michal Wozniak (Michal, I've tried to reply your mails but they are rejected saying your address was not valid) for their extensive bug hunting and suggestions. Meanwhile I'm working on Interprocess. I've replaced my old two-phase construction and implemented Filesystem-like error handling. mapped_file and mapped_region classes are done. I'm adding more tests to avoid embarrassing lock function problems found on shmem. Boost.Date_Time is now used with mutexes instead of good old xtime. I have a lot of work to do (I have to rework all the documentation, for example) but I plan to start reworking documentation soon. I will add some ABI breaking changes also (for example, small string optimization for shared memory basic_strings). I also plan to change the default top-bottom allocator to a bottom-up allocation so that I can in the future implement realloc-like functions and allocator version 2 functions. I *lot* of work. Please be patient! Regards, Ion

1 0

Re: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC
by JOAQUIN LOPEZ MU?Z 13 Apr '06

13 Apr '06

----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov(a)gmail.com> Fecha: Miércoles, Abril 12, 2006 7:17 pm Asunto: Re: [boost][multi_index] Problems with chained pointers in multi index from 1.34 RC > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > > > 1. What is the compiler error you're getting? > > > Now, from what you report, seems the restriction is > > being too much comprehensive. Could you test what is the > > value of > > > > boost::is_convertible< > > const name_record::Ptr, > > const name_record > > >::value > > > > on your compiler? > > No, this thing compiles and expands to false as expected. In fact, > the error > I'm getting is about > > boost/boost/type_traits/is_convertible.hpp(254): error: class > "name_record" has > no suitable copy constructor > BOOST_STATIC_CONSTANT(bool, value = > ^ > detected during: > instantiation of > class "boost::detail::is_convertible_basic_impl<From, To> [with > From=boost::detail::is_convertible_impl<const name_record, const > name_record>::ref_type, To=const name_record]" at line 286 > instantiation of class > "boost::detail::is_convertible_impl<From, > To> [with From=const name_record, To=const name_record]" at line 362 > instantiation of > class "boost::detail::is_convertible_impl_dispatch<From, To> [with > From=const > name_record, To=const name_record]" at line 409 > instantiation of class "boost::is_convertible<From, > To> [with > From=const name_record, To=const name_record]" at line 59 of > "D:\src\3rd- > parties\boost/boost/utility/enable_if.hpp" > > and can be reproduced with > > bool br = boost::is_convertible< > const name_record, > const name_record > >::value; > > It fails to compile as well. It seems that is_convertible doesn't > handle > noncopyable target type well. I guess you mean the source type (i.e. the From argument.) Well, this also explains the problems you're getting, and it's a serious issue (IMHO) with boost::is_convertible. I'll report this in a separate post. In the meantime, I guess you can work around the problem by specializing boost::is_convertible<const name_record,const name_record> like this: namespace boost{ template<> struct is_convertible< const name_record, const name_record >: public true_type{}; } This tecnhique is sanctioned at http://boost.org/doc/html/boost_typetraits/user_defined.html HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0