Is there a way to know if std::chrono::monotonic_clock is defined?
viboes
C++0X standard states in N3092 that monotonic_clock is conditionally
supported.
20.10.5.2 Class monotonic_clock [time.clock.monotonic]
1 Objects of class monotonic_clock represent clocks for which
values of time_point never decrease as physical time advances.
monotonic_clock may be a synonym for system_clock if
system_clock::is_monotonic is true.
** 2 The class monotonic_clock is conditionally supported.**
Is there a way, using SFINAE or another technique, to define a traits
class that states if monotonic_clock is defined?
struct is_monotonic_clock_defined;
If yes, how? If not, why the standard doesn't define a macro that
gives this information at preprocessing time?
Are there other conditionally supported classes?
Vicente
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Howard Hinnant
> Hi,
>
> C++0X standard states in N3092 that monotonic_clock is conditionally
> supported.
>
> class that states if monotonic_clock is defined?
>
> struct is_monotonic_clock_defined;
I am not aware of such a technique.
> If yes, how? If not, why the standard doesn't define a macro that
> gives this information at preprocessing time?
The LWG has shied away from feature-test macros, though I'm aware of
one that was argued successfully: __STDCPP_THREADS.
> Are there other conditionally supported classes?
The typedefs: yocto, zepto, zetta and yotta are conditionally
supported.
-Howard
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
viboes
> On Jun 1, 12:23 am, viboes <vicente.bo...@wanadoo.fr> wrote:
>
> > Hi,
>
> > C++0X standard states in N3092 that monotonic_clock is conditionally
> > supported.
>
> > Is there a way, using SFINAE or another technique, to define a traits
> > class that states if monotonic_clock is defined?
>
> > struct is_monotonic_clock_defined;
>
> I am not aware of such a technique.
Neither me :(
I'm wondering whether it will be useful to include a clock trait class
that gets a clock satisfying some clock features, as been monotonic
and having a period at least as fine as.
template <boos IsMonotonic, typename Period>
find_clock;
For example, if the implementation provide a monotonic_clock using
nanoseconds as period of its duration type we could specialize the
template as
template <true, nanosecons>
find_clock {
typedef monotonic_clock type;
};
In this way we can use the technique to check if a class has a member
type to define
has_type_member_type<find_clock<true,nanoseconds>>::value
> > If yes, how? If not, why the standard doesn't define a macro that
> > gives this information at preprocessing time?
>
> The LWG has shied away from feature-test macros, though I'm aware of
> one that was argued successfully: __STDCPP_THREADS.
I see in N3092, 29.4 Lock-free Property [atomics.lockfree]
"1 The ATOMIC_..._LOCK_FREE macros indicate the lock-free property of
the corresponding atomic types, with
the signed and unsigned variants grouped together. The properties also
apply to the corresponding specializations
of the atomic template. A value of 0 indicates that the types are
never lock-free. A value of 1
indicates that the types are sometimes lock-free. A value of 2
indicates that the types are always lock-free."
These seems to a feature-test macros, isn't it?
What was/is the main reason to shied away from feature-test macros? I
find them very useful.
I don't see the motivation to standardize features that can be
conditionally supported if we can not check its availability in a
portable way.
Looking at the macros defined by the standard, I see some without a
clear meaning and with implementation-defined contents. Why the
standard includes macros such as
_ _ STDC _ _
Whether _ _ STDC _ _ is predefined and if so, what its value is, are
implementation-defined.
_ _ STDC_VERSION _ _
Whether _ _ STDC_VERSION _ _ is predefined and if so, what its value
is, are implementation-defined.
?
> > Are there other conditionally supported classes?
>
> The typedefs: yocto, zepto, zetta and yotta are conditionally
> supported.
Oh, yes. Thanks,
Vicente