Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #474

Re: Random number engine adaptor requirements [rand.req.adapt]

Show all headers | View raw

Thank you very much for your helpful explanations.

It is great that there is a formalized conceptual language. Up to my understanding of this concepts language you have correctly interpreted what I meant by ReverseRandomNumberEngine and ReversibleRandomNumberEngineAdapter.

However, I'm not certain I fully understand yet. I have made a few statements below to check my understanding, and would be grateful if you could point out any errors in these statements.

On Saturday, March 24, 2012 10:26:49 PM UTC-4, Daniel Krügler wrote:
...
>
>  I don't see how this should work: The litmus test is: Does your engine
>  adaptor accept *any* engine (with or without reverse function)? If
>  not, it cannot satisfy the requirements from [rand.req.adapt]. But
>  hold on...
>
...
>
>  OK, so you say "in addition", which means that you provide the
>  required operator(), right? In this case, "reversible random number
>  engine" is a proper *refinement* of the "random number engine"
>  requirements. I translate this to
>
>  concept ReversibleRandomNumberEngine<typename E>  : RandomNumberEngine<E>  {
>   result_type G::reverse();
>  }
>
>  Fine for me so far.
>
>  >  Then I have an adapter template called reverse_adapter:
>  >
>  >  template<typename Engine, ...>    class reverse_adapter { ... };
>  >
>  >  In general it will only compile if Engine is a reversible random number engine (i.e. has a reverse()
>  >  method). (It should be obvious what the adapter does.)
>
>  >
>  >
>  >  My question is whether reverse_adapter can satisfy the requirements of the standard,
>  >  since it will not accept all Engine types?
>
>
>  It depends on the requirements ;-) But lets start formally: From a
>  standard perspective we have
>
>  concept RandomNumberEngineAdaptor<typename A, typename B0, typename...
>  Bi>  : RandomNumberEngine<A>  {
>   requires RandomNumberEngine<B0>  &&  RandomNumberEngine<Bi>...;
>   //...
>  }
>
>  as the requirement set for random number engine adaptors. Let's
>  compare with that one in the following.
>
>  >  My interpretation of the standard is yes,
>  >  since there is no explicit requirement to accept all Engine types. However, I know others
>  >  who have interpreted this section of the standard differently.
>
>
>  I agree that this is hard to conclude from the existing wording,
>  because this textual definition is far less precise than a formal
>  language. In concept language I would translate your type as
>  satisfying a refined requirement set described by
>
>  concept ReversibleRandomNumberEngineAdaptor<typename A, typename B0,
>  typename... Bi>  :
>   RandomNumberEngineAdaptor<A, B0, Bi...>
>  {
>   requires ReversibleRandomNumberEngine<B0>  &&
>  ReversibleRandomNumberEngine<Bi>...;
>  }
>
>  Note that this definition has two sides:
>
>  a) It demonstrates that your reverse_adaptor can be considered as
>  modelling some ReversibleRandomNumberEngineAdaptor requirement set,
>  which indirectly means that it also models RandomNumberEngineAdaptor
>  which means it models some specific random number engine adaptor that
>  is described by [rand.req.adapt].

According to my best understanding of what you have said:

(1) reverse_adapter does *not* model RandomNumberEngineAdapter, and therefore does not satisfy section [rand.req.adapt] of the standard.

(2) reverse_adapter does model the concept ReverseRandomNumberEngineAdapter, which indirectly "models" RandomNumberEngineAdpater by deriving from it and imposing further requirements on the Bi's. (Though I am a bit confused by what you mean by "it models some specific random number engine adaptor that is described by [rand.req.adapt]".)

And most importantly:

(3) Even though reverse_adapter does not satisfy the requirements of [rand.req.adapt], this is not a "defect" in the adapter, and just means that the additional requirement must be documented.

>
>  b) But it also shows that reverse_adaptor imposes stronger
>  requirements on the random number engine, so *not all* random number
>  engines are accepted. In this sense your adaptor should not be
>  considered as equivalent to the templates of [rand.adapt], which
>  accept *any* random number engine.
>
>  I'm emphasizing (b) here, because it acts like a kind of
>  contravariance rule here in contrast to the usual covariance rule of
>  return types of overrides of derived classes.
>
>  Let me close with a more practical example: The std::reverse_iterator
>  adaptor template can also be considered as an iterator adaptor which
>  imposes stronger requirements on the template parameter compared to
>  the std::move_iterator adaptor template. This approach is absolutely
>  feasible, but you should not forget to mention the additional
>  requirements on the engine argument.


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Random number engine adaptor requirements [rand.req.adapt] MiloRambaldi<james.hirschorn@gmail.com> - 2012-03-21 11:35 -0700
  Re: Random number engine adaptor requirements [rand.req.adapt] Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-03-22 11:23 -0700
    Re: Random number engine adaptor requirements [rand.req.adapt] MiloRambaldi<james.hirschorn@gmail.com> - 2012-03-23 17:10 -0700
      Re: Random number engine adaptor requirements [rand.req.adapt] Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-03-24 19:26 -0700
        Re: Random number engine adaptor requirements [rand.req.adapt] MiloRambaldi<james.hirschorn@gmail.com> - 2012-04-02 15:16 -0700
          Re: Random number engine adaptor requirements [rand.req.adapt] Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-04-03 23:20 -0700

csiph-web