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

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

[Boost-bugs] [ boost-Support Requests-1084615 ] spirit: run-time error
by SourceForge.net 13 Dec '04

13 Dec '04

Support Requests item #1084615, was opened at 2004-12-13 20:40 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=1084615&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alessio Marchetti (bnf) Assigned to: Nobody/Anonymous (nobody) Summary: spirit: run-time error Initial Comment: I am using the Spirit library v1.8.1, part of Boost 1.32. Here is a test case which fails at run-time: I get a VC++ Debug Library Error in file core\non-terminal\impl\rule.ipp at line 173. My compiler is VC++ 7.1 on Windows XP SP2. In particular I get a Run-Time Check Failure #2: Stack around the variable 'context-wrap' was corrupted. Any idea about what can be the problem? Please note that with the following I don't get any error: definition(const JSIGrammar& self) { Rule_T pp_token = real_p r = ch_p('#') >> str_p("line") >> +(pp_token); } struct JSIGrammar : public grammar<JSIGrammar> { template <typename ScannerT> struct definition { typedef rule<ScannerT> Rule_T; definition(const JSIGrammar& self) { Rule_T pp_number = real_p; Rule_T pp_token = pp_number; r = ch_p('#') >> str_p("line") >> +(pp_token); } const Rule_T& start() const { return r; } Rule_T r; }; }; int main(int argc, char* argv[]) { string str; { ifstream in(argv[1]); ostringstream out; out << in.rdbuf(); str = out.str(); } typedef parse_info<string::iterator> Info; JSIGrammar g; Info pi = parse(str.begin(), str.end(), g, space_p); if ( pi.hit ) { cout << "Match" << endl; cout << "Full: " << (pi.full ? "Yes" : "No") << endl; cout << "Length: " << pi.length << endl; } else { cout << "No match" << endl; } return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1084615&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

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

13 Dec '04

> 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 built-in unzipper in some file manager. A notice about this strange behavior on the download page with a link to some good unzipping tool (preferably without the cygwin dependency) would do, for example the official Info-Zip site: http://www.info-zip.org/UnZip.html#Win32 Links to unpackers for the downloadable files are also on other sites. And you may consider submitting a feature change request to Microsoft ;-) Ferda > Dave Abrahams

2 1

Some Boost.Filesystem problems
by Ben Hutchings 13 Dec '04

13 Dec '04

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. 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? Unfortunately it's impractical to test automatically, as empty volumes are hard to generate on demand! Ben. -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either.

1 1

A replacement to any_cast
by Yuval Ronen 13 Dec '04

13 Dec '04

Hi, I've checked the 'any' library, and I have a suggestion. Wouldn't it be nicer if class any will have a member method like: template <typename T> T get() const; or maybe even: template <typename T> const T& get() const; template <typename T> T& get(); In my humble opinion, that would look better of the current 'any_cast' way of doing it. Thanks, Yuval Ronen

9 15

Re: [boost] Re: [iostreams] Version of Iostreams compatible with1.32available
by JOAQUIN LOPEZ MU?Z 13 Dec '04

13 Dec '04

Hi Jonathan ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Domingo, Diciembre 12, 2004 1:10 am Asunto: [boost] Re: [iostreams] Version of Iostreams compatible with1.32available > Has this been tested on Borland 5.x? No, it hasn't. This utility is a spin-off of multi_index, which does not compile in BCC (for many other reasons.) > I get errors (see end) unless > I make the > following change at line 132 > > template<typename Type> > struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> > { > }; > > ==> > > template<typename Type> > struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> > { > typedef typename Allocator::BOOST_NESTED_TEMPLATE > rebind<Type>::other other; > }; Well, your fix is kinda redundant. I guess every compiler will be happy with this instead: template<typename Type> struct result { typedef typename Allocator::BOOST_NESTED_TEMPLATE rebind<Type>::other other; }; If this works for BCC and you could do a quick check that it doesn't break the others (GCC, MSVC), please go ahead and commit to the CVS (thank you!) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[logo] slightly OT: about the FedEx logo
by JOAQUIN LOPEZ MU?Z 12 Dec '04

12 Dec '04

I can't resist posting this delightful article about a little-known hidden surprise in the FedEx logo: http://www.thesneeze.com/mt-archives/000273.php This is IMHO the kind of elegance we should strive for when building our Boost logo. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[range + string algos] bug with Intel C++ 7.0 on Windows
by Pavel Vozenilek 12 Dec '04

12 Dec '04

This 2-liner: --------------------------- #include <boost/algorithm/string.hpp> #include <boost/range/iterator_range.hpp> --------------------------- produces error with Intel C++ 7.0 for Windows (plugged in VC6 IDE, old Dinkumware): P:\N\src\boost_1_32_0\boost/range/iterator_range.hpp(78): error: class template "boost::algorithm::iterator_range" may not be redeclared in the current scope class iterator_range ^ P:\N\src\boost_1_32_0\boost/range/iterator_range.hpp(78): error: class template "boost::algorithm::iterator_range" has already been defined class iterator_range ------ Comment on this from Eric Niebler: it's a compiler bug, algorithm/string.hpp causes iterator_range to be declared in boost::algorithm namespace, and range/iterator_range.hpp causes a different iterator_range to be defined in the boost namespace. That's fine, but your compiler doesn't seem to like it. The fix is probably to make the string algorithms use boost::iterator_range instead of defining its own version. ------ /Pavel

2 3