- Boost - lists.boost.org

tools/regression/run_tests.sh
by Jody Hagins 14 Apr '04

14 Apr '04

Straight out of CVS, run_tests.sh has the following on line 88: export BOOST_BUILD_PATH="$boost_build_path" "$BOOST_BUILD_PATH" which, of course, generates an error. Does anyone know the intent of this line? I can think of two obvious possibilities... 1. Prepend $boost_build_path to BOOST_BUILD_PATH, in which case it should be something like: if [ "${BOOST_BUILD_PATH}" ]; then BOOST_BUILD_PATH="$boost_build_path:$BOOST_BUILD_PATH" else BOOST_BUILD_PATH="$boost_build_path" fi which is a bit verbose, but probably necessary for max /bin/sh portability. 2. Just set it to boost_build_path: BOOST_BUILD_PATH="$boost_build_path" However, there could be some other intent, so I am not sure how I want to fix this. Anyone know? Thanks! -- Jody Hagins

2 4

Re: [boost] Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 14 Apr '04

14 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 11:17 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > From: =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= <joaquin(a)tid.es> > > De: Rob Stewart <stewart(a)sig.com> > > [index_list naming] > Now that I am, what about changing it to "indexes" or "indices" > according to your preference? IOW, I don't think "list" needs to > be part of the name at all. That name works fine regardless of > whether it is elaborated. It does not look bad, actually. But I'm really trying to narrow the target down now. Do you have strong objections to index_list? Nobody else complained. [moving into boost::container] > > Well, it's all about not wasting effort. Hopefully, some > > other boosters (and the authors of container libraries > > in Boost) will jump in and express themselves for a > > That will be ideal. I wasn't paying attention, but has this been > addressed in a separate thread with an appropriate subject in > order to garner their involvement? No. I don't feel like rising the noise level more than now by beginning a new thread. IMHO, it's unlikely that this will get any more attention (and it could be that it does not deserve it after all.) [philosophical discussion about convenience of 1st level namespaces] (excuse my snipping) Well, just for the record, what's your "vote" about pushing/not pushing into boost:container? It is not clear to me which side you're a supporter of. So far, noone has expressed any strong opinion on either option. (btw, thanks for involving into this discussion) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

RE: [boost] Re: Date-Time
by Powell, Gary 14 Apr '04

14 Apr '04

Rob wrote: >> >> Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 >Why? I can't imagine a good use case for wanting one, two, or >three days before the end of the month as a special form of date. To make this work: date d = January LAST-1; // the 30th add_month(d); d == February 27th or 28th depending on the leap year, add_month(d); d == March 30th; Which is why the specialized function is the way to go. LAST isn't enough and anything else is cumbersome, buggy and hard to maintain. Yours, -Gary-

2 1

RE: [boost] Re: Yo, move semantics anyone?
by Powell, Gary 14 Apr '04

14 Apr '04

>David Abrahams wrote: >> I'm just wondering if the deafening silence indicates a lack of >> interest or whether something else is going on? >The latter. Thanks for your efforts, I for my part will definitely have >a closer look on it when time allows. Stephan wrote: >BTW, what was the result of the proposal on clarification of this? Dave went to Sidney and pitched it. It passed as a Defect Report which is great news as it means that the current crop of compilers are required to fix this now not in N years when the C++0X standard is released. Yours, -Gary-

2 1

RE: [boost] Re: Date-Time
by Powell, Gary 14 Apr '04

14 Apr '04

