So far my best ideas have been as fallows

A) Represent a "card" in one structure and have a "deck" in another a deck being an array of 52 cards and a card being 2 chars one for and rank one for suit.

B) The second seems like it might be easier to manage but less obvious in code. Creating an array of ints each with a different value ranging from 1-52. Then crating a conversion function that would translate the value to a card structure that would have a string for the suit and a string for the rank. The value of zero could indicate a card that has not been "dealt".

Just trying to find a better way of doing this.

  • 2
    "Better" is a relative term that only makes sense when you evaluate your design against a set of requirements. What does your program need to do, how fast and how much memory can you spare for it? Define your goals and then shoot the arrows.
    – idoby
    Commented Mar 22, 2014 at 11:42
  • Memory and speed are important but not the main focus here. Functionality is. I would like to be able to reuse it in any card game but in the case I do need to be able to figure out odds based in pre-decided hands. So a method that would make this easier would help.
    – Joe
    Commented Mar 22, 2014 at 11:46
  • Sounds like you need to design your implementation to be most natural for C programmers to work with, since you have no need to sacrifice convenience for speed or memory use.
    – idoby
    Commented Mar 22, 2014 at 11:49
  • sounds right as I may not be the one who maintains this project but I would like to be able to add optimizations later on. It can not get much slower as the current implementation is written in Java. I would use it as an example but it is a very bad design and difficult to read.
    – Joe
    Commented Mar 22, 2014 at 11:53
  • Good rules of thumb: 1) never spend time optimizing unless you're sure you need to and 2) trust the compiler to do the right thing unless you know it won't.
    – idoby
    Commented Mar 22, 2014 at 11:56

2 Answers 2


It depends on the cards (joker included or not), but I'm using situation B mostly. However I use the first two bits of the integer value to define the color and the rest to define the card value making them together the card. Then I can get the color or value from the card much quicker with bitwise (or mod, divide and multiplication) operations. We simply store two integer values into one integer. The card value we store starting from the third bit, so we can simply multiply that value by four or use a bitshift of 2. Then we add the card color (0, 1, 2 and 3) which is never more than 2 bits in the first 2 bits of the card.

Assuming that the second card is a two and the second color is clubs. So a 2 of clubs will be stored as (binary) 100 + 1 = 101 which is 5 in decimals. If we have card 5 we can use mod and divide because card / 4 will tell us the card value and card % 4 will tell us the card color.

  • 3
    I'd look into using card & 3 to get the suit so that you clearly communicate the data in place isn't numeric. Likewise, shifting the suit off rather than /4 To communicate the nature of the data. They compile the same or similar, but working with them as non-numeric shows more of the intent of the data to the next programmer.
    – user40980
    Commented Mar 22, 2014 at 13:25
  • 2
    What so you think is more readable - card & 3 to access the suit, or card.Suit?
    – Doc Brown
    Commented Mar 22, 2014 at 18:17
  • @DocBrown The strut is ultimately the proper answer. However, if you are going to use a bitfield to store the data than using it as a number with integer math operations conveys the wrong information/intent about the data.
    – user40980
    Commented Mar 22, 2014 at 19:37
  • 1
    This post does only state how to use B, but does not contain any information why to prefer B over A.
    – Doc Brown
    Commented Mar 23, 2014 at 7:21

So you either want to represent a card as an int, with the need to convert to suit/rank whenever you need that, or you represent it as a

   struct Card
       char Suit;
       char Rank;

with no need to convert to suit/rank whenever you need those values. Performance and memory resources won't differ much between both approaches, I guess they are completely neglectable. So it all boils down to "which alternative is more readable" - and it seems very obvious to me that using a struct Card to represent cards will be much more readable than using an int and doing any unnecessary encoding / decoding.

EDIT: the only reason I can think of why one should use the integer representation is when you need the cardnumber (1...52) mainly as an array index, and you expect the usage as a card with Suit and Rank as very seldom needed in your program.

  • Another reason to use int might be performance-related. Most architectures do best on accessing int-aligned data (though your struct might be padded to do that anyway). Commented Mar 23, 2014 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.