Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You wrote about storing objects from your object model inside std::vector etc. and problems with using pointers to them. That reminds me that it's good to divide your C++ classes into two categories (I'm not sure about terminology here):</p> <ol> <li><p><strong>Entity classes</strong> which represent objects that are part of your object model. They are usually polymorphic or potentially will be in the future. They are created on heap and are always referenced by pointers or smart pointers. You never create them directly on stack, as class/struct members nor put them directly in containers like std::vectors. They don't have copy constructor nor operator= (you can make a new copy with some Clone method). You can compare them (their states) if it's meaningful to you but they are not interchangable because they have identity. Each two objects are distinct.</p></li> <li><p><strong>Value classes</strong> which implement primitive user defined types (like strings, complex numbers, big numbers, smart pointers, handle wrappers, etc). They are created directly on stack or as class/struct members. They are copyable with copy constructor and operator=. They are not polymorphic (polymorhism and operator= don't work well together). You often put their copies inside stl containers. You rarely store pointers to them in independent locations. They are interchangeable. When two instances have the same value, you can treat them as the same. (The variables that contain them are different things though.)</p></li> </ol> <p>There are many very good reasons to break above rules. But I observed that ignoring them from the start leads to programs that are unreadable, unreliable (especially when it comes to memory management) and hard to maintain.</p> <hr> <p>Now back to your question.</p> <p>If you want to store a data model with complex relationships and easy way to do queries like "find X's child named George", why not consider some in-memory relational database?</p> <p>Notice that when you are going to efficiently implement a) more complex bidirectional relationships and b) queries based on different object properties, then you will probably need to create indexed data structures that are very similar to what relational database does inside. Are your implementations (as there will be many, in single project) really going to be more effective and robust?</p> <p>Same goes for "collections of everything" and object ids. You'll need to track relationships between objects to avoid ids without objects anyway. How is it different from pointers? Other then getting meaningful errors instead of going crazy all over the memory, that is ;-)</p> <hr> <p>Some ideas for memory management:</p> <ul> <li><p>Strong ownership: when you can declare that some entity lives only as long as its owner and there is no possibility of independently existing pointers to it, you can just delete it in owner's destructor (or with scoped_ptr).</p></li> <li><p>Someone already proposed smart_ptr. They are great and can be used with stl containers. They are reference couter based though, so do not create cycles :-(. I am not aware of any widely used c++ automatic pointers that can handle cycles.</p></li> <li><p>Maybe there is some top-level object which owns all other objects. Eg. often you can say that all pieces belong to a document or an algorithm or a transaction. They can be created in context of top-level object and then deleted automatically when their top-level object is deleted (when you remove document from memory or finish execution of algorithm). Of course you cannot share pieces between top level objects.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POlibraries/approaches for implementing object models in C++
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTomek Szpakowicz
    1. USTomek Szpakowicz
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POlibraries/approaches for implementing object models in C++
      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. VTAcceptedByOriginator
    1. This table or related slice is empty.
 

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