- Boost - lists.boost.org

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

patch: Boost.DateTime wide string conversion in MSVC6
by Davlet Panech 13 Dec '04

13 Dec '04

Added missing int64_t to wide string conversion for MSVC6. --- boost/date_time/posix_time/time_formatters.hpp.orig 2004-12-13 14:52:15.054188600 -0500 +++ boost/date_time/posix_time/time_formatters.hpp 2004-12-12 17:42:54.000000000 -0500 @@ -6,7 +6,7 @@ * Boost Software License, Version 1.0. (See accompanying * file LICENSE-1.0 or http://www.boost.org/LICENSE-1.0) * Author: Jeff Garland, Bart Garst - * $Date: 2004/11/04 12:28:49 $ + * $Date: 2004/10/29 06:27:24 $ */ #include "boost/date_time/gregorian/gregorian.hpp" @@ -26,6 +26,20 @@ namespace boost { namespace posix_time { + +#if (defined(BOOST_MSVC) && (_MSC_VER <= 1200)) // 1200 == VC++ 6.0 + namespace detail { + template <typename charT> struct convert_int64; + template <> struct convert_int64<char> { + static char *convert (char *buff, boost::int64_t i) + { return _i64toa(i, buff, 10); } + }; + template <> struct convert_int64<wchar_t> { + static wchar_t *convert (wchar_t *buff, boost::int64_t i) + { return _i64tow(i, buff, 10); } + }; + } +#endif // template function called by wrapper functions: // to_*_string(time_duration) & to_*_wstring(time_duration) @@ -69,7 +83,7 @@ date_time::absolute_value(td.fractional_seconds()); // JDG [7/6/02 VC++ compatibility] charT buff[32]; - _i64toa(frac_sec, buff, 10); + detail::convert_int64<charT>::convert(buff, frac_sec); #else time_duration::fractional_seconds_type frac_sec = date_time::absolute_value(td.fractional_seconds()); @@ -138,7 +152,7 @@ date_time::absolute_value(td.fractional_seconds()); // JDG [7/6/02 VC++ compatibility] charT buff[32]; - _i64toa(frac_sec, buff, 10); + detail::convert_int64<charT>::convert(buff, frac_sec); #else time_duration::fractional_seconds_type frac_sec = date_time::absolute_value(td.fractional_seconds());

1 0

patch: Boost.DateTime with MSVC6/STLport IOStreams
by Davlet Panech 13 Dec '04

13 Dec '04

Workaround for an internal compiler error in VC6 when compiled with STLport iostreams. --- boost/date_time/date_formatting.hpp.orig 2004-12-13 14:09:35.404548400 -0500 +++ boost/date_time/date_formatting.hpp 2004-12-12 17:42:53.000000000 -0500 @@ -27,7 +27,16 @@ template<class month_type, class format_type, class charT=char> class month_formatter { - public: +// Workaround for ICE in MSVC 6 when building with STLport IOstreams +#if defined (BOOST_MSVC) && BOOST_MSVC <= 1200 && \ + (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) && \ + !defined (_STLP_NO_OWN_IOSTREAMS) + private: + typedef std::basic_ostream<charT> _ostream_type; + public: + static _ostream_type &format_month(const month_type& month, _ostream_type &os) +#else + public: //! Formats a month as as string into an ostream /*! This function demands that month_type provide * functions for converting to short and long strings @@ -35,6 +44,7 @@ */ static std::basic_ostream<charT>& format_month(const month_type& month, std::basic_ostream<charT>& os) +#endif { switch (format_type::month_format()) {

1 0

RE: [boost] Re: Unzipping the Boost distro
by Ferdinand Prantl 13 Dec '04

13 Dec '04

> From: David Abrahams > Ferdinand Prantl wrote: > >> From: boost-bounces(a)lists.boost.org > >> [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > >> > >> I just downloaded boost-1.32.0 and started to unzip it with the > >> built-in facilities in Windows XP; the OS reported it was going to > >> take 50 minutes and it was *crawling*. Using cygwin's > unzip tool it > >> was done in under a minute. > >> > >> I'm thinking we should stop distributing raw .zip files without an > >> extractor... > > > > Hmm, I have never tried it. I always use Info-Zip's unzip or the > > That's what I mean. I used the built-in unzipper in the Win > XP file manager. OK, I tried it with the WinXP extractor in the explorer (I used the copy&paste files method). It estimated at first 25 minutes, after a minute only 9 minutes and it finished after 20 minutes, wonderful... ;-) My machine is P4 2 GHz with 80 GB seagate / 2MB cache Norton antivirus and unbelievably messed up Windows installation ;-) Just to display the archive content (like a folder content) takes relatively long. I am not sure why but I would guess that it could be in the implementation of the shell namespace extension for archives in windows xp. It can be quite expensive to build the structure of shell item nodes for every file/folder in the archive, if the archive contains so many items. They should be created on demand, I faced the problem in my shell extension too. But without the source code I cannot guess. For example WinRAR shell extension "Extract Here" extracts the zip file quick - 2 minutes (it has no explore option, it is only a context menu shell extension) and I believe WinZIP or 7ZIP will have similar results. Btw., rd /q/s xxx is also faster that deleting using the explorer. I understand, that the zip distribution is primarily for the windows users and such slowness is painful. Nevertheless, a crappy implementation of some plugin in OS would annoy only the users who use it, the others can follow the recommendation from the boost download page, and download an alternative unzipping tool, for example from the info-zip site. There is no problem in the zipped file, it's just too big :-) An alternative would be a self-extracting archive, which can be produced by some free tools as well. Ferda

1 0