January 2007 - Boost - lists.boost.org

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

13 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 13 Jan '07

13 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

[graph] leda_graph.hpp - Succ_Adj_Edge etc. undocumented in LEDA?
by Jens Müller 12 Jan '07

12 Jan '07

Are functions like Succ_Adj_Edge inofficial? I googled for them and can't find any occurence in the official LEDA documentation. The "official way" seem to be member functions of the GRAPH class ... Obviously, in that case a reference to the graph would have to be stored in the iterator as well, so I see the advantage of the current solution. But shouldn't we stick to official interfaces? I stumbled over this while looking how to add support for the EdgeListGraph concept in the LEDA graph adapter ...

2 3

[Boost-bugs] [ boost-Support Requests-1634278 ] memory pattern question
by SourceForge.net 12 Jan '07

12 Jan '07

Support Requests item #1634278, was opened at 2007-01-12 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory pattern question Initial Comment: Hi, My team developed an application in C++. The application's working set increases steadily. All leaks we could track we corrected. The last remaining leak is a difficult one. The reason I post this message here is to see if someone has an idea of what this data structure could be or a pointer to where I could look. We use template stuff in the code (trees, sets, etc etc). We look at the memory by hexanalyzing a forced core. (this is a linux app). The pattern is inside blocks of malloce'd space and these blocks appear larger and larger with similar content. The patter is as follows: int char [4] void *; void * Exactly 16 bytes, the int is 1 or 2 for the most part but I have seen 0xFFFFFFFF at times. The char at times has character but never no more than 3 followed by \0. The last two seem to be real pointers and at time 0x20 and 0x40 from each other. At first glance it looks like a tree entry but not sure. Any ideas ? Thanks David De La Rosa delarosa(a)ilstechnology.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

12 Jan '07

I should have mentioned that one can't use wait(mtx,pred) because this needs to be used in the signalling thread. It might be better to have this as a scoped_lock constructor? Anyway... > -----Original Message----- > From: Sohail Somani > Sent: Friday, January 12, 2007 10:39 AM > To: 'boost(a)lists.boost.org' > Subject: [Threads] uncoditional scoped lock? > > Hi, > > Somewhat longer-than-normal-noise follows :) > > Consider the following pseudo-code which has a race condition: > > condition g_some_cond; > mutex g_condition_mtx; > > void thread_fn() > { > { > ... // get lock > g_some_cond.wait(condition_lock); > } > // do work > } > > void main_thread() > { > thread_group grp; > // Start all threads and have them wait on the condition > for(i in [0,N)) grp.create_thread(&thread_fn); > > { > ... // get lock > g_some_cond.notify_all(); // let threads continue > } > } > > The race condition is of course that it is possible that not > all threads actually start waiting on the condition before > notify_all() is called. In this case, it is possible to solve > the race condition in two ways: > > 1) Have the last thread that reaches the condition wait, > signal to the main thread > 2) Have the main thread checking the condition before notify_all() > > I don't really like the first case because it requires > bi-directional signalling between the threads. Though in my > ignorance, I really do consider it the correct solution. The > second solution would look something like this: > > while(true) > { > scoped_lock cond_lock(g_condition_mtx); > // .num_waiting_threads() is made up > if(N_EXPECTED_THREADS==g_some_cond.num_waiting_threads()){break;} > // release lock > } > > Should the second pattern be encapsulated in the condition > object somehow? It is almost like timed_wait(mtx,xt,pred) but > there is no timeout. So maybe untimed_wait()? Is there > another way to do this? > > Thanks for your eyes! > > Sohail

2 1

[iterator] Proposal for inclusion of a csv_ostream_iterator class.
by Emre Turkay 12 Jan '07

12 Jan '07

Hi folks, Attached is the csv_ostream_iterator class, I frequently use. I think it could be incorporated into the boost.iterator library (if there is no such thing somewhere in the standart or in some boost library so far.) What it does is very similar to the std::ostream_iterator, the only difference is that it does not put a delimiter after the last element inserted. Such as when we write an integer container to a stream with a comma delimiter, we get something like this: { 1, 7, 12, 5, 8, } however by using this class the last delimiter is gone { 1, 7, 12, 5, 8 } which is mostly the intended behavior. It can be used for textual data generation (for correct CSVs and good looking XMLs) including code generation. Note: Works with gcc-4.x, may needs to be modified to be portable. Thanks, Emre Turkay

2 1