Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>+1 for documenting the typedef conventions.</p> <ul> <li><em>Foo.h</em> - can you detail the problems you have with that? </li> <li><em>FooFwd.h</em> - I'd not use them generally, only on "obvious hotspots". (Yes, "hotspots" <em>are</em> hard to determine). It doesn't change the rules IMO because when you do introduce a fwd header, the associated typedefs from foo.h move there.</li> <li><em>Common.h</em> - cool for small projects, but doesn't scale, I do agree. </li> <li><em>Some kind of fancy #define</em>... PLEASE NO!...</li> <li><em>Use a vector subclass</em> - doesn't make it better. You might use containment, though.</li> </ul> <p>So here the prelimenary suggestions (revised from that other question..)</p> <ol> <li><p>Standard type headers <code>&lt;boost/shared_ptr.hpp&gt;</code>, <code>&lt;vector&gt;</code> etc. can go into a precompiled header / shared include file for the project. <strong>This is not bad.</strong> (I personally still include them where needed, but that works in addition to putting them into the PCH.) </p></li> <li><p>If the container is an implementation detail, the typedefs go where the container is declared (e.g. private class members if the container is a private class member) </p></li> <li><p>Associated types (like <code>FooListPtr</code>) go to where Foo is declarated, <strong>if</strong> the associated type is the primary use of the type. That's almost always true for some types - e.g. <code>shared_ptr</code>.</p></li> <li><p>If <code>Foo</code> gets a separate forward declaration header, and the associated type is ok with that, it moves to the FooFwd.h, too.</p></li> <li><p>If the type is only associated with a particular interface (e.g. parameter for a public method), it goes there.</p></li> <li><p>If the type is shared (and does not meet any of the previous criteria), it gets its own header. Note that this also means to pull in all dependencies.</p></li> </ol> <p>It feels "obvious" for me, but I agree it's not good as a coding standard. </p>
    singulars
    1. This table or related slice is empty.
    1. POHeader file best practices for typedefs
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdaramarak
    1. USpeterchen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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
    1. COgood points in general, but re #1: i don't recommend including the lot of standard libraries in a common header. the worst offense is the amount of private static data and definitions produced.
      singulars
      1. PO
      1. USjustin
    2. CO@Justin - Definitions - agreed, but that's what precompiled headers are for. but private static data? there's close to none in the standard headers (as it would be per translation unit anyway). Or do you mean the problems with early template support implementations? Unless that's a known and proven problem for your compiler, there's no point in sticking to it.
      singulars
      1. PO
      1. USpeterchen
    3. COi don't use precompiled headers. rationale: not enough commonality, and i often use combined builds so there is in many cases one file compiled per package. also, precompiled headers don't scale particularly well in distributed build systems. as far as static data, one obvious declaration that shows up is input/output streams (included by `iostream`). i lost about 20% of some binaries *after* removing superfluous includes from standard libraries (measured using a relatively modern implementation of std libs shipped with apple's gcc). the problems obviously extend beyond binary size.
      singulars
      1. PO
      1. USjustin
 

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