- Boost - lists.boost.org

Re: [boost] Re: Boost to the rescue
by JOAQUIN LOPEZ MU?Z 29 Apr '05

29 Apr '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Viernes, Abril 15, 2005 6:05 pm Asunto: [boost] Re: Boost to the rescue > > I'm amazed to discover that in only ONE single case have any of the > programmers, managers, etc ever even heard of boost. This group even > includes an ex head of the computer science department at a top tier > university !!! > Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because: 1. It's too big. 2. It's too hard to install. 3. The docs are too technical. 4. They fear it's too "advanced" for them to understand it. I've actually read comments on programmer sites touching on every one of these issues. My opinion is that: * #1 is not that much of an issue in a world where people are happy to install a multimegabyte IDE and don't complain about it. When it comes to installing a library, somehow they measure size by a different standard. * #2 is certainly a point, specially for Windows folks used to doubleclick on everything. Maybe it'd be a good idea to produce some graphical wizards (not necessarily as an official part of Boost) that automate the installation for at least the most commonly used platforms (read MS.) IMHO this would lower the entry barrier a lot. * As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :( Well, just some random ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

20 45

Re: [Boost-testing] Re: [thread] test_read_write_mutex breaksregressiontesting
by Caleb Epstein 29 Apr '05

29 Apr '05

On 4/28/05, Michael Glassford <glassfordm(a)hotmail.com> wrote: > <quote> > patching file util.inl > Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 350 > > This application has requested the Runtime to terminate it in an unusual > way. Please contact the application's support team for more information. > </quote> > > Any ideas why? In case it's a problem with the command line I'm > entering, what should it be? As with a compiler, this sort of tool just shouldn't crash. In the interests of expediency, I'm attaching the complete files (libs/thread/test/util.inl and test_read_write_mutex.cpp) with my changes applied. Here's the standard way I apply patches, in case this helps for the future: cd /path/to/boost/root # Test that the patch applies cleanly - if you see any "FAILED" messages, it doesn't :) patch -p0 --dry-run < patchfile # OK? Do it for real patch -p0 < patchfile -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

RE: [boost] Re: [website] Oh the fun..
by Martin Bonner 29 Apr '05

29 Apr '05

----Original Message---- From: Rene Rivera [mailto:grafik.list@redshift-software.com] Sent: 28 April 2005 16:28 To: boost(a)lists.boost.org Subject: Re: [boost] Re: [website] Oh the fun.. > Martin Bonner wrote: >> ----Original Message---- >> From: Rene Rivera [mailto:grafik.list@redshift-software.com] >> Sent: 28 April 2005 03:37 >> To: boost(a)lists.boost.org >> Subject: Re: [boost] Re: [website] Oh the fun.. > > Please change your posting program so that it doesn't include this > superfluous information. > >>> 2. I think just about all web designers agree that 800x600 is the >>> minimum one should design for at this time. >> >> Hmm. How about all (boost) USERS? > > You should already know that it's impossible to satisfy all users. Sure. But my point was that it is users, not web-designers that matter. > And the various *_ptr discussions should serve as an example. NOOO! This way madness lies :-) [snip] >> So why do you need to specify the background colour? I haven't >> looked at the source, but it looks white on my machine which is the >> default for my browser. > > What makes you assume that everyone has a default background color of > white? I certainly don't assume that, nor have my default as white. OK. I have now checked the source. The styles explicitly specify a background of white. I changed my background colour, and the design does NOT respect that. I think it should. > What you are saying is to abandon design and leave it entirely to the > browser defaults and user settings. Yes, I realize that means abandoning ANY control of colour - I don't think that is a bad thing. You can still control layout (and I would like to congratulate you on using %ages and em/pt measurements rather than px measurements). > And please don't assume that the browser developers made perfect, or > even good, choices about how to present a web page. That is depressingly true :-( > Like I just said above.. You can turn the CSS *off* and have your > browser+user settings prevail. For example with Firefox you can choose > the View/Page Style/No Style menu and voila you have your defaults. Ah! THAT was something I didn't know. Cool! That enormously weakens my argument (particulaly given that you have carefully avoided putting style information into the basic HTML). I think colour control probably /does/ make sense here (it allows the inverse banner, and the neat bullets (which are images, not characters). Having said all that: - I would prefer a more conventional appearence for the links (different colour, more striking underline - and I'm not keen on hover highlights [but that's just personal prejudice]). - I agree with the observation that Google has trained me to ignore boxes on the right Joel wrote: > IMO, Rene's work is superb. Good point Joel. I forgot to mention that didn't I? Sorry Rene - this is all carping at the edges. The overall effect is a big improvement on the main Boost website (which itself is by no means bad). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Review Managers Needed
by Tom Brinkman 29 Apr '05

29 Apr '05

The Typeof, "Function Types" and "Logging libraries" still need review manager volunteers. Contact me again at reportbase(a)google.com to volunteer. Review Queue as of April 28, 2005 1) FOREACH Macro (Starts: 25-Apr-2005; Ends: 1-May-2005) 2) Typeof (Review Manager Needed) 3) Singleton 4) Function Types (Review Manager Needed) 5) Logging (Review Manager Needed) 6) Policy Pointer 1) FOREACH Macro Author: Eric Niebler eric(a)boost-consulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler, foreach.zip BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. Documentation is at http://boost-sandbox.sourceforge.net/libs/foreach 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com Review Manager: Needed Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 4) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: Needed Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 5) Logging LIbrary Author: John Torjo <john.lists(a)torjo.com> Review Manaer: Needed Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 6. Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications.

