Re: How to elegantly get the enum code from its string type
* Leigh Johnston:
* James Kanze
Back when C was being standardize, 16 bit machines were still
legion, and the extra bit was necessary. Today, realistically,
size_t is an anachronism, and not really necessary. (It's worth
noting that the STL was originally developed using Borland C++,
on a 16 bit machine. Which possibly accounts for it's use of
unsigned size_type as well.)
Even today, size_t is designed to support the very lowest level
of programming, and there are contexts (e.g. writing a garbage
collector) where you really do need that extra bit. (A garbage
collector on a 32 bit machine has to handle memory blocks which
are larger than 2GB.) But you don't normally use it in
application level code, except to avoid signed/unsigned
comparison warnings when using the STL.
James your outlook is very antiquated. Modern C++ software development
does (or at least should, embedded aside) involve extensive use of the
"STL"
James is a bit of an expert on the STL...
and therefore extensive use of std::allocator<T>::size_type.
.... and this conclusion, if it is a conclusion, does not follow from your
premise. Perhaps it isn't a conclusion but just a silly wordplay, thinking that
if size_type is involved then it's "use"d at the application level. But that's
idiotic, so I assume you didn't mean that.
Use unsigned integral types where they make sense such as for
representing a "size" which cannot be negative or an "index" into an
array which cannot be negative.
And this is your umpteenth re-assertion of that viewpoint without any argument
to back it up, and ignoring all counter-arguments.
Take a look at the new C++0x array
container, its size_type is an explicit typedef of std::size_t and it is
used for both size() and element indexing.
Yes, it must, by historical accident; this is unfortunately the convention of
the library, too late to be fixed now.
Yes you have to make sure you do not create any signed/unsigned bugs but
that is what you are being paid for.
No. You may be paid to rapidly produce software that to the causal user looks OK
but is really a mess with both a lot of errors wrt. to spec and a spec that is
itself erroneous (especially when the customer is e.g. the Dutch army), or you
may be paid to somewhat slower produce correct software. But you're not paid to
knowingly use a technique that is more work in the first place and is likely to
introduce bugs, and then waste time identifying and fixing those bugs.
Cheers & hth.,
- Alf