>From: Jody Hagins <jody-boost-011304(a)atdesk.com> >> "Powell, Gary" <powellg(a)amazon.com> wrote: >> >> > That would surprise me as well. >> > >> > date = January 30; >> > >> > add_month(date); >> > add_month(date); >> > >> > date == March 30 ? Not March 28/29 No? >I'd expect April 1st or 2nd, depending upon whether it was a leap >year. I'm not sure what you're saying you'd expect. I'd expect March 30th. >For my expected result, it would simply increment the month and >then check for the corresponding day of the month. If it's past >the end of the month, it falls back to advancing by 30 days. >Then, the logic is repeated by the second call. I understand what you think you want but in practice I don't think it would work out as nicely as you think now. >> Or, instead, you use something like... >> >> date = January END or LAST; >> >> meaning the last day of the month. Then, adding a month would always >> jump to the last day of the next month. I imagine with... >That would work well. Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 That's why I use seconds.. >> date = February 28; >> add_month(date); >> >> you would want March 28, and not March 31??? >Yes. I would expect this as well. the 28th is either LAST, or just plain old 28th. Personally I like Jeff's solution, that you provide the increment function. Because it sounds like we have different use cases for "next month" The loose case of "see you for your next appointment next month", and "delivery is in One Month". Where 30 days is the "next month" vs the calendar end. Yours, -Gary-

2 1

RE: [boost] Re: Date-Time
by Powell, Gary 14 Apr '04

14 Apr '04

>Bob Bell wrote: >The interpretation that makes sense to me is: adding one month means the >same day of the next month, unless the date's not valid, in which case I >expect moving backwards to the latest date of said month. That's what >humans do when you say "next month", so I would think anything else >would be surprising. That would surprise me as well. date = January 30; add_month(date); add_month(date); date == March 30 ? Not March 28/29 No? Which means of course a lot of state has to be held by date, because otherwise February does rounding. As in the number of days until the end of the month. Yours, -Gary-

7 11

Date-Time
by Val Samko 14 Apr '04

14 Apr '04

I did not find any functions in Date-Time library to add a number of months to a given day, or to obtain the last/first day of the month. I mean something like date add_month(const date&, int month_count); date first_date_of_month(const date&); date last_date_of_month(const date&); I understand that I can use the month_iterator instead of add_month, and end_of_month_day instead of last_date_of_month, but since the functionality I described is heavily used in some applications (accounting for instance), it would be much simpler just to call add_month, ... functions. Is there any particular reason why they are not provided? Val Samko http://val.digiways.com

4 15

FSM offtopic question
by Erdei Andras 14 Apr '04

14 Apr '04

can someone suggest a free, preferably windoze tool for creating graphics represantion of FSMs ? something using an editable format, but allowing GIF/BMP/whatever export for documentation would be nice. tia andras

2 1

[serialization] all wide tests were failing because...
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, if you recall, all wide archive tests were failing for me. They still failed with #18, and now I finally (after quite some debugging) know why. The error I was getting was: Exception in "call_test_main": std::length_error: basic_string::reserve It occured even on test_vector, which is fairly simple. The generated data contained this: 22 boost::serialization .... note that this was for wide archive, where the data should have being in UCS-4 encoding, i.e. ('2' <zero> <zero> <zero> '2' ...) The reason, once found, is simple: { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); } You change codecvt in archive constructors and the archive also has locale saver. The destructor for archive is called *before* destructor for 'os'. At this time, codecvt is switched back, right? So, when destructor of 'os' calls 'close' which flushes the data, you're using default codecvt. If I add explicit 'os.close()' after writing to archive, the written data is correct. What this means is that destructor of archive *really should* call 'flush' on the stream. After I've made basic_text_oprimitive's destructor to flush stream: template<class OStream> basic_text_oprimitive<OStream>::~basic_text_oprimitive(){ os.flush(); } The test_vector passed with wide stream. I'm rerunning other tests now. In fact, I'm getting suspicious about changing codecvt at all. I suppose that if somebody is using wide streams, he already deals with encoding somehow, so why serialization library should try to second-guess the user? - Volodya

1 0

Re: [boost] Serialization. Pointer to constant object.
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: ... >void f3(A const* a, text_oarchive& oa) >{ > oa << a; >} >Why compiled function f1 and f2 but not f3 ? Good point. I have a fix - but it won't work for compilers that don't support Partial Template Specialization. I haven't been able to find a more general fix. Robert Ramey

2 1