Re: why does this work with Visual C++ 2005?
On Wednesday, 2 October 2013 07:07:58 UTC+1, gwowen wrote:
James Kanze <james.kanze@gmail.com> writes:
Except that std::array doesn't replace it in its main uses. You can't
pass an `std::array` to a C interface (you need to take the address of
it's first element explicitly),
"You can't pass it to a C-interface - except that you can."
The need to explicitly decay to a pointer is a feature, not a bug, and
maps quite nicely onto the operate-on-iterators-not-containers idiom.
Actually, on rereading the specifications: `std::array<>` has
the `data` functions which are explicit, and exactly what is
needed.
(The C decay-to-pointer can, of course, be viewed as expression of this
idiom, albeit one with a horrible warty syntax. And, yes, I do
appreciate the historical reasons why it is what it is. But that
doesn't mean I approve.
The automatic-pointer-decay in function arguments is a syntatic sugar
that confuses more often than it helps. If the function arg is really
a pointer, it is usually better for it to be declared as a pointer.
With 20-20 hindsight, the rule should've been "you can't pass an array
type to a function, you must pass its address explicitly")
I agree. And I never declare a function with an array argument;
I always use the pointer (the rare times I need it).
On the other hand, how many text books show main as
"int main( int argc, char* argv[] )", rather than
"int main( int argc, char** argv )" (which is the way I write
it). That's even how it is presented in the standard. And that
influences people.
and you can't get the compiler to calculate its dimensions from the
number of initializers.
Which is a shame, but its hardly insurmountable. And I wouldn't
describe automatic initialiser counting as one of the main uses.
It's the major reason I use C style arrays. (And for static
initialization, in pre-C++11 code.)
In my experience, given that the automatic sizeof() information gets
lost in any translation unit not containing the initializer, arrays of
user-specified size (often a C macro) are far more common.
(C-strings are the exception, because you can always find the embedded nu=
l).
But translation units not containing the initializer don't see
the C style array. It's almost always in the unnamed namespace.
You don't expose things like that to the outside, you provide an
interface which uses them.
I even have a couple of class templates which depends on it:
template< typename MappedType,
typename KeyType = char const* >
struct StaticMap
{
KeyType key;
MappedType value;
class Matcher
{
public:
explicit Matcher(KeyType const& target_key)
: m_Key(target_key)
{
}
bool operator()(StaticMap const& obj) const
{
return m_Key == obj.key;
}
private:
KeyType m_Key;
};
static StaticMap const* find(StaticMap const* begin, StaticMap cons=
t* end, KeyType const& value)
{
return std::find_if(begin, end, Matcher(value));
}
template < size_t n >
static StaticMap const* find(StaticMap const (&array)[n], KeyType c=
onst& value)
{
StaticMap const* retval = find(begin(array), end(array), valu=
e);
return retval == end(array) ? nullptr : retval;
}
};
(With a partial specialization for KeyType = char const*, with
a Matcher and find functions which take std::string.) I use
this a lot for things like mapping strings to enum constants,
for example. (In which case, the actual StaticMap instance, and
the wrapper functions which use it, are machine generated.) And
the mapping works even when called from the constructor of
a static object.
But yes,
std::array<int,auto> arr = {3,4,5};
would be nice.
It's also a nice solution with regards to the syntax. Making it
fit into the language is perhaps another issue, requiring
a special case. (But it's not as if the formal definition of
C++ was lacking special cases. One can argue that we already
have too many, and so we shouldn't introduce another one, but
one could also argue that given that there are so many, what's
one more or less.) Do that, and make main in C++ take a single
"std::vector<std::string> const&" argument, and we really could
do away with C style arrays.
--
James