Hi,

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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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.

> 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-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 31, 11:23 pm, viboes <vicente.bo...@wanadoo.fr> wrote:
> Hi,
>
> 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;

Standard SFINAE a la enable_if plus tapping into namespace std should
do the trick. Somewhat ugly, but better than nothing.

class monotonic_clock {}; // global namespace

namespace std {

struct is_monotonic_clock_defined {
template< class T >
static char sfinae( typename T::rep );
template< class >
static int sfinae( ... );

enum { value = sizeof sfinae< monotonic_clock >( 0 ) ==
sizeof(char) };
};

}

using std::is_monolithic_clock_defined;


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 1, 9:33 pm, Howard Hinnant <howard.hinn...@gmail.com> wrote:
> 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


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 2, 2:55 am, David Krauss <pot...@gmail.com> wrote:
> On May 31, 11:23 pm, viboes <vicente.bo...@wanadoo.fr> wrote:
>
>
>
> > Hi,
>
> > 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;
>
> Standard SFINAE a la enable_if plus tapping into namespace std should
> do the trick. Somewhat ugly, but better than nothing.
>
> class monotonic_clock {}; // global namespace
>
> namespace std {
>
> struct is_monotonic_clock_defined {
> template< class T >
> static char sfinae( typename T::rep );
> template< class >
> static int sfinae( ... );
>
> enum { value = sizeof sfinae< monotonic_clock >( 0 ) ==
> sizeof(char) };
>
> };
> }
>
> using std::is_monolithic_clock_defined;
>

Really cleaver. I never though to add a class to use ADL and avoid the
undefined symbol. There are however two problems:
A * A user can not add nothing to the std namespace, and
B * It introduces a class monotonic_clock that could create ambiguity
if a using std::chrono is used.

As I'm developing Chrono under Boost I'm not concerned by the issue
(A). The second issue (B) forces to use  monotonic_clock prefixed with
the chrono namespace.

As Howard said, in C++ we can just say, I don't know how to do it for
the moment, but sure someone else will find a workaround and clever
solution.

As you said this is better than nothing. Other suggestions :)?

Thanks,
Vicente


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 3 Jun., 23:24, viboes <vicente.bo...@wanadoo.fr> wrote:
> On Jun 2, 2:55 am, David Krauss <pot...@gmail.com> wrote:
>
> > On May 31, 11:23 pm, viboes <vicente.bo...@wanadoo.fr> wrote:
>
> > > 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;
>
> > Standard SFINAE a la enable_if plus tapping into namespace std should
> > do the trick. Somewhat ugly, but better than nothing.
>
> > class monotonic_clock {}; // global namespace
>
> > namespace std {
>
> > struct is_monotonic_clock_defined {
> > template< class T >
> > static char sfinae( typename T::rep );
> > template< class >
> > static int sfinae( ... );
>
> > enum { value = sizeof sfinae< monotonic_clock >( 0 ) ==
> > sizeof(char) };
>
> > };
> > }
>
> > using std::is_monolithic_clock_defined;
>
> Really cleaver. I never though to add a class to use ADL and avoid the
> undefined symbol. There are however two problems:
> A * A user can not add nothing to the std namespace, and
> B * It introduces a class monotonic_clock that could create ambiguity
> if a using std::chrono is used.
>
> As I'm developing Chrono under Boost I'm not concerned by the issue
> (A). The second issue (B) forces to use  monotonic_clock prefixed with
> the chrono namespace.

[..]

> As you said this is better than nothing. Other suggestions :)?

You can rid of problem B by usage of proper helper namespaces.

The following is a variant of David's code thereby fixing the
minor problem of using std::chrono::monotonic_clock:

#include <chrono>

namespace my_lib {
namespace test_std_features {
struct monotonic_clock {};
}
}

