Topic: N1891: Progress toward Opaque Typedefs for C++0X
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 02:16:02 +0100
Raw View
This is a multi-part message in MIME format.
--------------070105060105080903000107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
there is an old proposal [1] from Walter E. Brown about opaque types
that I have found quite interesting.
One of the motivating examples is the ability to overload on these new types
Progress toward Opaque Typedefs for C++0X
typedef *public* double X, Y, Z; // Cartesian 3D coordinate types
typedef *public* double Rho, Theta, Phi; // polar 3D coordinate types
class PhysicsVector
{
public:
PhysicsVector(X, Y, Z);
PhysicsVector(Rho, Theta, Phi);
....
}; // PhysicsVector
Could some one tell me if the committee was interested on this proposal?
Is there a plant to resurrect it?
Alisdair Meredith showed in [2] that forward constructor could help on
this but that there are some issues that are not addressed by this
construction.
|struct MyType : std::string {
using string::string;
};|
I'm wondering if the syntax couldn't be adapted so that the new type
could contain more function members.
|class Address*using* *public* std::string {
public:
};|
Note that there is no need to add forward constructors as the using
keyword would intend already to have the same interface as the
underlying type.
If |Address |should not be seen implicitly as a std::string the using
should be private
|class Address*using* *private* std::string {
// possibility to add new member functions
};|
Note that builtin types could also be used as underlying types as it is
the case of the Opaque typedef proposal.
|class Temperature*using* double {
// possibility to add new member functions
};|
By default the new type has the same operations than the underlying
type. Restricting the interface of the underlying type should also be
possible if the operation is decorated with delete.
|struct|||Address| *using* std::string {
std::size_t length() const = delete;
};
|
|One question is whether the new class can add new data members. I don't think tis is a good idea the new type and the underlying type should have the same size.|
||
|An alternative could be to use a new keyword (e.g. alias) so that this constraint is clearer.|
||
|
||*alias* |||Address| *using* std::string {
std::size_t length() const = delete;
};
|
Is there some interest?
Vicente
[1] *N1891: Progress toward Opaque Typedefs for C++0X*
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf>
[2] *N2141: Strong Typedefs in C++09(Revisited)*
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2141.html>
--
--------------070105060105080903000107
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
there is an old proposal [1] from Walter E. Brown about opaque types
that I have found quite interesting. <br>
<br>
One of the motivating examples is the ability to overload on these
new types<br>
<br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<title>Progress toward Opaque Typedefs for C++0X</title>
<br>
typedef <b>public</b> double X, Y, Z; // Cartesian 3D coordinate
types<br>
typedef <b>public</b> double Rho, Theta, Phi; // polar 3D
coordinate types<br>
class PhysicsVector<br>
{<br>
public:<br>
PhysicsVector(X, Y, Z);<br>
PhysicsVector(Rho, Theta, Phi);<br>
...<br>
}; // PhysicsVector<br>
<br>
Could some one tell me if the committee was interested on this
proposal? Is there a plant to resurrect it?<br>
<br>
Alisdair Meredith showed in [2] that forward constructor could help
on this but that there are some issues that are not addressed by
this construction.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre><code>struct MyType : std::string {
using string::string;
};</code></pre>
<br>
I'm wondering if the syntax couldn't be adapted so that the new type
could contain more function members.<br>
<br>
<pre><code>class Address <b>using</b> <b>public</b> std::string {
public:
};</code></pre>
Note that there is no need to add forward constructors as the using
keyword would intend already to have the same interface as the
underlying type. <br>
<br>
If <code>Address </code>should not be seen implicitly as a
std::string the using should be private<br>
<br>
<pre><code>class Address <b>using</b> <b>private</b> std::string {
// possibility to add new member functions
};</code></pre>
<br>
Note that builtin types could also be used as underlying types as it
is the case of the Opaque typedef proposal.<br>
<br>
<pre><code>class Temperature <b>using</b> double {
// possibility to add new member functions
};</code></pre>
<br>
By default the new type has the same operations than the underlying
type. Restricting the interface of the underlying type should also
be possible if the operation is decorated with delete.<br>
<br>
<pre><code>struct </code><code><code>Address</code> <b>using</b> std::string {
std::size_t length() const = delete;
};
</code></pre>
<pre><code>One question is whether the new class can add new data members. I don't think tis is a good idea the new type and the underlying type should have the same size.</code>
<code></code>
<code>An alternative could be to use a new keyword (e.g. alias) so that this constraint is clearer.</code>
<code></code></pre>
<code><br>
</code><code><b>alias</b> </code><code><code>Address</code> <b>using</b>
std::string {<br>
std::size_t length() const = delete;<br>
};<br>
</code>
<br>
Is there some interest?<br>
<br>
Vicente<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="term"><a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf"
target="_top"><span class="bold"><strong>N1891: Progress toward
Opaque Typedefs for C++0X</strong></span></a><br>
<br>
</span>[2]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="term"><a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2141.html"
target="_top"><span class="bold"><strong>N2141: Strong Typedefs
in C++09(Revisited)</strong></span></a></span><span
class="term"><br>
</span><br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070105060105080903000107--
.
Author: Martin Desharnais <martin.desharnais@gmail.com>
Date: Mon, 19 Nov 2012 18:59:13 -0800 (PST)
Raw View
------=_Part_129_12775068.1353380355286
Content-Type: text/plain; charset=ISO-8859-1
Alternativly, the alias declaration could be expand to support the explicit
specifier:
#include <vector>
using A = int;
using explicit B = int;
template<typename T> using C = std::vector<T>;
template<typename T> using explicit D = std::vector<T>;
int main()
{
int n = 0;
std::vector<int> v = { 1, 2, 3 };
A a = n; // Implicit conversion
B b = n; // Error, no implicit conversion
C<int> c = v; // Implicit conversion
D<int> d = v; // Error, no implicit conversion
}
I think that would be consistent with explicit constructor and explicit
conversion operator in that it disallow implicit conversion but stil let
the programmer explicitly ask it.
--
Martin
>
--
------=_Part_129_12775068.1353380355286
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Alternativly, the alias declaration could be expand to support the explicit=
specifier:<br><br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">#include</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"><=
vector></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">us=
ing</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">explicit</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> B </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> C </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">explicit</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> D </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> n </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vect=
or</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><int&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br> A a </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// Implicit conversion</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> B b </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
Error, no implicit conversion</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> C</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify"><int></span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Implic=
it conversion</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> D</span><span style=3D"color: #080;" class=3D"styled-b=
y-prettify"><int></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> d </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// Error, no implicit conve=
rsion</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>I think that would be consistent with explicit constructor an=
d explicit conversion operator in that it disallow implicit conversion but =
stil let the programmer explicitly ask it.<br><br>--<br>Martin<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_129_12775068.1353380355286--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 19 Nov 2012 19:41:46 -0800 (PST)
Raw View
------=_Part_452_18887401.1353382906657
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais wrote:
>
> Alternativly, the alias declaration could be expand to support the
> explicit specifier:
>
> #include <vector>
>
> using A = int;
> using explicit B = int;
> template<typename T> using C = std::vector<T>;
> template<typename T> using explicit D = std::vector<T>;
>
> int main()
> {
> int n = 0;
> std::vector<int> v = { 1, 2, 3 };
>
> A a = n; // Implicit conversion
> B b = n; // Error, no implicit conversion
> C<int> c = v; // Implicit conversion
> D<int> d = v; // Error, no implicit conversion
> }
>
> I think that would be consistent with explicit constructor and explicit
> conversion operator in that it disallow implicit conversion but stil let
> the programmer explicitly ask it.
>
I like the syntax here, particularly only allowing it with the new `using`
syntax instead of the old `typedef`. However, `enum class` already does
something similar with enumerators. So we might want to use syntax like
that instead of `explicit`:
using A = int;
using class B = int;
template<typename T> using C = std::vector<T>;
template<typename T> using class D = std::vector<T>;
Admittedly that's bikesheding. I do like the `class` being there, which
helps show that you're not creating a type alias but a new type.
>
--
------=_Part_452_18887401.1353382906657
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Alternativly, the alias de=
claration could be expand to support the explicit specifier:<br><br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px;word-wrap:break-word"><code><div><span styl=
e=3D"color:#800">#include</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#080"><vector></span><span style=3D"color:#000"><br><br>=
</span><span style=3D"color:#008">using</span><span style=3D"color:#000"> A=
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">int</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#008">using</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">explicit<=
/span><span style=3D"color:#000"> B </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</spa=
n><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">template</span><span style=3D"color:#660"><</=
span><span style=3D"color:#008">typename</span><span style=3D"color:#000"> =
T</span><span style=3D"color:#660">></span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">using</span><span style=3D"color:#000"> C =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">vecto=
r</span><span style=3D"color:#660"><</span><span style=3D"color:#000">T<=
/span><span style=3D"color:#660">>;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#008">template</span><span style=3D"color:#660=
"><</span><span style=3D"color:#008">typename</span><span style=3D"color=
:#000"> T</span><span style=3D"color:#660">></span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">using</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">explicit</span><span style=3D"color=
:#000"> D </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#=
000">vector</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#000">T</span><span style=3D"color:#660">>;</span><span style=3D"color=
:#000"><br><br></span><span style=3D"color:#008">int</span><span style=3D"c=
olor:#000"> main</span><span style=3D"color:#660">()</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"col=
or:#000"><br> </span><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> n </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br> std</=
span><span style=3D"color:#660">::</span><span style=3D"color:#000">vector<=
/span><span style=3D"color:#080"><int></span><span style=3D"color:#00=
0"> v </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </=
span><span style=3D"color:#066">1</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">2</span><span=
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#066">3</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">};</span><span style=3D"color:#000"><br><br> A a <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> n</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#800">// Implicit conversion</span><span style=3D"color=
:#000"><br> B b </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> n</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"> </span><span style=3D"color:#800">// Error, no implic=
it conversion</span><span style=3D"color:#000"><br> C</span><s=
pan style=3D"color:#080"><int></span><span style=3D"color:#000"> c </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> v</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#800">// Implicit conversion</span><span style=3D"color:=
#000"><br> D</span><span style=3D"color:#080"><int></spa=
n><span style=3D"color:#000"> d </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> v</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">// Error, no imp=
licit conversion</span><span style=3D"color:#000"><br></span><span style=3D=
"color:#660">}</span><span style=3D"color:#000"><br></span></div></code></d=
iv><br>I think that would be consistent with explicit constructor and expli=
cit conversion operator in that it disallow implicit conversion but stil le=
t the programmer explicitly ask it.<br></blockquote><div><br>I like the syn=
tax here, particularly only allowing it with the new `using` syntax instead=
of the old `typedef`. However, `enum class` already does something similar=
with enumerators. So we might want to use syntax like that instead of `exp=
licit`:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> B </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> C </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> D </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an></div></code></div><br>Admittedly that's bikesheding. I do like the `cla=
ss` being there, which helps show that you're not creating a type alias but=
a new type.<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_452_18887401.1353382906657--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 08:04:26 +0100
Raw View
This is a multi-part message in MIME format.
--------------000104070300030003000704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 04:41, Nicol Bolas a =E9crit :
>
>
> On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais wrote:
>
> Alternativly, the alias declaration could be expand to support the
> explicit specifier:
>
> |
> #include<vector>
>
> usingA =3Dint;
> usingexplicitB =3Dint;
> template<typenameT>usingC =3Dstd::vector<T>;
> template<typenameT>usingexplicitD =3Dstd::vector<T>;
>
> intmain()
> {
> intn =3D0;
> std::vector<int>v =3D{1,2,3};
>
> A a =3Dn;// Implicit conversion
> B b =3Dn;// Error, no implicit conversion
> C<int>c =3Dv;// Implicit conversion
> D<int>d =3Dv;// Error, no implicit conversion
> }
> |
>
> I think that would be consistent with explicit constructor and
> explicit conversion operator in that it disallow implicit
> conversion but stil let the programmer explicitly ask it.
>
>
> I like the syntax here, particularly only allowing it with the new=20
> `using` syntax instead of the old `typedef`.
Yes unifying proposals would be great. Please, could you point me to the=20
new using proposal?
> However, `enum class` already does something similar with enumerators.=20
> So we might want to use syntax like that instead of `explicit`:
>
> |
> usingA =3Dint;
> usingclassB =3Dint;
> template<typenameT>usingC =3Dstd::vector<T>;
> template<typenameT>usingclassD =3Dstd::vector<T>;
> |
>
> Admittedly that's bikesheding. I do like the `class` being there,=20
> which helps show that you're not creating a type alias but a new type.
>
>
One of the major concerns of the Opaque proposals was to make the=20
following difference:
Opaque typedef are explicitly convertible to the underlying type. But=20
are they implicitly convertible? It depends.
* public opaque : implicit conversion to the underlying type
* private opaque : explicit conversion to the underlying type
How the new syntax could take in account this point?
Does the new using proposal allows to add new function members?
Best,
Vicente
--=20
--------------000104070300030003000704
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 20/11/12 04:41, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:0f21bb1d-611d-44f5-8912-28f069970d66@isocpp.org"
type="cite"><br>
<br>
On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais
wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Alternativly,
the alias declaration could be expand to support the explicit
specifier:<br>
<br>
<div
style="background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style="color:#800">#include</span><span
style="color:#000"> </span><span style="color:#080"><vector></span><span
style="color:#000"><br>
<br>
</span><span style="color:#008">using</span><span
style="color:#000"> A </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#008">int</span><span
style="color:#660">;</span><span style="color:#000"><br>
</span><span style="color:#008">using</span><span
style="color:#000"> </span><span style="color:#008">explicit</span><span
style="color:#000"> B </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#008">int</span><span
style="color:#660">;</span><span style="color:#000"><br>
</span><span style="color:#008">template</span><span
style="color:#660"><</span><span style="color:#008">typename</span><span
style="color:#000"> T</span><span style="color:#660">></span><span
style="color:#000"> </span><span style="color:#008">using</span><span
style="color:#000"> C </span><span style="color:#660">=</span><span
style="color:#000"> std</span><span style="color:#660">::</span><span
style="color:#000">vector</span><span style="color:#660"><</span><span
style="color:#000">T</span><span style="color:#660">>;</span><span
style="color:#000"><br>
</span><span style="color:#008">template</span><span
style="color:#660"><</span><span style="color:#008">typename</span><span
style="color:#000"> T</span><span style="color:#660">></span><span
style="color:#000"> </span><span style="color:#008">using</span><span
style="color:#000"> </span><span style="color:#008">explicit</span><span
style="color:#000"> D </span><span style="color:#660">=</span><span
style="color:#000"> std</span><span style="color:#660">::</span><span
style="color:#000">vector</span><span style="color:#660"><</span><span
style="color:#000">T</span><span style="color:#660">>;</span><span
style="color:#000"><br>
<br>
</span><span style="color:#008">int</span><span
style="color:#000"> main</span><span style="color:#660">()</span><span
style="color:#000"><br>
</span><span style="color:#660">{</span><span
style="color:#000"><br>
</span><span style="color:#008">int</span><span
style="color:#000"> n </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#066">0</span><span
style="color:#660">;</span><span style="color:#000"><br>
std</span><span style="color:#660">::</span><span
style="color:#000">vector</span><span style="color:#080"><int></span><span
style="color:#000"> v </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#660">{</span><span
style="color:#000"> </span><span style="color:#066">1</span><span
style="color:#660">,</span><span style="color:#000"> </span><span
style="color:#066">2</span><span style="color:#660">,</span><span
style="color:#000"> </span><span style="color:#066">3</span><span
style="color:#000"> </span><span style="color:#660">};</span><span
style="color:#000"><br>
<br>
A a </span><span style="color:#660">=</span><span
style="color:#000"> n</span><span style="color:#660">;</span><span
style="color:#000"> </span><span style="color:#800">//
Implicit conversion</span><span style="color:#000"><br>
B b </span><span style="color:#660">=</span><span
style="color:#000"> n</span><span style="color:#660">;</span><span
style="color:#000"> </span><span style="color:#800">//
Error, no implicit conversion</span><span
style="color:#000"><br>
C</span><span style="color:#080"><int></span><span
style="color:#000"> c </span><span style="color:#660">=</span><span
style="color:#000"> v</span><span style="color:#660">;</span><span
style="color:#000"> </span><span style="color:#800">//
Implicit conversion</span><span style="color:#000"><br>
D</span><span style="color:#080"><int></span><span
style="color:#000"> d </span><span style="color:#660">=</span><span
style="color:#000"> v</span><span style="color:#660">;</span><span
style="color:#000"> </span><span style="color:#800">//
Error, no implicit conversion</span><span
style="color:#000"><br>
</span><span style="color:#660">}</span><span
style="color:#000"><br>
</span></div>
</code></div>
<br>
I think that would be consistent with explicit constructor and
explicit conversion operator in that it disallow implicit
conversion but stil let the programmer explicitly ask it.<br>
</blockquote>
<div><br>
I like the syntax here, particularly only allowing it with the
new `using` syntax instead of the old `typedef`.</div>
</blockquote>
<br>
Yes unifying proposals would be great. Please, could you point me to
the new using proposal?<br>
<blockquote
cite="mid:0f21bb1d-611d-44f5-8912-28f069970d66@isocpp.org"
type="cite">
<div> However, `enum class` already does something similar with
enumerators. So we might want to use syntax like that instead of
`explicit`:<br>
<br>
<div class="prettyprint" style="background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class="prettyprint">
<div class="subprettyprint"><span style="color: #008;"
class="styled-by-prettify">using</span><span
style="color: #000;" class="styled-by-prettify"> A </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">int</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">using</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">class</span><span
style="color: #000;" class="styled-by-prettify"> B </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">int</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">template</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="color: #000;" class="styled-by-prettify"> T</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">using</span><span
style="color: #000;" class="styled-by-prettify"> C </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> std</span><span
style="color: #660;" class="styled-by-prettify">::</span><span
style="color: #000;" class="styled-by-prettify">vector</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #000;" class="styled-by-prettify">T</span><span
style="color: #660;" class="styled-by-prettify">>;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">template</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="color: #000;" class="styled-by-prettify"> T</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">using</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">class</span><span
style="color: #000;" class="styled-by-prettify"> D </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> std</span><span
style="color: #660;" class="styled-by-prettify">::</span><span
style="color: #000;" class="styled-by-prettify">vector</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #000;" class="styled-by-prettify">T</span><span
style="color: #660;" class="styled-by-prettify">>;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span></div>
</code></div>
<br>
Admittedly that's bikesheding. I do like the `class` being
there, which helps show that you're not creating a type alias
but a new type.<br>
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
</blockquote>
<br>
</div>
</blockquote>
One of the major concerns of the Opaque proposals was to make the
following difference:<br>
Opaque typedef are explicitly convertible to the underlying type.
But are they implicitly convertible? It depends.
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem"> public opaque : implicit conversion to the
underlying type </li>
<li class="listitem"> private opaque : explicit conversion to
the underlying type </li>
</ul>
</div>
How the new syntax could take in account this point?<br>
Does the new using proposal allows to add new function members?<br>
<br>
Best,<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------000104070300030003000704--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 19 Nov 2012 23:29:58 -0800 (PST)
Raw View
------=_Part_635_857893.1353396598067
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, November 19, 2012 11:04:28 PM UTC-8, viboes wrote:
>
> Le 20/11/12 04:41, Nicol Bolas a =E9crit :
> =20
>
>
> On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais wrote:=
=20
>>
>> Alternativly, the alias declaration could be expand to support the=20
>> explicit specifier:
>>
>> #include <vector>
>>
>> using A =3D int;
>> using explicit B =3D int;
>> template<typename T> using C =3D std::vector<T>;
>> template<typename T> using explicit D =3D std::vector<T>;
>>
>> int main()
>> {
>> int n =3D 0;
>> std::vector<int> v =3D { 1, 2, 3 };
>>
>> A a =3D n; // Implicit conversion
>> B b =3D n; // Error, no implicit conversion
>> C<int> c =3D v; // Implicit conversion
>> D<int> d =3D v; // Error, no implicit conversion
>> }
>> =20
>> I think that would be consistent with explicit constructor and explicit=
=20
>> conversion operator in that it disallow implicit conversion but stil let=
=20
>> the programmer explicitly ask it.
>>
>
> I like the syntax here, particularly only allowing it with the new `using=
`=20
> syntax instead of the old `typedef`.
>
>
> Yes unifying proposals would be great. Please, could you point me to the=
=20
> new using proposal?
>
It's not a proposal; that's standard C++11<http://en.wikipedia.org/wiki/C%2=
B%2B11#Alias_templates>.=20
You can use it for templates (which was the primary purpose), but it also=
=20
can do everything that `typedef` could. And with much nicer syntax.
=20
> However, `enum class` already does something similar with enumerators.=
=20
> So we might want to use syntax like that instead of `explicit`:
>
> using A =3D int;
> using class B =3D int;
> template<typename T> using C =3D std::vector<T>;
> template<typename T> using class D =3D std::vector<T>;
> =20
> Admittedly that's bikesheding. I do like the `class` being there, which=
=20
> helps show that you're not creating a type alias but a new type.
>
>> =20
> =20
> One of the major concerns of the Opaque proposals was to make the=20
> following difference:
> Opaque typedef are explicitly convertible to the underlying type. But are=
=20
> they implicitly convertible? It depends. =20
>
> - public opaque : implicit conversion to the underlying type=20
> - private opaque : explicit conversion to the underlying type=20
>
> How the new syntax could take in account this point?
> Does the new using proposal allows to add new function members?
>
It depends entirely on exactly what problems you're trying to solve. The=20
one that Martin and I were solving was the ability to create an exact=20
duplicate of a type, only with a different name. This is also the problem=
=20
N1891 and N2141 are focused on solving.
Adding new function members is outside the scope of solving that problem.
--=20
------=_Part_635_857893.1353396598067
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, November 19, 2012 11:04:28 PM UTC-8, viboes wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 20/11/12 04:41, Nicol Bolas a
=E9crit :<br>
</div>
<blockquote type=3D"cite"><br>
<br>
On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">Alternativly,
the alias declaration could be expand to support the explicit
specifier:<br>
<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style=3D"color:#800">#include</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#080"><vector></span><span st=
yle=3D"color:#000"><br>
<br>
</span><span style=3D"color:#008">using</span><span style=3D"=
color:#000"> A </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">int</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008">using</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">explicit</span><span style=
=3D"color:#000"> B </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">using</span><span st=
yle=3D"color:#000"> C </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span s=
tyle=3D"color:#000">T</span><span style=3D"color:#660">>;</span><span st=
yle=3D"color:#000"><br>
</span><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">using</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">explicit</span><span =
style=3D"color:#000"> D </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span st=
yle=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span=
style=3D"color:#000">T</span><span style=3D"color:#660">>;</span><span =
style=3D"color:#000"><br>
<br>
</span><span style=3D"color:#008">int</span><span style=3D"co=
lor:#000"> main</span><span style=3D"color:#660">()</span><span style=3D"co=
lor:#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>
</span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> n </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br>
std</span><span style=3D"color:#660">::</span=
><span style=3D"color:#000">vector</span><span style=3D"color:#080"><int=
></span><span style=3D"color:#000"> v </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">1</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span=
style=3D"color:#066">2</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#066">3</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">};</span><span style=3D"colo=
r:#000"><br>
<br>
A a </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> n</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> </span><span style=3D"color:#800">//
Implicit conversion</span><span style=3D"color:#000"><br>
B b </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> n</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> </span><span style=3D"color:#800">//
Error, no implicit conversion</span><span style=3D"color:#0=
00"><br>
C</span><span style=3D"color:#080"><int>=
;</span><span style=3D"color:#000"> c </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> v</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#800">//
Implicit conversion</span><span style=3D"color:#000"><br>
D</span><span style=3D"color:#080"><int>=
;</span><span style=3D"color:#000"> d </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> v</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#800">//
Error, no implicit conversion</span><span style=3D"color:#0=
00"><br>
</span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br>
</span></div>
</code></div>
<br>
I think that would be consistent with explicit constructor and
explicit conversion operator in that it disallow implicit
conversion but stil let the programmer explicitly ask it.<br>
</blockquote>
<div><br>
I like the syntax here, particularly only allowing it with the
new `using` syntax instead of the old `typedef`.</div>
</blockquote>
<br>
Yes unifying proposals would be great. Please, could you point me to
the new using proposal?<br></div></blockquote><div><br>It's not a propo=
sal; <a href=3D"http://en.wikipedia.org/wiki/C%2B%2B11#Alias_templates">tha=
t's standard C++11</a>. You can use it for templates (which was the primary=
purpose), but it also can do everything that `typedef` could. And with muc=
h nicer syntax.<br> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div> However, `enum class` already does something similar with
enumerators. So we might want to use syntax like that instead of
`explicit`:<br>
<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style=3D"color:#008">using</span><span style=3D"colo=
r:#000"> A </span><span style=3D"color:#660">=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">int</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008">using</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">class</span><span style=3D"c=
olor:#000"> B </span><span style=3D"color:#660">=3D</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">int</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">using</span><span st=
yle=3D"color:#000"> C </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span s=
tyle=3D"color:#000">T</span><span style=3D"color:#660">>;</span><span st=
yle=3D"color:#000"><br>
</span><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">using</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> D </span><span style=3D"color:#660">=3D</span><span styl=
e=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span st=
yle=3D"color:#000">T</span><span style=3D"color:#660">>;</span><span sty=
le=3D"color:#000"><br>
</span></div>
</code></div>
<br>
Admittedly that's bikesheding. I do like the `class` being
there, which helps show that you're not creating a type alias
but a new type.<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
<br>
</div>
</blockquote>
One of the major concerns of the Opaque proposals was to make the
following difference:<br>
Opaque typedef are explicitly convertible to the underlying type.
But are they implicitly convertible? It depends.
<div>
<ul type=3D"disc">
<li> public opaque : implicit conversion to the
underlying type </li>
<li> private opaque : explicit conversion to
the underlying type </li>
</ul>
</div>
How the new syntax could take in account this point?<br>
Does the new using proposal allows to add new function members?<br></di=
v></blockquote><br>
It depends entirely on exactly what problems you're trying to solve. The =
one that Martin and I were solving was the ability to create an exact dupli=
cate of a type, only with a different name. This is also the problem N1891 =
and N2141 are focused on solving.<br><br>Adding new function members is out=
side the scope of solving that problem.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_635_857893.1353396598067--
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Tue, 20 Nov 2012 09:03:13 -0500
Raw View
--Boundary_(ID_g7Keqtse3rCPJ03nnwbHGw)
Content-type: text/plain; charset=ISO-8859-1
I'm not sure I understand why you think my suggestion of using inheriting constructors
prevents adding member functions. I was simply highlighting that inheriting constructors
could emulate a solution if the user chose to use them in such a simple/restricted way.
Nothing prevents the addition of more function (or data!) members, and we do not need a
new syntax to support that.
Among the known reasons that inheriting constructors do not solve Walter's original
problem are that they cannot be used for the following types:
fundamental types
aggregate classes
arrays
unions
final classes
enumerations
pointers
pointer-to-members
cv-qualified types
function types
incomplete types
There may well be some more type categories that I missed, but those are the ones
that I am immediately aware of. We may not want such a feature to support *all* of
these cases, but this would be my primary motivation for adding a new language
feature to support Walter's original proposal - and I will not be writing that paper
myself ;~)
AlisdairM
On Nov 19, 2012, at 8:16 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> there is an old proposal [1] from Walter E. Brown about opaque types that I have found quite interesting.
>
> One of the motivating examples is the ability to overload on these new types
>
>
> typedef public double X, Y, Z; // Cartesian 3D coordinate types
> typedef public double Rho, Theta, Phi; // polar 3D coordinate types
> class PhysicsVector
> {
> public:
> PhysicsVector(X, Y, Z);
> PhysicsVector(Rho, Theta, Phi);
> ...
> }; // PhysicsVector
>
> Could some one tell me if the committee was interested on this proposal? Is there a plant to resurrect it?
>
> Alisdair Meredith showed in [2] that forward constructor could help on this but that there are some issues that are not addressed by this construction.
>
> struct MyType : std::string {
> using string::string;
> };
>
> I'm wondering if the syntax couldn't be adapted so that the new type could contain more function members.
>
> class Address using public std::string {
> public:
>
> };
> Note that there is no need to add forward constructors as the using keyword would intend already to have the same interface as the underlying type.
>
> If Address should not be seen implicitly as a std::string the using should be private
>
> class Address using private std::string {
> // possibility to add new member functions
> };
>
> Note that builtin types could also be used as underlying types as it is the case of the Opaque typedef proposal.
>
> class Temperature using double {
> // possibility to add new member functions
> };
>
> By default the new type has the same operations than the underlying type. Restricting the interface of the underlying type should also be possible if the operation is decorated with delete.
>
> struct Address using std::string {
> std::size_t length() const = delete;
> };
>
> One question is whether the new class can add new data members. I don't think tis is a good idea the new type and the underlying type should have the same size.
>
> An alternative could be to use a new keyword (e.g. alias) so that this constraint is clearer.
>
> alias Address using std::string {
> std::size_t length() const = delete;
> };
>
> Is there some interest?
>
> Vicente
>
> [1] N1891: Progress toward Opaque Typedefs for C++0X
>
> [2] N2141: Strong Typedefs in C++09(Revisited)
>
>
> --
>
>
>
--
--Boundary_(ID_g7Keqtse3rCPJ03nnwbHGw)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; ">I'm not sure I understa=
nd why you think my suggestion of using inheriting constructors<div>prevent=
s adding member functions. I was simply highlighting that inheriting =
constructors</div><div>could emulate a solution if the user chose to use th=
em in such a simple/restricted way.</div><div>Nothing prevents the addition=
of more function (or data!) members, and we do not need a</div><div>new sy=
ntax to support that.</div><div><br></div><div>Among the known reasons that=
inheriting constructors do not solve Walter's original</div><div>problem a=
re that they cannot be used for the following types:</div><div>  =
;fundamental types</div><div> aggregate classes</div><div> =
; arrays</div><div> unions</div><div> final c=
lasses</div><div> enumerations</div><div> pointers<=
/div><div> pointer-to-members</div><div> cv-qualifi=
ed types</div><div> function types</div><div> incom=
plete types</div><div> </div><div><br></div><div>There may well=
be some more type categories that I missed, but those are the ones</div><d=
iv>that I am immediately aware of. We may not want such a feature to =
support *all* of</div><div>these cases, but this would be my primary motiva=
tion for adding a new language</div><div>feature to support Walter's origin=
al proposal - and I will not be writing that paper</div><div>myself ;~)</di=
v><div><br></div><div>AlisdairM</div><div><br><div><div>On Nov 19, 2012, at=
8:16 PM, Vicente J. Botet Escriba <<a href=3D"mailto:vicente.botet@wana=
doo.fr">vicente.botet@wanadoo.fr</a>> wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite">
=20
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-8=
859-1">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
there is an old proposal [1] from Walter E. Brown about opaque types
that I have found quite interesting. <br>
<br>
One of the motivating examples is the ability to overload on these
new types<br>
<br>
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3DISO-8859-1">
<title>Progress toward Opaque Typedefs for C++0X</title>
<br>
typedef <b>public</b> double X, Y, Z; // Cartesian 3D coordinate
types<br>
typedef <b>public</b> double Rho, Theta, Phi; // polar 3D
coordinate types<br>
class PhysicsVector<br>
{<br>
public:<br>
PhysicsVector(X, Y, Z);<br>
PhysicsVector(Rho, Theta, Phi);<br>
...<br>
}; // PhysicsVector<br>
<br>
Could some one tell me if the committee was interested on this
proposal? Is there a plant to resurrect it?<br>
<br>
Alisdair Meredith showed in [2] that forward constructor could help
on this but that there are some issues that are not addressed by
this construction.<br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
<pre><code>struct MyType : std::string {
using string::string;
};</code></pre>
<br>
I'm wondering if the syntax couldn't be adapted so that the new type
could contain more function members.<br>
<br>
<pre><code>class Address <b>using</b> <b>public</b> std::string {
public:
=20
};</code></pre>
Note that there is no need to add forward constructors as the using
keyword would intend already to have the same interface as the
underlying type. <br>
<br>
If <code>Address </code>should not be seen implicitly as a
std::string the using should be private<br>
<br>
<pre><code>class Address <b>using</b> <b>private</b> std::string {
// possibility to add new member functions
};</code></pre>
<br>
Note that builtin types could also be used as underlying types as it
is the case of the Opaque typedef proposal.<br>
<br>
<pre><code>class Temperature <b>using</b> double {
// possibility to add new member functions
};</code></pre>
<br>
By default the new type has the same operations than the underlying
type. Restricting the interface of the underlying type should also
be possible if the operation is decorated with delete.<br>
<br>
<pre><code>struct </code><code><code>Address</code> <b>using</b> std::s=
tring {
std::size_t length() const =3D delete;
};
</code></pre>
<pre><code>One question is whether the new class can add new data membe=
rs. I don't think tis is a good idea the new type and the underlying type s=
hould have the same size.</code>
<code></code>
<code>An alternative could be to use a new keyword (e.g. alias) so that thi=
s constraint is clearer.</code>
<code></code></pre>
<code><br>
</code><code><b>alias</b> </code><code><code>Address</code> <b>using</b=
>
std::string {<br>
std::size_t length() const =3D delete;<br>
};<br>
</code>
<br>
Is there some interest?<br>
<br>
Vicente<br>
<br>
[1]
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
<span class=3D"term"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2005/n1891.pdf" target=3D"_top"><span class=3D"bold"><strong>N1=
891: Progress toward
Opaque Typedefs for C++0X</strong></span></a><br>
<br>
</span>[2]
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
<span class=3D"term"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2006/n2141.html" target=3D"_top"><span class=3D"bold"><strong>N=
2141: Strong Typedefs
in C++09(Revisited)</strong></span></a></span><span class=3D"te=
rm"><br>
</span><br>
</div><div><br class=3D"webkit-block-placeholder"></div>
-- <br>
<br>
<br>
<br>
</blockquote></div><br></div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Boundary_(ID_g7Keqtse3rCPJ03nnwbHGw)--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 17:39:23 +0100
Raw View
This is a multi-part message in MIME format.
--------------000901070800010706000203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 15:03, Alisdair Meredith a =E9crit :
> I'm not sure I understand why you think my suggestion of using=20
> inheriting constructors
> prevents adding member functions. I was simply highlighting that=20
> inheriting constructors
> could emulate a solution if the user chose to use them in such a=20
> simple/restricted way.
> Nothing prevents the addition of more function (or data!) members, and=20
> we do not need a
> new syntax to support that.
I didn't want to intend this. Using a new class and inheriting the=20
constructors allows of course to add members functions.
>
> Among the known reasons that inheriting constructors do not solve=20
> Walter's original
> problem are that they cannot be used for the following types:
> fundamental types
> aggregate classes
> arrays
> unions
> final classes
> enumerations
> pointers
> pointer-to-members
> cv-qualified types
> function types
> incomplete types
This is exactly how I understand it.
>
>
> There may well be some more type categories that I missed, but those=20
> are the ones
> that I am immediately aware of. We may not want such a feature to=20
> support *all* of
> these cases, but this would be my primary motivation for adding a new=20
> language
> feature to support Walter's original proposal - and I will not be=20
> writing that paper
> myself ;~)
My point is that Walter's proposal could be extended to allow in=20
addition member function.
Vicente
--=20
--------------000901070800010706000203
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 20/11/12 15:03, Alisdair Meredith a
écrit :<br>
</div>
<blockquote cite="mid:3DB8FDED-1A8B-4A6D-9770-4A6D9BFAC9F9@me.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I'm not sure I understand why you think my suggestion of using
inheriting constructors
<div>prevents adding member functions. I was simply highlighting
that inheriting constructors</div>
<div>could emulate a solution if the user chose to use them in
such a simple/restricted way.</div>
<div>Nothing prevents the addition of more function (or data!)
members, and we do not need a</div>
<div>new syntax to support that.</div>
</blockquote>
I didn't want to intend this. Using a new class and inheriting the
constructors allows of course to add members functions.<br>
<br>
<blockquote cite="mid:3DB8FDED-1A8B-4A6D-9770-4A6D9BFAC9F9@me.com"
type="cite">
<div><br>
</div>
<div>Among the known reasons that inheriting constructors do not
solve Walter's original</div>
<div>problem are that they cannot be used for the following types:</div>
<div> fundamental types</div>
<div> aggregate classes</div>
<div> arrays</div>
<div> unions</div>
<div> final classes</div>
<div> enumerations</div>
<div> pointers</div>
<div> pointer-to-members</div>
<div> cv-qualified types</div>
<div> function types</div>
<div> incomplete types</div>
</blockquote>
This is exactly how I understand it.<br>
<blockquote cite="mid:3DB8FDED-1A8B-4A6D-9770-4A6D9BFAC9F9@me.com"
type="cite">
<div> <br>
</div>
<div><br>
</div>
<div>There may well be some more type categories that I missed,
but those are the ones</div>
<div>that I am immediately aware of. We may not want such a
feature to support *all* of</div>
<div>these cases, but this would be my primary motivation for
adding a new language</div>
<div>feature to support Walter's original proposal - and I will
not be writing that paper</div>
<div>myself ;~)</div>
</blockquote>
<br>
My point is that Walter's proposal could be extended to allow in
addition member function.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------000901070800010706000203--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 18:06:13 +0100
Raw View
This is a multi-part message in MIME format.
--------------070509070405030909000106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 08:29, Nicol Bolas a =E9crit :
>
>
> On Monday, November 19, 2012 11:04:28 PM UTC-8, viboes wrote:
>
> Le 20/11/12 04:41, Nicol Bolas a =E9crit :
>>
>>
>> On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin Desharnais
>> wrote:
>>
>> Alternativly, the alias declaration could be expand to
>> support the explicit specifier:
>>
>>
>> I think that would be consistent with explicit constructor
>> and explicit conversion operator in that it disallow implicit
>> conversion but stil let the programmer explicitly ask it.
>>
>>
>> I like the syntax here, particularly only allowing it with the
>> new `using` syntax instead of the old `typedef`.
>
> Yes unifying proposals would be great. Please, could you point me
> to the new using proposal?
>
>
> It's not a proposal; that's standard C++11=20
> <http://en.wikipedia.org/wiki/C%2B%2B11#Alias_templates>. You can use=20
> it for templates (which was the primary purpose), but it also can do=20
> everything that `typedef` could. And with much nicer syntax.
|I see. I thought alias were reserved to templates.|
>
>> However, `enum class` already does something similar with
>> enumerators. So we might want to use syntax like that instead of
>> `explicit`:
>>
>> |
>> usingA =3Dint;
>> usingclassB =3Dint;
>> template<typenameT>usingC =3Dstd::vector<T>;
>> template<typenameT>usingclassD =3Dstd::vector<T>;
>> |
>>
>> Admittedly that's bikesheding. I do like the `class` being there,
>> which helps show that you're not creating a type alias but a new
>> type.
>>
>>
> One of the major concerns of the Opaque proposals was to make the
> following difference:
> Opaque typedef are explicitly convertible to the underlying type.
> But are they implicitly convertible? It depends.
>
> * public opaque : implicit conversion to the underlying type
> * private opaque : explicit conversion to the underlying type
>
> How the new syntax could take in account this point?
> Does the new using proposal allows to add new function members?
>
>
> It depends entirely on exactly what problems you're trying to solve.=20
> The one that Martin and I were solving was the ability to create an=20
> exact duplicate of a type, only with a different name. This is also=20
> the problem N1891 and N2141 are focused on solving.
Yes but how the alias syntax allows to make a difference between=20
implicit/explicit conversions to the underlying type? Do you want to=20
mean a different things with
|
usingA =3Dint;// equivalent to a typedef, that is no new type
usingclassB =3Dint; // a new type with explicit conversion to int?
||usingstructB =3Dint;|||// a new type with implicit conversion to int?||
>
> Adding new function members is outside the scope of solving that problem.
>
Maybe. But IIRC this is something that has been discussed for enums.
Vicente
--=20
--------------070509070405030909000106
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 20/11/12 08:29, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:63e144af-45a6-4583-b609-22b2cbe01a7d@isocpp.org"
type="cite"><br>
<br>
On Monday, November 19, 2012 11:04:28 PM UTC-8, viboes wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Le 20/11/12 04:41, Nicol Bolas a écrit :<br>
</div>
<blockquote type="cite"><br>
<br>
On Monday, November 19, 2012 6:59:15 PM UTC-8, Martin
Desharnais wrote:
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">Alternativly, the alias
declaration could be expand to support the explicit
specifier:<br>
<br>
<br>
I think that would be consistent with explicit constructor
and explicit conversion operator in that it disallow
implicit conversion but stil let the programmer explicitly
ask it.<br>
</blockquote>
<div><br>
I like the syntax here, particularly only allowing it with
the new `using` syntax instead of the old `typedef`.</div>
</blockquote>
<br>
Yes unifying proposals would be great. Please, could you point
me to the new using proposal?<br>
</div>
</blockquote>
<div><br>
It's not a proposal; <a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/C%2B%2B11#Alias_templates">that's
standard C++11</a>. You can use it for templates (which was
the primary purpose), but it also can do everything that
`typedef` could. And with much nicer syntax.<br>
</div>
</blockquote>
<code class="prettyprint"><span style="color: #660;"
class="styled-by-prettify">I see. I thought alias were reserved
to templates.</span></code><br>
<blockquote
cite="mid:63e144af-45a6-4583-b609-22b2cbe01a7d@isocpp.org"
type="cite">
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div> However, `enum class` already does something similar
with enumerators. So we might want to use syntax like that
instead of `explicit`:<br>
<br>
<div
style="background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
<div><span style="color:#008">using</span><span
style="color:#000"> A </span><span
style="color:#660">=</span><span
style="color:#000"> </span><span
style="color:#008">int</span><span
style="color:#660">;</span><span
style="color:#000"><br>
</span><span style="color:#008">using</span><span
style="color:#000"> </span><span
style="color:#008">class</span><span
style="color:#000"> B </span><span
style="color:#660">=</span><span
style="color:#000"> </span><span
style="color:#008">int</span><span
style="color:#660">;</span><span
style="color:#000"><br>
</span><span style="color:#008">template</span><span
style="color:#660"><</span><span
style="color:#008">typename</span><span
style="color:#000"> T</span><span
style="color:#660">></span><span
style="color:#000"> </span><span
style="color:#008">using</span><span
style="color:#000"> C </span><span
style="color:#660">=</span><span
style="color:#000"> std</span><span
style="color:#660">::</span><span
style="color:#000">vector</span><span
style="color:#660"><</span><span
style="color:#000">T</span><span
style="color:#660">>;</span><span
style="color:#000"><br>
</span><span style="color:#008">template</span><span
style="color:#660"><</span><span
style="color:#008">typename</span><span
style="color:#000"> T</span><span
style="color:#660">></span><span
style="color:#000"> </span><span
style="color:#008">using</span><span
style="color:#000"> </span><span
style="color:#008">class</span><span
style="color:#000"> D </span><span
style="color:#660">=</span><span
style="color:#000"> std</span><span
style="color:#660">::</span><span
style="color:#000">vector</span><span
style="color:#660"><</span><span
style="color:#000">T</span><span
style="color:#660">>;</span><span
style="color:#000"><br>
</span></div>
</code></div>
<br>
Admittedly that's bikesheding. I do like the `class` being
there, which helps show that you're not creating a type
alias but a new type.<br>
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex"> </blockquote>
<br>
</div>
</blockquote>
One of the major concerns of the Opaque proposals was to make
the following difference:<br>
Opaque typedef are explicitly convertible to the underlying
type. But are they implicitly convertible? It depends.
<div>
<ul type="disc">
<li> public opaque : implicit conversion to the underlying
type </li>
<li> private opaque : explicit conversion to the
underlying type </li>
</ul>
</div>
How the new syntax could take in account this point?<br>
Does the new using proposal allows to add new function
members?<br>
</div>
</blockquote>
<br>
It depends entirely on exactly what problems you're trying to
solve. The one that Martin and I were solving was the ability to
create an exact duplicate of a type, only with a different name.
This is also the problem N1891 and N2141 are focused on solving.<br>
</blockquote>
Yes but how the alias syntax allows to make a difference between
implicit/explicit conversions to the underlying type? Do you want to
mean a different things with <br>
<code><span style="color:#008"><br>
using</span><span style="color:#000"> A </span><span
style="color:#660">=</span><span style="color:#000"> </span><span
style="color:#008">int</span><span style="color:#660">;</span><span
style="color:#000"> // equivalent to a typedef, that is no new
type<br>
</span><span style="color:#008">using</span><span
style="color:#000"> </span><span style="color:#008">class</span><span
style="color:#000"> B </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#008">int</span><span
style="color:#660">; // a new type with explicit conversion to
int?</span><span style="color:#000"><br>
</span><span style="color:#008"></span></code><code><span
style="color:#008">using</span><span style="color:#000"> struct</span><span
style="color:#000"> B </span><span style="color:#660">=</span><span
style="color:#000"> </span><span style="color:#008">int</span><span
style="color:#660">;</span></code><code><span style="color:#660"><code><span
style="color:#660"> // a new type with implicit conversion
to int?</span></code></span><span style="color:#000"></span></code><br>
<blockquote
cite="mid:63e144af-45a6-4583-b609-22b2cbe01a7d@isocpp.org"
type="cite"><br>
Adding new function members is outside the scope of solving that
problem.<br>
<br>
</blockquote>
Maybe. But IIRC this is something that has been discussed for enums.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070509070405030909000106--
.
Author: Martin Desharnais <martin.desharnais@gmail.com>
Date: Tue, 20 Nov 2012 09:52:28 -0800 (PST)
Raw View
------=_Part_525_19471724.1353433948513
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
> Yes but how the alias syntax allows to make a difference between=20
> implicit/explicit conversions to the underlying type? Do you want to mean=
a=20
> different things with=20
>
> using A =3D int; // equivalent to a typedef, that is no new type
> using class B =3D int; // a new type with explicit conversion to int?
> using struct B =3D int; // a new type with implicit conversion to int?
>
You are right that using "class/struct" specifier instead of "explicit"=20
bring that question but, fortunatly, it have already been solved by "enum":
enum class A { a, b, c };
enum struct A { a, b, c }; // Error, multiple definition of =91enum class A=
=92
The same rule would apply with the extend alias directive.
--
Martin
--=20
------=_Part_525_19471724.1353433948513
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">Yes but how the alias syntax allows to make a difference be=
tween
implicit/explicit conversions to the underlying type? Do you want to
mean a different things with <br>
<code><span style=3D"color:#008"><br>
using</span><span style=3D"color:#000"> A </span><span style=3D"col=
or:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">int</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"> // equivalent to a typedef, that is no new
type<br>
</span><span style=3D"color:#008">using</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">class</span><span style=3D"color:#00=
0"> B </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">int</span><span style=3D"color:#660">;=
// a new type with explicit conversion to
int?</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008"></span></code><code><span style=3D"=
color:#008">using</span><span style=3D"color:#000"> struct</span><span styl=
e=3D"color:#000"> B </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=3D=
"color:#660">;</span></code><code><span style=3D"color:#660"><code><span st=
yle=3D"color:#660"> // a new type with implicit conversion
to int?</span></code></span><span style=3D"color:#000"></span><=
/code><br></div></blockquote><div><br>You are right that using "class/struc=
t" specifier instead of "explicit" bring that question but, fortunatly, it =
have already been solved by "enum":<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> A </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">enum</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">struc=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> c </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Error=
, multiple definition of =91enum class A=92</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The same=
rule would apply with the extend alias directive.<br><br>--<br>Martin<br><=
/div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_525_19471724.1353433948513--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 19:27:23 +0100
Raw View
This is a multi-part message in MIME format.
--------------010505030906000002050309
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 18:52, Martin Desharnais a =E9crit :
>
> Yes but how the alias syntax allows to make a difference between
> implicit/explicit conversions to the underlying type? Do you want
> to mean a different things with
> |
> usingA =3Dint;// equivalent to a typedef, that is no new type
> usingclassB =3Dint; // a new type with explicit conversion to int?
> ||usingstructB =3Dint;|||// a new type with implicit conversion to
> int?||
>
>
> You are right that using "class/struct" specifier instead of=20
> "explicit" bring that question but, fortunatly, it have already been=20
> solved by "enum":
>
> |
>
> enumclassA {a,b,c };
> enumstructA {a,b,c };// Error, multiple definition of =91enum class A=92
> |
>
> The same rule would apply with the extend alias directive.
>
>
enum class and enum struct are equivalent. So I think that using them=20
for strongly types with a different semantics will not be coherent. I=20
guess that we need to find out some keywords to mean EXPLICT or IMPLICIT=20
conversion or something else.
|usingA =3Dint;// equivalent to a typedef, that is, no new type
usingB =3DEXPLICIT int; // a new type with explicit conversion to int?
||usingC=3DIMPLICIT int;|||// a new type with implicit conversion to int?||
-- Vicente
--=20
--------------010505030906000002050309
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 20/11/12 18:52, Martin Desharnais a
=E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:ed1eee55-c5c0-4151-8147-3a01965a28d5@isocpp.org"
type=3D"cite"><br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">Yes but how the alias
syntax allows to make a difference between implicit/explicit
conversions to the underlying type? Do you want to mean a
different things with <br>
<code><span style=3D"color:#008"><br>
using</span><span style=3D"color:#000"> A </span><span
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </=
span><span
style=3D"color:#008">int</span><span style=3D"color:#660">;</=
span><span
style=3D"color:#000"> // equivalent to a typedef, that is no
new type<br>
</span><span style=3D"color:#008">using</span><span
style=3D"color:#000"> </span><span style=3D"color:#008">class=
</span><span
style=3D"color:#000"> B </span><span style=3D"color:#660">=3D=
</span><span
style=3D"color:#000"> </span><span style=3D"color:#008">int</=
span><span
style=3D"color:#660">; // a new type with explicit
conversion to int?</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008"></span></code><code><span
style=3D"color:#008">using</span><span style=3D"color:#000">
struct</span><span style=3D"color:#000"> B </span><span
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </=
span><span
style=3D"color:#008">int</span><span style=3D"color:#660">;</=
span></code><code><span
style=3D"color:#660"><code><span style=3D"color:#660"> // a
new type with implicit conversion to int?</span></code></=
span><span
style=3D"color:#000"></span></code><br>
</div>
</blockquote>
<div><br>
You are right that using "class/struct" specifier instead of
"explicit" bring that question but, fortunatly, it have already
been solved by "enum":<br>
<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">enum</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #008;" class=3D"styled-by-prettify">class</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> A </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> a</spa=
n><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> b</spa=
n><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> c </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">enum</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #008;" class=3D"styled-by-prettify">struct<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> A </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> a</spa=
n><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> b</spa=
n><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> c </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #800;" class=3D"styled-by-prettify">//
Error, multiple definition of =91enum class A=92</span><spa=
n
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<br>
The same rule would apply with the extend alias directive.<br>
<br>
</div>
<br>
</blockquote>
enum class and enum struct are equivalent. So I think that using
them for strongly types with a different semantics will not be
coherent. I guess that we need to find out some keywords to mean
EXPLICT or IMPLICIT conversion or something else.<br>
<br>
<code><span style=3D"color:#008"> using</span><span style=3D"color:#000=
">
A </span><span style=3D"color:#660">=3D</span><span
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><=
span
style=3D"color:#660">;</span><span style=3D"color:#000"> //
equivalent to a typedef, that is, no new type<br>
</span><span style=3D"color:#008">using</span><span
style=3D"color:#000"> </span><span style=3D"color:#000">B </span><s=
pan
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span
style=3D"color:#008">EXPLICIT int</span><span style=3D"color:#660">=
;
// a new type with explicit conversion to int?</span><span
style=3D"color:#000"><br>
</span><span style=3D"color:#008"></span></code><code><span
style=3D"color:#008">using</span><span style=3D"color:#000"> C</spa=
n><span
style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><=
span
style=3D"color:#000"> IMPLICIT </span><span style=3D"color:#008">in=
t</span><span
style=3D"color:#660">;</span></code><code><span style=3D"color:#660=
"><code><span
style=3D"color:#660"> // a new type with implicit conversion
to int?</span></code></span><span style=3D"color:#000"></span><=
/code><br>
<br>
<br>
-- Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------010505030906000002050309--
.
Author: grigorij1981@gmail.com
Date: Tue, 20 Nov 2012 10:33:58 -0800 (PST)
Raw View
------=_Part_392_28570408.1353436438406
Content-Type: text/plain; charset=ISO-8859-1
>
>
> using A = int; // equivalent to a typedef, that is, no new type
> using B = EXPLICIT int; // a new type with explicit conversion to int?
> using C = IMPLICIT int; // a new type with implicit conversion to int?
>
>
> -- Vicente
>
>
>
> I would suggest
using A = int; // equivalent to a typedef, that is, no new type
using new explicit B = int; // a new type with explicit conversion to int?
using new C = int; // a new type with implicit conversion to int?
Regards,
Gregory
--
------=_Part_392_28570408.1353436438406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;" class=3D"gmail_quote"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><blo=
ckquote type=3D"cite"><div>
<br>
<code><span style=3D"color: rgb(0, 0, 136);"> using</span><span style=
=3D"color: rgb(0, 0, 0);">
A </span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);=
">int</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=3D=
"color: rgb(0, 0, 0);"> //
equivalent to a typedef, that is, no new type<br>
</span><span style=3D"color: rgb(0, 0, 136);">using</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 0);">B </=
span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"colo=
r: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">EXPLICIT i=
nt</span><span style=3D"color: rgb(102, 102, 0);">;
// a new type with explicit conversion to int?</span><span style=3D=
"color: rgb(0, 0, 0);"><br>
</span><span style=3D"color: rgb(0, 0, 136);"></span></code><code><sp=
an style=3D"color: rgb(0, 0, 136);">using</span><span style=3D"color: rgb(0=
, 0, 0);"> C</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=
=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);=
"> IMPLICIT </span><span style=3D"color: rgb(0, 0, 136);">int</span><span s=
tyle=3D"color: rgb(102, 102, 0);">;</span></code><code><span style=3D"color=
: rgb(102, 102, 0);"><code><span style=3D"color: rgb(102, 102, 0);"> // a n=
ew type with implicit conversion
to int?</span></code></span><span style=3D"color: rgb(0, 0, 0);=
"></span></code><br>
<br>
<br>
-- Vicente<br>
</div><div> </div></blockquote></div></blockquote><div>I would =
suggest</div><div> </div><div> <font face=3D"Courier New"><font =
color=3D"#000088">using</font><span style=3D"color: rgb(0, 0, 0);"> =
A </span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"=
color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">int</s=
pan><span style=3D"color: rgb(102, 102, 0);">;</span></font><font face=3D"C=
ourier New"><span style=3D"color: rgb(0, 0, 0);"> // equivalent to a=
typedef, that is, no new type<br></span><span style=3D"color: rgb(0, 0, 13=
6);"> using new explicit </span><span style=3D"color: rgb(0, 0, 0=
);">B </span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">in=
t</span><span style=3D"color: rgb(102, 102, 0);">; // a new type wit=
h explicit conversion to int?</span></font><span style=3D"color: rgb(0, 0, =
0);"><br></span><span style=3D"color: rgb(0, 0, 136);"></span><code><span s=
tyle=3D"color: rgb(0, 0, 136);"> using new </span><span style=3D"=
color: rgb(0, 0, 0);">C</span><span style=3D"color: rgb(0, 0, 0);"> </span>=
<span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rg=
b(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">int</span>=
<span style=3D"color: rgb(102, 102, 0);">;</span></code><code><span style=
=3D"color: rgb(102, 102, 0);"><code><span style=3D"color: rgb(102, 102, 0);=
"> // a new type with=
implicit conversion to int?</span></code></span></code></div><p=
><code><span style=3D"color: rgb(102, 102, 0);"><code><span style=3D"color:=
rgb(102, 102, 0);"></span></code></span></code> </p><div><code><span =
style=3D"color: rgb(102, 102, 0);"><code><span style=3D"color: rgb(102, 102=
, 0);"></span></code></span><span style=3D"color: rgb(0, 0, 0);"></span></c=
ode> </div><div>Regards,</div><div>Gregory<br></div><div> </div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_392_28570408.1353436438406--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 21:07:30 +0100
Raw View
This is a multi-part message in MIME format.
--------------090109020509090401010603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 19:33, grigorij1981@gmail.com a =E9crit :
>
>>
>> |usingA =3Dint;// equivalent to a typedef, that is, no new type
>> usingB =3DEXPLICIT int; // a new type with explicit conversion to in=
t?
>> ||usingC=3DIMPLICIT int;|||// a new type with implicit conversion
>> to int?||
>>
>>
>> -- Vicente
>
> I would suggest
> usingA =3Dint;// equivalent to a typedef, that is, no new type
> using new explicit B =3Dint; // a new type with explicit conversion to i=
nt?
> | using new C=3Dint;||| // a new type with implicit conversion=
=20
> to int?||
+1
'new explicit' and 'new' convey quite well the intent. Where these=20
keywords should be placed? After using as you are suggesting or
using new B =3D explicit int; // a new type with explicit conversion to i=
nt?
using new C =3D int; // a new type with implicit conversion to i=
nt?
or
using B =3D new explicit int; // a new type with explicit conversion to i=
nt?
using C =3D new int; // a new type with implicit conversion to i=
nt?
Vicente
--=20
--------------090109020509090401010603
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 20/11/12 19:33,
<a class="moz-txt-link-abbreviated" href="mailto:grigorij1981@gmail.com">grigorij1981@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:89b9d45f-de75-49d3-9034-4ef823cc836c@isocpp.org"
type="cite">
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div>
<br>
<code><span style="color: rgb(0, 0, 136);"> using</span><span
style="color: rgb(0, 0, 0);"> A </span><span
style="color: rgb(102, 102, 0);">=</span><span
style="color: rgb(0, 0, 0);"> </span><span
style="color: rgb(0, 0, 136);">int</span><span
style="color: rgb(102, 102, 0);">;</span><span
style="color: rgb(0, 0, 0);"> // equivalent to a
typedef, that is, no new type<br>
</span><span style="color: rgb(0, 0, 136);">using</span><span
style="color: rgb(0, 0, 0);"> </span><span
style="color: rgb(0, 0, 0);">B </span><span
style="color: rgb(102, 102, 0);">=</span><span
style="color: rgb(0, 0, 0);"> </span><span
style="color: rgb(0, 0, 136);">EXPLICIT int</span><span
style="color: rgb(102, 102, 0);">; // a new type with
explicit conversion to int?</span><span style="color:
rgb(0, 0, 0);"><br>
</span><span style="color: rgb(0, 0, 136);"></span></code><code><span
style="color: rgb(0, 0, 136);">using</span><span
style="color: rgb(0, 0, 0);"> C</span><span
style="color: rgb(0, 0, 0);"> </span><span
style="color: rgb(102, 102, 0);">=</span><span
style="color: rgb(0, 0, 0);"> IMPLICIT </span><span
style="color: rgb(0, 0, 136);">int</span><span
style="color: rgb(102, 102, 0);">;</span></code><code><span
style="color: rgb(102, 102, 0);"><code><span
style="color: rgb(102, 102, 0);"> // a new type
with implicit conversion to int?</span></code></span><span
style="color: rgb(0, 0, 0);"></span></code><br>
<br>
<br>
-- Vicente<br>
</div>
<div> </div>
</blockquote>
</div>
</blockquote>
<div>I would suggest</div>
<div> </div>
<div> <font face="Courier New"><font color="#000088">using</font><span
style="color: rgb(0, 0, 0);"> A </span><span style="color:
rgb(102, 102, 0);">=</span><span style="color: rgb(0, 0,
0);"> </span><span style="color: rgb(0, 0, 136);">int</span><span
style="color: rgb(102, 102, 0);">;</span></font><font
face="Courier New"><span style="color: rgb(0, 0, 0);"> //
equivalent to a typedef, that is, no new type<br>
</span><span style="color: rgb(0, 0, 136);"> using new
explicit </span><span style="color: rgb(0, 0, 0);">B </span><span
style="color: rgb(102, 102, 0);">=</span><span style="color:
rgb(0, 0, 0);"> </span><span style="color: rgb(0, 0, 136);">int</span><span
style="color: rgb(102, 102, 0);">; // a new type with
explicit conversion to int?</span></font><span style="color:
rgb(0, 0, 0);"><br>
</span><span style="color: rgb(0, 0, 136);"></span><code><span
style="color: rgb(0, 0, 136);"> using new </span><span
style="color: rgb(0, 0, 0);">C</span><span style="color:
rgb(0, 0, 0);"> </span><span style="color: rgb(102, 102,
0);">=</span><span style="color: rgb(0, 0, 0);"> </span><span
style="color: rgb(0, 0, 136);">int</span><span style="color:
rgb(102, 102, 0);">;</span></code><code><span style="color:
rgb(102, 102, 0);"><code><span style="color: rgb(102, 102,
0);"> // a new type with implicit conversion to
int?</span></code></span></code></div>
</blockquote>
+1<br>
'new explicit' and 'new' convey quite well the intent. Where these
keywords should be placed? After using as you are suggesting or <br>
<br>
using new B = explicit int; // a new type with explicit conversion
to int?<br>
using new C = int; // a new type with implicit conversion
to int?<br>
<br>
or<br>
<br>
using B = new explicit int; // a new type with explicit conversion
to int?<br>
using C = new int; // a new type with implicit conversion
to int?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------090109020509090401010603--
.
Author: grigorij1981@gmail.com
Date: Wed, 21 Nov 2012 01:22:40 -0800 (PST)
Raw View
------=_Part_98_24628378.1353489760810
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I do not have strong preference for either option.
=D0=92=D1=96=D0=B2=D1=82=D0=BE=D1=80=D0=BE=D0=BA, 20 =D0=BB=D0=B8=D1=81=D1=
=82=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 22:07:34 UTC+2 =D0=BA=D0=BE=
=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=B2:
>
> Le 20/11/12 19:33, grigor...@gmail.com <javascript:> a =C3=A9crit :
> =20
> =20
>> using A =3D int; // equivalent to a typedef, that is, no new type
>> using B =3D EXPLICIT int; // a new type with explicit conversion to int?
>> using C =3D IMPLICIT int; // a new type with implicit conversion to int?
>>
>>
>> -- Vicente
>> =20
>> =20
>>
>> I would suggest
> =20
> using A =3D int; // equivalent to a typedef, that is, no new type
> using new explicit B =3D int; // a new type with explicit conversion to=
=20
> int?
> using new C =3D int; // a new type with implicit conversion to=
=20
> int?
>
> +1
> 'new explicit' and 'new' convey quite well the intent. Where these=20
> keywords should be placed? After using as you are suggesting or=20
>
> using new B =3D explicit int; // a new type with explicit conversion to =
int?
> using new C =3D int; // a new type with implicit conversion to =
int?
>
> or
>
> using B =3D new explicit int; // a new type with explicit conversion to =
int?
> using C =3D new int; // a new type with implicit conversion to =
int?
>
> Vicente
> =20
--=20
------=_Part_98_24628378.1353489760810
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I do not have strong preference for either option.<br><br>=D0=92=D1=96=D0=
=B2=D1=82=D0=BE=D1=80=D0=BE=D0=BA, 20 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=BF=
=D0=B0=D0=B4=D0=B0 2012 =D1=80. 22:07:34 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=
=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=B2:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 20/11/12 19:33,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"K6=
NMbwu5MokJ">grigor...@gmail.com</a> a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
class=3D"gmail_quote">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div>
<br>
<code><span style=3D"color:rgb(0,0,136)"> using</span><span s=
tyle=3D"color:rgb(0,0,0)"> A </span><span style=3D"color:rgb(102,102,0)">=
=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">;</span><span sty=
le=3D"color:rgb(0,0,0)"> // equivalent to a
typedef, that is, no new type<br>
</span><span style=3D"color:rgb(0,0,136)">using</span><span=
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,0)">B </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">EXPLICIT int</span><span=
style=3D"color:rgb(102,102,0)">; // a new type with
explicit conversion to int?</span><span style=3D"color:rg=
b(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)"></span></code><co=
de><span style=3D"color:rgb(0,0,136)">using</span><span style=3D"color:rgb(=
0,0,0)"> C</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"co=
lor:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> IMPLICIT </=
span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(=
102,102,0)">;</span></code><code><span style=3D"color:rgb(102,102,0)"><code=
><span style=3D"color:rgb(102,102,0)"> // a new type
with implicit conversion to int?</span></code></span>=
<span style=3D"color:rgb(0,0,0)"></span></code><br>
<br>
<br>
-- Vicente<br>
</div>
<div> </div>
</blockquote>
</div>
</blockquote>
<div>I would suggest</div>
<div> </div>
<div> <font face=3D"Courier New"><font color=3D"#000088">using<=
/font><span style=3D"color:rgb(0,0,0)"> A </span><span style=3D"color:rgb(1=
02,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">;</s=
pan></font><font face=3D"Courier New"><span style=3D"color:rgb(0,0,0)"> //
equivalent to a typedef, that is, no new type<br>
</span><span style=3D"color:rgb(0,0,136)"> using new
explicit </span><span style=3D"color:rgb(0,0,0)">B </span>=
<span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"co=
lor:rgb(102,102,0)">; // a new type with
explicit conversion to int?</span></font><span style=3D"color:r=
gb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)"></span><code><span style=
=3D"color:rgb(0,0,136)"> using new </span><span style=3D"color:rg=
b(0,0,0)">C</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(102=
,102,0)">;</span></code><code><span style=3D"color:rgb(102,102,0)"><code><s=
pan style=3D"color:rgb(102,102,0)"> &nbs=
p; // a new type with implicit conversion to
int?</span></code></span></code></div>
</blockquote>
+1<br>
'new explicit' and 'new' convey quite well the intent. Where these
keywords should be placed? After using as you are suggesting or <br>
<br>
using new B =3D explicit int; // a new type with explicit convers=
ion
to int?<br>
using new C =3D int; &nb=
sp; // a new type with implicit conversion
to int?<br>
<br>
or<br>
<br>
using B =3D new explicit int; // a new type with explicit convers=
ion
to int?<br>
using C =3D new int; &nb=
sp; // a new type with implicit conversion
to int?<br>
<br>
Vicente<br>
</div>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_98_24628378.1353489760810--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 21 Nov 2012 05:28:59 -0800 (PST)
Raw View
------=_Part_456_4676401.1353504539740
Content-Type: text/plain; charset=ISO-8859-1
using new B = explicit int;
I think this is the better choice. Having new T is just too confusing-
people will start trying to declare variables that way.
--
------=_Part_456_4676401.1353504539740
Content-Type: text/html; charset=ISO-8859-1
using new B = explicit int;<div><br></div><div>I think this is the better choice. Having new T is just too confusing- people will start trying to declare variables that way.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_456_4676401.1353504539740--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 21 Nov 2012 15:47:09 +0100
Raw View
--20cf3071c76cdbbe6604cf026c07
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Nov 21, 2012 at 2:28 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> I think this is the better choice. Having new T is just too confusing-
> people will start trying to declare variables that way.
That being said, the word "new" is only used for runtime manipulations so
far; it feels a bit confusing too (but without practice it's hard to say).
I prefer class for consistency, personally.
Whatever the naming, I felt the need for such feature very often too.
Joel Lamotte
--
--20cf3071c76cdbbe6604cf026c07
Content-Type: text/html; charset=ISO-8859-1
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 2:28 PM, DeadMG <span dir="ltr"><<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is the better choice. Having new T is just too confusing- people will start trying to declare variables that way.</blockquote>
</div><br></div><div class="gmail_extra">That being said, the word "new" is only used for runtime manipulations so far; it feels a bit confusing too (but without practice it's hard to say).<br>I prefer class for consistency, personally.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Whatever the naming, I felt the need for such feature very often too.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Joel Lamotte</div><div class="gmail_extra">
<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
--20cf3071c76cdbbe6604cf026c07--
.
Author: grigorij1981@gmail.com
Date: Wed, 21 Nov 2012 07:05:29 -0800 (PST)
Raw View
------=_Part_525_27953803.1353510329826
Content-Type: text/plain; charset=ISO-8859-1
>
> By the way, it looks like a simple feature, but I have some reservations.
>
>
> One of them is connected to fundamental types, ability to have new
> fundamental type unrelated to other fundamental types is a breaking change.
> Other is about base classes. For example:
> using new A = B;
> What relation A has to base classes of B? What if we have virtual
> inheritance in the bases of B?
>
>
Third is about explicit template specializations. We have explicit
specialization for A, but none for B. Should we consider specialization for
A as specialization for B?
Regards,
Gregory
--
------=_Part_525_27953803.1353510329826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;" class=3D"gmail_quote"><div text=3D"#000000" bgcolor=3D"#FFFFFF">By t=
he way, it looks like a simple feature, but I have some reservations.<=
/div><div text=3D"#000000" bgcolor=3D"#FFFFFF"> </div></blockquote><di=
v> </div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;" class=3D"gmail_quote"><div text=3D"#000000" bgcolor=3D=
"#FFFFFF">One of them is connected to fundamental types, ability to ha=
ve new fundamental type unrelated to other fundamental types is a brea=
king change.</div><div text=3D"#000000" bgcolor=3D"#FFFFFF">Other is about =
base classes. For example:</div><div text=3D"#000000" bgcolor=3D"#FFFFFF">u=
sing new A =3D B;</div><div text=3D"#000000" bgcolor=3D"#FFFFFF">What relat=
ion A has to base classes of B? What if we have virtual inheritance in =
;the bases of B?</div><div text=3D"#000000" bgcolor=3D"#FFFFFF"> =
</div></blockquote><div> Third is about explicit template special=
izations. We have explicit specialization for A, but none for B. Should we =
consider specialization for A as specialization for B?</div><div> </di=
v><div>Regards,</div><div>Gregory</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_525_27953803.1353510329826--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 21 Nov 2012 17:35:29 +0100
Raw View
This is a multi-part message in MIME format.
--------------030107060106000000030503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 21/11/12 16:05, grigorij1981@gmail.com a =E9crit :
>
> By the way, it looks like a simple feature, but I have some
> reservations.
>
> One of them is connected to fundamental types, ability to have new
> fundamental type unrelated to other fundamental types is a
> breaking change.
>
I don't see how. Could you elaborate?
>
> Other is about base classes. For example:
> using new A =3D B;
> What relation A has to base classes of B? What if we have virtual
> inheritance in the bases of B?
>
I have not thought too much about that, but I guess that we can consider=20
that A is a "meta-clone" of B, so if B has X as base class, A has also X=20
as a base class. Note that A doesn't inherit from B. The single relation=20
between A and B is convertibility/substitutability.
>
> Third is about explicit template specializations. We have explicit=20
> specialization for A, but none for B. Should we consider=20
> specialization for A as specialization for B?
I don't understand. Could you elaborate with a concrete example?
Best,
Vicente
--=20
--------------030107060106000000030503
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 21/11/12 16:05,
<a class="moz-txt-link-abbreviated" href="mailto:grigorij1981@gmail.com">grigorij1981@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:f614f4c2-1c37-4678-bac5-51493fcc5fb2@isocpp.org"
type="cite">
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF">By the way, it looks like
a simple feature, but I have some reservations.</div>
<div text="#000000" bgcolor="#FFFFFF"> </div>
</blockquote>
<div> </div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF">One of them is connected
to fundamental types, ability to have new fundamental type
unrelated to other fundamental types is a breaking change.</div>
</blockquote>
</blockquote>
I don't see how. Could you elaborate?<br>
<blockquote
cite="mid:f614f4c2-1c37-4678-bac5-51493fcc5fb2@isocpp.org"
type="cite">
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF">Other is about base
classes. For example:</div>
<div text="#000000" bgcolor="#FFFFFF">using new A = B;</div>
<div text="#000000" bgcolor="#FFFFFF">What relation A has to
base classes of B? What if we have virtual inheritance in the
bases of B?</div>
</blockquote>
</blockquote>
I have not thought too much about that, but I guess that we can
consider that A is a "meta-clone" of B, so if B has X as base class,
A has also X as a base class. Note that A doesn't inherit from B.
The single relation between A and B is
convertibility/substitutability. <br>
<blockquote
cite="mid:f614f4c2-1c37-4678-bac5-51493fcc5fb2@isocpp.org"
type="cite">
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF"> </div>
</blockquote>
<div> Third is about explicit template specializations. We have
explicit specialization for A, but none for B. Should we
consider specialization for A as specialization for B?</div>
</blockquote>
I don't understand. Could you elaborate with a concrete example?<br>
<br>
Best,<br>
Vicente<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------030107060106000000030503--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 21 Nov 2012 22:59:40 +0100
Raw View
This is a multi-part message in MIME format.
--------------070905070506070209020501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 21/11/12 15:47, Klaim - Jo=C4=97l Lamotte a =C3=A9crit :
>
>
> On Wed, Nov 21, 2012 at 2:28 PM, DeadMG <wolfeinstein@gmail.com=20
> <mailto:wolfeinstein@gmail.com>> wrote:
>
> I think this is the better choice. Having new T is just too
> confusing- people will start trying to declare variables that way.
>
>
> That being said, the word "new" is only used for runtime manipulations=20
> so far; it feels a bit confusing too (but without practice it's hard=20
> to say).
> I prefer class for consistency, personally.
>
> Whatever the naming, I felt the need for such feature very often too.
>
>
If we follow the scoped scoped enum syntax and semantics, the following=20
could be equivalent
using class B =3D explicit int; // a new type with explicit conversion=
=20
to int?
using struct B =3D explicit int; // a new type with explicit conversion=
=20
to int?
and the same for
using class C =3D int; // a new type with implicit conversion=
=20
to int?
using struct C =3D int; // a new type with implicit conversion=
=20
to int?
The alias-declaration grammar
alias-declaration:
using identifier attribute-specifier-seqopt =3D type-id ;
could be replaced by
alias-declaration:
alias-key identifier attribute-specifier-seqopt =3D *explicit*opt type-i=
d ;
alias-key :
*using* |
*using class* |
*using struct*
The optional *explicit* keyword before the type-id could appear only if=20
the alias key is *using class* or *using struct*.
In addition to the 7 questions appearing in [1], I have some additional=20
question.
*Are the opaque types classes?**
*
[1] says that the type traits of the OT are defined as the ones of the=20
underlying type, is_TRAIT<OT> =3D is_TRAIT<UT>.
So if we have
using class C =3D int;
is_class<C> should be false_type. This should be a little bit confusing,=20
but there is an antecedent as an enum class is not a class.
I would prefer that opaque types be classes independently of the=20
underlying types but maybe there are some issues with the core language.
*Does the opaque type inherits from all the template classes specialized=20
with the under**lying type?**
*
For example if we have a trait
template <typename T> struct aTrait;
specialized by the underlying type
template <> struct aTrait<UT>: true_type;
Is aTrait<OT> an opaque type for aTrait<UT>?
*Which are the operations an opaque type provides?*
An opaque type having a builtin type as underlying type should provide=20
the same operations than the builtin type. It is less clear when the=20
base type is a defined type.
I would say that the opaque type provides at least all the member=20
functions defined by the underlying type or by its base classes. But=20
what about the non-member functions that have as one of its parameters=20
the underlying type? Providing all these functions will imply an=20
implicit conversion of the opaque type to the underlying type. So if =20
the opaque type should provide a subset of these functions we need a=20
mechanism to identify them. Now that there are more and more types that=20
define its interface using non-members functions I would say that there=20
is a need to 'inherit' from some of these functions.
I see two alternatives, either we identify them when defining the opaque=20
type, or when defining the underlying type.
I'm for the last alternative and IMO, we need a language mechanism to=20
identify the inherent operations of an underlying type which will be the=20
ones provided by an associated opaque type.
The fist one will need to extend the alias declaration.
*Should the user be able to define opaque types providing less functions=20
than its underlying type?**
*I would say yes, but then the alias statement should be extended in=20
some way.*
*
Before analyzing more deeply these subjects in order to make a concrete=20
proposal I would like to have some feedback. Maybe all this is already=20
clear for some of you and I'm missing something evident.
Best,
Vicente
[1] *N1891: Progress toward Opaque Typedefs for C++0X*=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf>
--=20
--------------070905070506070209020501
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 21/11/12 15:47, Klaim - Joël Lamotte
a écrit :<br>
</div>
<blockquote
cite="mid:CAOU91OP+0Myq7yoMQAQbC7Z=1kx2UeuJApixUsC4y72CYA2yYQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Nov 21, 2012 at 2:28 PM, DeadMG
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I think
this is the better choice. Having new T is just too
confusing- people will start trying to declare variables
that way.</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">That being said, the word "new" is only
used for runtime manipulations so far; it feels a bit confusing
too (but without practice it's hard to say).<br>
I prefer class for consistency, personally.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Whatever the naming, I felt the need for
such feature very often too.</div>
<div class="gmail_extra"><br>
</div>
<br>
</blockquote>
<br>
If we follow the scoped scoped enum syntax and semantics, the
following could be equivalent<br>
<br>
using class B = explicit int; // a new type with explicit
conversion to int?<br>
using struct B = explicit int; // a new type with explicit
conversion to int?<br>
<br>
and the same for<br>
<br>
using class C = int; // a new type with implicit
conversion to int?<br>
using struct C = int; // a new type with implicit
conversion to int?<br>
<br>
<br>
The alias-declaration grammar <br>
<br>
alias-declaration:<br>
using identifier attribute-specifier-seq<small><small>opt</small></small>
= type-id ;<br>
<br>
could be replaced by <br>
<br>
alias-declaration:<br>
alias-key identifier attribute-specifier-seq<small><small>opt</small></small>
= <b>explicit</b><small><small>opt </small></small>type-id ;<br>
<br>
alias-key :<br>
<b>using</b> |<br>
<b>using class</b> |<br>
<b>using struct</b><br>
<br>
The optional <b>explicit</b> keyword before the type-id could
appear only if the alias key is <b>using class</b> or <b>using
struct</b>.<br>
<br>
In addition to the 7 questions appearing in [1], I have some
additional question. <br>
<br>
<b>Are the opaque types classes?</b><b><br>
</b><br>
[1] says that the type traits of the OT are defined as the ones of
the underlying type, is_TRAIT<OT> = is_TRAIT<UT>.<br>
So if we have<br>
<br>
using class C = int;<br>
<br>
is_class<C> should be false_type. This should be a little bit
confusing, but there is an antecedent as an enum class is not a
class.<br>
<br>
I would prefer that opaque types be classes independently of the
underlying types but maybe there are some issues with the core
language.<br>
<br>
<br>
<b>Does the opaque type inherits from all the template classes
specialized with the under</b><b>lying type?</b><b><br>
</b><br>
For example if we have a trait<br>
<br>
template <typename T> struct aTrait;<br>
<br>
specialized by the underlying type<br>
<br>
template <> struct aTrait<UT>: true_type;<br>
<br>
Is aTrait<OT> an opaque type for aTrait<UT>? <br>
<br>
<b>Which are the operations an opaque type provides?</b><br>
<br>
An opaque type having a builtin type as underlying type should
provide the same operations than the builtin type. It is less clear
when the base type is a defined type.<br>
<br>
I would say that the opaque type provides at least all the member
functions defined by the underlying type or by its base classes. But
what about the non-member functions that have as one of its
parameters the underlying type? Providing all these functions will
imply an implicit conversion of the opaque type to the underlying
type. So if the opaque type should provide a subset of these
functions we need a mechanism to identify them. Now that there are
more and more types that define its interface using non-members
functions I would say that there is a need to 'inherit' from some of
these functions. <br>
<br>
I see two alternatives, either we identify them when defining the
opaque type, or when defining the underlying type.<br>
<br>
I'm for the last alternative and IMO, we need a language mechanism
to identify the inherent operations of an underlying type which will
be the ones provided by an associated opaque type.<br>
<br>
The fist one will need to extend the alias declaration.<br>
<br>
<b>Should the user be able to define opaque types providing less
functions than its underlying type?</b><b><br>
<br>
</b>I would say yes, but then the alias statement should be extended
in some way.<b><br>
</b>
<br>
Before analyzing more deeply these subjects in order to make a
concrete proposal I would like to have some feedback. Maybe all
this is already clear for some of you and I'm missing something
evident.<br>
<br>
<br>
Best,<br>
Vicente<br>
<br>
[1] <span class="term"><a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf"
target="_top"><span class="bold"><strong>N1891: Progress toward
Opaque Typedefs for C++0X</strong></span></a></span><br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070905070506070209020501--
.
Author: grigorij1981@gmail.com
Date: Wed, 21 Nov 2012 14:17:02 -0800 (PST)
Raw View
------=_Part_819_33309976.1353536222790
Content-Type: text/plain; charset=ISO-8859-1
Here's an expanded version.
N1891 has quite detailed explanation of relations between aliased types.
But it does not cover the relations to bases mentioned above.
And it states that
*Given two template instantiations, one with OT [opaque type] as a template
argument and the other with UT [underlying type] as the corresponding
argument, how are the instantiations related?*
*Proposed answer: the two instantiations are unrelated.*
Now, without opaque typedefs it was possible to write specializations for
all floating point types or for all integer types, with opaque typedefs
given that answer it would no longer be possible.
Moreover while N1891 states that all standard properties of type (exposed
via type-traits) are the same for OT and UT, it also implies that OT does
not keep non-standard properties of UT (like iterator traits), as these
properties are defined via template specializations.
e.g. following is not possible
using new IntPtr = int*;
int arr[10] = {1,2,...};
std::accumulate((IntPtr)arr, (IntPtr)arr + 10);
It seems, that keeping non-standard properties is desirable. It is also
desirable to have different specializations for UT and OT.
Regards,
Gregory
--
------=_Part_819_33309976.1353536222790
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<SPAN lang=3DEN>=20
<P>Here's an expanded version. </P>
<DIV>N1891 has quite detailed explanation of relations between aliased type=
s. But it does not cover the relations to bases mentioned above.</DIV>
<DIV> </DIV>
<DIV>And it states that </DIV>
<DIV><SPAN lang=3DEN>
<P><EM>Given two template instantiations, one with <FONT color=3D#000080 si=
ze=3D2><FONT color=3D#000080 size=3D2>OT [opaque type] </FONT></FONT><FONT =
size=3D2>as a template argument and the other with UT [underlying type] </F=
ONT><FONT size=3D2><FONT color=3D#000000>as the corresponding argument, how=
are the instantiations related?</FONT></FONT></EM></P>
<P><FONT size=3D2><EM>Proposed answer: the two instantiations are unrelated=
..</EM></P>
<P>Now, without opaque typedefs it was possible to write specializations fo=
r all floating point types or for all integer types, with opaque typedefs g=
iven that answer it would no longer be possible.</P>
<P>Moreover while N1891 states that all standard properties =
of type (exposed via type-traits) are the same for OT and UT, it also impli=
es that OT does not keep non-standard properties of UT (like iterator =
traits), as these properties are defined via template specializations.</P>
<P>e.g. following is not possible</P>
<P><FONT face=3D"courier new,monospace">using new IntPtr =3D int*;</FONT></=
P>
<P><FONT face=3D"courier new,monospace">int arr[10] =3D {1,2,...};</FONT></=
P>
<P><FONT face=3D"courier new,monospace">std::accumulate((IntPtr)arr, (IntPt=
r)arr + 10);</FONT></P>
<P>It seems, that keeping non-standard properties is desirable. It is also =
desirable to have different specializations for UT and OT.</P>
<P> </P>
<P>Regards,</P>
<P>Gregory</P>
<P> </P></FONT></SPAN></DIV></SPAN>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_819_33309976.1353536222790--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 21 Nov 2012 16:40:03 -0600
Raw View
--0015175cd9c6b5440404cf091ac9
Content-Type: text/plain; charset=ISO-8859-1
On 21 November 2012 16:17, <grigorij1981@gmail.com> wrote:
> Now, without opaque typedefs it was possible to write specializations for
> all floating point types or for all integer types, with opaque typedefs
> given that answer it would no longer be possible.
>
Presumably we can add another magic type trait to get to the UT from the
OT, so that problem should be solvable.
I'm just much less clear on what is different and what is the same.
Given the following (syntax issues notwithstanding):
using A = unique_ptr<int>;
using B = explicit unique_ptr<int>;
what would the interfaces for A and B look like if they were written by
hand? Does the interface to unique_ptr<int> change? What about free
functions which take them (such as the unique_ptr comparison operators)?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--0015175cd9c6b5440404cf091ac9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 21 November 2012 16:17, <span dir=3D"ltr"><<a href=3D"mailto:grigori=
j1981@gmail.com" target=3D"_blank">grigorij1981@gmail.com</a>></span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span lang=3D"EN"><div><span lang=3D"EN"><p>Now, without opaque typedefs it=
was possible to write specializations for all floating point types or for =
all integer types, with opaque typedefs given that answer it would no longe=
r be possible.<br>
</p></span></div></span></blockquote><div>Presumably we can add another mag=
ic type trait to get to the UT from the OT, so that problem should be solva=
ble.<br></div><br clear=3D"all">
</div>I'm just much less clear on what is different and what is the sam=
e.<br><br>Given the following (syntax issues notwithstanding):<br><br>using=
A =3D unique_ptr<int>;<br>using B =3D explicit unique_ptr<int>=
;<br>
<br>what would the interfaces for A and B look like if they were written by=
hand?=A0 Does the interface to unique_ptr<int> change?=A0 What about=
free functions which take them (such as the unique_ptr comparison operator=
s)?<br>
-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a h=
ref=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(=
847) 691-1404</a><br>
<p></p>
-- <br />
<br />
<br />
<br />
--0015175cd9c6b5440404cf091ac9--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Thu, 22 Nov 2012 00:09:53 +0100
Raw View
--f46d042f9504bb3fdd04cf0972bc
Content-Type: text/plain; charset=ISO-8859-1
Some feedback :
On Wed, Nov 21, 2012 at 10:59 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> *Are the opaque types classes?**
> *
> [1] says that the type traits of the OT are defined as the ones of the
> underlying type, is_TRAIT<OT> = is_TRAIT<UT>.
> So if we have
>
> using class C = int;
>
> is_class<C> should be false_type. This should be a little bit confusing,
> but there is an antecedent as an enum class is not a class.
>
> I would prefer that opaque types be classes independently of the
> underlying types but maybe there are some issues with the core language.
>
>
I can understand that enum class cannot be considered the same way than a
class.
However, here the feature is, as far as I understand it, supposed to "clone
perfectly" the right-side type, which would imply that
is_class<C>::value == is_class<int>::value
Because otherwise I don't see the point of this feature.
>
> *Does the opaque type inherits from all the template classes specialized
> with the under**lying type?**
> *
>
As I said, i don't see the point if the generated type isn't an exact clone.
>
> *Which are the operations an opaque type provides?*
>
>
Same logic for me: it should just be a type clone.
> *Should the user be able to define opaque types providing less functions
> than its underlying type?**
>
> *I would say yes, but then the alias statement should be extended in some
> way.
I don't see any use case for this. Do you have one? (I might miss something
here).
Joel Lamotte
--
--f46d042f9504bb3fdd04cf0972bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_extra">Some feedback :<br><br><div class=3D"gmail_quote=
">On Wed, Nov 21, 2012 at 10:59 PM, Vicente J. Botet Escriba <span dir=3D"l=
tr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicen=
te.botet@wanadoo.fr</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><b>Are the opaque types classes?</b><b><br>
</b><br>
[1] says that the type traits of the OT are defined as the ones of
the underlying type, is_TRAIT<OT> =3D is_TRAIT<UT>.<br>
So if we have<br>
<br>
=A0 using class C =3D int;<br>
<br>
is_class<C> should be false_type. This should be a little bit
confusing, but there is an antecedent as an enum class is not a
class.<br>
<br>
I would prefer that opaque types be classes independently of the
underlying types but maybe there are some issues with the core
language.<br>
<br></blockquote><div><br></div><div>I can understand that enum class c=
annot be considered the same way than a class.</div><div>However, here the =
feature is, as far as I understand it, supposed to "clone perfectly&qu=
ot; the right-side type, which would imply that</div>
<div><br></div><div>is_class<C>::value =3D=3D is_class<int>::va=
lue</div><div><br></div><div>Because otherwise I don't see the point of=
this feature.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<b>Does the opaque type inherits from all the template classes
specialized with the under</b><b>lying type?</b><b><br></b><br></bloc=
kquote><div><br></div><div>As I said, i don't see the point if the gene=
rated type isn't an exact clone.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
<b>Which are the operations an opaque type provides?</b><br><br></block=
quote><div><br></div><div>Same logic for me: it should just be a type clone=
..</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<b>Should the user be able to define opaque types providing less
functions than its underlying type?</b><b><br>
<br>
</b>I would say yes, but then the alias statement should be extended
in some way.</blockquote></div><br></div><div class=3D"gmail_extra">I d=
on't see any use case for this. Do you have one? (I might miss somethin=
g here).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a">
Joel Lamotte</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra"><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
--f46d042f9504bb3fdd04cf0972bc--
.
Author: "Vladimir Merzliakov" <wanderer@sfedu.ru>
Date: Thu, 22 Nov 2012 03:16:17 +0400
Raw View
This is a multi-part message in MIME format.
------=_NextPart_000_001F_01CDC85F.BD06A4F0
Content-Type: text/plain; charset=ISO-8859-1
Sorry if my comment will pointless and early discussed, but.
Why instead extending 'using' not allow just have non-class types as class
parent types so have:
class C : private int { . }
or
class S : public int { . }
That directly allow easy define interface of new type and provide same
implicit/explicit difference new type from original type
Using existed C++ syntax features.
Vladimir
From: Vicente J. Botet Escriba [mailto:vicente.botet@wanadoo.fr]
Sent: Thursday, November 22, 2012 2:00 AM
To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: N1891: Progress toward Opaque Typedefs for
C++0X
Should the user be able to define opaque types providing less functions than
its underlying type?
I would say yes, but then the alias statement should be extended in some
way.
Before analyzing more deeply these subjects in order to make a concrete
proposal I would like to have some feedback. Maybe all this is already
clear for some of you and I'm missing something evident.
Best,
Vicente
[1] <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf>
N1891: Progress toward Opaque Typedefs for C++0X
--
--
------=_NextPart_000_001F_01CDC85F.BD06A4F0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.term
{mso-style-name:term;}
span.bold
{mso-style-name:bold;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DRU li=
nk=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><sp=
an lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif=
";color:#1F497D'>Sorry if my comment will pointless and early discussed, bu=
t…<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US style=
=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Why =
instead extending ‘using’ not allow just have non-class types a=
s class parent types so have:<o:p></o:p></span></p><p class=3DMsoNormal><sp=
an lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif=
";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span lan=
g=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo=
r:#1F497D'>class C : private int { … }<o:p></o:p></span></p><p class=
=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Cali=
bri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMso=
Normal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";color:#1F497D'>or<o:p></o:p></span></p><p class=3DMsoNormal><sp=
an lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif=
";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span lan=
g=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo=
r:#1F497D'>class S : public int { … }<o:p></o:p></span></p><p class=
=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Cali=
bri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMso=
Normal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";color:#1F497D'>That directly allow easy define interface of new=
type and provide same implicit/explicit difference new type from original =
type<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'=
font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Using ex=
isted C++ syntax features.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";c=
olor:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span lang=
=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color=
:#1F497D'>Vladimir<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DE=
N-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US s=
tyle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>=
<o:p> </o:p></span></p><div><div style=3D'border:none;border-top:solid=
#B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span sty=
le=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>=
From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-=
serif";color:windowtext'> Vicente J. Botet Escriba [mailto:vicente.botet@wa=
nadoo.fr] <br><b>Sent:</b> Thursday, November 22, 2012 2:00 AM<br><b>To:</b=
> std-proposals@isocpp.org<br><b>Subject:</b> Re: [std-proposals] Re: N1891=
: Progress toward Opaque Typedefs for C++0X<o:p></o:p></span></p></div></di=
v><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style=3D'm=
argin-bottom:12.0pt'><b><span lang=3DEN-US>Should the user be able to defin=
e opaque types providing less functions than its underlying type?<br><br></=
span></b>I would say yes, but then the alias statement should be extended i=
n some way.<b><br></b><br>Before analyzing more deeply these subjects in or=
der to make a concrete proposal I would like to have some feedback. M=
aybe all this is already clear for some of you and I'm missing something ev=
ident.<br><br><br>Best,<br>Vicente<br><br>[1] <span class=3Dterm><a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf" target=
=3D"_top"><strong>N1891: Progress toward Opaque Typedefs for C++0X</strong>=
</a></span><br><br><o:p></o:p></p><p class=3DMsoNormal><span style=3D'color=
:windowtext'>-- <br> <br> <br> <o:p></o:p></span></p></div><=
/body></html>
<p></p>
-- <br />
<br />
<br />
<br />
------=_NextPart_000_001F_01CDC85F.BD06A4F0--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Thu, 22 Nov 2012 00:19:12 +0100
Raw View
--047d7b15a1ef08c33404cf0994e1
Content-Type: text/plain; charset=ISO-8859-1
Re-reading this discussion, I think I might have confused what I wish this
feature would do with what was initially proposed.
My need would have been (as as said above) to make this:
class K
{
int a;
float b;
string c;
vector d;
};
using class U = K;
equivalent to
class K
{
int a;
float b;
string c;
vector d;
};
class U
{
int a;
float b;
string c;
vector d;
};
Which would mean that the compiler just generate the type on the right side
of the expression,
as if it would have copy-pasted the declaration (and definition if
available at this point) of the type and just changed the name.
Which would imply that:
is_[any test]< K > ::value == is_[any test]< U >
and
is_same< K, U > ::value == false
Which also imply that I don't see the point of the explicit optional marker.
Sorry if I'm being retarded about this, I might have misunderstood the
original intent?
Joel Lamotte
--
--047d7b15a1ef08c33404cf0994e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Re-reading this discussion, I think I might have confused what I wish this =
feature would do with what was initially proposed.<div><br></div><div>My ne=
ed would have been (as as said above) to make this:</div><div><br></div>
<div><br></div><div>=A0 =A0class K</div><div>=A0 =A0{</div><div>=A0 =A0 =A0=
=A0int a;<br>=A0 =A0 =A0 =A0float b;</div><div>=A0 =A0 =A0 =A0string c;</d=
iv><div>=A0 =A0 =A0 =A0vector d;</div><div>=A0 =A0 };<br><br>=A0 =A0using c=
lass U =3D K;<br><br>equivalent to=A0</div><div>
<br></div><div>=A0 =A0class K</div><div>=A0 =A0{</div><div>=A0 =A0 =A0 =A0i=
nt a;<br>=A0 =A0 =A0 =A0float b;</div><div>=A0 =A0 =A0 =A0string c;</div><d=
iv>=A0 =A0 =A0 =A0vector d;</div><div>=A0 =A0 };</div><div><br></div><div>=
=A0 =A0 class U</div><div>=A0 =A0{</div><div>=A0 =A0 =A0 =A0int a;<br>
=A0 =A0 =A0 =A0float b;</div><div>=A0 =A0 =A0 =A0string c;</div><div>=A0 =
=A0 =A0 =A0vector d;</div><div>=A0 =A0 };=A0<br><br><br>Which would mean th=
at the compiler just generate the type on the right side of the expression,=
=A0</div><div>as if it would have copy-pasted the declaration (and definiti=
on if available at this point) of the type and just changed the name.</div>
<div><br></div><div>Which would imply that:</div><div><br></div><div>is_[an=
y test]< K > ::value =3D=3D is_[any test]< U ><br><br>and<br><b=
r>is_same< K, U > ::value =3D=3D false<br><br><br>Which also imply th=
at I don't see the point of the explicit optional marker.<br>
<br><br>Sorry if I'm being retarded about this, I might have misunderst=
ood the original intent?</div><div><br></div><div>Joel Lamotte</div>
<p></p>
-- <br />
<br />
<br />
<br />
--047d7b15a1ef08c33404cf0994e1--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 22 Nov 2012 00:44:40 -0800 (PST)
Raw View
------=_Part_1255_24536573.1353573880888
Content-Type: text/plain; charset=ISO-8859-1
> *Which are the operations an opaque type provides?*
>
> An opaque type having a builtin type as underlying type should provide the
> same operations than the builtin type. It is less clear when the base type
> is a defined type.
>
> I would say that the opaque type provides at least all the member
> functions defined by the underlying type or by its base classes. But what
> about the non-member functions that have as one of its parameters the
> underlying type? Providing all these functions will imply an implicit
> conversion of the opaque type to the underlying type. So if the opaque
> type should provide a subset of these functions we need a mechanism to
> identify them. Now that there are more and more types that define its
> interface using non-members functions I would say that there is a need to
> 'inherit' from some of these functions.
>
> I see two alternatives, either we identify them when defining the opaque
> type, or when defining the underlying type.
>
> I'm for the last alternative and IMO, we need a language mechanism to
> identify the inherent operations of an underlying type which will be the
> ones provided by an associated opaque type.
>
My reply may be a bit off-topic, but you have touched a very interesting
subject: type X's interface consists not only of its member functions but
also of some free-standing functions. And clearly, not every free-standing
function that takes X as argument is X's interface: only some of the
functions. The need to identify this "extended interface" goes beyond
opaque typedefs. For instance, concepts do this distinction. I believe (but
I know the C++ Standard only from books like "D&E of C++") that not having
this mechanism in place led to the introduction of ADL which would not be
otherwise necessary.
>
--
------=_Part_1255_24536573.1353573880888
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
<b>Which are the operations an opaque type provides?</b><br>
<br>
An opaque type having a builtin type as underlying type should
provide the same operations than the builtin type. It is less clear
when the base type is a defined type.<br>
<br>
I would say that the opaque type provides at least all the member
functions defined by the underlying type or by its base classes. But
what about the non-member functions that have as one of its
parameters the underlying type? Providing all these functions will
imply an implicit conversion of the opaque type to the underlying
type. So if the opaque type should provide a subset of these
functions we need a mechanism to identify them. Now that there are
more and more types that define its interface using non-members
functions I would say that there is a need to 'inherit' from some of
these functions. <br>
<br>
I see two alternatives, either we identify them when defining the
opaque type, or when defining the underlying type.<br>
<br>
I'm for the last alternative and IMO, we need a language mechanism
to identify the inherent operations of an underlying type which will
be the ones provided by an associated opaque type.<br></div></blockquot=
e><div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>My reply may be a bit=
off-topic, but you have touched a very interesting subject: type X's inter=
face consists not only of its member functions but also of some free-standi=
ng functions. And clearly, not every free-standing function that takes X as=
argument is X's interface: only some of the functions. The need to identif=
y this "extended interface" goes beyond opaque typedefs. For instance, conc=
epts do this distinction. I believe (but I know the C++ Standard only from =
books like "D&E of C++") that not having this mechanism in place led to=
the introduction of ADL which would not be otherwise necessary.<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1255_24536573.1353573880888--
.
Author: grigorij1981@gmail.com
Date: Thu, 22 Nov 2012 01:58:22 -0800 (PST)
Raw View
------=_Part_1353_12461228.1353578303514
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I still have to write a proposal for named operators, but I believe=20
that they solve that problem for new code.
=20
Regards,
Gregory
=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 22 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=
=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 10:44:41 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=
=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 Andrzej Krzemie=C5=84ski=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
>
> *Which are the operations an opaque type provides?*
>>
>> An opaque type having a builtin type as underlying type should provide=
=20
>> the same operations than the builtin type. It is less clear when the bas=
e=20
>> type is a defined type.
>>
>> I would say that the opaque type provides at least all the member=20
>> functions defined by the underlying type or by its base classes. But wha=
t=20
>> about the non-member functions that have as one of its parameters the=20
>> underlying type? Providing all these functions will imply an implicit=20
>> conversion of the opaque type to the underlying type. So if the opaque=
=20
>> type should provide a subset of these functions we need a mechanism to=
=20
>> identify them. Now that there are more and more types that define its=20
>> interface using non-members functions I would say that there is a need t=
o=20
>> 'inherit' from some of these functions.=20
>>
>> I see two alternatives, either we identify them when defining the opaque=
=20
>> type, or when defining the underlying type.
>>
>> I'm for the last alternative and IMO, we need a language mechanism to=20
>> identify the inherent operations of an underlying type which will be the=
=20
>> ones provided by an associated opaque type.
>>
> =20
> My reply may be a bit off-topic, but you have touched a very interesting=
=20
> subject: type X's interface consists not only of its member functions but=
=20
> also of some free-standing functions. And clearly, not every free-standin=
g=20
> function that takes X as argument is X's interface: only some of the=20
> functions. The need to identify this "extended interface" goes beyond=20
> opaque typedefs. For instance, concepts do this distinction. I believe (b=
ut=20
> I know the C++ Standard only from books like "D&E of C++") that not havin=
g=20
> this mechanism in place led to the introduction of ADL which would not be=
=20
> otherwise necessary.
>
>>
--=20
------=_Part_1353_12461228.1353578303514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>I still have to write a proposal for named operators, but I believe th=
at they solve that problem for new code.</div><div> </d=
iv><div>Regards,</div><div>Gregory</div><div><br>=D0=A7=D0=B5=D1=82=D0=B2=
=D0=B5=D1=80, 22 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 201=
2 =D1=80. 10:44:41 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=
=D0=B0=D1=87 Andrzej Krzemie=C5=84ski =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=
=D0=B2:</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;" class=3D"gmail_quote"><br><blockquote style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;" class=3D"gmail_quote">=
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<b>Which are the operations an opaque type provides?</b><br>
<br>
An opaque type having a builtin type as underlying type should
provide the same operations than the builtin type. It is less clear
when the base type is a defined type.<br>
<br>
I would say that the opaque type provides at least all the member
functions defined by the underlying type or by its base classes. But
what about the non-member functions that have as one of its
parameters the underlying type? Providing all these functions will
imply an implicit conversion of the opaque type to the underlying
type. So if the opaque type should provide a subset of these
functions we need a mechanism to identify them. Now that there are
more and more types that define its interface using non-members
functions I would say that there is a need to 'inherit' from some of
these functions. <br>
<br>
I see two alternatives, either we identify them when defining the
opaque type, or when defining the underlying type.<br>
<br>
I'm for the last alternative and IMO, we need a language mechanism
to identify the inherent operations of an underlying type which will
be the ones provided by an associated opaque type.<br></div></blockquot=
e><div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br>My reply may be a bit=
off-topic, but you have touched a very interesting subject: type X's inter=
face consists not only of its member functions but also of some free-standi=
ng functions. And clearly, not every free-standing function that takes X as=
argument is X's interface: only some of the functions. The need to identif=
y this "extended interface" goes beyond opaque typedefs. For instance, conc=
epts do this distinction. I believe (but I know the C++ Standard only from =
books like "D&E of C++") that not having this mechanism in place led to=
the introduction of ADL which would not be otherwise necessary.<br>
</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;" class=3D"gmail_quote">
</blockquote></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1353_12461228.1353578303514--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 18:06:16 +0100
Raw View
This is a multi-part message in MIME format.
--------------080607070100030305080203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 22/11/12 10:58, grigorij1981@gmail.com a =E9crit :
> I still have to write a proposal for named operators, but I believe=20
> that they solve that problem for new code.
>
Hi,
could you elaborate on how your future named operator proposal will=20
address the mentioned problems?
Vicente
> ??????, 22 ????????? 2012 ?. 10:44:41 UTC+2 ?????????? Andrzej=20
> Krzemien'ski ???????:
>
>
> *Which are the operations an opaque type provides?*
>
> An opaque type having a builtin type as underlying type should
> provide the same operations than the builtin type. It is less
> clear when the base type is a defined type.
>
> I would say that the opaque type provides at least all the
> member functions defined by the underlying type or by its base
> classes. But what about the non-member functions that have as
> one of its parameters the underlying type? Providing all these
> functions will imply an implicit conversion of the opaque type
> to the underlying type. So if the opaque type should provide
> a subset of these functions we need a mechanism to identify
> them. Now that there are more and more types that define its
> interface using non-members functions I would say that there
> is a need to 'inherit' from some of these functions.
>
> I see two alternatives, either we identify them when defining
> the opaque type, or when defining the underlying type.
>
> I'm for the last alternative and IMO, we need a language
> mechanism to identify the inherent operations of an underlying
> type which will be the ones provided by an associated opaque type=
..
>
>
> My reply may be a bit off-topic, but you have touched a very
> interesting subject: type X's interface consists not only of its
> member functions but also of some free-standing functions. And
> clearly, not every free-standing function that takes X as argument
> is X's interface: only some of the functions. The need to identify
> this "extended interface" goes beyond opaque typedefs. For
> instance, concepts do this distinction. I believe (but I know the
> C++ Standard only from books like "D&E of C++") that not having
> this mechanism in place led to the introduction of ADL which would
> not be otherwise necessary.
>
> --=20
>
>
>
--=20
--------------080607070100030305080203
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/11/12 10:58,
<a class="moz-txt-link-abbreviated" href="mailto:grigorij1981@gmail.com">grigorij1981@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:b272af7c-b1db-4ae4-beed-4e056bbb32e3@isocpp.org"
type="cite">
<div>I still have to write a proposal for named operators, but I
believe that they solve that problem for new code.</div>
<div> </div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal will
address the mentioned problems?<br>
<br>
Vicente<br>
<blockquote
cite="mid:b272af7c-b1db-4ae4-beed-4e056bbb32e3@isocpp.org"
type="cite">
<div>Четвер, 22 листопада 2012 р. 10:44:41 UTC+2 користувач
Andrzej Krzemieński написав:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote"><br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF"> <b>Which are the
operations an opaque type provides?</b><br>
<br>
An opaque type having a builtin type as underlying type
should provide the same operations than the builtin type. It
is less clear when the base type is a defined type.<br>
<br>
I would say that the opaque type provides at least all the
member functions defined by the underlying type or by its
base classes. But what about the non-member functions that
have as one of its parameters the underlying type? Providing
all these functions will imply an implicit conversion of the
opaque type to the underlying type. So if the opaque type
should provide a subset of these functions we need a
mechanism to identify them. Now that there are more and more
types that define its interface using non-members functions
I would say that there is a need to 'inherit' from some of
these functions. <br>
<br>
I see two alternatives, either we identify them when
defining the opaque type, or when defining the underlying
type.<br>
<br>
I'm for the last alternative and IMO, we need a language
mechanism to identify the inherent operations of an
underlying type which will be the ones provided by an
associated opaque type.<br>
</div>
</blockquote>
<div text="#000000" bgcolor="#FFFFFF"> <br>
My reply may be a bit off-topic, but you have touched a very
interesting subject: type X's interface consists not only of
its member functions but also of some free-standing functions.
And clearly, not every free-standing function that takes X as
argument is X's interface: only some of the functions. The
need to identify this "extended interface" goes beyond opaque
typedefs. For instance, concepts do this distinction. I
believe (but I know the C++ Standard only from books like
"D&E of C++") that not having this mechanism in place led
to the introduction of ADL which would not be otherwise
necessary.<br>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
</blockquote>
</blockquote>
-- <br>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------080607070100030305080203--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 18:26:24 +0100
Raw View
This is a multi-part message in MIME format.
--------------050309090104010305000500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 22/11/12 10:58, grigorij1981@gmail.com a =E9crit :
> I still have to write a proposal for named operators, but I believe=20
> that they solve that problem for new code.
> Regards,
> Gregory
>
> ??????, 22 ????????? 2012 ?. 10:44:41 UTC+2 ?????????? Andrzej=20
> Krzemien'ski ???????:
>
>
> *Which are the operations an opaque type provides?*
>
> An opaque type having a builtin type as underlying type should
> provide the same operations than the builtin type. It is less
> clear when the base type is a defined type.
>
> I would say that the opaque type provides at least all the
> member functions defined by the underlying type or by its base
> classes. But what about the non-member functions that have as
> one of its parameters the underlying type? Providing all these
> functions will imply an implicit conversion of the opaque type
> to the underlying type. So if the opaque type should provide
> a subset of these functions we need a mechanism to identify
> them. Now that there are more and more types that define its
> interface using non-members functions I would say that there
> is a need to 'inherit' from some of these functions.
>
> I see two alternatives, either we identify them when defining
> the opaque type, or when defining the underlying type.
>
> I'm for the last alternative and IMO, we need a language
> mechanism to identify the inherent operations of an underlying
> type which will be the ones provided by an associated opaque type=
..
>
>
> My reply may be a bit off-topic, but you have touched a very
> interesting subject: type X's interface consists not only of its
> member functions but also of some free-standing functions. And
> clearly, not every free-standing function that takes X as argument
> is X's interface: only some of the functions. The need to identify
> this "extended interface" goes beyond opaque typedefs. For
> instance, concepts do this distinction. I believe (but I know the
> C++ Standard only from books like "D&E of C++") that not having
> this mechanism in place led to the introduction of ADL which would
> not be otherwise necessary.
>
>
Hi,
I would share a possibility for the 2nd alternative, which consists in=20
adding the prototype of all the associated functions just after the type=20
definition
class X
{
}
{
X& operator+(X const&, X const&);
X& operator-(X const&, X const&);
}
;
The symbol '+' could be used to separate the class members from the=20
associated non-members functions.
Vicente
--=20
--------------050309090104010305000500
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/11/12 10:58,
<a class="moz-txt-link-abbreviated" href="mailto:grigorij1981@gmail.com">grigorij1981@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:b272af7c-b1db-4ae4-beed-4e056bbb32e3@isocpp.org"
type="cite">
<div>I still have to write a proposal for named operators, but I
believe that they solve that problem for new code.</div>
<div> </div>
<div>Regards,</div>
<div>Gregory</div>
<div><br>
Четвер, 22 листопада 2012 р. 10:44:41 UTC+2 користувач Andrzej
Krzemieński написав:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote"><br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF"> <b>Which are the
operations an opaque type provides?</b><br>
<br>
An opaque type having a builtin type as underlying type
should provide the same operations than the builtin type. It
is less clear when the base type is a defined type.<br>
<br>
I would say that the opaque type provides at least all the
member functions defined by the underlying type or by its
base classes. But what about the non-member functions that
have as one of its parameters the underlying type? Providing
all these functions will imply an implicit conversion of the
opaque type to the underlying type. So if the opaque type
should provide a subset of these functions we need a
mechanism to identify them. Now that there are more and more
types that define its interface using non-members functions
I would say that there is a need to 'inherit' from some of
these functions. <br>
<br>
I see two alternatives, either we identify them when
defining the opaque type, or when defining the underlying
type.<br>
<br>
I'm for the last alternative and IMO, we need a language
mechanism to identify the inherent operations of an
underlying type which will be the ones provided by an
associated opaque type.<br>
</div>
</blockquote>
<div text="#000000" bgcolor="#FFFFFF"> <br>
My reply may be a bit off-topic, but you have touched a very
interesting subject: type X's interface consists not only of
its member functions but also of some free-standing functions.
And clearly, not every free-standing function that takes X as
argument is X's interface: only some of the functions. The
need to identify this "extended interface" goes beyond opaque
typedefs. For instance, concepts do this distinction. I
believe (but I know the C++ Standard only from books like
"D&E of C++") that not having this mechanism in place led
to the introduction of ADL which would not be otherwise
necessary.<br>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class="gmail_quote">
</blockquote>
</blockquote>
<br>
</blockquote>
Hi,<br>
<br>
I would share a possibility for the 2nd alternative, which consists
in adding the prototype of all the associated functions just after
the type definition<br>
<br>
class X <br>
{<br>
<br>
} <br>
{<br>
X& operator+(X const&, X const&);<br>
X& operator-(X const&, X const&);<br>
} <br>
;<br>
<br>
The symbol '+' could be used to separate the class members from the
associated non-members functions. <br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------050309090104010305000500--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 18:54:38 +0100
Raw View
This is a multi-part message in MIME format.
--------------060905010109060406050507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 22/11/12 00:16, Vladimir Merzliakov a =E9crit :
>
> Sorry if my comment will pointless and early discussed, but...
>
> Why instead extending 'using' not allow just have non-class types as=20
> class parent types so have:
>
> class C : private int { ... }
>
Which would be the operations provided by C?
>
> or
>
> class S : public int { ... }
>
This forces C to be a int and we want the new type C to be possibly not=20
an int.
In addition the conversion from an int need to be added explicitly.
>
> That directly allow easy define interface of new type and provide same=20
> implicit/explicit difference new type from original type
>
> Using existed C++ syntax features.
>
Vicente
--=20
--------------060905010109060406050507
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/11/12 00:16, Vladimir Merzliakov
a écrit :<br>
</div>
<blockquote cite="mid:001e01cdc83e$35f504f0$a1df0ed0$@ru"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.term
{mso-style-name:term;}
span.bold
{mso-style-name:bold;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Sorry if my comment will pointless and early
discussed, but…<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Why instead extending ‘using’ not allow just
have non-class types as class parent types so have:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">class C : private int { … }<o:p></o:p></span></p>
</div>
</blockquote>
Which would be the operations provided by C?<br>
<blockquote cite="mid:001e01cdc83e$35f504f0$a1df0ed0$@ru"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">or<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">class S : public int { … }</span></p>
</div>
</blockquote>
This forces C to be a int and we want the new type C to be possibly
not an int. <br>
<br>
In addition the conversion from an int need to be added explicitly.<br>
<blockquote cite="mid:001e01cdc83e$35f504f0$a1df0ed0$@ru"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">That directly allow easy define interface of
new type and provide same implicit/explicit difference new
type from original type<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Using existed C++ syntax features.<o:p></o:p></span></p>
</div>
</blockquote>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------060905010109060406050507--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 19:00:00 +0100
Raw View
Le 22/11/12 00:19, Klaim - Jo=C4=97l Lamotte a =C3=A9crit :
> Re-reading this discussion, I think I might have confused what I wish=20
> this feature would do with what was initially proposed.
>
>
> ...
> Which also imply that I don't see the point of the explicit optional=20
> marker.
>
We want either that the conversion from the new type to the underlying=20
type to be implicit or explicit.
Vicente
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 19:15:15 +0100
Raw View
This is a multi-part message in MIME format.
--------------080808080509040506080000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 22/11/12 00:09, Klaim - Jo=EBl Lamotte a =E9crit :
> Some feedback :
>
> On Wed, Nov 21, 2012 at 10:59 PM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> *Are the opaque types classes?**
> *
> [1] says that the type traits of the OT are defined as the ones of
> the underlying type, is_TRAIT<OT> =3D is_TRAIT<UT>.
> So if we have
>
> using class C =3D int;
>
> is_class<C> should be false_type. This should be a little bit
> confusing, but there is an antecedent as an enum class is not a class=
..
>
> I would prefer that opaque types be classes independently of the
> underlying types but maybe there are some issues with the core
> language.
>
>
> I can understand that enum class cannot be considered the same way=20
> than a class.
> However, here the feature is, as far as I understand it, supposed to=20
> "clone perfectly" the right-side type, which would imply that
>
> is_class<C>::value =3D=3D is_class<int>::value
>
> Because otherwise I don't see the point of this feature.
I agree as far as there is no mechanism to extend the opaque type with=20
new operations.
>
>
> *Does the opaque type inherits from all the template classes
> specialized with the under**lying type?**
> *
>
>
> As I said, i don't see the point if the generated type isn't an exact=20
> clone.
Let me show an example. I can define a meta-function that tells if two=20
classes belong to the same domain.
template <typename T, typename U>
struct same_domain : false_type {};
template <>
struct same_domain<A,B> : true_type{};
If I define a new opaque type
using class C =3D A;
should be same_domain<C,B> a true_type or false_type?
>
> *Which are the operations an opaque type provides?*
>
>
> Same logic for me: it should just be a type clone.
By clone I understand that it is a different type.
class A;
A& operator+(A const&,A const&);
using class C =3D A;
Could I expect the following to be valid
C c;
c =3D c + c ;
>
> *Should the user be able to define opaque types providing less
> functions than its underlying type?**
>
> *I would say yes, but then the alias statement should be extended
> in some way.
>
>
> I don't see any use case for this. Do you have one? (I might miss=20
> something here).
>
Think for example to a process identifier new opaque type PId with an=20
underlying type int. I wouldn't expect to be able to add two PId. But I=20
expect them to be comparable, ....
Vicente
--=20
--------------080808080509040506080000
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/11/12 00:09, Klaim - Joël Lamotte
a écrit :<br>
</div>
<blockquote
cite="mid:CAOU91OOSvG=gHtJ4t7EgQ1OKaL8z9a3_4BsXnj9FafcO00exxQ@mail.gmail.com"
type="cite">
<div class="gmail_extra">Some feedback :<br>
<br>
<div class="gmail_quote">On Wed, Nov 21, 2012 at 10:59 PM,
Vicente J. Botet Escriba <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><b>Are the
opaque types classes?</b><b><br>
</b><br>
[1] says that the type traits of the OT are defined as the
ones of the underlying type, is_TRAIT<OT> =
is_TRAIT<UT>.<br>
So if we have<br>
<br>
using class C = int;<br>
<br>
is_class<C> should be false_type. This should be a
little bit confusing, but there is an antecedent as an enum
class is not a class.<br>
<br>
I would prefer that opaque types be classes independently of
the underlying types but maybe there are some issues with
the core language.<br>
<br>
</blockquote>
<div><br>
</div>
<div>I can understand that enum class cannot be considered the
same way than a class.</div>
<div>However, here the feature is, as far as I understand it,
supposed to "clone perfectly" the right-side type, which
would imply that</div>
<div><br>
</div>
<div>is_class<C>::value == is_class<int>::value</div>
<div><br>
</div>
<div>Because otherwise I don't see the point of this feature.</div>
</div>
</div>
</blockquote>
I agree as far as there is no mechanism to extend the opaque type
with new operations.<br>
<blockquote
cite="mid:CAOU91OOSvG=gHtJ4t7EgQ1OKaL8z9a3_4BsXnj9FafcO00exxQ@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<b>Does the opaque type inherits from all the template
classes specialized with the under</b><b>lying type?</b><b><br>
</b><br>
</blockquote>
<div><br>
</div>
<div>As I said, i don't see the point if the generated type
isn't an exact clone.</div>
</div>
</div>
</blockquote>
Let me show an example. I can define a meta-function that tells if
two classes belong to the same domain.<br>
<br>
template <typename T, typename U><br>
struct same_domain : false_type {};<br>
<br>
template <><br>
struct same_domain<A,B> : true_type{};<br>
<br>
If I define a new opaque type<br>
<br>
using class C = A;<br>
<br>
should be same_domain<C,B> a true_type or false_type?<br>
<br>
<blockquote
cite="mid:CAOU91OOSvG=gHtJ4t7EgQ1OKaL8z9a3_4BsXnj9FafcO00exxQ@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<b>Which are the operations an opaque type provides?</b><br>
<br>
</blockquote>
<div><br>
</div>
<div>Same logic for me: it should just be a type clone.</div>
</div>
</div>
</blockquote>
By clone I understand that it is a different type.<br>
<br>
class A;<br>
A& operator+(A const&,A const&);<br>
using class C = A;<br>
<br>
Could I expect the following to be valid<br>
<br>
C c;<br>
c = c + c ;<br>
<blockquote
cite="mid:CAOU91OOSvG=gHtJ4t7EgQ1OKaL8z9a3_4BsXnj9FafcO00exxQ@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <b>Should
the user be able to define opaque types providing less
functions than its underlying type?</b><b><br>
<br>
</b>I would say yes, but then the alias statement should be
extended in some way.</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">I don't see any use case for this. Do you
have one? (I might miss something here).</div>
<br>
</blockquote>
Think for example to a process identifier new opaque type PId with
an underlying type int. I wouldn't expect to be able to add two PId.
But I expect them to be comparable, ....<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------080808080509040506080000--
.
Author: grigorij1981@gmail.com
Date: Fri, 30 Nov 2012 04:17:44 -0800 (PST)
Raw View
------=_Part_1297_27232281.1354277864322
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=
=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=
=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=B2:
>
> Le 22/11/12 10:58, grigor...@gmail.com <javascript:> a =C3=A9crit :
> =20
> I still have to write a proposal for named operators, but I believe=20
> that they solve that problem for new code.
> =20
>
> Hi,
>
> could you elaborate on how your future named operator proposal will=20
> address the mentioned problems?
>
> Vicente
>
=20
Named operator is a free function declared with operator keyword.
=20
A operator fun(const A& a);
=20
Such functions should be considered as a part of an interface of its first=
=20
(?) parameter.
That gives us a way to distinguish between usual free functions and free=20
functions coupled to the class.
=20
Type that is an opaque alias of some class should by default 'inherit' from=
=20
it both usual and named operators.
That is, if we have
using class B =3D A;
=20
And the above declaration of fun is visible then such declaration also=20
defines =20
=20
B operator fun(const B& b);
=20
Regards,
Gregory
> =20
>
--=20
------=_Part_1297_27232281.1354277864322
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=
=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=
=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=B2:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;" class=3D"gmail_quote">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 22/11/12 10:58,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Sx=
YGJ3OrQUMJ">grigor...@gmail.com</a> a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div>I still have to write a proposal for named operators, but I
believe that they solve that problem for new code.</=
div>
<div> </div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal will
address the mentioned problems?<br>
<br>
Vicente</div></blockquote><div> </div><div>Named operator is a fre=
e function declared with operator keyword.</div><div> </div=
><div><font face=3D"courier new,monospace">A operator fun(const A& a);<=
/font></div><div> </div><div>Such functions should be considered as a =
part of an interface of its first (?) parameter.</div><div>That gives us a =
way to distinguish between usual free functions and free functions coupled =
to the class.</div><div> </div><div>Type that is an opaque alias of&nb=
sp;some class should by default 'inherit' from it both usual and named=
operators.</div><div>That is, if we have</div><div><font face=3D"courier n=
ew,monospace">using class B =3D A;</font></div><div> </div><div>And th=
e above declaration of fun is visible then such declaration =
also defines </div><div> </div><div><font face=3D"Courier N=
ew">B operator fun(const B& b);</font></div><div><font face=3D"Cou=
rier New"></font> </div><div><font face=3D"arial,sans-serif">Regards,<=
/font></div><div>Gregory</div><blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;" class=3D"gmail_quote"><div text=3D"#00=
0000" bgcolor=3D"#FFFFFF"> </div></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1297_27232281.1354277864322--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 30 Nov 2012 05:07:57 -0800 (PST)
Raw View
------=_Part_1539_29589585.1354280877547
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 30 listopada 2012 13:17:44 UTC+1 u=C5=BCytkownik=20
grigor...@gmail.com napisa=C5=82:
>
>
> =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=
=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=
=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=B2:
>>
>> Le 22/11/12 10:58, grigor...@gmail.com a =C3=A9crit :
>> =20
>> I still have to write a proposal for named operators, but I believe=20
>> that they solve that problem for new code.
>> =20
>>
>> Hi,
>>
>> could you elaborate on how your future named operator proposal will=20
>> address the mentioned problems?
>>
>> Vicente
>>
> =20
> Named operator is a free function declared with operator keyword.
> =20
> A operator fun(const A& a);
> =20
> Such functions should be considered as a part of an interface of its firs=
t=20
> (?) parameter.
>
The constraint on only the first parameter is unacceptable (for me at=20
least). The motivation for ADL was this:
class A{};
std::ostream& operator<<(std::ostream&, A const&);
The operator is clearly A's interface, and A is second argument.
Regards,
&rzej
=20
--=20
------=_Part_1539_29589585.1354280877547
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=C4=85tek, 30 listopada 2012 13:17:44 UTC+1 u=C5=BCytkowni=
k grigor...@gmail.com napisa=C5=82:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><br>=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=
=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=
=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=B2:<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid" class=3D"gmail_quote">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 22/11/12 10:58,
<a>grigor...@gmail.com</a> a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div>I still have to write a proposal for named operators, but I
believe that they solve that problem for new code.</=
div>
<div> </div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal will
address the mentioned problems?<br>
<br>
Vicente</div></blockquote><div> </div><div>Named operator is a fre=
e function declared with operator keyword.</div><div> </div=
><div><font face=3D"courier new,monospace">A operator fun(const A& a);<=
/font></div><div> </div><div>Such functions should be considered as a =
part of an interface of its first (?) parameter.</div></blockquote><div><br=
>The constraint on only the first parameter is unacceptable (for me at leas=
t). The motivation for ADL was this:<br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>ostream</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><<(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">ostream</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> A </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><br>The operator is clea=
rly A's interface, and A is second argument.<br><br>Regards,<br>&rzej<b=
r><br> <br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1539_29589585.1354280877547--
.
Author: grigorij1981@gmail.com
Date: Fri, 30 Nov 2012 05:27:12 -0800 (PST)
Raw View
------=_Part_193_18339713.1354282032492
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
That's why I have question mark there.=20
However, *named* operators and usual ones while having some similarities=20
are different entities. I was talking specifically about named operators.
Maybe usual binary operators should be a part of interfaces of both their=
=20
arguments, but for a named operator I would prefer to have a single class=
=20
to which it should be connected.
=D0=9F=CA=BC=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=8F, 30 =D0=BB=D0=B8=D1=81=D1=
=82=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 15:07:57 UTC+2 =D0=BA=D0=BE=
=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 Andrzej=20
Krzemie=C5=84ski =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
>
>
> W dniu pi=C4=85tek, 30 listopada 2012 13:17:44 UTC+1 u=C5=BCytkownik=20
> grigor...@gmail.com napisa=C5=82:
>>
>>
>> =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=
=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=
=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=B2:
>>>
>>> Le 22/11/12 10:58, grigor...@gmail.com a =C3=A9crit :
>>> =20
>>> I still have to write a proposal for named operators, but I believe=20
>>> that they solve that problem for new code.
>>> =20
>>>
>>> Hi,
>>>
>>> could you elaborate on how your future named operator proposal will=20
>>> address the mentioned problems?
>>>
>>> Vicente
>>>
>> =20
>> Named operator is a free function declared with operator keyword.
>> =20
>> A operator fun(const A& a);
>> =20
>> Such functions should be considered as a part of an interface of its=20
>> first (?) parameter.
>>
>
> The constraint on only the first parameter is unacceptable (for me at=20
> least). The motivation for ADL was this:
>
> class A{};
> std::ostream& operator<<(std::ostream&, A const&);
>
> The operator is clearly A's interface, and A is second argument.
>
> Regards,
> &rzej
>
> =20
>
--=20
------=_Part_193_18339713.1354282032492
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>That's why I have question mark there. </div><div>However, <em>named</=
em> operators and usual ones while having some similarities are different e=
ntities. I was talking specifically about named operators.</div><div>Maybe&=
nbsp;usual binary operators should be a part of interfaces of bot=
h their arguments, but for a named operator I would prefer to have a single=
class to which it should be connected.</div><div><br>=D0=9F=CA=BC=D1=
=8F=D1=82=D0=BD=D0=B8=D1=86=D1=8F, 30 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=BF=
=D0=B0=D0=B4=D0=B0 2012 =D1=80. 15:07:57 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=
=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 Andrzej Krzemie=C5=84ski =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0=D0=B2:</div><blockquote style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;" class=3D"gmail_quote"><br><br>W dn=
iu pi=C4=85tek, 30 listopada 2012 13:17:44 UTC+1 u=C5=BCytkownik <a>grigor.=
...@gmail.com</a> napisa=C5=82:<blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;" class=3D"gmail_quote"><br>=D0=A7=D0=B5=
=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=BF=D0=B0=D0=
=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=
=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:=
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;" class=3D"gmail_quote">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 22/11/12 10:58,
<a>grigor...@gmail.com</a> a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div>I still have to write a proposal for named operators, but I
believe that they solve that problem for new code.</=
div>
<div> </div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal will
address the mentioned problems?<br>
<br>
Vicente</div></blockquote><div> </div><div>Named operator is a fre=
e function declared with operator keyword.</div><div> </div=
><div><font face=3D"courier new,monospace">A operator fun(const A& a);<=
/font></div><div> </div><div>Such functions should be considered as a =
part of an interface of its first (?) parameter.</div></blockquote><div><br=
>The constraint on only the first parameter is unacceptable (for me at leas=
t). The motivation for ADL was this:<br><br><div style=3D"border: 1px solid=
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250,=
250);"><code><div><span style=3D"color: rgb(0, 0, 136);">class</span><span=
style=3D"color: rgb(0, 0, 0);"> A</span><span style=3D"color: rgb(102, 102=
, 0);">{};</span><span style=3D"color: rgb(0, 0, 0);"><br>std</span><span s=
tyle=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, =
0);">ostream</span><span style=3D"color: rgb(102, 102, 0);">&</span><sp=
an style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 1=
36);">operator</span><span style=3D"color: rgb(102, 102, 0);"><<(</sp=
an><span style=3D"color: rgb(0, 0, 0);">std</span><span style=3D"color: rgb=
(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);">ostream</span=
><span style=3D"color: rgb(102, 102, 0);">&,</span><span style=3D"color=
: rgb(0, 0, 0);"> A </span><span style=3D"color: rgb(0, 0, 136);">const</sp=
an><span style=3D"color: rgb(102, 102, 0);">&);</span><span style=3D"co=
lor: rgb(0, 0, 0);"><br></span></div></code></div><br>The operator is clear=
ly A's interface, and A is second argument.<br><br>Regards,<br>&rzej<br=
><br> <br></div></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_193_18339713.1354282032492--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 30 Nov 2012 19:25:40 +0100
Raw View
This is a multi-part message in MIME format.
--------------010100010804070900010005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 30/11/12 13:17, grigorij1981@gmail.com a =C3=A9crit :
>
> =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=
=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=
=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=B2:
>
> Le 22/11/12 10:58, grigor...@gmail.com <javascript:> a =C3=A9crit :
>> I still have to write a proposal for named operators, but I
>> believe that they solve that problem for new code.
>>
> Hi,
>
> could you elaborate on how your future named operator proposal
> will address the mentioned problems?
>
> Vicente
>
> Named operator is a free function declared with operator keyword.
> A operator fun(const A& a);
> Such functions should be considered as a part of an interface of its=20
> first (?) parameter.
> That gives us a way to distinguish between usual free functions and=20
> free functions coupled to the class.
Are named operators a separated proposal? If yes, which is his added=20
value? How the named operators are called?
I insists because I'm myself elaborating a proposal on named operators=20
as an alternative to C++/CLI Properties that seams to have a completely=20
different semantic.
Vicente
--=20
--------------010100010804070900010005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 30/11/12 13:17,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:grigorij1981@gma=
il.com">grigorij1981@gmail.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:6356c7ed-4d4d-4010-be2c-3165439cf4d6@isocpp.org"
type=3D"cite"><br>
=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=
=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=
=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left-color: rgb(204, 204, 204); border-left-width: 1px;
border-left-style: solid;" class=3D"gmail_quote">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 22/11/12 10:58, <a moz-do-not-send=3D"true"
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"SxYGJ3OrQUMJ">grigor...@gmail.com</a=
>
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div>I still have to write a proposal for named operators,
but I believe that=C2=A0they=C2=A0solve that problem for=C2=
=A0new code.</div>
<div>=C2=A0</div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal
will address the mentioned problems?<br>
<br>
Vicente</div>
</blockquote>
<div>=C2=A0</div>
<div>Named operator is a free function=C2=A0=C2=A0declared with opera=
tor
keyword.</div>
<div>=C2=A0</div>
<div><font face=3D"courier new,monospace">A operator fun(const
A& a);</font></div>
<div>=C2=A0</div>
<div>Such functions should be considered as a part of an interface
of its first (?) parameter.</div>
<div>That gives us a way to distinguish between usual free
functions and free functions coupled to the class.</div>
</blockquote>
Are named operators a separated proposal? If yes, which is his added
value? How the named operators are called?<br>
<br>
I insists because I'm myself elaborating a proposal on named
operators as an alternative to C++/CLI Properties that seams to have
a completely different semantic. <br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------010100010804070900010005--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Nov 2012 22:08:47 +0100
Raw View
--047d7b2ede714323ac04cfbcce28
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Nov 29, 2012 at 7:15 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> I agree as far as there is no mechanism to extend the opaque type with
> new operations.
>
>
You mean associated non-member functions?
> Let me show an example. I can define a meta-function that tells if two
> classes belong to the same domain.
>
> template <typename T, typename U>
> struct same_domain : false_type {};
>
> template <>
> struct same_domain<A,B> : true_type{};
>
> If I define a new opaque type
>
> using class C = A;
>
> should be same_domain<C,B> a true_type or false_type?
>
>
>
I would say false_type but I'm not sure if I'm missing a unfortunate side
effect in this specific case.
>
>
>>
>> *Which are the operations an opaque type provides?*
>>
>>
> Same logic for me: it should just be a type clone.
>
> By clone I understand that it is a different type.
>
> class A;
> A& operator+(A const&,A const&);
> using class C = A;
>
> Could I expect the following to be valid
>
> C c;
> c = c + c ;
>
>
Ah yes indeed, I understand the problem now. Thanks!
Hard to solve...
Joel Lamotte
--
--047d7b2ede714323ac04cfbcce28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, N=
ov 29, 2012 at 7:15 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><<a h=
ref=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wan=
adoo.fr</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>I agree as far as there is no mechanism to extend the opaque type
with new operations.<br></div><div class=3D"im"><br></div></div></block=
quote><div><br></div><div>You mean associated non-member functions?=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><blockquote typ=
e=3D"cite"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
</div>
</div>
</blockquote></div>
Let me show an example. I can define a meta-function that tells if
two classes belong to the same domain.<br>
<br>
template <typename T, typename U><br>
struct same_domain : false_type {};<br>
<br>
template <><br>
struct same_domain<A,B> : true_type{};<br>
<br>
If I define a new opaque type<br>
<br>
using class C =3D A;<br>
<br>
should be same_domain<C,B> a true_type or false_type?<div class=
=3D"im"><br>
<br></div></div></blockquote><div><br></div><div>I would say false_type=
but I'm not sure if I'm missing a unfortunate side effect in this =
specific case.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im">
<blockquote type=3D"cite">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"> <br>
<b>Which are the operations an opaque type provides?</b><br>
<br>
</blockquote>
<div><br>
</div>
<div>Same logic for me: it should just be a type clone.</div>
</div>
</div>
</blockquote></div>
By clone I understand that it is a different type.<br>
<br>
class A;<br>
A& operator+(A const&,A const&);<br>
using class C =3D A;<br>
<br>
Could I expect the following to be valid<br>
<br>
C c;<br>
c =3D c + c ;<div class=3D"im"><br></div></div></blockquote><div><br></=
div><div><br></div><div>Ah yes indeed, I understand the problem now. Thanks=
!</div><div>Hard to solve...</div><div><br></div><div>Joel Lamotte</div></d=
iv>
</div>
<p></p>
-- <br />
<br />
<br />
<br />
--047d7b2ede714323ac04cfbcce28--
.
Author: grigorij1981@gmail.com
Date: Sat, 1 Dec 2012 05:32:02 -0800 (PST)
Raw View
------=_Part_78_11809992.1354368722278
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Named operators allow strict definition of *extended interface of a class.*=
That notion is useful not only for opaque aliases. I started thinking about=
=20
it when I read ADL Control for C++<http://open-std.org/JTC1/SC22/WG21/docs/=
papers/2012/n3490.html>.=20
There was proposed to have an option to disable ADL for all non-operator=20
names in the current scope except for those that are mentioned in a special=
=20
using directive. In my opinion it was okay to disable ADL for most of the=
=20
functions, however not for those that are connected to a class, and those=
=20
may be usual functions not only operators.=20
So, my initial idea was to have named operators proposal as addendum to the=
=20
*N3490* <http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html>.
=20
If we stop here, then named operators are just specially declared free=20
functions and are called as such:
func(a,b);
or
operator func(a,b);
=20
But there was another idea - to open-up classes<http://open-std.org/JTC1/SC=
22/WG21/docs/papers/2004/n1742.pdf>in C++, that is to allow a limited form =
of partial classes of C#/VB - allow=20
additional definitions of class that contain typedefs and members. It seems=
=20
with using aliases we on a longer term will not need inner typedefs anyway,=
=20
but adding new non-virtual functions to exiting class may be beneficial -=
=20
with that we would have a sort of concept maps for non-generic code.
=20
That is possible if we allow named operators to be called like members.=20
That is the second part of the proposal. There are unsolved problems=20
however, it is tempting to have an ability to overload existing=20
member-function with named operator, but member-function if it matches=20
parameters should always be considered as better match than named operator,=
=20
that leads to more complicated matching procedure...
Anyway, with second part of the proposal named operators may be called as=
=20
member functions:
a.func(b);
=20
Regards,
Gregory
=D0=9F=CA=BC=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=8F, 30 =D0=BB=D0=B8=D1=81=D1=
=82=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 20:25:40 UTC+2 =D0=BA=D0=BE=
=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=B2:
> Le 30/11/12 13:17, grigor...@gmail.com <javascript:> a =C3=A9crit :
> =20
>
> =D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=
=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=D0=
=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=B2:=20
>>
>> Le 22/11/12 10:58, grigor...@gmail.com a =C3=A9crit :
>> =20
>> I still have to write a proposal for named operators, but I believe=20
>> that they solve that problem for new code.
>> =20
>>
>> Hi,
>>
>> could you elaborate on how your future named operator proposal will=20
>> address the mentioned problems?
>>
>> Vicente
>>
> =20
> Named operator is a free function declared with operator keyword.
> =20
> A operator fun(const A& a);
> =20
> Such functions should be considered as a part of an interface of its firs=
t=20
> (?) parameter.
> That gives us a way to distinguish between usual free functions and free=
=20
> functions coupled to the class.
>
> Are named operators a separated proposal? If yes, which is his added=20
> value? How the named operators are called?
>
> I insists because I'm myself elaborating a proposal on named operators as=
=20
> an alternative to C++/CLI Properties that seams to have a completely=20
> different semantic.=20
>
> Vicente
> =20
--=20
------=_Part_78_11809992.1354368722278
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>Named operators allow strict definition of <em>extended interface=
of a class.</em> That notion is useful not only for opaque aliases. I star=
ted thinking about it when I read <a href=3D"http://open-std.org/JTC1/SC22/=
WG21/docs/papers/2012/n3490.html"> ADL Control for C++</a>. </div><div>Ther=
e was proposed to have an option to disable ADL for all non-operator names&=
nbsp;in the current scope except for those that are mentioned in a special =
using directive. In my opinion it was okay to disable ADL for most of the f=
unctions, however not for those that are connected to a class, and tho=
se may be usual functions not only operators. </div><div>So, my initia=
l idea was to have named operators proposal as addendum to the <a href=3D"h=
ttp://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html"><u><font col=
or=3D"#0066cc">N3490</font></u></a>.</div><div> </div><div>If we stop =
here, then named operators are just specially declared free functions and a=
re called as such:</div><div><font face=3D"courier new,monospace">func(a,b)=
;</font></div><div>or</div><div><font face=3D"courier new,monospace">operat=
or func(a,b);</font></div><div> </div><div>But there was another idea&=
nbsp;- <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1742=
..pdf">to open-up classes</a> in C++, that is to allow a limited form of par=
tial classes of C#/VB - allow additional definitions of clas=
s that contain typedefs and members. It seems with using aliases we on a lo=
nger term will not need inner typedefs anyway, but adding new non-virtual f=
unctions to exiting class may be beneficial - with that we would have a sor=
t of concept maps for non-generic code.</div><div> </div><div>That is =
possible if we allow named operators to be called like members. That is the=
second part of the proposal. There are unsolved problems however, it is te=
mpting to have an ability to overload existing member-function with named o=
perator, but member-function if it matches parameters should always be cons=
idered as better match than named operator, that leads to more complicated =
matching procedure...</div><div>Anyway, with second part of the proposal na=
med operators may be called as member functions:</div><div><font face=3D"co=
urier new,monospace">a.func(b);</font></div><div> </div><div>Regards,<=
/div><div>Gregory</div><div><br>=D0=9F=CA=BC=D1=8F=D1=82=D0=BD=D0=B8=D1=86=
=D1=8F, 30 =D0=BB=D0=B8=D1=81=D1=82=D0=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=
=80. 20:25:40 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=
=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 30/11/12 13:17,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"9t=
zMHH4psrsJ">grigor...@gmail.com</a> a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite"><br>
=D0=A7=D0=B5=D1=82=D0=B2=D0=B5=D1=80, 29 =D0=BB=D0=B8=D1=81=D1=82=D0=
=BE=D0=BF=D0=B0=D0=B4=D0=B0 2012 =D1=80. 19:06:16 UTC+2 =D0=BA=D0=BE=D1=80=
=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 viboes
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 22/11/12 10:58, <a>grigor...@gmail.com</a>
a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div>I still have to write a proposal for named operators,
but I believe that they solve that problem for =
;new code.</div>
<div> </div>
<br>
</blockquote>
Hi,<br>
<br>
could you elaborate on how your future named operator proposal
will address the mentioned problems?<br>
<br>
Vicente</div>
</blockquote>
<div> </div>
<div>Named operator is a free function declared with opera=
tor
keyword.</div>
<div> </div>
<div><font face=3D"courier new,monospace">A operator fun(const
A& a);</font></div>
<div> </div>
<div>Such functions should be considered as a part of an interface
of its first (?) parameter.</div>
<div>That gives us a way to distinguish between usual free
functions and free functions coupled to the class.</div>
</blockquote>
Are named operators a separated proposal? If yes, which is his added
value? How the named operators are called?<br>
<br>
I insists because I'm myself elaborating a proposal on named
operators as an alternative to C++/CLI Properties that seams to have
a completely different semantic. <br>
<br>
Vicente<br>
</div>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_78_11809992.1354368722278--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 08 Dec 2012 14:29:50 +0100
Raw View
This is a multi-part message in MIME format.
--------------060009080905000708030609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/12/12 14:32, grigorij1981@gmail.com a =E9crit :
> Named operators allow strict definition of /extended interface of a=20
> class./ That notion is useful not only for opaque aliases. I started=20
> thinking about it when I read ADL Control for C++=20
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html>.
> There was proposed to have an option to disable ADL for all=20
> non-operator names in the current scope except for those that are=20
> mentioned in a special using directive. In my opinion it was okay to=20
> disable ADL for most of the functions, however not for those that are=20
> connected to a class, and those may be usual functions not only=20
> operators.
> So, my initial idea was to have named operators proposal as addendum=20
> to the _N3490_=20
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html>.
I don't understand the rationale of why is needed to make a difference=20
for operators in N3490.
> If we stop here, then named operators are just specially declared free=20
> functions and are called as such:
> func(a,b);
> or
> operator func(a,b);
> But there was another idea - to open-up classes=20
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1742.pdf> in=20
> C++, that is to allow a limited form of partial classes of C#/VB=20
> - allow additional definitions of class that contain typedefs and=20
> members. It seems with using aliases we on a longer term will not need=20
> inner typedefs anyway, but adding new non-virtual functions to exiting=20
> class may be beneficial - with that we would have a sort of concept=20
> maps for non-generic code.
> That is possible if we allow named operators to be called like=20
> members. That is the second part of the proposal. There are unsolved=20
> problems however, it is tempting to have an ability to overload=20
> existing member-function with named operator, but member-function if=20
> it matches parameters should always be considered as better match than=20
> named operator, that leads to more complicated matching procedure...
> Anyway, with second part of the proposal named operators may be called=20
> as member functions:
> a.func(b);
>
IIUC your idea, the trouble I see with your named operators applied to=20
strong types is that the inherited interface is open and depends on=20
which files are you seen. The same applies to the open-up classes=20
proposal. I really think that we nedd a single point on which non-member=20
functions are added to the set of inherited functions.
Best,
Vicente
--=20
--------------060009080905000708030609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/12/12 14:32,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:grigorij1981@gma=
il.com">grigorij1981@gmail.com</a> a =E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:d6a0e87f-a125-4902-a3da-2bb9f3dc1750@isocpp.org"
type=3D"cite">
<div>Named operators allow=A0strict definition of <em>extended
interface of a class.</em> That notion is useful not only for
opaque aliases. I started thinking about it when I read <a
moz-do-not-send=3D"true"
href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490=
..html">
ADL Control for C++</a>. </div>
<div>There was proposed to have an option to disable ADL for all
non-operator names=A0in the current scope except for those that
are mentioned in a special using directive. In my opinion it was
okay to disable ADL for most of the functions, however not for
those that are connected to=A0a class, and those may be usual
functions not only operators.=A0</div>
<div>So, my initial idea was to have named operators proposal as
addendum to the <a moz-do-not-send=3D"true"
href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490=
..html"><u><font
color=3D"#0066cc">N3490</font></u></a>.</div>
</blockquote>
I don't understand the rationale of why is needed to make a
difference for operators in N3490.<br>
<blockquote
cite=3D"mid:d6a0e87f-a125-4902-a3da-2bb9f3dc1750@isocpp.org"
type=3D"cite">
<div>=A0</div>
<div>If we stop here, then named operators are just specially
declared free functions and are called as such:</div>
<div><font face=3D"courier new,monospace">func(a,b);</font></div>
<div>or</div>
<div><font face=3D"courier new,monospace">operator func(a,b);</font><=
/div>
<div>=A0</div>
<div>But there was another idea=A0- <a moz-do-not-send=3D"true"
href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1742=
..pdf">to
open-up classes</a> in C++, that is to allow a limited form of
partial classes of=A0C#/VB -=A0allow additional definitions of=A0cl=
ass
that contain typedefs and members. It seems with using aliases
we on a longer term will not need inner typedefs anyway, but
adding new non-virtual functions to exiting class may be
beneficial - with that we would have a sort of concept maps for
non-generic code.</div>
<div>=A0</div>
<div>That is possible if we allow named operators to be called
like members. That is the second part of the proposal. There are
unsolved problems however, it is tempting to have an ability to
overload existing member-function with named operator, but
member-function if it matches parameters should always be
considered as better match than named operator, that leads to
more complicated matching procedure...</div>
<div>Anyway, with second part of the proposal named operators may
be called as member functions:</div>
<div><font face=3D"courier new,monospace">a.func(b);</font></div>
=A0=A0
<br>
</blockquote>
IIUC your idea, the trouble I see with your named operators applied
to strong types is that the inherited interface is open and depends
on which files are you seen. The same applies to the open-up classes
proposal. I really think that we nedd a single point on which
non-member functions are added to the set of inherited functions.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------060009080905000708030609--
.
Author: grigorij1981@gmail.com
Date: Sun, 9 Dec 2012 04:17:14 -0800 (PST)
Raw View
------=_Part_38_29677004.1355055434254
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
=F3=D5=C2=CF=D4=C1, 8 =C7=D2=D5=C4=CE=D1 2012 =D2. 15:29:50 UTC+2 =CB=CF=D2=
=C9=D3=D4=D5=D7=C1=DE viboes =CE=C1=D0=C9=D3=C1=D7:
>
> I don't understand the rationale of why is needed to make a difference=
=20
> for operators in N3490.
>
The main reason for introducing ADL was to keep the expected behavior for=
=20
operators in the presence of namespaces. N3490 tries to get ADL right, that=
=20
is to turn it off for those functions that are never inteded to be found by=
=20
ADL, but keep it for functions that should be found by ADL (operators).=20
=20
> IIUC your idea, the trouble I see with your named operators applied to=20
> strong types is that the inherited interface is open and depends on which=
=20
> files are you seen. The same applies to the open-up classes proposal. I=
=20
> really think that we nedd a single point on which non-member functions ar=
e=20
> added to the set of inherited functions.
>
> Why do you consider this as a trouble? Opening-up classes, that is=20
allowing to add new member-functions to existing classes in non-intrusive=
=20
way was the whole point of N1742.=20
Regards,
Gregory
--=20
------=_Part_38_29677004.1355055434254
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<br><br>=F3=D5=C2=CF=D4=C1, 8 =C7=D2=D5=C4=CE=D1 2012 =D2. 15:29:50 UTC+2 =
=CB=CF=D2=C9=D3=D4=D5=D7=C1=DE viboes =CE=C1=D0=C9=D3=C1=D7:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>I don't understand the rationale of why is needed to make a
difference for operators in N3490.<br></div></div></blockquote><div><br=
></div><div>The main reason for introducing ADL was to keep the expected be=
havior for operators in the presence of namespaces. N3490 tries to get ADL =
right, that is to turn it off for those functions that are never inteded to=
be found by ADL, but keep it for functions that should be found by ADL (op=
erators). </div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
IIUC your idea, the trouble I see with your named operators applied
to strong types is that the inherited interface is open and depends
on which files are you seen. The same applies to the open-up classes
proposal. I really think that we nedd a single point on which
non-member functions are added to the set of inherited functions.<br><b=
r></div></blockquote><div>Why do you consider this as a trouble? Opening-up=
classes, that is allowing to add new member-functions to existing classes =
in non-intrusive way was the whole point of N1742. </div><div><br></di=
v><div>Regards,</div><div>Gregory</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_38_29677004.1355055434254--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 09 Dec 2012 14:48:27 +0100
Raw View
This is a multi-part message in MIME format.
--------------060408020907060807090107
Content-Type: text/plain; charset=KOI8-U; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/12/12 13:17, grigorij1981@gmail.com a e'crit :
>
>
> =F3=D5=C2=CF=D4=C1, 8 =C7=D2=D5=C4=CE=D1 2012 =D2. 15:29:50 UTC+2 =CB=CF=
=D2=C9=D3=D4=D5=D7=C1=DE viboes =CE=C1=D0=C9=D3=C1=D7:
>
> I don't understand the rationale of why is needed to make a
> difference for operators in N3490.
>
>
> The main reason for introducing ADL was to keep the expected behavior=20
> for operators in the presence of namespaces. N3490 tries to get ADL=20
> right, that is to turn it off for those functions that are never=20
> inteded to be found by ADL, but keep it for functions that should be=20
> found by ADL (operators).
>
I believe I understand it now.
>
> IIUC your idea, the trouble I see with your named operators
> applied to strong types is that the inherited interface is open
> and depends on which files are you seen. The same applies to the
> open-up classes proposal. I really think that we nedd a single
> point on which non-member functions are added to the set of
> inherited functions.
>
> Why do you consider this as a trouble? Opening-up classes, that is=20
> allowing to add new member-functions to existing classes in=20
> non-intrusive way was the whole point of N1742.
>
I understand the point of N1742. What I mean is that I'm not sure all=20
the new member-functions added to the underlying type (using N1742)=20
should be inherited by the strong type. Or are you suggesting that the=20
user should use the N1742 mechanism to extend the operations on the=20
Strong type?
In addition, the N1742 mechanism doesn't covers all the operations a=20
strongly type could inherit from, as it forces to change the call syntax=20
of the inherited function.
Best,
Vicente
--=20
--------------060408020907060807090107
Content-Type: text/html; charset=KOI8-U
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DKOI8-U" http-equiv=3D"Content-Typ=
e">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 09/12/12 13:17,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:grigorij1981@gma=
il.com">grigorij1981@gmail.com</a> a écrit=9A:<br>
</div>
<blockquote
cite=3D"mid:fe683121-64df-4435-b133-06257ded8e95@isocpp.org"
type=3D"cite"><br>
<br>
=F3=D5=C2=CF=D4=C1, 8 =C7=D2=D5=C4=CE=D1 2012 =D2. 15:29:50 UTC+2 =CB=
=CF=D2=C9=D3=D4=D5=D7=C1=DE viboes =CE=C1=D0=C9=D3=C1=D7:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>I don't understand the rationale of why is needed to make
a difference for operators in N3490.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The main reason for introducing ADL was to keep the expected
behavior for operators in the presence of namespaces. N3490
tries to get ADL right, that is to turn it off for those
functions that are never inteded to be found by ADL, but keep it
for functions that should be found by ADL (operators).=9A</div>
<div>=9A=9A <br>
</div>
</blockquote>
I believe I understand it now.<br>
<blockquote
cite=3D"mid:fe683121-64df-4435-b133-06257ded8e95@isocpp.org"
type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> IIUC your idea, the
trouble I see with your named operators applied to strong
types is that the inherited interface is open and depends on
which files are you seen. The same applies to the open-up
classes proposal. I really think that we nedd a single point
on which non-member functions are added to the set of
inherited functions.<br>
<br>
</div>
</blockquote>
<div>Why do you consider this as a trouble? Opening-up classes,
that is allowing to add new member-functions to existing classes
in non-intrusive way was the whole point of N1742.=9A</div>
<div><br>
</div>
</blockquote>
I understand the point of N1742. What I mean is that I'm not sure
all the new member-functions added to the underlying type (using
N1742) should be inherited by the strong type. Or are you suggesting
that the user should use the N1742 mechanism to extend the
operations on the Strong type?<br>
<br>
In addition, the N1742 mechanism doesn't covers all the operations a
strongly type could inherit from, as it forces to change the call
syntax of the inherited function.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------060408020907060807090107--
.
Author: grigorij1981@gmail.com
Date: Sun, 9 Dec 2012 07:31:53 -0800 (PST)
Raw View
------=_Part_151_5152358.1355067113368
Content-Type: text/plain; charset=ISO-8859-1
>
> I understand the point of N1742. What I mean is that I'm not sure all the
> new member-functions added to the underlying type (using N1742) should be
> inherited by the strong type. Or are you suggesting that the user should
> use the N1742 mechanism to extend the operations on the Strong type?
>
> In addition, the N1742 mechanism doesn't covers all the operations a
> strongly type could inherit from, as it forces to change the call syntax of
> the inherited function.
>
>
I do not propose mechanism used in N1742. I'm saying that in my view
classes should be more open than they are now in C++. And the existence of
N1742 suggests that I'm not alone :).
However, whatever mechanism we would have for extending existing classes
there's no reason not to apply this mechanism to opaque aliases.
If opaque aliases inherits all operations of aliased type, then it should
inherit those additional functions as well.
I understand your reservations though. If there's need to provide
restricted interface for alias compared to the interface of original type,
such implicit inheritance of all operations do not help.
IMHO if there's real need to have restricted interfaces for opaque aliases
then it should be addressed separately.
Regards,
Gregory
--
------=_Part_151_5152358.1355067113368
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000"><blockquote type=3D"cite"><div><br></div>
</blockquote>
I understand the point of N1742. What I mean is that I'm not sure
all the new member-functions added to the underlying type (using
N1742) should be inherited by the strong type. Or are you suggesting
that the user should use the N1742 mechanism to extend the
operations on the Strong type?<br>
<br>
In addition, the N1742 mechanism doesn't covers all the operations a
strongly type could inherit from, as it forces to change the call
syntax of the inherited function.<br><br></div></blockquote><div><br></=
div><div>I do not propose mechanism used in N1742. I'm saying that in my vi=
ew classes should be more open than they are now in C++. And the existence =
of N1742 suggests that I'm not alone :). <br></div><div>However, what=
ever mechanism we would have for extending existing classes there's no reas=
on not to apply this mechanism to opaque aliases. </div><div>If opaque=
aliases inherits all operations of aliased type, then it should inherit th=
ose additional functions as well. </div><div><br></div><div>I understa=
nd your reservations though. If there's need to provide restricted interfac=
e for alias compared to the interface of original type, such implicit inher=
itance of all operations do not help. </div><div>IMHO if there's real =
need to have restricted interfaces for opaque aliases then it should be add=
ressed separately. </div><div><br></div><div>Regards,</div><div>Gregor=
y</div><div><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_151_5152358.1355067113368--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 12 Dec 2012 09:07:40 -0800 (PST)
Raw View
------=_Part_2618_12595131.1355332060030
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 9 grudnia 2012 13:17:14 UTC+1 u=C5=BCytkownik=20
grigor...@gmail.com napisa=C5=82:
>
>
>
> =D0=A1=D1=83=D0=B1=D0=BE=D1=82=D0=B0, 8 =D0=B3=D1=80=D1=83=D0=B4=D0=BD=D1=
=8F 2012 =D1=80. 15:29:50 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=D1=83=
=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:
>>
>> I don't understand the rationale of why is needed to make a difference=
=20
>> for operators in N3490.
>>
>
> The main reason for introducing ADL was to keep the expected behavior for=
=20
> operators in the presence of namespaces. N3490 tries to get ADL right, th=
at=20
> is to turn it off for those functions that are never inteded to be found =
by=20
> ADL, but keep it for functions that should be found by ADL (operators).=
=20
>
Just one clarification here. Perhaps a bit off topic. While operators might=
=20
have been the primary motivation for ADL, non-operator functions also now=
=20
depend on it. The example I have in mind is swap(), which in a way has=20
something of an operator.
Regards,
&rzej
--=20
------=_Part_2618_12595131.1355332060030
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu niedziela, 9 grudnia 2012 13:17:14 UTC+1 u=C5=BCytkownik gri=
gor...@gmail.com napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<br><br>=D0=A1=D1=83=D0=B1=D0=BE=D1=82=D0=B0, 8 =D0=B3=D1=80=D1=83=D0=B4=D0=
=BD=D1=8F 2012 =D1=80. 15:29:50 UTC+2 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=
=D1=83=D0=B2=D0=B0=D1=87 viboes =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>I don't understand the rationale of why is needed to make a
difference for operators in N3490.<br></div></div></blockquote><div><br=
></div><div>The main reason for introducing ADL was to keep the expected be=
havior for operators in the presence of namespaces. N3490 tries to get ADL =
right, that is to turn it off for those functions that are never inteded to=
be found by ADL, but keep it for functions that should be found by ADL (op=
erators). </div></blockquote><div><br>Just one clarification here. Per=
haps a bit off topic. While operators might have been the primary motivatio=
n for ADL, non-operator functions also now depend on it. The example I have=
in mind is swap(), which in a way has something of an operator.<br><br>Reg=
ards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_2618_12595131.1355332060030--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 12 Dec 2012 11:52:39 -0600
Raw View
--f46d0401689b57b8a404d0ab7950
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 12 December 2012 11:07, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wr=
ote:
>
> Just one clarification here. Perhaps a bit off topic. While operators
> might have been the primary motivation for ADL, non-operator functions al=
so
> now depend on it. The example I have in mind is swap(), which in a way ha=
s
> something of an operator.
>
Also begin and end for range-based for.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
--f46d0401689b57b8a404d0ab7950
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 12 December 2012 11:07, Andrzej Krzemie=C5=84ski <span dir=3D"ltr"><<=
a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</=
a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br><div>Just one clarification here. Perhaps a bit off topic. While operat=
ors might have been the primary motivation for ADL, non-operator functions =
also now depend on it. The example I have in mind is swap(), which in a way=
has something of an operator.<br clear=3D"all">
</div></blockquote><div><br>Also begin and end for range-based for. <br></d=
iv></div><br>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>>=C2=A0 (847) 691-1404<br>
<p></p>
-- <br />
<br />
<br />
<br />
--f46d0401689b57b8a404d0ab7950--
.
Author: 3dw4rd@verizon.net
Date: Tue, 19 Mar 2013 11:32:00 -0700 (PDT)
Raw View
------=_Part_1815_2810953.1363717920937
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 19, 2012 8:16:12 PM UTC-5, Vicente J. Botet Escriba
wrote:
>
> Hi,
>
> there is an old proposal [1] from Walter E. Brown about opaque types that
> I have found quite interesting.
>
> One of the motivating examples is the ability to overload on these new
> types
>
>
> typedef *public* double X, Y, Z; // Cartesian 3D coordinate types
> typedef *public* double Rho, Theta, Phi; // polar 3D coordinate types
> class PhysicsVector
> {
> public:
> PhysicsVector(X, Y, Z);
> PhysicsVector(Rho, Theta, Phi);
> ...
> }; // PhysicsVector
>
> Could some one tell me if the committee was interested on this proposal?
> Is there a plant to resurrect it?
>
> Alisdair Meredith showed in [2] that forward constructor could help on
> this but that there are some issues that are not addressed by this
> construction.
>
> struct MyType : std::string {
> using string::string;
> };
>
>
> I'm wondering if the syntax couldn't be adapted so that the new type could
> contain more function members.
>
> class Address *using* *public* std::string {
> public:
>
> };
>
> Note that there is no need to add forward constructors as the using
> keyword would intend already to have the same interface as the underlying
> type.
>
> If Address should not be seen implicitly as a std::string the using
> should be private
>
> class Address *using* *private* std::string {
> // possibility to add new member functions
> };
>
>
> Note that builtin types could also be used as underlying types as it is
> the case of the Opaque typedef proposal.
>
> class Temperature *using* double {
> // possibility to add new member functions
> };
>
>
> By default the new type has the same operations than the underlying type.
> Restricting the interface of the underlying type should also be possible if
> the operation is decorated with delete.
>
> struct Address *using* std::string {
> std::size_t length() const = delete;
> };
>
>
> One question is whether the new class can add new data members. I don't think tis is a good idea the new type and the underlying type should have the same size.An alternative could be to use a new keyword (e.g. alias) so that this constraint is clearer.
>
>
> *alias* Address *using* std::string {
> std::size_t length() const = delete;
> };
>
> Is there some interest?
>
> Vicente
>
> [1] *N1891: Progress toward Opaque Typedefs for C++0X*<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf>
>
> [2] *N2141: Strong Typedefs in C++09(Revisited)*<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2141.html>
>
I have long wondered if allowing classes to derive from basic types would
be helpful:
class Energy : public double
{
// possibly override operators, add user-defined literals, etc.
// Otherwise have all arithmetic operators and I/O because of public
derivation from double.
};
The class Energy would not be implicitly convertible to double. It might
get by default an explicit operator to double, I'm not sure. To my eye
this syntax is easy to learn because it mimics regular class definition.
OTOH, I'm not sure one should be allowed to add members and what would
happen if you did. I guess all the inherited operators would only touch
the 'double' part - similar to what happens in class hierarchies today.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1815_2810953.1363717920937
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, November 19, 2012 8:16:12 PM UTC-5, Vicente J. Botet Esc=
riba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
there is an old proposal [1] from Walter E. Brown about opaque types
that I have found quite interesting. <br>
<br>
One of the motivating examples is the ability to overload on these
new types<br>
<br>
=20
=20
<br>
typedef <b>public</b> double X, Y, Z; // Cartesian 3D coordinate
types<br>
typedef <b>public</b> double Rho, Theta, Phi; // polar 3D
coordinate types<br>
class PhysicsVector<br>
{<br>
public:<br>
PhysicsVector(X, Y, Z);<br>
PhysicsVector(Rho, Theta, Phi);<br>
...<br>
}; // PhysicsVector<br>
<br>
Could some one tell me if the committee was interested on this
proposal? Is there a plant to resurrect it?<br>
<br>
Alisdair Meredith showed in [2] that forward constructor could help
on this but that there are some issues that are not addressed by
this construction.<br>
<br>
=20
<pre><code>struct MyType : std::string {
using string::string;
};</code></pre>
<br>
I'm wondering if the syntax couldn't be adapted so that the new type
could contain more function members.<br>
<br>
<pre><code>class Address <b>using</b> <b>public</b> std::string {
public:
=20
};</code></pre>
Note that there is no need to add forward constructors as the using
keyword would intend already to have the same interface as the
underlying type. <br>
<br>
If <code>Address </code>should not be seen implicitly as a
std::string the using should be private<br>
<br>
<pre><code>class Address <b>using</b> <b>private</b> std::string {
// possibility to add new member functions
};</code></pre>
<br>
Note that builtin types could also be used as underlying types as it
is the case of the Opaque typedef proposal.<br>
<br>
<pre><code>class Temperature <b>using</b> double {
// possibility to add new member functions
};</code></pre>
<br>
By default the new type has the same operations than the underlying
type. Restricting the interface of the underlying type should also
be possible if the operation is decorated with delete.<br>
<br>
<pre><code>struct </code><code><code>Address</code> <b>using</b> std::s=
tring {
std::size_t length() const =3D delete;
};
</code></pre>
<pre><code>One question is whether the new class can add new data membe=
rs. I don't think tis is a good idea the new type and the underlying type s=
hould have the same size.</code>
<code></code>
<code>An alternative could be to use a new keyword (e.g. alias) so that thi=
s constraint is clearer.</code>
<code></code></pre>
<code><br>
</code><code><b>alias</b> </code><code><code>Address</code> <b>using</b=
>
std::string {<br>
std::size_t length() const =3D delete;<br>
};<br>
</code>
<br>
Is there some interest?<br>
<br>
Vicente<br>
<br>
[1]
=20
<span><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
5/n1891.pdf" target=3D"_blank"><span><b>N1891: Progress toward
Opaque Typedefs for C++0X</b></span></a><br>
<br>
</span>[2]
=20
<span><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
6/n2141.html" target=3D"_blank"><span><b>N2141: Strong Typedefs
in C++09(Revisited)</b></span></a></span><span><br></span></div=
></blockquote><div><br><br>I have long wondered if allowing classes to deri=
ve from basic types would be helpful:<br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Energy</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// possibly override operators, add user-d=
efined literals, etc.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// Otherwise have all</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify"> arithmetic operators and I/O because of public der=
ivation from double.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>The class Energy would not be implicitly conv=
ertible to double. It might get by default an explicit operator to do=
uble, I'm not sure. To my eye this syntax is easy to learn because it=
mimics regular class definition. OTOH, I'm not sure one should be al=
lowed to add members and what would happen if you did. I guess all th=
e inherited operators would only touch the 'double' part - similar to what =
happens in class hierarchies today.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1815_2810953.1363717920937--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 20 Mar 2013 13:50:16 -0700
Raw View
On 3/19/13, 3dw4rd@verizon.net <3dw4rd@verizon.net> wrote:
> I have long wondered if allowing classes to derive from basic
> types would be helpful:
>
> class Energy : public double
> {
> // possibly override operators, add user-defined literals, etc.
> // Otherwise have all arithmetic operators and I/O because of
> // public derivation from double.
> };
>
> The class Energy would not be implicitly convertible to double.
> It might get by default an explicit operator to double, I'm
> not sure. To my eye this syntax is easy to learn because it
> mimics regular class definition. OTOH, I'm not sure one should be
> allowed to add members and what would happen if you did. I guess
> all the inherited operators would only touch the 'double' part -
> similar to what happens in class hierarchies today.
The normal semantics of public inheritance would make conversion
from Energy& to double& pretty strongly available. I don't think
we should change that.
For private inheritance, we would need to explicitly reintroduce
the operators, perhaps with =default. I don't think this extra
work is necessarily a bad thing, because Energy*Energy is not Energy.
If the intent is to create 'units', then I think we are doomed to
fail with this approach. We need to track value/representation
separately from the units.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 20 Mar 2013 16:55:06 -0400
Raw View
On Wed, Mar 20, 2013 at 4:50 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>
> The normal semantics of public inheritance would make conversion
> from Energy& to double& pretty strongly available. I don't think
> we should change that.
definitely agreed. I was about to say the same thing.
>
> For private inheritance, we would need to explicitly reintroduce
> the operators, perhaps with =default.
wouldn't it be via 'using', like you do normally for pulling base
functions into derived space?
I guess the syntax might be:
using double::operator*;
> I don't think this extra
> work is necessarily a bad thing, because Energy*Energy is not Energy.
>
> If the intent is to create 'units', then I think we are doomed to
> fail with this approach. We need to track value/representation
> separately from the units.
>
> --
> Lawrence Crowl
>
> --
>
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 20 Mar 2013 16:52:07 -0500
Raw View
--047d7bdc0b2421723d04d8623e8f
Content-Type: text/plain; charset=ISO-8859-1
On 20 March 2013 15:55, Tony V E <tvaneerd@gmail.com> wrote:
> > For private inheritance, we would need to explicitly reintroduce
> > the operators, perhaps with =default.
>
> wouldn't it be via 'using', like you do normally for pulling base
> functions into derived space?
> I guess the syntax might be:
>
> using double::operator*;
>
Wouldn't that be for multiplying Energy with doubles, not multiplying
Energy with Energy?
> > I don't think this extra
> > work is necessarily a bad thing, because Energy*Energy is not Energy.
>
It depends. The problem is, the tedious extra work (such as for '+', where
Energy+Energy is Energy) keeps people from writing little types and instead
just falling back on using already existing "rich" types (fundamental
types, std::string, etc.) everywhere.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7bdc0b2421723d04d8623e8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 20 March 2013 15:55, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tv=
aneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wrote=
:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">> For private inheritance, we would need to explicitly=
reintroduce</div><div class=3D"im">
> the operators, perhaps with =3Ddefault.<br>
<br>
</div>wouldn't it be via 'using', like you do normally for pull=
ing base<br>
functions into derived space?<br>
I guess the syntax might be:<br>
<br>
using double::operator*;<br></blockquote><div><br></div><div>Wouldn't t=
hat be for multiplying Energy with doubles, not multiplying Energy with Ene=
rgy?</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im HOEnZb">> I don't think this extra<br>
> work is necessarily a bad thing, because Energy*Energy is not Energy.<=
br></div></blockquote><div><br></div><div>It depends. =A0The problem is, th=
e tedious extra work (such as for '+', where Energy+Energy is Energ=
y) keeps people from writing little types and instead just falling back on =
using already existing "rich" types (fundamental types, std::stri=
ng, etc.) everywhere.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bdc0b2421723d04d8623e8f--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 20 Mar 2013 18:01:05 -0400
Raw View
On Wed, Mar 20, 2013 at 5:52 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 20 March 2013 15:55, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> > For private inheritance, we would need to explicitly reintroduce
>> > the operators, perhaps with =default.
>>
>> wouldn't it be via 'using', like you do normally for pulling base
>> functions into derived space?
>> I guess the syntax might be:
>>
>> using double::operator*;
>
>
> Wouldn't that be for multiplying Energy with doubles, not multiplying Energy
> with Energy?
>
right. Good point.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.