Andy Little wrote:
OK. FWIW I found that creating a sequence by pushing_back result_types to an empty vector is a great way to 'create' a result sequence at compile time. It kind of creates something out of nothing. At runtime however I found I could employ a different approach by using recursive functors(that is still compile time rather than runtime recursion, but much faster to compile and using less resources, whereas joint_view can be a resource hog)
A resource hog? At compile time? At runtime? I'd like to know how you arrived at that observation. You can use result_of::push_back to build your sequence at compile time and that (AFAICT) is quite cheap. , because now the type of
the result sequence is known. Basically the compile time and runtime stages are doing different jobs. The compile time fold push_back is working out what the final sequence will be. Now the runtime's job is to figure out the most efficient way to initialise the sequence, that it already knows about. I havent yet figured how to create an initialiser so that the compiler will initialise the sequence right in the constructor(not that its impossible, just havent got round to trying), but I guess that would be ideal. The compiler is seeming to optimise away the default ctor, followed by the fill anyway, but it would be satisfying if I could express that intent more directly. I guess this might involve making a view, where each element contains an individual view of the function for initialising that element.
If it helps, you can also use mpl to build your type. Fusion can take in MPL sequences. Example: as_vector(an_mpl_sequence)
Anyway it might be worth thinking about not copying too slavishly the compile time behaviour at runtime, as maybe these are very different situations.
You mean: fusion should not copy the compile time behavior at runtime? Hmmm... but of course it does not. Let me get this straight: push_back *IS* cheap. It is the unfolding (iterating over) the push-backed view that is less than ideal. This can be made efficient by segmented techniques.
Second my analysis of copying is based on not too much science. IN VC8 the assembler code gets pretty big and later functions tend to join the output of earlier functions and with 20 Mb assembler files I tended to have ideas half way through reading it and never get to the end of the story to see what the compiler finally did! If that makes any sense. However it may well be that the compiler does keep track of the stuff its copying. It just gets a bit frightening seeing rep movsd instructions on bigger and bigger joint_views (where these might have typically 16 elemnts each with 2 referneces), with bigger and bigger arguments, but OTOH I suspect once it has to copy then the game is up.
The other question is whether Fusion scales. My guess is that the compile time should flatten out once the compiler starts seeing the same types, but OTOH this business of accumulating the result type may be 'interesting', but it requires writing some applications to find out, so that is what I'm currently about.
Ok. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net