Re: How to elegantly get the enum code from its string type
"Kai-Uwe Bux" <jkherciueh@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. If I
have values which can be positive or negative then I will use a signed
integral type.
Alf's assertion that unsigned types indicate "modular arithmetic" is a
nonsense as sizeof(T) does not indicate "modular arithmetic" and the type of
the sizeof operator is std::size_t which is an unsigned integral type.
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.
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. The return type of std::vector<int>::size() is
std::vector<int>::size_type not "int".
/Leigh