Boost logo

Boost :

From: Daniel James (daniel_at_[hidden])
Date: 2004-08-31 11:00:00

Arkadiy Vertleyb wrote:
> "Peder Holt" <peder.holt_at_[hidden]> wrote

> In my implementation there is no encode_array<T[10], 1>,
> encode_array<T[10],2>, etc.
> There is:
> template<class V, class T, int Size> struct encode_type_impl<V, const
> T[Size]>
> Which is the same type throughout BOOST_TYPEOF invocation, and therefore
> gets instantiated only once. So I insist that the order of my algorithm is
> O(N), which results from the need to instantiate "foo<n>(expr)" for every n
> from 0 to N-1.

I think some (older?) compilers might not reuse the encode_type_impl
instance, so they recalculate the list of integers (which takes o(m))
for all N instantiations of foo, giving a total O(Nm). Hopefully, this
isn't the case for the newer compilers, that your implementation
targets. So on them it's o(N), as you say.

I wonder if it's worth combinig the two techniques. That is, using
partial specialisation to encode the type, but storing the value list as
'compile-time constants' as in Peder's version. I think it should be

>>I think i am closing in on the ultimate typeof implementation.
> The "ultimate" implementation will come from the compiler vendors :)

Still, his implementation is fantastic, considering that it runs on
Visual C++ 6. Since my last post, I've made quite a lot of progress at
getting my variation to cope with complicated expressions with less
calls to 'foo'. But Peder's version takes about half the time to run my
tests, and will scale a lot better.


Boost list run by bdawes at, gregod at, cpdaniel at, john at