3 2

[pool] Making it honour BOOST_HAS_THREADS
by Markus Schöpflin 29 Apr '05

29 Apr '05

Hello, attached is a patch which makes the pool library honour the general boost threading support flag. As a side effect, it also makes the pool library usable on Tru64 because on that platform you can only include <pthread.h> if you're actually compiling with -pthread. Any objections to applying this patch, anyone? Markus Index: mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/detail/mutex.hpp,v retrieving revision 1.6 diff -u -r1.6 mutex.hpp --- mutex.hpp 28 Sep 2004 12:55:44 -0000 1.6 +++ mutex.hpp 28 Apr 2005 11:41:20 -0000 @@ -19,6 +19,10 @@ #define BOOST_MUTEX_HELPER_WIN32 1 #define BOOST_MUTEX_HELPER_PTHREAD 2 +#if !defined(BOOST_HAS_THREADS) && !defined(BOOST_NO_MT) +# define BOOST_NO_MT +#endif + #ifdef BOOST_NO_MT // No multithreading -> make locks into no-ops #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_NONE @@ -37,12 +41,13 @@ #error Unable to determine platform mutex type; define BOOST_NO_MT to assume single-threaded #endif - -#ifdef BOOST_WINDOWS - #include <windows.h> -#endif -#ifdef _POSIX_THREADS - #include <pthread.h> +#ifndef BOOST_NO_MT +# ifdef BOOST_WINDOWS +# include <windows.h> +# endif +# ifdef _POSIX_THREADS +# include <pthread.h> +# endif #endif namespace boost { @@ -50,6 +55,8 @@ namespace details { namespace pool { +#ifndef BOOST_NO_MT + #ifdef BOOST_WINDOWS class win32_mutex @@ -102,6 +109,8 @@ #endif // defined(_POSIX_THREADS) +#endif // !defined(BOOST_NO_MT) + class null_mutex { private:

2 2

RE: [boost] Re: Steps before moving to Subversion
by Schrom, Brian T 29 Apr '05

29 Apr '05

Do you have a test case that we can reproduce your missing line merge and post back to Subversion? -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Thursday, April 28, 2005 7:32 AM To: boost(a)lists.boost.org Subject: [boost] Re: Steps before moving to Subversion David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: >>Never mind.. just found the documentation of svnmerge. And hence have >>some answers. > > What are they, please? I don't know them. http://www.dellroad.org/svnmerge/index >>But here's the thing, it solves the book keeping aspect of the svn >>merge. But it doesn't solve the problem I had. It's not like I did not >>follow the procedure of marking the comments with merge points and >>using "-r N:M" to only merge the un-merged changes. My problem was >>that the svn merge operation lost a line, literally. Which means that >>the conflict resolution algorithm has a problem. So unless there's a >>solution out there that doesn't use "svn merge" we might get bitten. > > Oh. Well it's not nice to have a bug, but you have to check your > merge results by hand anyway, don't you? Of course you should check the merge results.. And I did in this case. But what I did was open the source file, which has the usual "<<<" and ">>>" conflict markers, and edit to make sure all the changes where in there. But that conflict result was missing a line. When I did a diff from what I had to the repository version on my branch, the other check I go through when merging, the missing line obviously didn't show either. What I failed to do was do a manual diff between the two other original source files, the head revision and the branch revision, which svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

