- Boost - lists.preview.boost.org

Suggested addition for BOOST_WORKAROUND
by Gennaro Prota 24 Mar '04

24 Mar '04

Hi, as pointed out when BOOST_WORKAROUND was being discussed, Borland C++ (I think, up to 0x600 excluded) just emits an optional warning for division by zero. The warning is enabled by default, but can be turned off with -w-zdi or -w-8082. So I (re)propose to add a special BOOST_WORKAROUND implementation for it: #if defined(__BORLANDC__) && (__BORLANDC__ < 0x600) // Borland needs a special version, as it just emits a warning for // division by zero (and you can even disable it with -w-zdi or // -w-8082 !!). But it supports sizeof expressions in #if-s // (NOTE: that's non-conforming) // # define BOOST_WORKAROUND(symbol, test) \ (((symbol) != 0) && (1 != sizeof(char[1 + ((symbol) test)]) )) #else # define BOOST_WORKAROUND(symbol, test) \ ((symbol != 0) && (1 % (( (symbol test) ) + 1))) ... Notes: a) it should be verified whether version 0x600 has the same problem or not; given that it uses an EDG front-end it probably won't, but who knows what they could have decided in the name of backward non-conformity :) b) I suggest to use __BORLANDC__ directly, instead of the (maybe) upcoming BOOST_BORLAND_xxx, to avoid including config.hpp for such a simple header. PS: Giovanni, I asked you in private mail a while ago. What does your 'typo revealing' patch do? -- Genny.

2 4

[program_options] post-review version -- compile problem
by Rob Lievaart 24 Mar '04

24 Mar '04

Hi, I just downloaded and compiled the version 262 of the library using Mingw (gcc 3.2.3) and I ran into a problem compiling parser.cpp: The function parse_environment contains the following lines: #if defined(_WIN32) char **environ = _environ; #endif But the mingw provided stdlib.h contains an unconditional #define environ _environ So it does not compile :-( I changed parser.cpp to #if defined(_WIN32) && !defined( __MINGW32__ ) char **environ = _environ; #endif And now it compiles and the samples run, but I have not actually tried to use enviroment variables. Also I checked the stdlib.h provided with MSVC6.5 and that contains #ifdef _POSIX_ extern char ** environ; /* pointer to environment table */ #else But I guess this would not cause a problem when _POSIX_ is defined, because the local environ would just hide the one from stdlib.h. And a small question, is the library supposed to work with 6.5 at all? I get a rather large amount of errors and warnings when I try to build it. I haven't looked into them yet, if it is not supposed to work then I won't spend any time on it. Rob Lievaart

3 3

RE: [boost] Formal Review: Indexed Set
by Powell, Gary 24 Mar '04

24 Mar '04

After a first quick review of the code, indexed set has the same problem as circular queue does with comparison operators. Only one value type comparison is possible. IMO, if two value types have a valid comparison operation, then they are comparable. Memory allocation should have no bearing on this, and the types do not have to be identical. i.e. an indexed set of shorts, { 1, 2, 3 } is equal to an indexed set of longs { 1L, 2L, 3L }. This means that less user code is written for these sort of things. More to come as I have time to spend... -Gary-

3 2

RE: [boost] FC++ examples?
by Rozental, Gennadiy 24 Mar '04

24 Mar '04

On Wed, Mar 03, 2004 at 08:03:20PM +0100, Giovanni Bajo wrote: > Are there a couple of examples showing real-life C++ problems that can be > solved with the help of FC++? > The paper > FC++: Functional Tools for OO Tasks > on the FC++ web page talks about how to use FC++ in the implementation > of common OO design patterns. The web page also points to the XR and for all these patterns we already have different (much better IMO) solutions. > > help, within a normal C++ program. The quicksort example was very cool, but it > > turns out that the generated code is too slow to be used for everything. If I > > need FP everywhere, I change language. > The quicksort example and also the tree iterator example I posted are > interesting. I posit that there are cases where shorter/easier code > may be more valuable than code that wins on raw performance, but > perhaps this is too-unpopular an idea among C++ people. Do you really beleave that quicksort could be an example that shows usefullness of lazy lists? I don't say that raw performance sould be primary goal, but an abstraction price should be commensurable to advantages. And I still do not see a single example of that. Gennadiy.

1 0

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