Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In general, if you are facing a <em>design</em> situation that gives you a choice, <strong>use templates</strong>. I stressed the word <em>design</em> because I think what you need to focus on is the distinction between the use cases of <code>std::function</code> and templates, which are pretty different. </p> <p>In general, the choice of templates is just an instance of a wider principle: <em>try to specify as many constraints as possible at compile-time</em>. The rationale is simple: if you can catch an error, or a type mismatch, even before your program is generated, you won't ship a buggy program to your customer. </p> <p>Moreover, as you correctly pointed out, calls to template functions are resolved statically (i.e. at compile time), so the compiler has all the necessary information to optimize and possibly inline the code (which would not be possible if the call were performed through a vtable).</p> <p>Yes, it is true that template support is not perfect, and C++11 is still lacking a support for concepts; however, I don't see how <code>std::function</code> would save you in that respect. <code>std::function</code> is not an alternative to templates, but rather a tool for design situations where templates cannot be used.</p> <p>One such use case arises when you need to resolve a call <strong>at run-time</strong> by invoking a callable object that adheres to a specific signature, but whose concrete type is unknown at compile-time. This is typically the case when you have a collection of callbacks of potentially <em>different types</em>, but which you need to <em>invoke uniformly</em>; the type and number of the registered callbacks is determined at run-time based on the state of your program and the application logic. Some of those callbacks could be functors, some could be plain functions, some could be the result of binding other functions to certain arguments.</p> <p><code>std::function</code> and <code>std::bind</code> also offer a natural idiom for enabling <em>functional programming</em> in C++, where functions are treated as objects and get naturally curried and combined to generate other functions. Although this kind of combination can be achieved with templates as well, a similar design situation normally comes together with use cases that require to determine the type of the combined callable objects at run-time.</p> <p>Finally, there are other situations where <code>std::function</code> is unavoidable, e.g. if you want to write <a href="https://stackoverflow.com/questions/14531993/can-lambda-functions-be-recursive/14532044#14532044">recursive lambdas</a>; however, these restrictions are more dictated by technological limitations than by conceptual distinctions I believe.</p> <p>To sum up, <strong>focus on design</strong> and try to understand what are the conceptual use cases for these two constructs. If you put them into comparison the way you did, you are forcing them into an arena they likely don't belong to.</p>
    singulars
    1. This table or related slice is empty.
    1. POstd::function vs template
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USAndy Prowl
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POstd::function vs template
      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. COI think "This is typically the case when you have a collection of callbacks of potentially different types, but which you need to invoke uniformly;" is the important bit. My rule of thumb is: "Prefer `std::function` on the storage end and template `Fun` on the interface".
      singulars
      1. PO
      1. USR. Martinho Fernandes
    2. CO@R.MartinhoFernandes: I agree with you, although what I tried to convey in my answer is that the OP should focus on the use cases for which the two constructs do not overlap, rather than on those for which they do overlap and can be compared - with obvious results. Technically, the key design discriminant is always the same IMO: whether dynamic polymorphism is needed or not. And yes, the bit you mention is probably most representative of the design situations which require dynamic polymorphism.
      singulars
      1. PO
      1. USAndy Prowl
    3. CONote: the technique of hiding concrete types is called *type erasure* (not to be confused with type erasure in managed languages). It's often implemented in terms of dynamic polymorphism, but is more powerful (e.g. `unique_ptr<void>` calling appropriate destructors even for types without virtual destructors).
      singulars
      1. PO
      1. USecatmur
 

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