Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've simplified your example to the following:</p> <pre><code>typedef unsigned int size_t; template &lt;typename T&gt; class List { public: typedef size_t size_type; List (List const &amp;); List (size_type i, T const &amp; = T()); }; typedef List&lt;unsigned char&gt; UCList; class MyClass { public: operator UCList const () const; operator unsigned char () const; }; void foo () { MyClass mc; (UCList)mc; } </code></pre> <p>The first point, is that the standard defines that the C-style cast should use the more appropriate C++ style cast, and in this case that's <code>static_cast</code>. So the above cast is equivalent to:</p> <pre><code>static_cast&lt;UCList&gt; (mc); </code></pre> <p>The definition of static_cast says:</p> <blockquote> <p>An expression e can be explicitly converted to a type T using a <code>static_cast</code> of the form <code>static_cast&lt;T&gt;(e)</code> if the declaration <code>"T t(e);"</code> is well-formed, for some invented temporary variable t (8.5)</p> </blockquote> <p>So the semantics for the cast are the same as for:</p> <pre><code>UCList tmp (mc); </code></pre> <p>From 13.3.1.3 we get the set of candidate constructors that we can use in <code>UCList</code>:</p> <pre><code>UCList (UCList const &amp;) #1 UCList (size_type, T const &amp; = T()); #2 </code></pre> <p>What happens next is two separate overload resolution steps, one for each conversion operator.</p> <p><strong>Converting to #1:</strong> With a target type of <code>UCList const &amp;</code>, overload resolution selects between the following conversion operators.: "<code>operator UCList const ()</code>" and "<code>operator unsigned char ()</code>". Using <code>unsigned char</code> would require an additional user conversion and so is not a viable function for this overload step. Therefore overload resolution succeeds and will use <code>operator UCList const ()</code>.</p> <p><strong>Converting to #2:</strong> With a target type of <code>size_t</code>. The default argument does not take part in overload resolution. Overload resolution again selects between the conversion operators: "<code>operator UCList const ()</code>" and "<code>operator unsigned char ()</code>". This time there is no conversion from <code>UCList</code> to <code>unsigned int</code> and so that is not a viable function. An <code>unsigned char</code> can be promoted to <code>size_t</code> and so this time overload resolution succeeds and will use "<code>operator UCList const ()</code>".</p> <p>But, now back at the top level there are two separate and independent overload resolution steps that have successfully converted from <code>mc</code> to <code>UCList</code>. The result is therefore ambiguous.</p> <p>To explain that last point, this example is different to the normal overload resolution case. Normally there is a 1:n relationship between argument and parameter types:</p> <pre><code>void foo (char); void foo (short); void foo (int); void bar() { int i; foo (i); } </code></pre> <p>Here there is <code>i=&gt;char</code>, <code>i=&gt;short</code> and <code>i=&gt;int</code>. These are compared by overload resolution and the <code>int</code> overload would be selected.</p> <p>In the above case we have an m:n relationship. The standard outlines the rules to select for each individual argument and all of the 'n' parameters, but that's where it ends, it does not specify how we should decide between using the different 'm' arguments.</p> <p>Hope this makes some sense!</p> <p><strong>UPDATE:</strong></p> <p>The two kinds of initialization syntax here are:</p> <pre><code>UCList t1 (mc); UCList t2 = mc; </code></pre> <p>'t1' is a direct initialiation (13.3.1.3) and <em>all</em> constructors are included in the overload set. This is almost like having more than one user defined conversion. There are the set of constructors <em>and</em> the set of conversion operators. (ie. m:n).</p> <p>In the case of 't2' the syntax uses copy-initialization (13.3.1.4) and the rules different:</p> <blockquote> <p>Under the conditions specified in 8.5, as part of a copy-initialization of an object of class type, a userdefined conversion can be invoked to convert an initializer expression to the type of the object being initialized. Overload resolution is used to select the user-defined conversion to be invoked</p> </blockquote> <p>In this case there is just one to type, <code>UCList</code>, and so there is only the set of conversion operator overloads to consider, ie. we do not consider the other constructors of UCList.</p>
    singulars
    1. This table or related slice is empty.
    1. POC++ Operator overloading - casting from class
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USRichard Corden
    1. USRichard Corden
    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
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COJust wondering, apparently direct copy constructing and assignation to new object(copy construction as well) don't work with the same rules? UCList t(mc); #This is ambiguous UCList mylist = mc; #This is not ambiguous
      singulars
      1. PO
      1. USArkaitz Jimenez
    2. COExtraordinary answer. You deserve to be voted up many many times :)
      singulars
      1. PO
      1. USthe_drow
    3. CO"_Hope this makes some sense!_" It doesn't make any sense, until one realizes that `(T)x` is the same thing as `T(x)`! That's just an early design mistake.
      singulars
      1. PO
      1. UScuriousguy
 

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