namespace std {
namespace chrono {
namespace my_lib_test_features {

using namespace my_lib::test_std_features;

struct is_monotonic_clock_defined {
 template<class T>
 static char sfinae( typename T::rep );
 template<class>
 static char(&sfinae( ... ))[2];
 enum { value = sizeof sfinae<monotonic_clock>(0) == sizeof(char) };
};

}
}
}

#include <type_traits>

namespace my_lib {

struct is_monotonic_clock_defined : std::integral_constant<bool,
 std::chrono::my_lib_test_features::is_monotonic_clock_defined::value
> {};

}

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

viboes wrote:
> C++0X standard states in N3092 that monotonic_clock is conditionally
> supported.
>
> [snip]
>
> Is there a way, using SFINAE or another technique, to define a traits
> class that states if monotonic_clock is defined?

I tried to implement it, but I'm confused by GCC not doing what I expected:

#include <chrono>
#include <type_traits>

namespace boost
{
 typedef void monotonic_clock;

 namespace impl
 {
   using namespace std::chrono;
   // struct monotonic_clock {};

   const bool has_monotonic_clock =
     !std::is_same< monotonic_clock, void >::value;
 }

 using impl::has_monotonic_clock;
}

int main()
{
 static_assert( boost::has_monotonic_clock, "failed" );
}

The problem is, that it fails, although I thought that using namespace
should,
per 3.4.1/2 (N3092):

"The declarations from the namespace nominated by a using-directive become
visible in a namespace enclosing the using-directive; see 7.3.4. For the
purpose of the unqualified name lookup rules described in 3.4.1, the
declarations from the namespace nominated by the using-directive are
considered members of that enclosing namespace."

Now, if I replace the using directive in the above code with "struct
monotonic_clock {};" (see the comment in the code), it works. Tested with
GCC
4.4 and 4.5. Is that a bug in GCC, should I file a bug report? Or am I
missing
something?

Regards, Daniel

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 6, 11:42 pm, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
wrote:
> On 3 Jun., 23:24, viboes <vicente.bo...@wanadoo.fr> wrote:
>
>
>
> > On Jun 2, 2:55 am, David Krauss <pot...@gmail.com> wrote:
>
> > > On May 31, 11:23 pm, viboes <vicente.bo...@wanadoo.fr> wrote:
>
> > > > Is there a way, using SFINAE or another technique, to define a
traits
> > > > class that states if monotonic_clock is defined?
>
> > > Standard SFINAE a la enable_if plus tapping into namespace std should
> > > do the trick. Somewhat ugly, but better than nothing.
>
> > Really cleaver. I never though to add a class to use ADL and avoid the
> > undefined symbol. There are however two problems:
> > A * A user can not add nothing to the std namespace, and
> > B * It introduces a class monotonic_clock that could create ambiguity
> > if a using std::chrono is used.
>
> > As I'm developing Chrono under Boost I'm not concerned by the issue
> > (A). The second issue (B) forces to use  monotonic_clock prefixed with
> > the chrono namespace.
>
> > As you said this is better than nothing. Other suggestions :)?
>
> You can rid of problem B by usage of proper helper namespaces.
>
> The following is a variant of David's code thereby fixing the
> minor problem of using std::chrono::monotonic_clock:
>
> #include <chrono>
>
> namespace my_lib {
> namespace test_std_features {
> struct monotonic_clock {};
>
> }
> }
>
> namespace std {
> namespace chrono {
> namespace my_lib_test_features {
>
> using namespace my_lib::test_std_features;
>
> struct is_monotonic_clock_defined {
>  template<class T>
>  static char sfinae( typename T::rep );
>  template<class>
>  static char(&sfinae( ... ))[2];
>  enum { value = sizeof sfinae<monotonic_clock>(0) == sizeof(char) }=
;
>
> };
> }
> }
> }
>
> #include <type_traits>
>
> namespace my_lib {
>
> struct is_monotonic_clock_defined : std::integral_constant<bool,
>  std::chrono::my_lib_test_features::is_monotonic_clock_defined::value
>
> > {};
> }
>
> HTH & Greetings from Bremen,