Re: [boost] Re: Re: [circular_buffer] comparison operators
by Jan Gaspar 29 Apr '05

29 Apr '05

Hi Frederik, the discussion didn't end up with a conclusion. (I appended all the submissions regarding this comparison operators issue.) In my opinion, there was an idea behind the fact the comparison operators don't work for different types at the time the STL was being designed. Although I don't know what idea it was. (Does anyone?) Regardless it was good or not I'd like the circular_buffer to behave the same way as other STL containers. I don't want to break the contract. On the other hand when we consider comparison between 2 circular_buffers of different types, why not to take it one step further and allow comparison of 2 different containers. E.g. circular_buffer<int> x = { 1, 2, 3}; deque<short> y = { 1, 2, 3}; x == y; // makes sense? It doesn't matter that the containers are of different types - it is about comparing content, isn't it? Jan --- Fredrik Blomqvist <fredrik_blomqvist(a)home.se> wrote: > Jan Gaspar wrote: > > Hi Fredrik, > > > > I'm attaching the discussion during the formal > review > > regarding the comparison operators. > Thanks. I now remember reading some of those posts. > Did you reach a conclusion then? (Guess I have to > dig the archives a bit...) > > > into the reading, I'd like to say that my > intension > > was to write STL compliant container nothing less > or > > more and I'd like to stick with this. > That's a goal I fully support! But to my > understanding > making this change wouldn't compromise compliance > (?). > And as mentioned, several other boost components > already > use this scheme, in this context most notably > multi-index. > > Regards > // Fredrik Blomqvist > > > > Subject: RE: [boost] Formal Review: Circular > Buffer > > Date: Tue, 9 Mar 2004 09:44:34 -0800 > > From: "Powell, Gary" <powellg(a)amazon.com> > > To: boost(a)lists.boost.org > > > > > > Shouldn't the comparison functions allow the types > to > > differ? I mean > > don't they still lexigraphically compare as long > as > > there is a comparison > > function F that a F b for each element exists > > > > circular_buffer<T, MyAlloc> x; > > circular_buffer<S, YourAlloc> y; > > > > bool b = x == y; for where the operator T == S is > > valid? And what does > > the allocator have to do with it? > > > > Therefore IMO, all of the comparison functions > should > > change from > > > > template< typename T, typename Alloc> > > bool operator F ( circular_buffer<T, Alloc> &lhs, > > circular_buffer<T, Alloc> &rhs); > > > > to > > > > template< typename T1, typename Alloc1, > > typename T2, typename Alloc2> > > bool operator F ( circular_buffer<T1, Alloc1> > &lhs, > > circular_buffer<T2, Alloc2> > &rhs); > > > > Yours, > > -Gary- > > > > ----------------------------------------------- > > > > > > To: boost(a)lists.boost.org > > From: "Pavel Vozenilek" > <pavel_vozenilek(a)hotmail.com> > > > > Date: Tue, 9 Mar 2004 20:52:29 +0100 > > Subject: [boost] Re: Formal Review: Circular > Buffer > > > > > > Hmm, do you know a STL implementation/some > container > > with this feature? It may be often bug to compare > > containers with > > different types. > > > > /Pavel > > > > > ----------------------------------------------------- > > > > Subject: RE: [boost] Re: Formal Review: Circular > > Buffer > > Date: Tue, 9 Mar 2004 13:55:15 -0800 > > From: "Powell, Gary" <powellg(a)amazon.com> > > To: boost(a)lists.boost.org > > > > > > No, but just because the standard libraries > scr*wed up > > is no reason to perpetuate the mistake. > > > > It's the rule of unexpected consequences. > > > > Is > > circular_buffer<int> x = { 1, 2, 3}; > > circular_buffer<short> y = { 1, 2 ,3}; > > > > x == y ?? or not? > > > > Sure looks like it should work. > > > > The VTL library does it IMO correctly, allowing > that > > if there is an operation T1 F T2, then V1 F V2 > > compiles. Otherwise you just force the user to > write > > what should be library code. > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

3 3

Re: [boost] Re: Boost to the rescue
by JOAQUIN LOPEZ MU?Z 28 Apr '05

