I can use FieldTypeTuple and FieldNameTuple, but I am a bit lost as to how without static foreach to loop through these in order to generate a mixin to declare the new type. I can turn it into a string, but what is the better option?

The simplest solution is something like:

   template SOA(Struct, size_t LENGTH) {
      struct SOA  {
enum MEMBERNAME(size_t N) = __traits(identifier, Struct.tupleof[N]);

         static __gentypes() {
            string ret;
            foreach (I, TYPE; typeof(Struct.tupleof))
ret ~= "align(16) typeof(Struct.tupleof["~I.stringof~"])["~LENGTH.stringof~"] "
                       ~ MEMBERNAME!I ~ ";";
            return ret;
         }
         mixin(__gentypes());
      }
   }

   alias PriceBars = SOA!(PriceBar, 8);

which you'll have to adjust to your requirements (eg drop the '"~LENGTH.stringof~"' part to get a struct-of-slices, which is what your example above shows).

artur



Thanks to Artur, John Colvin, and Babu for the very helpful responses. This should be up on the wiki, and ideally someone should write a little tutorial text talking the reader through how this works and why choices were made a certain way. I will stick these up on the wiki with attribution if there are no objections. Something is better than perfect in this situation.

There is a big gap between understanding what language terms do and knowing in practice how to use them for metaprogramming if you don't previously come from a C++ background. I originally learnt C with parameters in K&R style, and the world has changed quite a lot since those days - both the relative slowness of memory, and CTFE/metaprogramming are quite new concepts to me (Forth doesn't count). It's very easy to be quickly productive in D for most things (I found it easier than Python, which I learnt previously) but there is a bigger leap in learning templates+CTFE - not because it's intrinsically hard, but it's a different way of thinking that is unfamiliar. Probably I should read more source code - the harder way is often easier in the longer term.

In case it's of interest my own reason for wanting to do this transformation was not cache efficiency, but just to be able to easily get the data into a form I can access from PydMagic and PyD, since for some chart applications it's easier to have the data in this form, and I would rather do all transformations in D and stick to Python only for pure charting.

I appreciate the thoughtful responses.


Laeeth.

Reply via email to