Re: A type-safe, compile-time constant for the array size
Lance Diduck schrieb:
These techniques have long been used, and in fact are now standard.
The author need have only consulted a good reference on TR1.
To wit:
enum{ count =tr1::extent<int[5][10][20] >::value};//5!!!
enum{ mcount=tr1::rank<int[5][10][20]>::value};//3!!!
enum{ count1=tr1::extent<remove_extent<
int[5][10][20] >::type >::value};//10!!!
enum{ count1=tr1::rank<remove_extent<
int[5][10][20] >::type >::value};//2!!!
typedef tr1::remove_all_extents<
int[5][10][20] >::type my_type;//int!!!
It is not hard to see how, using recursion, I could make a COUNT_OF
for any possible type of built-in array of any dimension, and wrap
this in any interface I found convenient.
And for the "compile-time error detection"
template <bool T>struct Detect;
template <>struct Detect<true>{enum {Yayyy};};
enum{ Yippiee=Detect<tr1::is_array<int[5][10][20]>::value>::Yayyy};
or whatever your favorite CompileTimeAssert mechanism is.
So while it is possible to invent and recount many different ways of
solving this, the real question is: why? I don't know about VC6, but
the above does work on a plethora of compilers, include xlC6, Sun
WS6U2, MSVC7.1, and imaginably any compiler written in this century.
I see one advantage of the proposed ansatz, that cannot be
realized by means of the new typetraits proposal: It works for
arrays of local types. I have the impression, that the author
basically has done his maths: He properly references other
well-known techniques and even provides an essentially
historic reference to an public discussion of this theme from
usenet in 1998, see
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/8e45b21773e191ea
This might not be the very first application of this technique,
but it is at least one of the first.
He did *not* reference the new typetraits proposal, but to be
fair, one has to recognize that this would only be the second
part to do the job (and would not work for local classes due
to 14.3.1/2): Via typetraits one cannot *immediately* deduce
the dimensions of a given object (e.g. by asking
std::extent<x>::value, where x is the tested instance), they
provide these data from a somehow deduced type. Of course,
after this has been done, the results are much more detailled.
The article also mentiones runtime approaches to realize this
issue.
One could criticize that once again an unnecessary reinvented
ASSERT and COMPILE_TIME_ASSERT is used (assert would
work here as well, and instead of COMPILE_TIME_ASSERT one
could have mentioned BOOST_STATIC_ASSERT and the upcoming
standardized static_assert).
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]