Re: How to elegantly get the enum code from its string type
On Apr 14, 2:27 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
"Kai-Uwe Bux" <jkherci...@gmx.net> wrote in message
news:hq4f9d$9qf$1@news.doubleSlash.org...
The unsigned types are indeed a perfectly fine language
feature; and there are contexts where you absolutely would
want to have them. What causes trouble, every once in a
while, are the rules for conversion and promotion. It is
with those in mind that one has to make the call whether a
variable or a return type should be signed or unsigned.
Opinions differ on what is advantageous in which context.
Probably, a lot depends on the local culture: code should
reflect intent, and different shops can use the
signed/unsigned distinction as slightly different markers.
Yes code should reflect intent and my use of unsigned integral
types reflect the fact that I am using values that only make
sense when positive.
That's true for people who don't know the language. In fact,
the use of unsigned integral types says more than that: it says
that modulo arithmetic is desired, and that differences of the
values don't make sense.
Alf's assertion that unsigned types indicate "modular
arithmetic" is a nonsense
Nonsense or not, it's what the standard says.
as sizeof(T) does not indicate "modular arithmetic"
It indicates that, on certain, very old machines, you need that
extra bit.
and the type of the sizeof operator is std::size_t which is an
unsigned integral type.
Or that the STL was developed on 16 bit machines, where that
extra bit might have been relevant.
std::size_t is used extensively in the real world so unsigned
types are also used extensively in the real world and not just
in "modular arithmetic" contexts.
Once code has been tainted by an unsigned type, you more or less
have to go with the flow.
std::allocator<T>::size_type is a typedef of std::size_t which
is an unsigned integral type.
As I mentioned elsewhere in this thread the following is perfectly fine:
typedef std::vector<int> items;
...
items theItems;
...
for (items::size_type i = 0; i != theItems.size(); ++i)
{
/* do stuff with theItems[i] */
}
making "i" above an "int" or even more perversely a ptrdiff_t
would be just plain wrong.
Agreed. Since theItems.size() has tainted the code with
unsignedness, you more or less have to follow suite. That
doesn't mean that it's a good choice in general.
--
James Kanze