December 2004 - Boost - lists.preview.boost.org

RE: [boost] Re: Cross Builder, v1.0
by Ferdinand Prantl 15 Dec '04

15 Dec '04

Hi Hajo, > From: Hajo Kirchhoff > > I am trying to decide on a build tool for the Lit Window > Library and am considering bjam, cmake, bakefile and would > just like to get an opinion about your tool before delving > deeper into it. BTW, I need linux support as well as VC6++ > and .NET project creation, meaning the tool should create > .NET project/solution files rather than acting as a build tool. I wanted the same - just generate makefiles/projects. I use tmake (1.11 with some tweaks of me) from Trolltech (predecessor of qmake written in Perl). It generates makefiles/projects from templates and creates them for a platform from a couple of lines in a file.pro. You must run the build afterwards manually. Doxygen uses tmake, for example and Qt uses qmake, which has the same principle and configuration. The discussion gets a little off-topic... ;-) Ferda

1 0

Front page, one last time.
by Rene Rivera 15 Dec '04

15 Dec '04

Boosters, OK, I haven't heard anything in the way of further comment on the new front page design. I've put in a version of the current logo while we work that out. And done some minor cleanup of the css and xhtml: http://redshift-software.com/~grafik/boost/index.htm Boost C++ Libraries If there aren't any serious objections, I'll go ahead and commit this to CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

16 33

RE: [boost] Re: Re: rational with finite precision
by Michiel Salters 15 Dec '04

15 Dec '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: zondag 12 december 2004 22:48 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: rational with finite precision ... > Finally, it would be nice if someone would actually submit > infinite precision number types ... Are you aware of N1692? There will probably be two follow-ups to it, one (N1718) by the same author who will be proposing a rational class as well, and one by me ( currently still in MSWord form, and I'm waiting for a number) which proposes standardese for an <integer> header/class. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Config library public or not?
by Ulrich Eckhardt 15 Dec '04

15 Dec '04

Hi! The documentation says the lib is not intended for users of boost, but only to aid implementing boost itself. I asked the question some time ago (long before 1.32) and the consensus was that it was in fact public and the documentation was wrong/outdated, but even with this release it didn't change. What's the deal? Did I miss anything? Uli

4 4

[Boost-bugs] [ boost-Support Requests-1085691 ] Boost-1.30.2 and gcc-3.4.2
by SourceForge.net 15 Dec '04

15 Dec '04

Support Requests item #1085691, was opened at 2004-12-15 02:08 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=1085691&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost-1.30.2 and gcc-3.4.2 Initial Comment: I cannot build the boost-1.30.2 with the new compiler gcc-3.4.2 on RH and EM64T machine. Does this version support the new compiler? The last boost version - 1.32 passed compilation with gcc-3.4.2 without problems. Thanks, Genia ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1085691&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Language Binding API
by Brian Braatz 14 Dec '04

14 Dec '04

A few months ago I recall David Abrahams sent a quick mail that referenced a Language Binding API for hooking in dynamic languages into C++. It looked like something he was brewing on. I was just curious if anything became of that. (or is it like those 1,000 things I have on my plate and have not been able to finish :) ) Dave?

3 2

is_abstract update
by John Maddock 14 Dec '04

14 Dec '04

Following on from the recent discussion, we now have: BOOST_NO_IS_ABSTRACT added to the config system, this is likely to cause some new failures with config_test.cpp until we get the macro added to those compiler config files that need it (although Gcc, Visual C++, Borland C++ are already taken care of). is_abstract no longer uses SFINAE when BOOST_NO_IS_ABSTRACT is defined, instead it defaults to the same value as is_polymorphic: the rationale is that "true" is the safe default (if there is one), but since non-polymorphic types obviously can't be abstract, we can safely evaluate to false for those. Users wanting some other behaviour should check for BOOST_NO_IS_ABSTRACT. Robert, is this enough for you to fix the ODR problem in the serialisation lib for is_abstract? John.

4 5

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? Good catch! I can confirm that it is indeed a problem. Should have a fix in a day or two. The last error code is set to ERROR_FILE_NOT_FOUND in the particular case you are talking about, and something else otherwise, so it is possible to distinguish it from other conditions. --Beman

1 0

patch: Boost.Jam: PATH_MAX not defined in SCO 5.0.5
by Davlet Panech 13 Dec '04

13 Dec '04

Added default for PATH_MAX as it isn't defined on my system (sco3.2v5.0.5/gcc2.95.2) --- tools/build/jam_src/pwd.c.orig 2004-12-13 14:58:32.362510600 -0500 +++ tools/build/jam_src/pwd.c 2004-12-12 17:32:07.000000000 -0500 @@ -21,7 +21,9 @@ #endif #endif - +#ifndef PATH_MAX +# define PATH_MAX 4096 +#endif LIST* pwd(void)

1 0

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >I noticed that Boost.Filesystem doesn't use readdir_r to iterate over >directories, even if it is available, making that non-thread-safe. >There is a comment to this effect in operations_posix_windows.cpp. > >I've attached a patch that I believe will allow it to detect whether >readdir_r is available and to use it iff it is. I have only tested this >on Linux with g++ 3.3, but I tried deliberately breaking the declaration >of readdir_r and verified that the code continues to work without it. Interesting approach! I guess the alternative is hand configuration, and that isn't very attractive. So let me take a look at your patch in detail and get back to you. >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? I've got some code that should serve to check that out. I'll let you know. > Unfortunately it's impractical to test >automatically, as empty volumes are hard to generate on demand! That's one of the difficulties of the library; there are quite a few test cases which are difficult and/or expensive to create on demand for testing. Thanks for you help, --Beman

1 0