Another iostreams question

Is it possible to do something like template <typename T> T* Access(int n) { return chain.component<n, T>(); } because my compiler (GCC) doesn't like it. And if not, then how can I access a component without knowing at compile time its index?

"Lisa Glendenning" <lisa@lanl.gov> wrote in message news:1124320594.18856.24.camel@jenkins.tsasa.lanl.gov...
Is it possible to do something like
template <typename T> T* Access(int n) { return chain.component<n, T>(); }
because my compiler (GCC) doesn't like it.
What version of GCC are you using? Have you tried chain.template component<n, T>(); ?
And if not, then how can I access a component without knowing at compile time its index?
That's a good point. The index probably should have been a runtime value. This was a feature I added after review, and I never solicited comments on it. Jonathan

I am building a templated container class C. Normally it acts just like an stl::map. However, if the mapped_type of a container C<key1, value1> is also a specialization of C (value1 = C<key2, value2>) then the key types of the containers are merged in to a tuple yielding a container that acts like C< <key1, key2>, value2 >. Obviously the MPL has been quite useful for this but I'm not clear on the best style / usage for a particular effect. Inside C, the insert method has two parts, the part that's the same regardless of whether C is merged container and the part that isn't. How should I arrange to have different code executed depending on whether C is a merged container or not? I have a class static const bool IS_OUTER that is set to true for merged containers and false otherwise. 1) Compile both paths but use a run time if on IS_OUTER to select the proper action. Presume the compiler will get rid of the cruft via dead code elimination. 2) Have two sub-methods, one for merged and one for not, and use mpl::if_c with bind from the non-differentiated method to invoke the appropriate sub-method. 3) As (2) but with explicit functors instead of sub-methods. 4) Use a pair of specialized mixin classes of which the main container inherits exactly one depending on whether it's merged or not. Each mixin defines the same set of methods with differing implementations for the two cases. 5) Use traits classes keyed by IS_OUTER to provide the differing implementations. Surely other people have done with MPL and I'd be interested to know what style they used.
participants (3)
-
Alan M. Carroll
-
Jonathan Turkanis
-
Lisa Glendenning