On Fri, Sep 09, 2016 at 09:15:23AM -0400, Daniel Lee wrote:
> > Need to make things fail at that point, I think and I'm not sure
> how
> > to do that.
> #ifdef WRONG_ORDER
> #error "You included things in the wrong order"
> #endif
>
> That makes sense if there's only one way to instantiate our library. We
> have 12. The right order is different for those 12 different use cases.
> If you're wondering how we have 12, it's {primitive, reverse mode,
> forward mode, mixed mode} x {scalar, array, matrix}.
So in stage 1 {primitive, reverse mode, forward mode, mixed mode} you do:
#ifndef STAGE_1
#define STAGE_1
#endif
And then in stage 2 {scalar, array, matrix} you do:
#ifndef STAGE_2
#define STAGE_2
#endif
Since you don't want STAGE_2 to come before STAGE_1, you also need for
stage 1:
#ifdef STAGE_2
#error "All stage 1 needs to come before stage 2"
#endif
> And if you instantiate the traits for the wrong thing, it won't
> work.
> We definitely need the first distinction: primitive, reverse mode,
> forward mode, mixed mode. We have trouble compiling models with mixed
> mode under different compilers, so we can't just blanket include
> everything.
> We might be able to do away with the second distinction: scalar, array,
> matrix. But... we've got it working now. It came out of early users'
> desire to have minimal library dependencies. Right now, if you include
> scalar, it shouldn't bring std::vector (but it probably does). If you
> bring in array, it won't bring in Eigen::Matrix. If you bring in
> matrix, it'll bring in Eigen::Matrix and std::vector. All three depend
> on Boost.
Hm, well ...
> > It may be discussed in either the Josuttis and Vandevoorde
> > book or Alexandrescu.
>
> Dunno. I don't think you need a book. It should be easy to figure
> out.
>
> Lol. Things are easy to people that know how to do them!
> I'm looking for any direction here. If you wanted to put up a working
> example, I'd be happy to take it from there. If you wanted to point me
> to any references, online or print, that would be helpful. I don't know
> much about the C preprocessor and how it works.
It's just a matter of describing the requirements precisely. If you can
explain when you need then it is easy to translate into CPP macros.