Re: Xcode 2 Question
Re: Xcode 2 Question
- Subject: Re: Xcode 2 Question
- From: Shawn Erickson <email@hidden>
- Date: Fri, 6 May 2005 09:09:03 -0700
On May 6, 2005, at 8:17 AM, Clark Cox wrote:
On 5/5/05, Markian Hlynka <email@hidden> wrote:
On May 4, 2005, at 17:03, Shawn Erickson wrote:
On May 4, 2005, at 3:36 PM, Markian Hlynka wrote:
In Xcode 1.5, if you had structs with member functions, they
completely fubared the function menu in xcode. For example:
typedef struct __PartialMove
{
//PartialMove is a coordinate!
short r,c; //source and destintion row and column.
//shorts are 16 bits (2 bytes), at least that's what they are
right now!
bool operator==(const struct __PartialMove &b)
{
return (r == b.r) && (c == b.c);
}
bool operator!=(const struct __PartialMove &b)
{
return !( (r == b.r) && (c == b.c) );
//alternatively, (r != b.r) || (c != b.c);
}
} PartialMove;
Ugh ;-)
If you really want to insure a certain sizing consider using int16_t
(#include <stdint.h>) instead of short (is a signed short really
what
you want?).
I'd say that odds are, if short isn't 16-bits, then there will be no
int16_t defined. Remember that the exact width integer types are
*optional*.
Yes I know. My wording wasn't the best in the above.
(note my "ugh" wasn't related at all to the use of short just the use
of functions in struct definition... it was also meant as a joking jab)
I was trying to point out the existence of standardized types that
better codify the intent you have for the sizing of a variable and
will insure that they are at least the size requested or larger. This
suggestion is better seen when dealing with things like long or int
that are more likely to vary from platform to platform (which size of
"long" did the coder want?).
I really wasn't trying to focus on that one short but on the
possibility that he didn't know or think about using types (not just
in the realm of shorts) that would help express intent as well as
insure minimum sizing.
His code comment below the short lead me to believe that he may not
have thought about it.
I'm aware of stdint.h, though I was also aware that it wasn't
officially C++ yet.
You're correct, it isn't. Though GCC supports it as an extension.
...or you could attempt to provide your own matching typedefs
depending on portability needs.
But, is there something wrong with just using
"short"? I didn't need precisely 16 bits... I just didn't need
anywhere
near 32 of 'em. ie, I wanted something smaller, but not too small.
char
or byte would probably have done as well.
IMHO, that's exactly the reasoning that should lead someone to use
short.
Yes agreed but using a typedef that better states the sizing (the
case of short isn't the best example for this reasoning) can make
code easier to follow and help avoid platform portability issues.
Should I be explicitly choosing my sizes, then? Is it bad form to use
"short" nowadays?
I'd say that, in this case 'short' is not only acceptable, but the
right choice.
No nothing wrong with using it but being more explicit doesn't hurt
either.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden