Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Also for the first call of g(1), I should have one call of f(char) followed by two calls of f(int) and for the second call I should get three calls of f(char).</p> </blockquote> <p>This is not the expected result with a Standard compliant compiler. Since both time you call it with a fundamental type, you will <em>not</em> get name lookup at the instantiation context for the function call. </p> <p>Name lookup at instantiation context only happens for argument dependent lookup (called <em>lookup using associated namespaces</em>). Both of <code>int</code> and <code>char</code> do not have argument dependent lookup, an thus <em>all</em> the function calls you do will call <code>f(char)</code> after you removed the <code>d++</code> line. </p> <hr> <p>Since i understand you won't possibly just believe me, here is the Standard quote, out of <code>14.6.4.2</code>:</p> <blockquote> <p>For a function call that depends on a template parameter, if the function name is an unqualified-id but not a template-id, the candidate functions are found using the usual lookup rules (3.4.1, 3.4.2) except that:</p> <ul> <li>For the part of the lookup using unqualified name lookup (3.4.1), only function declarations with external linkage from the template definition context are found.</li> <li>For the part of the lookup using associated namespaces (3.4.2), only function declarations with external linkage found in either the template definition context or the template instantiation context are found.</li> </ul> </blockquote> <p>Note that the article uses a defective example of the Standard (at <code>14.6/9</code>) (and note that examples are non-normative: They can't change or state rules. Their purpose entirely is illustrative). The defect has been fixed and is incorporated into the upcoming Standard. See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197" rel="nofollow noreferrer">this defect report</a>.</p> <hr> <p>As you see, you will have to change from <code>int</code> / <code>char</code> to some user defined type (enums or classes) too see the effect of lookup in instantiation context. Read this answer <a href="https://stackoverflow.com/questions/804217/function-template-declaration-order-affects-visibility-sometimes/804686#804686">Order affects visibility</a> for more information. </p>
    singulars
    1. This table or related slice is empty.
    1. POName resolution in templates
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USJohannes Schaub - litb
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POName resolution in templates
      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. COExcellent - I hadn't read that defect report. It's a little more subtle than I thought.
      singulars
      1. PO
      1. USJames Hopkin
    2. COIf I've read the DR correctly, it seems they've gone for a 'quick fix' - make the example fit the wording - but actually the behaviour is inconsistent, and I'd guess hard to implement.
      singulars
      1. PO
      1. USJames Hopkin
    3. CO@James i don't know why ordinary name lookup doesn't work at instantiation context. But i guess that would make the instantiation context too much dependent on the position the call happens. You as a user of the template function would have to consider every candidate function in the current scope. Now, with only ADL working, you only have to consider the argument's associated namespaces and classes.
      singulars
      1. PO
      1. USJohannes Schaub - litb
 

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