Thanks,

yes this helps to avoid the ambiguity issue. I don't know if there is
another technique that doesn't needs the definition of the helper
class inside std::chrono.

That means that we can not know is the implementation has a
monotonic_clock without the std::chrono library implementor
collaboration. But for the std::chrono library implementor it would be
much easier to provide this as a constant, as s/he know if it provides
one or not.

namespace std { namespace {
 struct has_monotonic_clock : std::integral_constant<bool, true> {};
 // or struct has_monotonic_clock : std::integral_constant<bool,
false> {};
}}

If this is not possible, a portable library can not make use of
monotonic_clock other than defining its own conditional compilation
define, and set it depending on an a priori knowledge of what the
platform implementation provides. :(

Thanks again,
Vicente


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daniel Frey wrote:
>
> I tried to implement it, but I'm confused by GCC not doing what I expected:
>
> #include <chrono>
> #include <type_traits>
>
> namespace boost
> {
>  typedef void monotonic_clock;
>
>  namespace impl
>  {
>   using namespace std::chrono;
>   // struct monotonic_clock {};
>
>   const bool has_monotonic_clock =
>     !std::is_same< monotonic_clock, void >::value;
>  }
>
>  using impl::has_monotonic_clock;
> }
>
> int main()
> {
>  static_assert( boost::has_monotonic_clock, "failed" );
> }
>
> The problem is, that it fails, although I thought that using namespace
> should,
> per 3.4.1/2 (N3092):
>
> "The declarations from the namespace nominated by a using-directive become
> visible in a namespace enclosing the using-directive; see 7.3.4. For the
> purpose of the unqualified name lookup rules described in 3.4.1, the
> declarations from the namespace nominated by the using-directive are
> considered members of that enclosing namespace."
>
> Now, if I replace the using directive in the above code with "struct
> monotonic_clock {};" (see the comment in the code), it works. Tested with
> GCC
> 4.4 and 4.5. Is that a bug in GCC, should I file a bug report? Or am I
> missing
> something?

I tried the same idea with comeau online and msvc-10 and got the same
results. Could it be that all three compilers implemented it wrong,
or could somebody explain from the standard POV?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 8 Jun., 03:07, Daniel Frey <n...@example.com> wrote:
> viboes wrote:
> > C++0X standard states in N3092 that monotonic_clock is conditionally
> > supported.
>
> > [snip]
>
> > Is there a way, using SFINAE or another technique, to define a traits
> > class that states if monotonic_clock is defined?
>
> I tried to implement it, but I'm confused by GCC not doing what I
expected:
>
> #include <chrono>
> #include <type_traits>
>
> namespace boost
> {
>  typedef void monotonic_clock;
>
>  namespace impl
>  {
>    using namespace std::chrono;
>    // struct monotonic_clock {};
>
>    const bool has_monotonic_clock =
>      !std::is_same< monotonic_clock, void >::value;
>  }
>
>  using impl::has_monotonic_clock;
>
> }
>
> int main()
> {
>  static_assert( boost::has_monotonic_clock, "failed" );
>
> }
>
> The problem is, that it fails, although I thought that using namespace
> should,
> per 3.4.1/2 (N3092):
>
> "The declarations from the namespace nominated by a using-directive becom=
e
> visible in a namespace enclosing the using-directive; see 7.3.4. For the
> purpose of the unqualified name lookup rules described in 3.4.1, the
> declarations from the namespace nominated by the using-directive are
> considered members of that enclosing namespace."
>
> Now, if I replace the using directive in the above code with "struct
> monotonic_clock {};" (see the comment in the code), it works. Tested with
> GCC
> 4.4 and 4.5. Is that a bug in GCC, should I file a bug report? Or am I
> missing
> something?

[Second trial, my first attempt seems to get lost in the deadly
dangerous internet]

You are missing that using directives are constrained by
[namespace.udir]/2:

"A using-directive specifies that the names in the nominated namespace
can
be used in the scope in which the using-directive appears after the
using-
directive. During unqualified name lookup (3.4.1), the names appear as
if they
were declared in the nearest enclosing namespace which contains both
the
using-directive and the nominated namespace. [ Note: in this context,
=93contains=94
means =93contains directly or indirectly=94. =97end note ]"

The "nearest enclosing namespace" of ::boost::impl
(that is, where the using-directive sits in) and ::std::chrono
(the nominated namespace) is the global namespace, this
means, that name-lookup happens equivalent to the following
case:

struct monotonic_clock { /.../ }; // Actually: In std::chrono
namespace boost
{
 typedef void monotonic_clock;
 namespace impl
 {
 const bool has_monotonic_clock =
    !std::is_same<monotonic_clock, void>::value;
 }
}

Thus, ::boost::monotonic_clock will always hide
::std::chrono::monotonic_clock using this
naming technique.

Your fix is not a real fix (or I misunderstood your
description), because it will of-course have the
effect that ::boost::impl::has_monotonic_clock
*always* evaluates to true - independent on the
existence of the monotonic clock in std:.chrono.

We can invert my rationale to explain why the
approach used by David Krauss works, because
now the hiding effect is inverted: If std::chrono::monotonic_clock
exists, it will always hide the added test name and
will result in the wanted effect. This in turn let's us
create a solution which is in fact a merge of yours
and of David (combined with my slight improvement
in regard to inner namespaces):

#include <chrono>
#include <type_traits>

namespace my_lib {
namespace test_std_features {
 typedef void monotonic_clock;
}
}

namespace std {
namespace chrono {
namespace my_lib_test_features {

using namespace my_lib::test_std_features;

const bool has_monotonic_clock =
    !std::is_same<monotonic_clock, void>::value;

}
}
}

namespace my_lib {

struct is_monotonic_clock_defined : std::integral_constant<bool,
 std::chrono::my_lib_test_features::has_monotonic_clock
> {};

}

I agree that this approach still violates the standard library
requirements, but it is the best approach I found so far unless
the standard adds a feature test.

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 10, 3:49 pm, Ilya Sokolov <ilyaso...@gmail.com> wrote:
> Daniel Frey wrote:
>
> > I tried to implement it, but I'm confused by GCC not doing what I
expected:
>
> > #include <chrono>
> > #include <type_traits>
>
> > namespace boost
> > {
> >  typedef void monotonic_clock;
>
> >  namespace impl
> >  {
> >   using namespace std::chrono;
> >   // struct monotonic_clock {};
>
> >   const bool has_monotonic_clock =
> >     !std::is_same< monotonic_clock, void >::value;
> >  }
>
> >  using impl::has_monotonic_clock;
> > }
>
> > int main()
> > {
> >  static_assert( boost::has_monotonic_clock, "failed" );
> > }
>
> > The problem is, that it fails, although I thought that using namespace
> > should,
> > per 3.4.1/2 (N3092):
>
> > "The declarations from the namespace nominated by a using-directive
become
> > visible in a namespace enclosing the using-directive; see 7.3.4. For th=
e
> > purpose of the unqualified name lookup rules described in 3.4.1, the
> > declarations from the namespace nominated by the using-directive are
> > considered members of that enclosing namespace."
>
> > Now, if I replace the using directive in the above code with "struct
> > monotonic_clock {};" (see the comment in the code), it works. Tested
with
> > GCC
> > 4.4 and 4.5. Is that a bug in GCC, should I file a bug report? Or am I
> > missing
> > something?
>
> I tried the same idea with comeau online and msvc-10 and got the same
> results. Could it be that all three compilers implemented it wrong,
> or could somebody explain from the standard POV?

>From 7.3.4/1, "During unqualified name lookup (3.4.1), the names
appear as if they were declared in the nearest enclosing namespace
which contains both the using-directive and the nominated namespace. =85
A using-directive does not add any members to the declarative region
in which it appears."

The names appear as if they were declared in the global namespace. The
using directive is not a blunt instrument for reorganizing, it only
creates shortcuts.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 8 Jun., 03:07, Daniel Frey <n...@example.com> wrote:
> viboes wrote:
> > C++0X standard states in N3092 that monotonic_clock is conditionally
> > supported.
>
> > [snip]
>
> > Is there a way, using SFINAE or another technique, to define a traits
> > class that states if monotonic_clock is defined?
>
> I tried to implement it, but I'm confused by GCC not doing what I
expected:
>
> #include <chrono>
> #include <type_traits>
>
> namespace boost
> {
>  typedef void monotonic_clock;
>
>  namespace impl
>  {
>    using namespace std::chrono;
>    // struct monotonic_clock {};
>
>    const bool has_monotonic_clock =
>      !std::is_same< monotonic_clock, void >::value;
>  }
>
>  using impl::has_monotonic_clock;
>
> }
>
> int main()
> {
>  static_assert( boost::has_monotonic_clock, "failed" );
> }
>
> The problem is, that it fails, although I thought that using namespace
> should,
> per 3.4.1/2 (N3092):
>
> "The declarations from the namespace nominated by a using-directive becom=
e
> visible in a namespace enclosing the using-directive; see 7.3.4. For the
> purpose of the unqualified name lookup rules described in 3.4.1, the
> declarations from the namespace nominated by the using-directive are
> considered members of that enclosing namespace."
>
> Now, if I replace the using directive in the above code with "struct
> monotonic_clock {};" (see the comment in the code), it works. Tested with
> GCC 4.4 and 4.5. Is that a bug in GCC, should I file a bug report? Or am =
I
> missing something?

You probably missed the constraints described in [namespace.udir]/2:

"[..] During unqualified name lookup (3.4.1), the names appear as if
they
were declared in the nearest enclosing namespace which contains both
the using-directive and the nominated namespace. [..]"

This has the effect that ::boost::monotonic_clock always hides
the added ::std::chrono::monotonic_clock, also compare for
the last example given in [namespace.udir]/4. A more pictorial
understanding of the hiding effect is, that it has the same effect
as:

struct monotonic_clock{}; // Global namespace is "nearest
                                     // enclosing"
namespace boost
{
 typedef void monotonic_clock;

 namespace impl
 {
  const bool has_monotonic_clock =
    !std::is_same< monotonic_clock, void >::value;
 }
}

In other words: Your approach does unfortunately not work.
Even your replacement strategy doesn't work: You can
check that by removing the <chrono> inclusion and you will
notice that has_monotonic_clock always evaluates to true,
because boost::impl::monotonic_clock always hides
boost::monotonic_clock.

For exactly the same reason, the approach suggested by David
Krauss (and my slightly safer variant) works, because within a
sub-namespace of namespace std::chrono, the name of the entity
std::chrono::monotonic_clock will always hide the name added by
the using-directive.

Thus we can deduce the following combination of both approaches
(yours and David Krauss') by writing

#include <chrono>
#include <type_traits>

namespace my_lib {
namespace test_std_features {
 typedef void monotonic_clock;
}
}

namespace std {
namespace chrono {
namespace my_lib_test_features {

using namespace my_lib::test_std_features;

const bool has_monotonic_clock =
    !std::is_same<monotonic_clock, void>::value;

}
}
}

namespace my_lib {

struct is_monotonic_clock_defined : std::integral_constant<bool,
 std::chrono::my_lib_test_features::has_monotonic_clock
> {};

}

The only disadvantage of this approach is, that it violates the
requirements of the standard library, because the program
adds members to namespace std. But the approach looks
as if it would be ok for practical purposes.

HTH & Greeetings from Bremen,

Daniel Kr=FCgler



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]