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

date_time high resolution clock for Win32
by Aaron W. LaFramboise 19 May '04

19 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, (This is a followup to this question of mine on boost-users http://lists.boost.org/MailArchives/boost-users/msg06618.php . Jeff Garland suggested comments on that thread should be posted here. I'm new to this list, and not entirely sure if messages with this sort of platform-specific detail are welcome here; if they aren't, let me know.) I've been examining possibilities for a high resolution clock in date_time for Win32 over the past few days. In particular, Windows, like many other platforms, has a system clock with only fair precision (usually about 10ms), but excellent 'counter' clocks with very high precision. It seemed reasonable to me that it should be possible to combine the accuracy of the system clock with the precision of a high-resolution counters, to create a Boost date_time clock that had both the system's maximum accuracy and maximum precision. So, after a few days of casual research and brainstorming, I came up with this simple, incomplete prototype clock. The idea is that it queries both the system clock and the high resolution counter, saves them in static memory. Future calls only use the high resolution counter, using the saved correspondence between the two clocks to calculate the real time. This sort of timer, if it can be implemented reasonably, might be useful on many platforms, including when only time() and clock() are availible. This implementation has these characteristics: THEORY (Wishful thinking) - -Should be the best general-purpose clock and timer on Win32, that would be very difficult to exceed in useful precision or accuracy in a reimplementation. - -Should gracefully handle user changes of system clock. PRACTICE - -It does in fact have the promised ten millisecond accuracy and sub-microsecond resolution. - -The Windows system clock is a lot more "jittery" than I had noticed before. This is a huge problem. The clock routine checks every call to ensure that the two clocks are not further apart than twice the reported precision of the system clock. If they are, the saved times are re-initialized, and the clock starts over from the system time. There is a small problem in my implementation that causes the clock to return subsequent decreasing times for only very small drifts, which should not happen. I have not yet decided how to fix this, but this is not the big problem. The big problem is that while the system clock and counter stay very well in synch under 'normal conditions,' the system clock jitters a whole lot when a lot of system resources are being used in the background, causing the clock to reset itself when it really should not. This in turn causes some strange precision characteristics which might be unacceptable for some applications. I'm going to let this sit for a few days while I think about it. I'd be very interested in hearing any comments in the meantime. Aaron W. LaFramboise #include "boost/date_time/c_time.hpp" #include <windows.h> namespace boost { namespace date_time { ~ template<class time_type> ~ class win32_clock ~ { ~ public: ~ typedef typename time_type::date_type date_type; ~ typedef typename time_type::time_duration_type time_duration_type; ~ typedef typename time_duration_type::rep_type resolution_traits_type; ~ //! Return the local time based on computer clock settings ~ static time_type local_time() { ~ SYSTEMTIME st; ~ ::GetSystemTime(&st); ~ LARGE_INTEGER pc; ~ ::QueryPerformanceCounter(&pc); ~ return create_time(st, pc); ~ } ~ private: ~ static time_type create_time(const SYSTEMTIME &system_time, ~ const LARGE_INTEGER &count) ~ { ~ // Suspicious: lock mutex. ~ static long mutex; ~ while(::InterlockedExchange(&mutex, 1)) ~ Sleep(1); ~ // System time and counter at a previous call. ~ static ULONGLONG saved_time; ~ static ULONGLONG saved_count; ~ // Decode system time and get system time precision ~ ULONGLONG now_time; ~ ::SystemTimeToFileTime(&system_time, ~ reinterpret_cast<FILETIME *>(&now_time)); ~ DWORD sysincrement; ~ { ~ DWORD sysadjust; ~ BOOL sysdisabled; ~ ::GetSystemTimeAdjustment(&sysadjust, &sysincrement, &sysdisabled); ~ } ~ // Convert counter, and get frequency. ~ ULONGLONG now_count = count.QuadPart; ~ LONGLONG frequency; ~ ::QueryPerformanceFrequency( ~ reinterpret_cast<LARGE_INTEGER *>(&frequency)); ~ if(frequency <= 0) { ~ frequency = 1; ~ now_count = 0; ~ } ~ // Release mutex. ~ ::InterlockedExchange(&mutex, 0); ~ // Calculate time now (in FILETIME style measurement) according ~ // to the counter, and calculate drift from system clock. ~ double now = static_cast<double>(now_count - saved_count) ~ * 10000000 / frequency + saved_time; ~ double drift = now - now_time; ~ if(drift < 0) ~ drift = -drift; ~ // Initialize static data on first call, or counter drift. ~ // Adjust time now if counter has drifted. ~ if(saved_count == 0 ~ || now_time < saved_time ~ || now_count < saved_count ~ || drift > sysincrement * 2) { ~ if(saved_count != 0) ~ std::cerr << "DRIFT " << now - now_time << std::endl; ~ saved_time = now_time; ~ saved_count = now_count; ~ now = saved_time; ~ } ~ // Now that we've decided what time it is, break it into time units. ~ ULONGLONG now_ull = static_cast<ULONGLONG>(now); ~ SYSTEMTIME now_systemtime; ~ ::FileTimeToSystemTime(reinterpret_cast<FILETIME *>(&now_ull), ~ &now_systemtime); ~ now_systemtime.wMilliseconds = 0; ~ ::SystemTimeToFileTime(&now_systemtime, ~ reinterpret_cast<FILETIME *>(&now_ull)); ~ double frac_seconds = (now - now_ull)/10000000; ~ // Create date_now and time_duration_now. ~ date_type date_now(now_systemtime.wYear, now_systemtime.wMonth, ~ now_systemtime.wDay); ~ time_duration_type time_duration_now(now_systemtime.wHour, ~ now_systemtime.wMinute, now_systemtime.wSecond, ~ static_cast<ULONGLONG>(frac_seconds ~ * resolution_traits_type::res_adjust())); ~ return time_type(date_now, time_duration_now); ~ } ~ }; } } //namespace date_time #include <iostream> // #include "clock.hpp" #include "boost/date_time/posix_time/posix_time.hpp" using boost::posix_time::ptime; ptime now() { ~ return boost::date_time::win32_clock<ptime>::local_time(); } int main() { ~ using boost::posix_time::seconds; ~ ptime start = now(); ~ ptime last = start; ~ ptime n = last; ~ do { ~ n = now(); ~ if(n == last) ~ std::cerr << "two times equal!\n"; ~ if(n < last) ~ std::cerr << "time went backwards: " << n - last << '\n'; ~ last = n; ~ } while(n < start + seconds(15)); ~ std::cout << n - start << '\n'; ~ return 0; } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAnX8tlp/lhnWsM8QRAjAdAJoDKMO0++1NeO4CMqaY9K+Q/VhvKgCdGS7x aOARRMWjmfr3KrMiDsNH7qk= =M9Kf -----END PGP SIGNATURE-----

4 8

Re: [boost] basic_string interface generator
by Igor Kholodov 18 May '04

18 May '04

>Reece Dunn wrote: >> >> Is there any interest in the ability to generate a basic_string compliant >> interface from a base set of functions in a similar way that the iterator >> adaptors work? > >While I don't have a present need for it, there has been >discussion of various types of strings including ropes and small >string optimized on the list. A utility such as you've proposed >would make writing them easier. > This would also benefit libraries designed specifically for STL strings. See, for example, Common Text Transformation Library, http://cttl.sourceforge.net/. Is there is a need for grammar-based STL string transformations? Igor Kholodov http://cttl.sourceforge.net/

1 0

RE: [boost] basic_string interface generator
by Max Khesin 18 May '04

18 May '04

Just curious: what do you think of Andrei's work on policy-based strings: http://www.cuj.com/documents/s=7994/cujcexp1906alexandr/alexandr.htm http://moderncppdesign.com/code/flex_string.zip - does it do what you want (or leave flexibility to do what you want) - if so why not just use it - if not what doesn't it do m > -----Original Message----- > From: Reece Dunn [mailto:msclrhd@hotmail.com] > Sent: Tuesday, May 18, 2004 2:30 PM > To: boost(a)lists.boost.org > Subject: [boost] basic_string interface generator > > > Is there any interest in the ability to generate a > basic_string compliant > interface from a base set of functions in a similar way that > the iterator > adaptors work? > > I am currently developing a fixed-capacity string class that > complies to the > basic_string interface and have at least 3 variants: > > boost::fixed_string< n, CharT = char, StringPolicy = > std::char_traits< > char > > > boost::char_string > boost::wchar_string > > where fixed_string derives from boost::char_string or > boost::wchar_string > depending on CharT. It may be useful to implement these like this: > > struct char_string: boost::basic_string_impl< char_string > > { > // ... > }; > > void myfn( char_string & s ) > { > // manipulate s like a basic_string or apply C-string functions > } > > So the question is this: are other people interested in this > concept, or is > it better placed as an implementation detail? > > Regards, > Reece > > _________________________________________________________________ > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > http://toolbar.msn.co.uk/ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

"+" sign in filesystems
by Florian Becker 18 May '04

18 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, have wondered, why the "+" sign won t work in filesystem lib. So i have added it. I need this, for monotone system control use. Maybe you can add this to the tree for later.. boost_1_31_0/libs/filesystem/src/operations_posix_windows.cpp line 119 only add a "+" sign. I have build patched packages for this. ftp://ftp.yplus.org/monotools/ Cheers, - -- - -------------------------------------------------------- Florian Becker - -------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqlgGtdIR2yXuDwERAoOPAKDOT1iMwdJVsAVJan68c/UK5RzSaACeKHcu eotMtSZd3cAgsXH+QsGoXSs= =xl4O -----END PGP SIGNATURE-----

2 1

basic_string interface generator
by Reece Dunn 18 May '04

18 May '04

Is there any interest in the ability to generate a basic_string compliant interface from a base set of functions in a similar way that the iterator adaptors work? I am currently developing a fixed-capacity string class that complies to the basic_string interface and have at least 3 variants: boost::fixed_string< n, CharT = char, StringPolicy = std::char_traits< char > > boost::char_string boost::wchar_string where fixed_string derives from boost::char_string or boost::wchar_string depending on CharT. It may be useful to implement these like this: struct char_string: boost::basic_string_impl< char_string > { // ... }; void myfn( char_string & s ) { // manipulate s like a basic_string or apply C-string functions } So the question is this: are other people interested in this concept, or is it better placed as an implementation detail? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

[preprocessor] math macros.
by Cromwell Enage 18 May '04

18 May '04

As promised, I have some results. My work can be found this time at <http://groups.yahoo.com/group/boost/files/pp_math.zip>. The example program is simpler and has been confirmed to work correctly when compiled under MinGW 3.2 and MSVC 7.1 (using the VC 2003 Toolkit). Later on I'll test it using MSVC 6. The usual caveats that apply to other macros (no incrementing, decrementing, or runtime functions with side effects can be called from within parameters) apply here. Once again, comments welcome! Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

1 1

Filesystem iterator suggestion
by Martin 18 May '04

18 May '04

I have used the filesystem library for some time now and noticed that there is no portable way of iterating over files in a directory that matches a pattern. In my applications I often need to find all files in a directory that matches "*.txt" or "input.*". I think it would be a good idea to add another constructor to the directory_iterator that support some primitive wilcards. The support could be limited to "*" at the end or followed by a "." (e.g. "*", "a*.*", "*.txt", "a.*") for (path::directory_iterator itr = directory_iterator(path, "*.txt"); itr != directory_iterator(); ++itr) ... I assume this limited wildcard support could easily be ported to most operating systems. ------------------- Another small improvement that would make the directory_iterator easier to use is to somehow allow it to only list directories or files. In the current implementation you need to create a temporary to use an algorithm on all files in a directory (or use some lambda if construct). std::vector<path> tmp; std::remove_copy_if(directory_iterator(dir), directory_iterator(), back_inserter(tmp), std::ptr_fun(is_directory)) std::for_each(tmp.begin(), tmp.end(), func); instead of just std::for_each(directory_iterator(dir, files_only), directory_iterator(), func);

4 4

Fwd: Bug#247643: boost::format completely broken on ia64
by Domenico Andreoli 18 May '04

18 May '04

hi all, i received this bug report for the Boost debian package version 1.31.0-4, the full log is available at [0]. it is reproducible on ia64 architecture. anybody with in depth knowledge of the format library is able to give me a hint about where the problem might be? i cannot provide any access to the debian project's ia64 box but i'm available to perform any test i'm asked to further delve into the bug. best regards domenico [0] http://bugs.debian.org/247643 ----- Forwarded message from Martin Pool <mbp(a)samba.org> ----- Date: Thu, 06 May 2004 17:03:38 +1000 From: Martin Pool <mbp(a)samba.org> To: submit(a)bugs.debian.org Reply-To: Martin Pool <mbp(a)samba.org>, 247643(a)bugs.debian.org Cc: mbp(a)sourcefrog.net Subject: Bug#247643: boost::format completely broken on ia64 Package: libboost-dev Version: 1.31.0-4 Severity: important X-Debbugs-CC: debian-ia64(a)lists.debian.org Here is a test case, extracted from the examples in http://www.boost.org/libs/format/example/sample_formats.cpp: --------------- #include <iostream> #include <boost/format.hpp> using namespace boost; using namespace std; int main(void) { cout << format("Hello %d!\n") % 69; return 0; } ----------------- I build this with g++ -o boost-format-bug boost-format-bug.cpp On i386 it works fine. On ia64, with g++ 4:3.3.3-2 and libstdc++ 1:3.3.3-6, it crashes. In fact I cannot find any use of the format class other than passing a constant string which does not crash. gdb shows Catchpoint 1 (exception thrown) 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 (gdb) bt #0 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 #1 0x20000000000acc50 in std::__throw_length_error () from /usr/lib/libstdc++.so.5 #2 0x200000000012fc30 in std::string::_M_replace_safe<char const*> () from /usr/lib/libstdc++.so.5 #3 0x200000000012ba40 in std::string::append () from /usr/lib/libstdc++.so.5 #4 0x400000000000db60 in boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> > () #5 0x400000000000c900 in boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, int const&> () #6 0x400000000000ac60 in boost::io::detail::distribute<char, std::char_traits<char>, int const&> () #7 0x40000000000076c0 in boost::io::detail::feed<char, std::char_traits<char>, int const&> () #8 0x4000000000003fe0 in boost::basic_format<char, std::char_traits<char> >::operator%<int> () #9 0x4000000000003d00 in main () Regards Martin ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2 1

RE: [boost] Re: static sized strings
by Reece Dunn 18 May '04

18 May '04

Martin wrote: >Do you plan to add more of the basic_string members? I intend to (hopefully) have as close to the basic_string interface as I can get to help interoperability. I have been working on getting core functionality up and running initially, but I am working on adding more basic_string members. >Many of the string algorithms (e.g. trim & replace) seem to require insert >& >erase? I haven't included these yet, but I shall work to get them implemented as soon as I can. I am also thinking about how to implement substrings: either create a std::basic_string or have an internal/external type that operates on const char * instead of const char[ n ], etc. Then there's the issue of compilers/standard libraries that don't have the correct std::reverse_iterator, std::iterator_traits, std::basic_[i/o]stream implementations (sigh). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

RE: [boost] Is there interest in a decimal floating-point class?
by Michiel Salters 18 May '04

18 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: maandag 17 mei 2004 14:34 > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there interest in a decimal floating-point > class? > > > On Sun, 16 May 2004 19:26:51 +0200, Richard Kaiser wrote > > I want to ask the boost community if there is interest in a decimal > > floating-point class implementing one or more of the decimal > > floating-point types that are intended to become part of a future C > > and C++ standard. > > At this moment I don't need this, but I've need something > like this in the past and suspect I will again. So I'd like to > see it. Only question is will the compiler vendors get > there first if it's already clear this is going in the standard? It's just a proposal, and I doubt it will become part of the standard. P.J.Plauger wasn't very positive, and NNI (Dutch) voted against it. I'm not aware of other formal votes, though. One problem I saw was that the proposal implemented its types as core language, with semantics that I felt were hard if not impossible to achieve for UDTs (w.r.t. conversion sequences) Regards, -- Michiel Salters Consultant Software Engineering LogicaCMG RTSE1, the Netherlands Michiel.Salters(a)logicacmg.com 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