On 14/01/16 20:41 +, Jonathan Wakely wrote:
On 14/01/16 20:57 +0100, Marc Glisse wrote:
Once you constrain, you could even use 'std' as the associated
namespace ;-)
True! And std is already an associated namespace of the standard
distributions, so we wouldn't be making ADL look anywhere ad
On 14/01/16 20:46 +, Jonathan Wakely wrote:
On 14/01/16 20:43 +, Jonathan Wakely wrote:
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly
On 14/01/16 20:43 +, Jonathan Wakely wrote:
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly taking as much space as the explicit inline
defi
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly taking as much space as the explicit inline
definition of operator!) and there could be a single
On 14/01/16 20:57 +0100, Marc Glisse wrote:
Once you constrain, you could even use 'std' as the associated
namespace ;-)
True! And std is already an associated namespace of the standard
distributions, so we wouldn't be making ADL look anywhere additional.
2016-01-14 20:21 GMT+01:00 Jonathan Wakely :
> We could constrain the generic operator== and operator!= to only match
> types that we want it to match, e.g. by having a type trait that is
> true for all our distributions and their parameter types. That would
> mean adding a specialization of it for
On Thu, 14 Jan 2016, Jonathan Wakely wrote:
On 14/01/16 20:13 +0100, Marc Glisse wrote:
I didn't think about it much, but I am worried that __random_not_eq will
accidentally become an associated namespace for more classes than we would
expect.
Yes, it would be an associated namespace for typ
On 14/01/16 20:13 +0100, Marc Glisse wrote:
I didn't think about it much, but I am worried that __random_not_eq
will accidentally become an associated namespace for more classes than
we would expect.
Yes, it would be an associated namespace for types that derive from
the distributions, or clas
On Thu, 14 Jan 2016, Jonathan Wakely wrote:
How do people feel about this approach to solving PR 69240?
The bug is that we don't define operator!= for RND::param_type, where
RND is any of random number distributions in or .
Rather than tediously defining it for every param_type I've added
this
How do people feel about this approach to solving PR 69240?
The bug is that we don't define operator!= for RND::param_type, where
RND is any of random number distributions in or .
Rather than tediously defining it for every param_type I've added
this:
namespace __random_not_eq
{
// Derive
10 matches
Mail list logo
