Zacariaz wrote:Solar wrote:1) A "card" object should represent a card, not a way to store multiple cards. IMHO, whether to use a linked list, STL container or whatever should be the decision of the client code, not the class itself.
yes, but somewhere i allso wrote that the math was to complex to do what i wanted to do, so instead i would do some trial statistics. For that it would be very nice to have a deck of cards.
This is about "thinking object-oriented". A class defines the characteristics of something. A card in real life has a value, and is of a set. A card does
not have a pointer to another card. So, making a "class card" having such a pointer breaks the abstraction, and you should spend some time thinking about if you could do without (which you can, as I have pointed out in my code).
Zacariaz wrote:Solar wrote:
2) You let the client (deck) modify the next-pointer of card objects? "Friend" declarations are evil...
how is that any different than a normal linked list?
Again, this has to do with using the programming language "right". C++ is very flexible in that you
can implement things in almost every way you like, but some are better suited to the language than others.
Zacariaz wrote:you have a struct, in this case a class, and you add nodes to it by doing axcactly this, or am i completely wrong here?
Correct, if you're doing a linked list in C. But a) this is C++, so handling of member pointers should be done by member functions, not "friends", and b) I seriously doubt a linked list is called for here. As long as you can "get away" using standard containers like <vector>, do so.
Zacarias wrote:Solar wrote:
5) why are the sets valued 5, 4, 3i, 6 respectively?
they are, atleast on my computer, a part of the ascii table representing spades, hearts, diamonds and clubs symbols.
Ah, I see. Add this as a comment.
Zacariaz wrote:The important thing to understand here is that V[] and S[] in deck in only used to ease outputting hte cards ag.
Ace of spades == As == 0,3
but i dont want to print 0,3 to the screen, As looks so much better so:
std::cout << V[0] << S[3];
outputs As
It is not a good solution, i know, but it was the only opne i could think of.
Here we come to the point where "friend" declarations actually make sense:
Code: Select all
class Card {
...
friend ostream& operator<<( ostream& os, const Card& card );
};
ostream& operator<<( ostream& os, const Card& card )
{
os << "[" << Card::Set[ card.mSet ] << Card::Set[ card.mValue ] << "]";
return os;
}
Zacariaz wrote:Solar wrote:
6) You are calling new() in Deck::Deck(), but your destructor does nothing: Memory leak.
is this simular to point 4.? if not i think it requires further explanation for me to understand it.
A "normal" variable declaration (without "new") means the variable is constructed on the stack. Once the stack frame is deleted - because the block in which the variable was declared is ended - the variable gets auto-destroyed, i.e. its destructor called.
If you declare a variable using "new", the variable is constructed on the
heap instead, and will remain there untill you explicitly call delete() for it.
Now, your deck() constructor repeatedly calls "new card()", creating 52 cards on the heap. The ~deck()
destructor does nothing, i.e. the deck gets deleted, but the 52 cards remain in memory.
Since you now no longer have a "deck" object that knows
where those card objects are located, you can no longer delete() those cards, and have lost 52 * sizeof( card ) in memory. Do this repeatedly, and your memory will "leak" away.
The correct action would have been to go through the lists of your cards, in ~deck(), and calling delete() for every one of it.
Zacariaz wrote:i dont think it is very hard to understand what im trying to do...
The "what" (deck of cards with the option of printing their values in some intelligible manner) is not in question, but the "how" (linked list handling).
Zacariaz wrote:...and i do think this is the right approach for creating a deck of cards, which in this case is the only thing im trying to do.
Your approach was not "wrong"
per se, it just did not make efficient use of the language and was needlessly complicated, making things difficult for you. Now, if you tell me you want to program this
for the sake of learning to handle linked lists, my alternative suggestion would have looked different.