- Boost - lists.boost.org

[asio] misc_ecat is undefined on Windows
by Pavel Kalugin 13 Jan '07

13 Jan '07

There is an error in boost/asio/error.hpp in HEAD - definition of boost::asio::detail::error_base<T>::misc_ecat is unavailable on Windows build. The solution is to move #endif from line 103 to line 98. The following patch works for me: Index: error.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/asio/error.hpp,v retrieving revision 1.11 diff -u -r1.11 error.hpp --- error.hpp 9 Jan 2007 13:54:51 -0000 1.11 +++ error.hpp 13 Jan 2007 04:18:33 -0000 @@ -95,12 +95,12 @@ static std::string addrinfo_md(const boost::system::error_code& ec); static boost::system::wstring_t addrinfo_wmd( const boost::system::error_code& ec); +#endif // !defined(BOOST_WINDOWS) && !defined(__CYGWIN__) static boost::system::error_category misc_ecat; static int misc_ed(const boost::system::error_code& ec); static std::string misc_md(const boost::system::error_code& ec); static boost::system::wstring_t misc_wmd(const boost::system::error_code& ec); -#endif // !defined(BOOST_WINDOWS) && !defined(__CYGWIN__) static boost::system::error_category ssl_ecat; static int ssl_ed(const boost::system::error_code& ec); -- Pavel

2 2

Re: [boost] Final Getting Started Guide
by David Abrahams 13 Jan '07

13 Jan '07

Roland Schwarz <roland.schwarz(a)chello.at> writes: > Hallo David, > > I already posted the below to the list, but got no response. Possibly > it slipped through your attention, No, it's just down in my priority queue. > since I answered to an old post. > > Ah, yes, the link actually is > boost_root/doc/html/thread/build.html#thread.build Thanks... > (without the last ".building") > > Roland > > > David Abrahams wrote: >> > I refactored the getting started guide into separate documents. >> > Please see >> > >> > http://www.boost-consulting.com/boost/more/getting_started.html >> > >> > Library authors have not posted any working URLS of library-specific >> > build instructions, so library names other than Boost.Python all link >> > to the librarys' top-level pages. > > For the thread lib this is: > boost_root/doc/html/thread/build.html#thread.build.building > > This link is available after the docs have been built. No stub available. > > While trying to update this piece of the doc I found the following: > > 1) The getting started guide uses " --toolset= " while the bbv2 manual > states " toolset= ". Obviously both versions work. Which one should go > into the documentation? I think most users who don't know more about BBv2 will be less confused by --toolset=. Of course, they may be confused later when they learn more. Tradeoff. I don't find it's a big priority to change, and since I'm busy... :) > 2) The Boost.Build ref link from the windows.html getting started points > to tools/build/v2. This might be fine when viewed over a web server but > opens a directory when viewed from the filesystem. I suggest correcting > this link to use the index.html file. If I find the time. > 3) The only place I have found where toolset names are explicitely named > is in the getting started guide. I intend to link to > /more/getting_started/windows.html#identify-your-toolset. Questions are > if this is a stable link Should be > and how this will work in a pdf scenario? A "pdf scenario?" I suppose you mean when the Boost docs are generated as PDF? Links to web pages from PDFs just work. That page won't be part of the fraction of Boost docs that are generated as PDF as long as we're going the strict DocBook -> FOP route. > 4) I tried to build the getting_started doc on my local machine. But no > luck. What do I need beyond using docutils ; in my user-config.jam? That's all I have. What are your errors? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

[Report] 20 regressions on RC_1_34_0
by Douglas Gregor 13 Jan '07

13 Jan '07

Boost Regression test failures Report time: 2007-01-11T07:17:04Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 20 failures in 5 libraries concept_check (15) date_time (1) regex (1) test (2) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64

6 11

Re: [boost] Transition to SVN from CVS? (was: Web access to CVS)
by Gregory Dai 12 Jan '07

12 Jan '07

Hi there, In the recent months, I experienced a transition from using CVS to using SVN with the same project that I've been working on for the past few years in my company. SVN is much faster and much easier to use. I'd suggest that boost make such a transition ASAP.

