Regarding Problem with Short Data Type
-
in some c++ coding standard guidance i noticed following text written : "Avoid using short as its still generally packaged into a 32 bit chunk of memory. There are very few places where a short can be justified over a long." Can someone explain why is it so ?
-
in some c++ coding standard guidance i noticed following text written : "Avoid using short as its still generally packaged into a 32 bit chunk of memory. There are very few places where a short can be justified over a long." Can someone explain why is it so ?
That is don't use
UNICODEstrings?. :rolleyes: BTW probably you should give some more info about the context of the above statement. Sometimes taking a sentence out of its context doesn't make sense. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
in some c++ coding standard guidance i noticed following text written : "Avoid using short as its still generally packaged into a 32 bit chunk of memory. There are very few places where a short can be justified over a long." Can someone explain why is it so ?
Well it seems that author is trying to say that since a short which is 16 bit long is internally stored as 32 bit number it doesn't make sense to use it. I am not sure if this indeed is the case. -Saurabh
-
Well it seems that author is trying to say that since a short which is 16 bit long is internally stored as 32 bit number it doesn't make sense to use it. I am not sure if this indeed is the case. -Saurabh
Saurabh.Garg wrote:
I am not sure if this indeed is the case.
It depends on the compiler and platform. "1==sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)" is all the standard says. This tends to be interpreted as "char is 8 bits, short is 16 bits, int is 32 bits and long is 64 bits". But it doesn't need to be that case.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
Saurabh.Garg wrote:
I am not sure if this indeed is the case.
It depends on the compiler and platform. "1==sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)" is all the standard says. This tends to be interpreted as "char is 8 bits, short is 16 bits, int is 32 bits and long is 64 bits". But it doesn't need to be that case.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"Yes you are right but if you read original question again it says: "Avoid using short as its still generally packaged into a 32 bit chunk of memory. There are very few places where a short can be justified over a long." It clearly indicates that author is implying that short is not 32-bit but is generally packages as 32-bit. So I was just trying to say that I am not sure that short is packaged as 32-bit. -Saurabh
-
Yes you are right but if you read original question again it says: "Avoid using short as its still generally packaged into a 32 bit chunk of memory. There are very few places where a short can be justified over a long." It clearly indicates that author is implying that short is not 32-bit but is generally packages as 32-bit. So I was just trying to say that I am not sure that short is packaged as 32-bit. -Saurabh
Saurabh.Garg wrote:
It clearly indicates that author is implying that short is not 32-bit but is generally packages as 32-bit.
There is not ehough information available to rule out any of at least two possibilities: - They need to support some (exotic?) platform where short == int == long. - The sentece refers to #pragma pack, which defaults to a 32Bit boundaries to gain a significant speed boost at the expense of a non-significant amount of memory. The last possibility would be that rule is like 99% of all coding standard rules: Utter crap, designed to stop the programmers from doing real work.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
Saurabh.Garg wrote:
It clearly indicates that author is implying that short is not 32-bit but is generally packages as 32-bit.
There is not ehough information available to rule out any of at least two possibilities: - They need to support some (exotic?) platform where short == int == long. - The sentece refers to #pragma pack, which defaults to a 32Bit boundaries to gain a significant speed boost at the expense of a non-significant amount of memory. The last possibility would be that rule is like 99% of all coding standard rules: Utter crap, designed to stop the programmers from doing real work.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"Well I don't think author meant any of two things you mentioned.
jhwurmbach wrote:
The last possibility would be that rule is like 99% of all coding standard rules: Utter crap, designed to stop the programmers from doing real work.
I was really trying to say this but I was being polite :-) -Saurabh
