Boost.Chrono: cleanup

[SVN r68188]

include/boost/chrono/chrono.hpp

@@ -1,68 +1,15 @@
 //  chrono.hpp  --------------------------------------------------------------//
 
-//  Copyright 2008 Howard Hinnant
-//  Copyright 2008 Beman Dawes
-//  Copyright 2009-2010 Vicente J. Botet Escriba
+//  Copyright 2009-2011 Vicente J. Botet Escriba
 
 //  Distributed under the Boost Software License, Version 1.0.
 //  See http://www.boost.org/LICENSE_1_0.txt
 
-/*
-
-This code was derived by Beman Dawes from Howard Hinnant's time2_demo prototype.
-Many thanks to Howard for making his code available under the Boost license.
-The original code was modified to conform to Boost conventions and to section
-20.9 Time utilities [time] of the C++ committee's working paper N2798.
-See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf.
-
-time2_demo contained this comment:
-
-    Much thanks to Andrei Alexandrescu,
-                   Walter Brown,
-                   Peter Dimov,
-                   Jeff Garland,
-                   Terry Golubiewski,
-                   Daniel Krugler,
-                   Anthony Williams.
-*/
-
-/*
-
-TODO:
-
-  * Fully implement error handling, with test cases.
-  * Use boost::throw_exception. (Currently not used because of an issue with Intel 11.0.)
-  * Consider issues raised by Michael Marcin:
-
-    > In the past I've seen QueryPerformanceCounter give incorrect results,
-    > especially with SpeedStep processors on laptops. This was many years ago and
-    > might have been fixed by service packs and drivers.
-    >
-    > Typically you check the results of QPC against GetTickCount to see if the
-    > results are reasonable.
-    > http://support.microsoft.com/kb/274323
-    >
-    > I've also heard of problems with QueryPerformanceCounter in multi-processor
-    > systems.
-    >
-    > I know some people SetThreadAffinityMask to 1 for the current thread call
-    > their QueryPerformance* functions then restore SetThreadAffinityMask. This
-    > seems horrible to me because it forces your program to jump to another
-    > physical processor if it isn't already on cpu0 but they claim it worked well
-    > in practice because they called the timing functions infrequently.
-    >
-    > In the past I have chosen to use timeGetTime with timeBeginPeriod(1) for
-    > high resolution timers to avoid these issues.
-
-*/
-
 #ifndef BOOST_CHRONO_CHRONO_HPP
 #define BOOST_CHRONO_CHRONO_HPP
 
 #include <boost/chrono/duration.hpp>
 #include <boost/chrono/time_point.hpp>
 #include <boost/chrono/system_clocks.hpp>
-//~ #include <boost/chrono/process_cpu_clocks.hpp>
-//~ #include <boost/chrono/thread_clock.hpp>
 
 #endif // BOOST_CHRONO_CHRONO_HPP