3 3

[1.34][function] testgenerators date-time qcc regression failure
by Jeff Garland 12 Jan '07

12 Jan '07

Below is the trace of the current 'date-time' qcc failure. Has there been are recent change to boost.function that has precipitated this failure b/c this has been passing forever and date-time hasn't changed? Jeff --------------------- Test output: QNX630sp3-V2 - date_time - testgenerators / qcc-3.3.5_gpp Report Time: Thu, 11 Jan 2007 07:17:04 +0000 Compiler output [2006-12-20 19:47:22 UTC]: "QCC" -Wc,-ftemplate-depth-128 -g -O0 -Wc,-fno-inline -shared -V3.3.5,gcc_ntox86_gpp -DBOOST_ALL_NO_LIB -DBOOST_ALL_NO_LIB=1 -DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG -DBOOST_DATE_TIME_STATIC_LINK -DDATE_TIME_INLINE -I".." -c -o "/fs/hd1/boost-RC_1_34_0/results/boost/bin.v2/libs/date_time/test/testgenerators.test/qcc-3.3.5_gpp/debug/testgenerators.o" "../libs/date_time/test/gregorian/testgenerators.cpp" In file included from ../boost/function/detail/function_iterate.hpp:14, from ../boost/preprocessor/iteration/detail/iter/forward1.hpp:97, from ../boost/function.hpp:62, from ../boost/iterator/transform_iterator.hpp:10, from ../boost/algorithm/string/case_conv.hpp:16, from ../boost/date_time/string_parse_tree.hpp:14, from ../boost/date_time/period_parser.hpp:13, from ../boost/date_time/date_facet.hpp:17, from ../boost/date_time/gregorian/gregorian_io.hpp:12, from ../boost/date_time/gregorian/conversion.hpp:23, from ../boost/date_time/gregorian/gregorian.hpp:21, from ../libs/date_time/test/gregorian/testgenerators.cpp:8: ../boost/function/detail/maybe_include.hpp:-112239: internal compiler error: segmentation violation Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.qnx.com/support/sd_problem_report> for instructions. cc: /usr/qnx630/host/qnx6/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5/cc1plus error 1

2 2

Re: [boost] [date_time] timezone database
by boost＠flatiron.com 12 Jan '07

12 Jan '07

> boost(a)flatiron.com wrote: > > I believe others have pointed out that the time zone database would be > > much more useful if for each time zone one could have multiple > > daylight saving rules, each with its own start and stop time of > > applicablity. > > I'm not sure it would be *much more useful*. Before the change in US rules, > only one person has asked for this feature in the last couple years...not > exactly overwhelming demand. In addition, there is a cost in memory and > complexity to be paid. I recently had to become knowledgeable about time zones for my job, and I have discovered that most people don't know much about them, so I'm not suprised at the lack of demand. There are two problems that I know of with time zone systems that don't provide for multiple daylight saving rules and times of their applicability. First, using a single daylight saving rule will sometimes produce an incorrect result on dates older than the period of applicability the rule. Thus any program that uses such a rule and has to deal with dates other than fairly recent ones will occasionally malfunction in dealing with many, if not most time zones. Second, there is an administrative problem for a system that is in constant use: when do you change the rule? With the multiple rule kind of database you can put in the new rule well ahead of when it is needed, at any convenient time. In short, the one daylight saving rule approach cannot be expected to function correctly for some applications. > > It seems to me that the easiest way to do this would > > be to use the files generated from the zoneinfo files by zic. > > > > A time zone database would be specified by the path to a directory > > structure containing one or more files produced by zic. On many > > Unix-style systems these files already exist, and the tool (zic) > > exists to produce them for others. > > Thx for this pointer, somehow I was not aware of this tool -- although at this> stage I'm not sure how this would help. The library uses a csv file for data.> This is for simplicity, portability, and customizability. The portability > issue is something that is particularly problematic. Windows and common *nix > systems have very different approaches to the timezone data which can't really> be unified easily. Even among Linux systems there's a heterogeneity of > solutions even though the 'basic approach' is common. The bottom line is that> it seemed much more practical to me to provide a single easily editable file > that application developers could customize and be sure had the desired data. > Another reason for the csv approach was to provide an easily editable file > that people could customize for their own purposes. So, for example, if they > need a tz database with only a few entries they could trivially use common > tools (open office, excel, emacs) to change the file. The zoneinfo data base is a relatively easily edited file, or series of files. Furthermore, it is constantly updated, with new changes being added far in advance of their need. The new US rules have been included for some time, I believe. It seems to me it would be easier, and more likely to be correct for someone who only wants a subset of all the rule to take the zoninfo files and cut out the parts which they dont want, rather than create a new database from scratch. > All that said, the library is specifically designed to allow for users that > have more specific needs to write their own derivative of time_zone to provide> for historic information or other time zone features that go beyond basic > needs. A new csv file file form could certainly be created that provides for > historic dates. > > So to be clear, I'm not opposed to upgrading the library with other approaches> to reading different kinds of zone files, supporting historical dates, etc. > There just hasn't been much of a request until recently. As I've said to > others, I'm willing to help other that want to contribute. I hope the above comments don't sound too negative. I appreciate all the work that has gone into the date_time library. I know just enough about some of the problems to realize how complicated a subject it is.