28 Apr '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Miércoles, Abril 27, 2005 11:05 pm Asunto: [boost] Re: Boost to the rescue > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > * As for #3 and #4, I've got this idea round my head > > that Boost would benefit of a "community site" where > > people of various expertise levels could mingle > > together, post Boost-related articles, etc. Something > > like CodeProject or Gamedev, which have a less > > intimidating appearance than www.boost.org. Some months > > ago I asked for a Boost-related forum in CodeProject, > > to no avail :( > > Something wrong with boost-users? There *must* be something wrong with it: Consider the (developer list)/(user list) posting ratio, around 10:1 --I guess (I hope) that the actual developer/user ratio is much lower than that. So, it seems like somehow the list is not so popular. Some hypotheses as of why: * Posting to and scanning a mailing list is not an impulsive action, and takes some will from the part of the poster. * The list could feel a little imposing, as most of the time it is the lib's author herself who responds. Somehow this formality prevents casual chatting, experience sharing etc. I'd hope most of the support to be provided by other users, not the authors. * Response time is not as fast as with a forum. * The looks ain't sexy. * Boost users don't really have that many problems to consult about :) > > If so, I'd be happy to set up a forum at boost-consulting.com, if we > can decide on the right software. > A couple of seemingly popular free bulletin packages are YaBB and MyBulletinBoard. More ambitious community packages are Plone (which has about anything) and Postnuke: these two latter could serve as the basis for a fuller community site. Joaquín M López Muñoz Telefóinca, Investigación y Desarrollo

3 4

[Boost-bugs] [ boost-Bugs-1191985 ] boost/functional addressof collision
by SourceForge.net 28 Apr '05

28 Apr '05

Bugs item #1191985, was opened at 2005-04-28 14:15 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=1191985&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Foster Brereton (fosterbrereton) Assigned to: Nobody/Anonymous (nobody) Summary: boost/functional addressof collision Initial Comment: in boost/functional.hpp, line 473: if (!detail::function::has_empty_target(addressof(f))) { addressof is a function that resides in the Metrowerks namespace as well, so there are instances in boost::bind that will fail with an ambiguous lookup. Specifying boost::addressof explicitly will fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191985&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Big integer continued
by Marcin Kalici�ski 28 Apr '05

28 Apr '05

Hi, I got the big integer proposal document id wrong, it is actually n1744, here's a link to it: http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf I think there are 2 major, separate issues with big integer class: interface and implementation. 1. Interface Class name is 'integer'. Some sort of rationale for this name is in n1744: "just like std::string introduces a variable length string to complement char[N], this class introduces an integer class without a fixed size". It will be a signed integer. Unsigned version could also be done, but does it give anything extra? I plan to make the interface closely resemble that of boost::rational, as it was already accepted into boost. What I like about it is being minimalistic. I'd like to follow that style, it is much easier to add new functions later than to remove existing ones. What I plan to have initially: - construction from long - construction from const char *, possibly also std::string (strings with C-style number literals, but with unlimited length) - addition, subtraction, multiplication, division, modulo - increment, decrement (pre and postfix) - unary plus and minus - all comparisons - bitwise operations (and, or, xor, not). - shifts - conversion to unspecified bool type - stream input and output There's an issue with some of the bitwise operations, as they are only well defined for integers of fixed size. What should for example ~boost::integer(0) return? Ideally an infinitely long integer filled with binary 1s. boost::rational does not have a conversion operator to integer type, which is good as most of rationals are not integers. Should boost::integer have such an operator, with runtime range checking? 2. Implementation Current implementation uses the following representation: bool sign; std::vector<some unsigned integer type> ; The basic question is how far should I go with performance optimization? It is of course impossible for one person to achieve the performance level of some estabilished big integer libraries, such as GMP. Addition and subtraction of large integers can be done very efficiently in assembly language of most processors, for example on 80x86 by utilizing carry flag. Portable C++ implementation would be probably about a magnitude slower. I haven't measured that, but I have a portable implementation and it does a lot of ifs just to detect integer overflows. Unlike boost::rational, implementation of some big integer operations (multiplication, division) is not easy, depending on the performance we are trying to get. There are several multiplication algorithms with different complexity bounds. The fastest known is Strassen multiplication using FFT, as far as I know. There are also some in-the-middle algorithms, such as Karatsuba multiplication. Performance-oriented libraries choose one of them depending on multiplicands sizes. Implementing all that may be a real pain, and implementing that in assembly language optimized for some processor is a task outside my capabilities. And there are also multi-processor multiplication algorithms... Another idea would be to write portable, potentially slow implementations only, and allow boost::integer to use some existing libraries internally, when user really cares about speed. cheers, M.

1 0