Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Yes, <strong>in this case</strong> it seems to be reasonable (by "in this case" I mean "considering what I can guess about the semantics of your <code>GameEngine</code> and <code>Board</code> classes and the nature of their association/aggregation relationship"):</p> <ol> <li>Rather use a smart pointer than a raw pointer to hold the <code>Board</code> object in <code>GameEngine</code>. <code>unique_ptr</code> is probably what you want in this case, because all other aliases seems to be just observers and the lifetime of the board object is bound to the one of the <code>GameEngine</code> object. However, if shared ownership is needed, opt for <code>shared_ptr</code>. Just try not to use raw pointers, <code>new</code>, and <code>delete</code>, because they lead to buggy code;</li> <li>You still need to provide public functions on the interface of the <code>Board</code> class to modify the board, because <code>Player</code> won't be able to access its private member variables (and <code>board</code> happens to be one).</li> <li>Rather than <code>#define</code>s, use <code>constexpr</code> values for the sizes of the board (if you are using C++11). You might also want to consider <a href="http://www.boost.org/doc/libs/1_52_0/libs/multi_array/doc/index.html" rel="nofollow">Boost.MultiArray</a> for creating <em>safe</em> bi-dimensional C-style arrays.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POc++ OOP design - passing data member to other classes - is it reasonable?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAndy Prowl
    1. USAndy Prowl
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POc++ OOP design - passing data member to other classes - is it reasonable?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you very much for your answer. I'll add an arrow, collisions (only between players) and support for 2-3 players (Human and Computer). I just always believed It is really forbidden to let a class like Player to know about its Board. That's one point I can use to deduce for a lot of other Projects where I tried to avoid passing ref of a data member or this in the sake of OOP rules.
      singulars
      1. PO
      1. USSyndicatorBBB
    2. CO@SyndicatorBBB: this is what I was afraid of :-) Do not "deduce a lot". The fact that a class should not know about the implementation details of another class is a valid principle and it is called *Information Hiding*. You don't want to give that up. However, here it seems to me that the board is a *visible* element of the `GameEngine` class. The pointer is declared as private because you don't want other classes to overwrite that *pointer*, making `GameEngine` point to *another* board. But the *pointed object* itself is supposed to be shared, I guess. [continues...]
      singulars
      1. PO
      1. USAndy Prowl
    3. CO@SyndicatorBBB: [...] So you are not really passing a private member of the class, but rather you are passing an object to which the class is associated through a private member (in your case, a raw pointer, but again, use smart pointers instead). Now if you were giving `Player` a *reference* to that pointer, meaning that you are actually passing *the association itself* and not only the associated object, then you would be breaking the encapsulation principle. So indeed passing a reference or a pointer **to** a member variable is usually not OK. But in this case you are not doing that.
      singulars
      1. PO
      1. USAndy Prowl
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload