- Boost - lists.boost.org

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 24 Mar '04

24 Mar '04

> out. I think the sheer difficulty of generic/template/ > meta-programming should cause us to welcome thorough examples > of working libraries, because at the least, they show us what > can and can't be done, and serve as a model full of lessons > that can be re-used in other contexts. Let's not mix apples and oranges. C++ type system present natural environment for FP techniques, and we bound to use them. While submitted library promote FP in runtime environment. And I found it difficult to justify to myself need for that without clear examples and tests. > Even just discussing > the library helps formalize idioms and practices that maybe > some people find obvious, but are not gathered together into > any definitive document. These idioms already formalized pretty good in FP dedicated literature. Gennadiy.

6 14

Interpretation of failing prg_exec_fail2 regression test
by Toon Knapen 24 Mar '04

24 Mar '04

Currently the prg_exec_fail2 regression test fails on IBM VisualAge but this depends on how you interpret it. This regression test is supposed (by its creator) to fail at runtime because of a detection of a division by zero. If the executable does not detect the division by zero, the regression test is reported to fail. AFAICT this is not a failure of the executable on IBM, this is just a property of the executable. The idea of the regression tests is to verify if there are no regressions (by definition) and they are also used to verify if the compiler and created exe react as required by the standard. Well AFAIK nowhere is required that a division by zero is detected. It's just that some processors detect it, others don't. But I don't think regression tests should not be used to test 'properties' of the compiler or executable. Because I for instance interpret a failing regression test as being an error of the compiler or exe. There is a way though to detect division by zero with VisualAge by setting a specific pragma. However this incurs a runtime penalty (for the extra error checking code) so we don't want to do this in general. So I can assure the test to run as expected but I don't want to cripple performance just for the sake of passing this regression test. I can see 2 solutions: 1) Or regression tests are not used anymore to test *properties* of the platform/compiler/exe 2) Or I include the pragma only for this regression test just for the sake of passing the test. I definitly prefer option 1 because I consider option 2 as a cheat. toon

2 1

status of FC++ review
by Dave Gomboc 24 Mar '04

24 Mar '04

> The circular_buffer library by Jan Gaspar has > been accepted into Boost. Did I miss the accept/reject for FC++? Dave

2 1

boost FSM and another idea
by jp 24 Mar '04

24 Mar '04

hey boosters i was searching for finite state machine ideas and i came across some old posts from Bryan Ross and Andreas Huber regarding a boost fsm. i love boost, even tho i havent really used it much. i intend to get to grips w/ boost::graph soon. i dont kno if there is now a boost::fsm. the above messages were in 2002! anyway, i have been using an object oriented fsm pattern for years now which uses virtual function dispatching in place of the old function pointer table thingy. i find it very robust & easy to understand. i have made a few preliminary ventures into boosting it into a generic template, and i wonder if theres still any interest in this idea. i have a tendency to see everything in computer science as either a graph or a proposition, so i find fsm's almost universally applicable... heheh another offspring of my fevered brain is a little lisp (or maybe its a scheme..?), & i wondered about adding something like this to boost. it is already amenable to templated type extensions and *i* like it. i call it terp, so maybe it could be called boost::terp. any comments? cheers. jp the a/p

12 20

[Boost-bugs] [ boost-Bugs-922097 ] Bugs in atomic_count_gcc.hpp
by SourceForge.net 23 Mar '04

23 Mar '04

Bugs item #922097, was opened at 2004-03-24 00:02 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=922097&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Huber (andreas_huber69) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs in atomic_count_gcc.hpp Initial Comment: These have been reported before: http://lists.boost.org/MailArchives/boost/msg57537.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=922097&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Review Result: Circular Buffer
by Pavel Vozenilek 23 Mar '04

23 Mar '04

The circular_buffer library by Jan Gaspar has been accepted into Boost. The reviews were helpful in finding at least one issue with the library and few ones with its documentation. Thanks to all reviewers for the time and effort! Post-review version 3.7 will be released before code gets into main CVS. Main points to be addressed: - issue of copy construction versus construct/destruct has been cleared (the problem was created by me) - documentation should list exception safety for every function - documentation may add some rationale on its internal data structures and their advantage over std::deque - portability problems should be solved - adaptor with notification when oldest element gets pushed out of bufer may be added Other points that may be considered: - name of data() function - existence of push_back(void) like functions - using new iterator adaptors - difference between resize/set_capacity may be more emphasized in docs, - other fixes/improvements suggested during review. Thanks for professional quality work, Jano. /Pavel

1 0

AW: [boost] Design flaw in Date-Time Library?
by Wolf, Frank 23 Mar '04

23 Mar '04

