On 5/27/05, David Abrahams <dave@boost-consulting.com> wrote:
Alexander Nasonov <alnsn-boost@yandex.ru> writes:
Peder Holt <peder.holt <at> gmail.com> writes:
On 5/27/05, Alexander Nasonov <alnsn-boost <at> yandex.ru> wrote:
Sizes may become very huge, though.
If you replace your function with: char (&foo())[900][800][700][600]; you will get an overflow when calculating e.g. sizeof(foo()) / sizeof(foo()[0]), and the result will be garbage.
That's right. Huge arrays can be replaced with tuples.
tuple<char(&)[9], char(&)[8], char(&)[7], char(&)[6]> foo();
Why not an mpl::vector for that matter?
It's easy enough to extract each dimension of an array with partial specialization. Just do the representation backwards:
char (& foo( whatever ) ) [CODEN][CODEN-1]...[CODE1][CODE0]
Steve Dewhurst was here before us.
sizeof(get<0>(foo())); sizeof(get<1>(foo())); sizeof(get<2>(foo())); sizeof(get<3>(foo()));
Not sure if it compiles with boost::tuple.
Inefficient at compile time. get<N> is O(N) each time, thus the above is O(N^2); that's part of what's behind the fusion library.
I made a version of typeof_impl that uses a single function invocation and an additional encode struct invocation (in addition to encode_type) Instead of taking the size of a function, I take the size of a member of the struct returned by a function. Current version: Access element 1: sizeof(at<1>(expr)) Proposed version: Access element 1: sizeof(typeof_result(expr).value1) If this is in any way better performance-wise than the current implementation, I do not know. Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost