Also yes ->nVersion is a pointer to the int nVersion contained in pStart, there are no other shiny bits involved. Honestly if I were coding this from scratch I would have made nVersion private and added a method getVersion(); That's probably my Java experience talking, but it seems like better OO practice in my mind.
On Wed, Jan 22, 2014 at 7:35 PM, S. Dale Morrey <[email protected]>wrote: > SO the ampersand & in this case simply means bitwise AND, (bitmasking > operation), not Address Of? > That clarifies things. I believe it is in fact part of the marshalling and > serialization code to send client info to disk or over the wire, thus it > probably needs to be very specific if for no reason other than endianess, > right? > > > > On Wed, Jan 22, 2014 at 2:31 PM, Levi Pearson <[email protected]>wrote: > >> On Wed, Jan 22, 2014 at 5:23 AM, S. Dale Morrey <[email protected]> >> wrote: >> >> > For instance in many places, Origin has... >> > pstart->nVersion >> > >> > but fork1 has >> > pstart->nVersion&0xff >> > >> > According to the header nVersion is defined as an int. >> > >> > For the life of me I just can't understand what fork1 is doing with that >> > line of code. It's possible that this code was present in the origin >> code >> > base and only modified later, frankly I'm not sure how I would go about >> > checking. >> > >> > Still the line is bothering me, it's used in several places usually in >> > something along the lines of >> > if(pstart->nVersion >= 2){do something} >> > >> > and in the fork code it's the same except fork1 has the &0xff part as >> well. >> > if ((pstart->nVersion&0xff) >= 2){do something} >> > >> > I'm reading the origin code as >> > pstart object nVersion >> > >> > and the fork1 code as >> > pstart object nVersion at byte 255 >> > >> > So it's not making much sense to me. >> > I realize that an int in C++ is 4 bytes, and so this may be saying look >> at >> > only the first (or possibly second) 2 bytes. Even so I'm not sure >> which it >> > may be saying to look at or for that matter why would we only look at 2 >> > bytes of a 4 byte int. >> >> The type 'int' in C++ varies in representation depending on the >> architecture. Specifically, it's: >> * not smaller than 'short' >> * at least 16 bits (on a 32/64-bit system, it will usually be at >> least 32 bits, but there is no guarantee of this in the spec) >> * signed >> >> See the std::numeric_limits template class in <limits> to determine >> the numeric properties of the base types in the standard C++ way. >> To find out what they are in C, you'd use <stdint.h> >> In either language, the 'sizeof' operator will give you the size of >> any variable or type (types must be parenthesized, but variable names >> need not be). >> Note that 'sizeof' returns the size in multiples of the 'char' type's >> size, i.e. 'sizeof (char)' is always 1. >> >> The type 'char' in C++ is defined to be: >> * large enough to store any member of the implementation's basic >> character set (which is not defined by the spec) >> * possibly holds negative values (implementation-defined) >> * all bits participate in the representation (no padding) >> * for unsigned char, all bit patterns represent numbers >> >> Note that nothing there says '8 bits'; there are some platforms where >> the bit-width of char is not 8. A co-worker of mine was fairly >> recently programming a DSP chip where the bit width of char was 32 >> bits, which was the addressable unit of the processor. Of course, >> this meant that sizeof (int) = 1 for that platform. He was very >> confused for a while. >> >> Also note that if the C or C++ specifications speak of a 'byte', they >> really mean a 'char'. They normally don't use 'byte', though, as it >> is not an unambiguous term. >> >> So... on to the code. >> >> pstart->nVersion&0xff >> >> There are two operators in this expression, '->' and '&'. They are >> both left-associative, and '->' has higher precedence. So this is >> equivalent to: >> >> (pstart->nVersion) & 0xff >> >> The '->' operator is the "member of pointer" operator. Unless it's >> overloaded, in which case it might do something unexpected, it >> dereferences the pointer to its left and looks up the member named on >> its right at the dereferenced struct/object. Unless that member is a >> function or enumeration, the result will be an lvalue designating that >> member. >> >> You didn't explicitly give the type of the nVersion member; based on >> what you *did* say I will assume it is 'int', but if it's actually >> something different then the following could be not quite correct. >> >> So, we have an lvalue of type int on the left of the '&' operator and >> a hexadecimal literal value on the right. >> >> A literal with no suffix will have the smallest type of int, long int, >> or long long int that it will fit in. So, at least 16 bits, most >> likely 32, a signed quantity, and all but the least significant 8 bits >> are zero. We have an 'int' on the left and an 'int' on the right, so >> no integral type conversion takes place. >> >> The '&' operator is the bitwise-AND operator. Since both sides have >> the same bit width, the implementation is the obvious bitwise AND >> (unless it was overloaded, of course), which will have the effect of >> setting all but the least significant 8 bits of the final value to 0, >> with the least significant bits retaining the value they had on the >> left-hand side. >> >> So the final evaluation of the expression is an rvalue of type int. >> It will be a positive integer between 0 and 255 consisting of the >> least-significant 8 bits of the value stored at pstart->nVersion. >> >> This seems like an odd thing to do to a version number, but it might >> be reasonable if it's going to be put into an 8-bit field somewhere >> after the quoted bit of code. It would ensure that you didn't try to >> stuff more than 8 bits into the 8-bit field, but it would certainly >> mangle version numbers that were negative or too large to fit. >> >> --Levi >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ >> > > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