Hi Jeff, > > According the comments in one of the headers constructing a > > "time_period" with zero duration is not possible; i.e. the > duration is > > at least 1. > > Where is this? It's in file "period.hpp" after line 35. > I believe I agree, but it is going to take awhile to evaluate > the impact. In the meantime, I recommend using is_null() to > avoid this. Or if you want to take a crack at changing the > logic on your own it is really a matter of modifying the > date_time/period.hpp file. Well I already changed period.hpp for me. That's what I did: 1. Replaced member "last_" by new one called "end_" which now stores the next point in time not belonging to the period. 2. Changed all methods, operators and constructors to use the new variable correctly. 3. Added a new constructor which accepts just a "ptime" as argument. Unfortunately I couldn't make regression tests to ensure that this change doesn't have any negative side effects. Regards, Frank ps: is_adjacent() is using method "begin()" where it could use "begin_" instead which might be more efficient. ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

1 0

Re: [boost] Re: [config] Patch for Intel 8.0 + Dinkum lib
by Stefan Slapeta 23 Mar '04

23 Mar '04

Gennaro Prota <gennaro_prota(a)yahoo.com> wrote: // // FWIW, I always use at least the following in my .cfg file: // // /Qms0 // /Zc:wchar_t,forScope // -Qoption,c,--arg_dep_lookup // -Qoption,c,--alternative_tokens // // plus, when possible, /Za and -Qoption,c,--dep_name in the command // line. If you have other things that can be useful... Collecting the // switches that unleash the real beast living inside Intel C++ has // become sort of a hobby of mine :) // You can find all the front end switches at www.edg.com. -Qoption,c,--dep_name does not work for the VC 7.1 library (<locale> and others). But maybe this can be patched easily. Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

2 2

Design flaw in Date-Time Library?
by Wolf, Frank 23 Mar '04

23 Mar '04

Hi all, maybe this has already been discussed here!? I have a problem constructing an "time_period" object with a duration of zero which seems to be a special case not handled properly in my opinion. According the comments in one of the headers constructing a "time_period" with zero duration is not possible; i.e. the duration is at least 1. Whats the rationale to make construction of this special case possible then? (see code sample). That means what's the rationale not to handle the special case of a zero duration? Please see the following sample code: ------------------------------------------------------------------------ { // Contruct a time_period representing a whole day ptime pToday(date(2004, 2, 29) ); time_period wholeDay(pToday, time_duration(24, 0, 0) ); std::cout << to_simple_string(wholeDay) << std::endl; // Contruct a time_period representing just the next point of time ptime pTomorrow(date(2004, 3, 1) ); time_period wholeDay2(pTomorrow, time_duration(0, 0, 0) ); std::cout << to_simple_string(wholeDay2) << std::endl; // Our second period is not contained in the first one if (wholeDay.contains(wholeDay2) != false) std::cout << "Error" << std::endl; } ------------------------------------------------------------------------ gives: [2004-Feb-29 00:00:00/2004-Feb-29 23:59:59.999999] // Correct [2004-Mar-01 00:00:00/2004-Feb-29 23:59:59.999999] // Wrong? Error? // Wrong!!! >From my understanding the second time_period is not contained in the first one, but the design of the library gives such a result. Wouldn't it make sense to change the definition of the "time_period" class to handle the special case of a zero duration too? At least it should not be possible to construct a "time_period" with zero duration!? (But I would really favor a solution which regards a "ptime" equvalent to the special case of a "time_period" with zero duration). Regards, Frank ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

2 1

Compiler identification macros (please comment)
by Gennaro Prota 23 Mar '04

23 Mar '04

As recently come up (again) in the threads "Comment regarding __GNUC__ spoofing" "[config] Patch for Intel 8.0 + Dinkum lib" boost library developers have often a need to know the exact compiler in use, but they have no straightforward and easily maintainable way do that. The issue is that they can't just rely on compiler "identification" macros, as predefined by each compiler, because those are not *unique* to each compiler. Two typical cases are __GNUC__, which is defined both by g++ and Intel for Linux, and _MSC_VER which is defined by several compilers. A test for "real" g++, for instance, would look something like #if defined(__GNUC__) && !defined(__ICL) && !defined... which is unnecessarily tedious, error prone and hard to maintain. The problem would be solved if the config system exposed a macro for each compiler that it identifies. There seems to be agreement that this should be done, so please express your opinion about the names you prefer for the macros, or tell why you don't want them. I heartedly ask for *short* names, because preprocessing lines become easily enourmous otherwise (the typical test has the form: #if defined(MACRO_NAME) && (MACRO_NAME <= xx)). Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis): BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2) ---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym. Genny.

9 10