2 1

Re: [boost] [bind/lambda] a functor holding a shared_ptr
by Steven Watanabe 12 Jan '07

12 Jan '07

AMDG Yuval Ronen wrote: > In the following code: > > struct A > { > void func(); > } > > int main() > { > shared_ptr<A> a(new A); > boost::bind(&A::func, a); > } > > the bind() call returns a function object which holds the shared_ptr by > value (it's one of the shared owners). This is an important feature I'm > using, because sometimes the functor is the last owner left standing, > and I want to keep A alive until the functor's destructor (actually, I > don't really like this design, but I'm talking about legacy code here). > Replacing boost::bind with lambda::bind doesn't compile. Is this feature > not supported by lambda::bind? If not supported now, is it planned to be > supported in the future? Can I in the mean time implement this feature > in my code with relative ease? > > Thanks, > Yuval You can explicitly dereference the shared_ptr. #include <boost/shared_ptr.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> struct A { void func() {} }; template<class T> struct identity_t { mutable T t; template<class Args> struct sig { typedef T& type; }; identity_t(const T& arg) : t(arg) {} T& operator()() const { return(t); } }; template<class T> identity_t<T> identity(const T& t) { return(t); } int main() { boost::shared_ptr<A> a(new A); boost::lambda::bind(&A::func, *boost::lambda::bind(identity(a)))(); } In Christ, Steven Watanabe

2 1

Foreshadowing a coming review
by John Phillips 12 Jan '07

12 Jan '07

Possibly because of the recent holidays, there hasn't been much reviewing activity recently. The schedule says the last one ended in mid-November. However, I want to remind everyone that this is changing soon. The Accumulators library review is coming at the end of the month. Since I know I have occassionally wanted to participate in a review and then found that I just ddidn't have the time for it when the review period started, as the manager for this review I want to encourage everyone to take a look early, and avoid the last minute time crunch. The review will begin on January 29. The real announcement will come then. I hope many of you can make the time to contribute. John Phillips

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Dmitry Ivankov > > By the way, what about extending barrier so that it can use > any functor not > only waiting_threads == m_threshold? > At least > timed_barrier, which unblocks when (waiting_threads == m_threshold || > time_since_first_wait > m_time_threshold), > and maybe unblocks in destructor. > > So it'll implement scenario: do the work in groups, i.e. not > very often. > That can be for example some time-expensive background cached work. Thanks to the GP for the pointer to barrier. +1 for any functor from me anyway. The case I used was just an example. Barrier+functor would be higher-level, more obvious, and I'd think less prone to errors. Sohail

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Dmitry Ivankov > > But just wait in threads is bad, because of spurious wake > ups. It should be > like > > while (!::we_can_start) > g_some_cond.wait(condition_lock); > > and > > ::we_can_start = true; > condition_lock.notify_all(); Yes, I do need to read my OS dev textbook again which tried to hammer this in. Is there some way to encapsulate this? Bad idea? Thanks, Sohail

1 0