Topic: Any plans for strong typedef
Author: nx02columbia@gmail.com
Date: Fri, 4 Jan 2013 03:22:36 -0800 (PST)
Raw View
------=_Part_24_2833777.1357298556173
Content-Type: text/plain; charset=ISO-8859-1
Hi, just a quick Q:
Any plans to add to core lang strong typedef(aka it creates new type not an
alias of a existing one).
Existing library implementation is BOOST_STRONG_TYPEDEF but it only works
for simple(sorry, IDK exact terminology, maybe I should say fundamental ? )
types.
more can be seen here:
http://www.boost.org/doc/libs/1_52_0/libs/serialization/doc/strong_typedef.html
I know std ppl dont like new keywords so maybe you could use something like:
explicit typedef
--
------=_Part_24_2833777.1357298556173
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, just a quick Q:<br>Any plans to add to core lang strong typedef(aka it =
creates new type not an alias of a existing one). <br><br>Existing library =
implementation is BOOST_STRONG_TYPEDEF but it only works for simple(sorry, =
IDK exact terminology, maybe I should say fundamental ? ) types.<br><br>mor=
e can be seen here:<br>http://www.boost.org/doc/libs/1_52_0/libs/serializat=
ion/doc/strong_typedef.html<br><br>I know std ppl dont like new keywords so=
maybe you could use something like:<br><br>explicit typedef<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_24_2833777.1357298556173--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 4 Jan 2013 13:04:22 +0100
Raw View
--e89a8f839f6fb2b65a04d275474e
Content-Type: text/plain; charset=ISO-8859-1
There have been a big discussion about this, with a paper, the feature
being called "opaque typedef".
See
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/-u6e-rohWXM
Joel Lamotte
--
--e89a8f839f6fb2b65a04d275474e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There have been a big discussion about this, with a paper,=
the feature being called "opaque typedef".<div><br></div><div>Se=
e <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-propo=
sals/-u6e-rohWXM">https://groups.google.com/a/isocpp.org/forum/#!topic/std-=
proposals/-u6e-rohWXM</a><br>
</div><div><br></div><div style>Joel Lamotte</div><div style><br></div></di=
v>
<p></p>
-- <br />
<br />
<br />
<br />
--e89a8f839f6fb2b65a04d275474e--
.
Author: nx02columbia@gmail.com
Date: Fri, 4 Jan 2013 04:55:27 -0800 (PST)
Raw View
------=_Part_982_11593048.1357304127517
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
seems inconclusive. :D
either way tnx for the link. I hope it will end up in C++17 in some form.=
=20
On Friday, January 4, 2013 2:04:22 PM UTC+2, Klaim - Jo=EBl Lamotte wrote:
>
> There have been a big discussion about this, with a paper, the feature=20
> being called "opaque typedef".
>
> See=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/-u6e-r=
ohWXM
>
> Joel Lamotte
>
>
--=20
------=_Part_982_11593048.1357304127517
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
seems inconclusive. :D<br>either way tnx for the link. I hope it will end u=
p in C++17 in some form. <br><br>On Friday, January 4, 2013 2:04:22 PM UTC+=
2, Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">There have been a big discussion about this, with a pape=
r, the feature being called "opaque typedef".<div><br></div><div>See <a hre=
f=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/-u6=
e-rohWXM" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/for=
um/#!topic/std-<wbr>proposals/-u6e-rohWXM</a><br>
</div><div><br></div><div>Joel Lamotte</div><div><br></div></div>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_982_11593048.1357304127517--
.
Author: robertmacleranramey@gmail.com
Date: Tue, 8 Jan 2013 09:20:22 -0800 (PST)
Raw View
------=_Part_421_21573229.1357665622841
Content-Type: text/plain; charset=ISO-8859-1
FWIW I'm the author of BOOST_STRONG_TYPEDEF.
I made this small component in order to make numeric things like integers
have different types for template meta programming but still behave like
integers by inheriting the behavior of integers - arithmetic operators,
implicit conversions etc.
It seemed like a good idea at the time but I eventually came to regret it.
Not there was anything intrinsically wrong with the idea. But
inheritance/conversion of integers create subsequent problems that implicit
conversions and and C++ arithmetic do. So I eventually replaced usage of
BOOST_STRONG_TYPEDEF with the idiom:
class class_version {
unsigned int m_i;
public:
bool operator==(const class_version & rhs) const;
// etc.
};
This let me control the usage and trap future errors. Soooo - I'm really
wondering whether adding something more to the language is really a great
idea.
Robert Ramey
--
------=_Part_421_21573229.1357665622841
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
FWIW I'm the author of BOOST_STRONG_TYPEDEF.<br><br>I made this small compo=
nent in order to make numeric things like integers have different types for=
template meta programming but still behave like integers by inheriting the=
behavior of integers - arithmetic operators, implicit conversions etc.<br>=
<br>It seemed like a good idea at the time but I eventually came to regret =
it. Not there was anything intrinsically wrong with the idea. B=
ut inheritance/conversion of integers create subsequent problems that impli=
cit conversions and and C++ arithmetic do. So I eventually replaced u=
sage of BOOST_STRONG_TYPEDEF with the idiom:<br><br>class class_version {<b=
r> unsigned int m_i;<br>public:<br> bool oper=
ator=3D=3D(const class_version & rhs) const;<br> // etc.<br>};<br=
><br>This let me control the usage and trap future errors. Soooo - I'=
m really wondering whether adding something more to the language is really =
a great idea.<br><br>Robert Ramey<br><br><br><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_421_21573229.1357665622841--
.
Author: nx02columbia@gmail.com
Date: Tue, 8 Jan 2013 09:38:43 -0800 (PST)
Raw View
------=_Part_1780_10580454.1357666723494
Content-Type: text/plain; charset=ISO-8859-1
Hi, I found your work really helpful when I have functions taking bunch of
arguments and some of them are same type...
for example latitude and longitude... it is real pain to remember to pass
them in correct order, and bothering with class or std::pair-ing them also
feels like overkill.
So if you can I would really like if you could provide some of the real
world examples that made you regret making BOOST_STRONG_TYPEDEF
On Tuesday, January 8, 2013 7:20:22 PM UTC+2, robertmac...@gmail.com wrote:
>
> FWIW I'm the author of BOOST_STRONG_TYPEDEF.
>
> I made this small component in order to make numeric things like integers
> have different types for template meta programming but still behave like
> integers by inheriting the behavior of integers - arithmetic operators,
> implicit conversions etc.
>
> It seemed like a good idea at the time but I eventually came to regret
> it. Not there was anything intrinsically wrong with the idea. But
> inheritance/conversion of integers create subsequent problems that implicit
> conversions and and C++ arithmetic do. So I eventually replaced usage of
> BOOST_STRONG_TYPEDEF with the idiom:
>
> class class_version {
> unsigned int m_i;
> public:
> bool operator==(const class_version & rhs) const;
> // etc.
> };
>
> This let me control the usage and trap future errors. Soooo - I'm really
> wondering whether adding something more to the language is really a great
> idea.
>
> Robert Ramey
>
>
>
>
--
------=_Part_1780_10580454.1357666723494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, I found your work really helpful when I have functions taking bunch of =
arguments and some of them are same type... <br>for example latitude and lo=
ngitude... it is real pain to remember to pass them in correct order, and b=
othering with class or std::pair-ing them also feels like overkill.<br>So i=
f you can I would really like if you could provide some of the real world e=
xamples that made you regret making BOOST_STRONG_TYPEDEF<br><br><br><br>On =
Tuesday, January 8, 2013 7:20:22 PM UTC+2, robertmac...@gmail.com wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">FWIW I'm the author of BOOST_STRO=
NG_TYPEDEF.<br><br>I made this small component in order to make numeric thi=
ngs like integers have different types for template meta programming but st=
ill behave like integers by inheriting the behavior of integers - arithmeti=
c operators, implicit conversions etc.<br><br>It seemed like a good idea at=
the time but I eventually came to regret it. Not there was anything =
intrinsically wrong with the idea. But inheritance/conversion of inte=
gers create subsequent problems that implicit conversions and and C++ arith=
metic do. So I eventually replaced usage of BOOST_STRONG_TYPEDEF with=
the idiom:<br><br>class class_version {<br> unsigned int=
m_i;<br>public:<br> bool operator=3D=3D(const class_version &a=
mp; rhs) const;<br> // etc.<br>};<br><br>This let me control the usag=
e and trap future errors. Soooo - I'm really wondering whether adding=
something more to the language is really a great idea.<br><br>Robert Ramey=
<br><br><br><br></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1780_10580454.1357666723494--
.
Author: Chris Bush <chrbsh@gmail.com>
Date: Tue, 8 Jan 2013 13:17:29 -0500
Raw View
On Fri, Jan 4, 2013 at 6:22 AM, <nx02columbia@gmail.com> wrote:
> Hi, just a quick Q:
> Any plans to add to core lang strong typedef(aka it creates new type not an
> alias of a existing one).
>
> Existing library implementation is BOOST_STRONG_TYPEDEF but it only works
> for simple(sorry, IDK exact terminology, maybe I should say fundamental ? )
> types.
>
> more can be seen here:
> http://www.boost.org/doc/libs/1_52_0/libs/serialization/doc/strong_typedef.html
>
> I know std ppl dont like new keywords so maybe you could use something like:
>
> explicit typedef
>
I have also been interested in this issue, partially inspired by a
segment of Bjarne Stroustrup's "Going Native" keynote in which he
discusses the programming error at the root of a certain Mars probe's
failure - calculations in one unit system were passed to a function
that expected calculations in another. I think we could all benefit
from a simple way to make differentiated PODs (and, I guess, more
complex types). Now if only coming up with a 'simple solution' were...
well, you know.
One immediate solution I have used was to create a template
`hard_type` which is simply a wrapper that re-implements the operators
exclusively with matching type. In addition to the type it is supposed
to replicate, it takes an number as template argument, which is to be
manually incremented for each differentiation. The C++11 `using` is
used to define the types:
using feet_per_second = hard_type<double,0>;
using meters_per_second = hard_type<double,1>;
This has worked for my little purposes but I can see how it would
quickly become problematic if used in library headers: to boot,
protection would be lost if multiple libraries define a
hard_type<double,0>. Plus who wants to manually keep track of which
number have been used even if all using calls are in the same place.
An internal hash of the new type name might do the trick, but that
would be up to the compiler writer.
Again, the whole purpose of this is to have the compiler reject
mismatched hard types.
Like you, I also had the thought that the keyword `explicit` might be
a good candidate for letting the compiler know that my_type is a T
that is not to be crossed with another T. Something like
using my_type = explicit int;
But whether that's feasible or even practical is beyond my experience.
All of this to say +1 for strong typedefs.
CB
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 8 Jan 2013 13:21:55 -0600
Raw View
--0015175cfccc3692b304d2cbf471
Content-Type: text/plain; charset=ISO-8859-1
On 8 January 2013 12:17, Chris Bush <chrbsh@gmail.com> wrote:
> I think we could all benefit
> from a simple way to make differentiated PODs (and, I guess, more
> complex types).
I'm not sure I'd try anything more than fundamental types.
> One immediate solution I have used was to create a template
> `hard_type` which is simply a wrapper that re-implements the operators
> exclusively with matching type.
Does it do so using Boost.Operator Type Traits <
http://www.boost.org/doc/libs/1_52_0/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html>?
That would be interesting...
> In addition to the type it is supposed
> to replicate, it takes an number as template argument, which is to be
> manually incremented for each differentiation.
You would be better off using a type tag; that way, you don't need a
centralized place to manage the count.
The hard question is: what operations are allowed across types and what
aren't? For instance, is it possible to legally convert a my_type* into an
int*? If you move to user defined types, that question becomes nearly
impossible to answer.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--0015175cfccc3692b304d2cbf471
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 8 January 2013 12:17, Chris Bush <span dir=3D"ltr"><<a href=3D"mailto=
:chrbsh@gmail.com" target=3D"_blank">chrbsh@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">I think we could all benefit</div><=
/div>
from a simple way to make differentiated PODs (and, I guess, more<br>
complex types).</blockquote><div><br></div><div>I'm not sure I'd tr=
y anything more than fundamental types.</div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
One immediate solution I have used was to create a template<br>
`hard_type` which is simply a wrapper that re-implements the operators<br>
exclusively with matching type. </blockquote><div><br></div><div>Does it do=
so using Boost.Operator Type Traits <<a href=3D"http://www.boost.org/do=
c/libs/1_52_0/libs/type_traits/doc/html/boost_typetraits/category/value_tra=
its/operators.html">http://www.boost.org/doc/libs/1_52_0/libs/type_traits/d=
oc/html/boost_typetraits/category/value_traits/operators.html</a>>? =A0T=
hat would be interesting...</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">In addition to the type it is =
supposed<br>
to replicate, it takes an number as template argument, which is to be<br>
manually incremented for each differentiation.</blockquote><div><br></div><=
div>You would be better off using a type tag; that way, you don't need =
a centralized place to manage the count.</div><div><br></div><div><br>
</div><div>The hard question is: what operations are allowed across types a=
nd what aren't? =A0For instance, is it possible to legally convert a my=
_type* into an int*? =A0If you move to user defined types, that question be=
comes nearly impossible to answer.</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 />
<br />
--0015175cfccc3692b304d2cbf471--
.
Author: s.hesp@oisyn.nl
Date: Tue, 8 Jan 2013 14:54:05 -0800 (PST)
Raw View
------=_Part_502_31112105.1357685646042
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 8, 2013 7:17:29 PM UTC+1, C Bush wrote:
>
> In addition to the type it is supposed
> to replicate, it takes an number as template argument, which is to be
> manually incremented for each differentiation. The C++11 `using` is
> used to define the types:
>
> using feet_per_second = hard_type<double,0>;
> using meters_per_second = hard_type<double,1>;
>
> This has worked for my little purposes but I can see how it would
> quickly become problematic if used in library headers: to boot,
> protection would be lost if multiple libraries define a
> hard_type<double,0>. Plus who wants to manually keep track of which
> number have been used even if all using calls are in the same place.
But that's easily solvable. Drop the non-type template parameter and add a
type parameter.
using feet_per_second = hard_type<double, struct feet_per_second_tag>;
using meters_per_second = hard_type<double, struct meters_per_second_tag>;
A workable solution, but suffice to say I'd prefer a language feature as
well
- Sylvester
--
------=_Part_502_31112105.1357685646042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, January 8, 2013 7:17:29 PM UTC+1, C Bush wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">In addition to the type it is supposed
<br>to replicate, it takes an number as template argument, which is to be
<br>manually incremented for each differentiation. The C++11 `using` is
<br>used to define the types:
<br>
<br> using feet_per_second =3D hard_type<double,0>;
<br> using meters_per_second =3D hard_type<double,1>;
<br>
<br>This has worked for my little purposes but I can see how it would
<br>quickly become problematic if used in library headers: to boot,
<br>protection would be lost if multiple libraries define a
<br>hard_type<double,0>. Plus who wants to manually keep track of whi=
ch
<br>number have been used even if all using calls are in the same place.</b=
lockquote><div><br></div><div>But that's easily solvable. Drop the non-type=
template parameter and add a type parameter.</div><div><br></div><div>usin=
g feet_per_second =3D hard_type<double, struct feet_per_second_tag>;<=
/div><div>using meters_per_second =3D hard_type<double, struct meters_pe=
r_second_tag>;</div><div><br></div><div>A workable solution, but suffice=
to say I'd prefer a language feature as well</div><div><br></div><div>- Sy=
lvester</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_502_31112105.1357685646042--
.
Author: Chris Bush <chrbsh@gmail.com>
Date: Fri, 11 Jan 2013 01:14:27 -0500
Raw View
On Tue, Jan 8, 2013 at 2:21 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> You would be better off using a type tag; that way, you don't need a
> centralized place to manage the count.
+
On Tue, Jan 8, 2013 at 5:54 PM, <s.hesp@oisyn.nl> wrote:
>
> But that's easily solvable. Drop the non-type template parameter and add a
> type parameter.
>
> using feet_per_second = hard_type<double, struct feet_per_second_tag>;
> using meters_per_second = hard_type<double, struct meters_per_second_tag>;
>
> A workable solution, but suffice to say I'd prefer a language feature as
> well
>
> - Sylvester
>
Type tags. Thanks for that tip!
On Tue, Jan 8, 2013 at 2:21 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> One immediate solution I have used was to create a template
>> `hard_type` which is simply a wrapper that re-implements the operators
>> exclusively with matching type.
>
>
> Does it do so using Boost.Operator Type Traits
> <http://www.boost.org/doc/libs/1_52_0/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html>?
> That would be interesting...
Regrettably no.
> The hard question is: what operations are allowed across types and what
> aren't? For instance, is it possible to legally convert a my_type* into an
> int*? If you move to user defined types, that question becomes nearly
> impossible to answer.
Let's focus on simple types, then.
I would suggest that this pointer conversion, without a cast, should
be impossible because my_type is not a derived type (which would allow
for such a conversion due to polymorphism) but is rather meant to be a
distinct type. As you can't convert e.g. a short* to an int* without a
cast, neither should you be able to convert my_type* to int* even
though my_type is based on int. But this distinction can be cast away
so as not to hinder or limit the conscientious programmer.
People using this hypothetical feature will expect their functions
that specifically request a my_type* to guarantee that no other
int-type pointer makes its way in unless someone *really* went out of
their way to mess it up.
Thoughts?
CB
--
.
Author: robertmacleranramey@gmail.com
Date: Fri, 11 Jan 2013 09:38:14 -0800 (PST)
Raw View
------=_Part_14_17145627.1357925894786
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 8, 2013 9:38:43 AM UTC-8, nx02co...@gmail.com wrote:
>
> Hi, I found your work really helpful when I have functions taking bunch of
> arguments and some of them are same type...
> for example latitude and longitude... it is real pain to remember to pass
> them in correct order, and bothering with class or std::pair-ing them also
> feels like overkill.
> So if you can I would really like if you could provide some of the real
> world examples that made you regret making BOOST_STRONG_TYPEDEF
>
>
Regret is too strong. It was convenient at the time but I later found that
it had some downsides so I backed it out. Note that this occurred in a
number of places in the serialization library. That is, one has to "get it
done" and which is a huge job. Later when more time is available, one can
go back and fix bugs/complaints by re-implementing some things.
Here's the case with BOOST_STRONG_TYPEDEF. I have a "special" kind of
integer. For example a class version number. This is a number well
modeled by an integer. But I want to maintain it as a separate type so
that overload resolution and specialization can depend on the type. I
needed this in a number of instances and so rather than re-implementing it
every time I make BOOST_STRONG_TYPEDEF. This leveraged on another boost
library which implemented all the arithmetic operations so I could derive
from this. So it was only a few lines of macro code and imported all the
"numeric" capabilities via inheritance. Just perfect.
But in time I came to appreciate that the things I was using it for weren't
really normal numbers. It makes sense to increment a class version number
- but it doesn't make any sense to multiply two class version numbers.
Does it make sense to automatically convert a class version number to an
unsigned int? Hmmmm - it seemed like a good idea a the time, but it
introduced some very sticky errors in the binary_?archive. So I realized
that what I really needed was more specific control over the numeric
operations rather than just inheritiing the whole set for integers. So I
evolved away from BOOST_STRONG_TYPEDEF.
No question that BOOST_STRONG_TYPEDEF has value and is useful. But it's
also not the whole story. It's more of a stepping stone along the way to
more perfect code. Most programs stop evolving before it gets to the point
where one want's to go back and make this more explicit. The serialization
library is somewhat different because under pressure of users to make it
more bug free and bullet proof, I was motivated to evolve/enhance things
longer than one might so for other types of projects.
Robert Ramey
--
------=_Part_14_17145627.1357925894786
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, January 8, 2013 9:38:43 AM UTC-8, nx02co...@gmail.com w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Hi, I found your work rea=
lly helpful when I have functions taking bunch of arguments and some of the=
m are same type... <br>for example latitude and longitude... it is real pai=
n to remember to pass them in correct order, and bothering with class or st=
d::pair-ing them also feels like overkill.<br>So if you can I would really =
like if you could provide some of the real world examples that made you reg=
ret making BOOST_STRONG_TYPEDEF<br><br></blockquote><div><br>Regret is too =
strong. It was convenient at the time but I later found that it had s=
ome downsides so I backed it out. Note that this occurred in a number=
of places in the serialization library. That is, one has to "get it =
done" and which is a huge job. Later when more time is available, one=
can go back and fix bugs/complaints by re-implementing some things.<br><br=
>Here's the case with BOOST_STRONG_TYPEDEF. I have a "special" =
kind of integer. For example a class version number. This is a =
number well modeled by an integer. But I want to maintain it as a sep=
arate type so that overload resolution and specialization can depend on the=
type. I needed this in a number of instances and so rather than re-impleme=
nting it every time I make BOOST_STRONG_TYPEDEF. This leveraged on an=
other boost library which implemented all the arithmetic operations so I co=
uld derive from this. So it was only a few lines of macro code and im=
ported all the "numeric" capabilities via inheritance. Just perfect.<=
br><br>But in time I came to appreciate that the things I was using it for =
weren't really normal numbers. It makes sense to increment a class ve=
rsion number - but it doesn't make any sense to multiply two class version =
numbers. Does it make sense to automatically convert a class version =
number to an unsigned int? Hmmmm - it seemed like a good idea a the t=
ime, but it introduced some very sticky errors in the binary_?archive. =
; So I realized that what I really needed was more specific control over th=
e numeric operations rather than just inheritiing the whole set for integer=
s. So I evolved away from BOOST_STRONG_TYPEDEF.<br><br>No question th=
at BOOST_STRONG_TYPEDEF has value and is useful. But it's also not th=
e whole story. It's more of a stepping stone along the way to more perfect =
code. Most programs stop evolving before it gets to the point where o=
ne want's to go back and make this more explicit. The serialization l=
ibrary is somewhat different because under pressure of users to make it mor=
e bug free and bullet proof, I was motivated to evolve/enhance things longe=
r than one might so for other types of projects.<br><br>Robert Ramey<br></d=
iv>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_14_17145627.1357925894786--
.
Author: vvenedict@gmail.com
Date: Wed, 10 Dec 2014 14:14:37 -0800 (PST)
Raw View
------=_Part_311_1429698815.1418249677355
Content-Type: multipart/alternative;
boundary="----=_Part_312_753457422.1418249677356"
------=_Part_312_753457422.1418249677356
Content-Type: text/plain; charset=UTF-8
On Friday, January 11, 2013 9:38:14 AM UTC-8, Robert Ramey wrote:
>
>
>
> On Tuesday, January 8, 2013 9:38:43 AM UTC-8, nx02co...@gmail.com wrote:
>>
>> Hi, I found your work really helpful when I have functions taking bunch
>> of arguments and some of them are same type...
>> for example latitude and longitude... it is real pain to remember to pass
>> them in correct order, and bothering with class or std::pair-ing them also
>> feels like overkill.
>> So if you can I would really like if you could provide some of the real
>> world examples that made you regret making BOOST_STRONG_TYPEDEF
>>
>>
> Regret is too strong. It was convenient at the time but I later found
> that it had some downsides so I backed it out. Note that this occurred in
> a number of places in the serialization library. That is, one has to "get
> it done" and which is a huge job. Later when more time is available, one
> can go back and fix bugs/complaints by re-implementing some things.
>
> Here's the case with BOOST_STRONG_TYPEDEF. I have a "special" kind of
> integer. For example a class version number. This is a number well
> modeled by an integer. But I want to maintain it as a separate type so
> that overload resolution and specialization can depend on the type. I
> needed this in a number of instances and so rather than re-implementing it
> every time I make BOOST_STRONG_TYPEDEF. This leveraged on another boost
> library which implemented all the arithmetic operations so I could derive
> from this. So it was only a few lines of macro code and imported all the
> "numeric" capabilities via inheritance. Just perfect.
>
> But in time I came to appreciate that the things I was using it for
> weren't really normal numbers. It makes sense to increment a class version
> number - but it doesn't make any sense to multiply two class version
> numbers. Does it make sense to automatically convert a class version
> number to an unsigned int? Hmmmm - it seemed like a good idea a the time,
> but it introduced some very sticky errors in the binary_?archive. So I
> realized that what I really needed was more specific control over the
> numeric operations rather than just inheritiing the whole set for
> integers. So I evolved away from BOOST_STRONG_TYPEDEF.
>
> No question that BOOST_STRONG_TYPEDEF has value and is useful. But it's
> also not the whole story. It's more of a stepping stone along the way to
> more perfect code. Most programs stop evolving before it gets to the point
> where one want's to go back and make this more explicit. The serialization
> library is somewhat different because under pressure of users to make it
> more bug free and bullet proof, I was motivated to evolve/enhance things
> longer than one might so for other types of projects.
>
> Robert Ramey
>
Robert ,
Why typedef T type
was not included in your implementation, when using BOOST_STRONG_TYPDEF
with templates it's not possible to figure out underlying type.
Say , you are writing a something combined with boost::hash<T>
I though it would be nice to do like
BOOST_STRONG_TYPDEF(std::string, MyType)
Test<MyType> test; // it takes MyType as template parameter
.....
......
......
template <typename boost_strong_type>
struct Test {
//it would be nice if besides exposing T _t in BOOST_STRONG_TYPEDEF macro
, the macro would also create and alias for T with typedef T type;
typedef boost::unorteder_set <MyType , boost::hash<boost_strong_type::*type*>
> my_map_t ;
....
....
}
Thanks,
Vlad.
--
---
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/.
------=_Part_312_753457422.1418249677356
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, January 11, 2013 9:38:14 AM UTC-8, Robe=
rt Ramey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tues=
day, January 8, 2013 9:38:43 AM UTC-8, <a>nx02co...@gmail.com</a> wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Hi, I found your work really helpful w=
hen I have functions taking bunch of arguments and some of them are same ty=
pe... <br>for example latitude and longitude... it is real pain to remember=
to pass them in correct order, and bothering with class or std::pair-ing t=
hem also feels like overkill.<br>So if you can I would really like if you c=
ould provide some of the real world examples that made you regret making BO=
OST_STRONG_TYPEDEF<br><br></blockquote><div><br>Regret is too strong. =
It was convenient at the time but I later found that it had some downsides=
so I backed it out. Note that this occurred in a number of places in=
the serialization library. That is, one has to "get it done" and whi=
ch is a huge job. Later when more time is available, one can go back =
and fix bugs/complaints by re-implementing some things.<br><br>Here's the c=
ase with BOOST_STRONG_TYPEDEF. I have a "special" kind of integ=
er. For example a class version number. This is a number well m=
odeled by an integer. But I want to maintain it as a separate type so=
that overload resolution and specialization can depend on the type. I need=
ed this in a number of instances and so rather than re-implementing it ever=
y time I make BOOST_STRONG_TYPEDEF. This leveraged on another boost l=
ibrary which implemented all the arithmetic operations so I could derive fr=
om this. So it was only a few lines of macro code and imported all th=
e "numeric" capabilities via inheritance. Just perfect.<br><br>But in=
time I came to appreciate that the things I was using it for weren't reall=
y normal numbers. It makes sense to increment a class version number =
- but it doesn't make any sense to multiply two class version numbers. =
; Does it make sense to automatically convert a class version number to an =
unsigned int? Hmmmm - it seemed like a good idea a the time, but it i=
ntroduced some very sticky errors in the binary_?archive. So I realiz=
ed that what I really needed was more specific control over the numeric ope=
rations rather than just inheritiing the whole set for integers. So I=
evolved away from BOOST_STRONG_TYPEDEF.<br><br>No question that BOOST_STRO=
NG_TYPEDEF has value and is useful. But it's also not the whole story=
.. It's more of a stepping stone along the way to more perfect code. M=
ost programs stop evolving before it gets to the point where one want's to =
go back and make this more explicit. The serialization library is som=
ewhat different because under pressure of users to make it more bug free an=
d bullet proof, I was motivated to evolve/enhance things longer than one mi=
ght so for other types of projects.<br><br>Robert Ramey<br></div></blockquo=
te><div><br></div><div><br></div><div><br></div><div>Robert , </div><d=
iv>Why typedef T type </div><div><br></div><div>was not included in yo=
ur implementation, when using BOOST_STRONG_TYPDEF with templates it's not p=
ossible to figure out underlying type.</div><div>Say , you are writing a so=
mething combined with boost::hash<T></div><div><br></div><div>I thoug=
h it would be nice to do like </div><div><br></div><div>BOOST_STRONG_T=
YPDEF(std::string, MyType)</div><div><br></div><div>Test<MyType> test=
; // it takes MyType as template parameter</div><div>....</div><div>.....</=
div><div>.....</div><div><br></div><div>template <typename boost_strong_=
type></div><div>struct Test {</div><div>//it would be nice if besides ex=
posing T _t in BOOST_STRONG_TYPEDEF macro , the macro would also crea=
te and alias for T with typedef T type;</div><div>typedef boost::unorteder_=
set <MyType , boost::hash<boost_strong_type::<b>type</b>> &g=
t; my_map_t ; </div><div>...</div><div>...</div><div>}</div><div=
><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div=
>Thanks,</div><div>Vlad.</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_312_753457422.1418249677356--
------=_Part_311_1429698815.1418249677355--
.
Author: vvenedict@gmail.com
Date: Wed, 10 Dec 2014 14:32:43 -0800 (PST)
Raw View
------=_Part_679_1341887414.1418250763189
Content-Type: multipart/alternative;
boundary="----=_Part_680_804690492.1418250763189"
------=_Part_680_804690492.1418250763189
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 10, 2014 2:14:37 PM UTC-8, vven...@gmail.com wrote:
>
>
>
> On Friday, January 11, 2013 9:38:14 AM UTC-8, Robert Ramey wrote:
>>
>>
>>
>> On Tuesday, January 8, 2013 9:38:43 AM UTC-8, nx02co...@gmail.com wrote:
>>>
>>> Hi, I found your work really helpful when I have functions taking bunch
>>> of arguments and some of them are same type...
>>> for example latitude and longitude... it is real pain to remember to
>>> pass them in correct order, and bothering with class or std::pair-ing them
>>> also feels like overkill.
>>> So if you can I would really like if you could provide some of the real
>>> world examples that made you regret making BOOST_STRONG_TYPEDEF
>>>
>>>
>> Regret is too strong. It was convenient at the time but I later found
>> that it had some downsides so I backed it out. Note that this occurred in
>> a number of places in the serialization library. That is, one has to "get
>> it done" and which is a huge job. Later when more time is available, one
>> can go back and fix bugs/complaints by re-implementing some things.
>>
>> Here's the case with BOOST_STRONG_TYPEDEF. I have a "special" kind of
>> integer. For example a class version number. This is a number well
>> modeled by an integer. But I want to maintain it as a separate type so
>> that overload resolution and specialization can depend on the type. I
>> needed this in a number of instances and so rather than re-implementing it
>> every time I make BOOST_STRONG_TYPEDEF. This leveraged on another boost
>> library which implemented all the arithmetic operations so I could derive
>> from this. So it was only a few lines of macro code and imported all the
>> "numeric" capabilities via inheritance. Just perfect.
>>
>> But in time I came to appreciate that the things I was using it for
>> weren't really normal numbers. It makes sense to increment a class version
>> number - but it doesn't make any sense to multiply two class version
>> numbers. Does it make sense to automatically convert a class version
>> number to an unsigned int? Hmmmm - it seemed like a good idea a the time,
>> but it introduced some very sticky errors in the binary_?archive. So I
>> realized that what I really needed was more specific control over the
>> numeric operations rather than just inheritiing the whole set for
>> integers. So I evolved away from BOOST_STRONG_TYPEDEF.
>>
>> No question that BOOST_STRONG_TYPEDEF has value and is useful. But it's
>> also not the whole story. It's more of a stepping stone along the way to
>> more perfect code. Most programs stop evolving before it gets to the point
>> where one want's to go back and make this more explicit. The serialization
>> library is somewhat different because under pressure of users to make it
>> more bug free and bullet proof, I was motivated to evolve/enhance things
>> longer than one might so for other types of projects.
>>
>> Robert Ramey
>>
>
>
>
> Robert ,
> Why typedef T type
>
> was not included in your implementation, when using BOOST_STRONG_TYPDEF
> with templates it's not possible to figure out underlying type.
> Say , you are writing a something combined with boost::hash<T>
>
> I though it would be nice to do like
>
> BOOST_STRONG_TYPDEF(std::string, MyType)
>
> Test<MyType> test; // it takes MyType as template parameter
> ....
> .....
> .....
>
> template <typename boost_strong_type>
> struct Test {
> //it would be nice if besides exposing T _t in BOOST_STRONG_TYPEDEF macro
> , the macro would also create and alias for T with typedef T type;
> typedef boost::unorteder_set <MyType , boost::hash<boost_strong_type::
> *type*> > my_map_t ;
> ...
> ...
> }
>
>
>
>
>
> Thanks,
> Vlad.
>
I meant to say :
template <typename boost_strong_type>
struct Test {
//it would be nice if besides exposing T _t in BOOST_STRONG_TYPEDEF macro
, the macro would also create and alias for T with typedef T type;
typedef boost::unorteder_set <boost_string_type ,
boost::hash<boost_strong_type::*type*> > my_map_t ;
....
....
}
--
---
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/.
------=_Part_680_804690492.1418250763189
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 10, 2014 2:14:37 PM UTC-8, =
vven...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>On Friday, January 11, 2013 9:38:14 AM UTC-8, Robert Ram=
ey wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, Januar=
y 8, 2013 9:38:43 AM UTC-8, <a>nx02co...@gmail.com</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">Hi, I found your work really helpful when I have =
functions taking bunch of arguments and some of them are same type... <br>f=
or example latitude and longitude... it is real pain to remember to pass th=
em in correct order, and bothering with class or std::pair-ing them also fe=
els like overkill.<br>So if you can I would really like if you could provid=
e some of the real world examples that made you regret making BOOST_STRONG_=
TYPEDEF<br><br></blockquote><div><br>Regret is too strong. It was con=
venient at the time but I later found that it had some downsides so I backe=
d it out. Note that this occurred in a number of places in the serial=
ization library. That is, one has to "get it done" and which is a hug=
e job. Later when more time is available, one can go back and fix bug=
s/complaints by re-implementing some things.<br><br>Here's the case with&nb=
sp; BOOST_STRONG_TYPEDEF. I have a "special" kind of integer. F=
or example a class version number. This is a number well modeled by a=
n integer. But I want to maintain it as a separate type so that overl=
oad resolution and specialization can depend on the type. I needed this in =
a number of instances and so rather than re-implementing it every time I ma=
ke BOOST_STRONG_TYPEDEF. This leveraged on another boost library whic=
h implemented all the arithmetic operations so I could derive from this.&nb=
sp; So it was only a few lines of macro code and imported all the "numeric"=
capabilities via inheritance. Just perfect.<br><br>But in time I cam=
e to appreciate that the things I was using it for weren't really normal nu=
mbers. It makes sense to increment a class version number - but it do=
esn't make any sense to multiply two class version numbers. Does it m=
ake sense to automatically convert a class version number to an unsigned in=
t? Hmmmm - it seemed like a good idea a the time, but it introduced s=
ome very sticky errors in the binary_?archive. So I realized that wha=
t I really needed was more specific control over the numeric operations rat=
her than just inheritiing the whole set for integers. So I evolved aw=
ay from BOOST_STRONG_TYPEDEF.<br><br>No question that BOOST_STRONG_TYPEDEF =
has value and is useful. But it's also not the whole story. It's more=
of a stepping stone along the way to more perfect code. Most program=
s stop evolving before it gets to the point where one want's to go back and=
make this more explicit. The serialization library is somewhat diffe=
rent because under pressure of users to make it more bug free and bullet pr=
oof, I was motivated to evolve/enhance things longer than one might so for =
other types of projects.<br><br>Robert Ramey<br></div></blockquote><div><br=
></div><div><br></div><div><br></div><div>Robert , </div><div>Why type=
def T type </div><div><br></div><div>was not included in your implemen=
tation, when using BOOST_STRONG_TYPDEF with templates it's not possible to =
figure out underlying type.</div><div>Say , you are writing a something com=
bined with boost::hash<T></div><div><br></div><div>I though it would =
be nice to do like </div><div><br></div><div>BOOST_STRONG_TYPDEF(std::=
<wbr>string, MyType)</div><div><br></div><div>Test<MyType> test; // i=
t takes MyType as template parameter</div><div>....</div><div>.....</div><d=
iv>.....</div><div><br></div><div>template <typename boost_strong_type&g=
t;</div><div>struct Test {</div><div>//it would be nice if besides exposing=
T _t in BOOST_STRONG_TYPEDEF macro , the macro would also create and=
alias for T with typedef T type;</div><div>typedef boost::unorteder_set &l=
t;MyType , boost::hash<boost_strong_type:<wbr>:<b>type</b>> >=
; my_map_t ; </div><div>...</div><div>...</div><div>}</div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
Thanks,</div><div>Vlad.</div></div></blockquote><div><br></div><div><br></d=
iv><div>I meant to say :</div><div><br></div><div>template <typename boo=
st_strong_type></div><div>struct Test {</div><div>//it would be nice if =
besides exposing T _t in BOOST_STRONG_TYPEDEF macro , the macro would=
also create and alias for T with typedef T type;</div><div>typedef boost::=
unorteder_set <boost_string_type , boost::hash<boost_strong_type:<wbr=
>:<b>type</b>> > my_map_t ; </div><div>...</div><div=
>...</div><div>} </div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_680_804690492.1418250763189--
------=_Part_679_1341887414.1418250763189--
.
Author: german.gomez@personifyinc.com
Date: Wed, 10 Dec 2014 18:38:02 -0800 (PST)
Raw View
------=_Part_1203_754485180.1418265482771
Content-Type: multipart/alternative;
boundary="----=_Part_1204_1888968372.1418265482771"
------=_Part_1204_1888968372.1418265482771
Content-Type: text/plain; charset=UTF-8
On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02co...@gmail.com wrote:
>
> Hi, just a quick Q:
> Any plans to add to core lang strong typedef(aka it creates new type not
> an alias of a existing one).
>
My question is: if we can finally overload operator dot, would we need a
specific mechanism for strong typedefs?
http://isocpp.org/files/papers/N4173.pdf
--
---
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/.
------=_Part_1204_1888968372.1418265482771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02c=
o...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi, just =
a quick Q:<br>Any plans to add to core lang strong typedef(aka it creates n=
ew type not an alias of a existing one). <br></blockquote><div><br></div><d=
iv>My question is: if we can finally overload operator dot, would we need a=
specific mechanism for strong typedefs?</div><div><br></div><div>http://is=
ocpp.org/files/papers/N4173.pdf</div><div><br></div><div> </div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1204_1888968372.1418265482771--
------=_Part_1203_754485180.1418265482771--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 11 Dec 2014 08:01:45 +0100
Raw View
This is a multi-part message in MIME format.
--------------070303030309070600090207
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/12/14 03:38, german.gomez@personifyinc.com a =C3=A9crit :
>
>
> On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02co...@gmail.com wrote:
>
> Hi, just a quick Q:
> Any plans to add to core lang strong typedef(aka it creates new
> type not an alias of a existing one).
>
>
> My question is: if we can finally overload operator dot, would we need=20
> a specific mechanism for strong typedefs?
>
> http://isocpp.org/files/papers/N4173.pdf
>
>
My question would be: do we want to make much complex than needed the=20
definition of a strong type?
Maybe with overload operator dot, the strong type alias would be only=20
syntactic sugar.
Vicente
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--------------070303030309070600090207
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 11/12/14 03:38,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:german.gomez@per=
sonifyinc.com">german.gomez@personifyinc.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:b38f452a-2221-4215-a0cd-7931b3fb6bda@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Friday, January 4, 2013 6:22:36 PM UTC+7, <a class=3D"moz-txt-li=
nk-abbreviated" href=3D"mailto:nx02co...@gmail.com">nx02co...@gmail.com</a>
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi, just
a quick Q:<br>
Any plans to add to core lang strong typedef(aka it creates
new type not an alias of a existing one). <br>
</blockquote>
<div><br>
</div>
<div>My question is: if we can finally overload operator dot,
would we need a specific mechanism for strong typedefs?</div>
<div><br>
</div>
<div><a class=3D"moz-txt-link-freetext" href=3D"http://isocpp.org/f=
iles/papers/N4173.pdf">http://isocpp.org/files/papers/N4173.pdf</a></div>
<div><br>
</div>
<div>=C2=A0</div>
</div>
<br>
</blockquote>
<br>
My question would be: do we want to make much complex than needed
the definition of a strong type?<br>
Maybe with overload operator dot, the strong type alias would be
only syntactic sugar.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070303030309070600090207--
.
Author: german.gomez@personifyinc.com
Date: Wed, 10 Dec 2014 23:09:44 -0800 (PST)
Raw View
------=_Part_5236_1133311541.1418281784046
Content-Type: multipart/alternative;
boundary="----=_Part_5237_1534604344.1418281784046"
------=_Part_5237_1534604344.1418281784046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, December 11, 2014 2:01:47 PM UTC+7, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 11/12/14 03:38, german...@personifyinc.com <javascript:> a =C3=A9crit=
:
> =20
>
>
> On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02co...@gmail.com wrote:=
=20
>>
>> Hi, just a quick Q:
>> Any plans to add to core lang strong typedef(aka it creates new type not=
=20
>> an alias of a existing one).=20
>>
>
> My question is: if we can finally overload operator dot, would we need a=
=20
> specific mechanism for strong typedefs?
>
> http://isocpp.org/files/papers/N4173.pdf
>
> =20
> =20
> =20
> My question would be: do we want to make much complex than needed the=20
> definition of a strong type?
> Maybe with overload operator dot, the strong type alias would be only=20
> syntactic sugar.
>
Well, designing a specific feature that goes into core, if we have the=20
tools availabel (operator dot) maybe a lib solution (template with=20
policies?)
is better. You don't marry to a template, but you marry the compiler to a=
=20
language feature. Besides that, it is easier
to make a feature into the lib than into core, I guess, for the marriage=20
reason :)
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_5237_1534604344.1418281784046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, December 11, 2014 2:01:47 PM UTC+7, V=
icente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 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 11/12/14 03:38,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2x=
Eh8xjwTDsJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">german...@personifyinc.com</a> =
a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Friday, January 4, 2013 6:22:36 PM UTC+7, <a>nx02co...@gmail.com=
</a>
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Hi, just
a quick Q:<br>
Any plans to add to core lang strong typedef(aka it creates
new type not an alias of a existing one). <br>
</blockquote>
<div><br>
</div>
<div>My question is: if we can finally overload operator dot,
would we need a specific mechanism for strong typedefs?</div>
<div><br>
</div>
<div><a href=3D"http://isocpp.org/files/papers/N4173.pdf" target=3D=
"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4173.pdf\46sa\75D\46sntz\0751\46usg\75A=
FQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN417=
3.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';retu=
rn true;">http://isocpp.org/files/<wbr>papers/N4173.pdf</a></div>
<div><br>
</div>
<div> </div>
</div>
<br>
</blockquote>
<br>
My question would be: do we want to make much complex than needed
the definition of a strong type?<br>
Maybe with overload operator dot, the strong type alias would be
only syntactic sugar.<br></div></blockquote><div><br></div><div>Well, d=
esigning a specific feature that goes into core, if we have the tools avail=
abel (operator dot) maybe a lib solution (template with policies?)</div><di=
v>is better. You don't marry to a template, but you marry the compiler to a=
language feature. Besides that, it is easier</div><div>to make a feature i=
nto the lib than into core, I guess, for the marriage reason :)</div><div><=
br></div><div><br></div><div><br></div><div><br></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5237_1534604344.1418281784046--
------=_Part_5236_1133311541.1418281784046--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 11 Dec 2014 08:24:04 +0100
Raw View
This is a multi-part message in MIME format.
--------------080304080502010702000204
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/12/14 08:09, german.gomez@personifyinc.com a =C3=A9crit :
>
>
> On Thursday, December 11, 2014 2:01:47 PM UTC+7, Vicente J. Botet=20
> Escriba wrote:
>
> Le 11/12/14 03:38, german...@personifyinc.com <javascript:> a =C3=A9c=
rit :
>>
>>
>> On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02co...@gmail.com
>> wrote:
>>
>> Hi, just a quick Q:
>> Any plans to add to core lang strong typedef(aka it creates
>> new type not an alias of a existing one).
>>
>>
>> My question is: if we can finally overload operator dot, would we
>> need a specific mechanism for strong typedefs?
>>
>> http://isocpp.org/files/papers/N4173.pdf
>> <http://isocpp.org/files/papers/N4173.pdf>
>>
>>
>
> My question would be: do we want to make much complex than needed
> the definition of a strong type?
> Maybe with overload operator dot, the strong type alias would be
> only syntactic sugar.
>
>
> Well, designing a specific feature that goes into core, if we have the=20
> tools availabel (operator dot) maybe a lib solution (template with=20
> policies?)
> is better. You don't marry to a template, but you marry the compiler=20
> to a language feature. Besides that, it is easier
> to make a feature into the lib than into core, I guess, for the=20
> marriage reason :)
>
>
>
Agreed completely. I didn't said that it was a simple task to introduce=20
a new core feature to the standard. What I'm asking is if we want that=20
users use simple things via simple syntax.
Vicente
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--------------080304080502010702000204
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 11/12/14 08:09,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:german.gomez@per=
sonifyinc.com">german.gomez@personifyinc.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:47713b59-b451-4814-9a4e-76e0a901f96a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Thursday, December 11, 2014 2:01:47 PM UTC+7, Vicente J.
Botet Escriba wrote:
<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>Le 11/12/14 03:38, <a moz-do-not-send=3D"true"
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"2xEh8xjwTDsJ"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;">german..=
..@personifyinc.com</a>
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Friday, January 4, 2013 6:22:36 PM UTC+7, <a
moz-do-not-send=3D"true">nx02co...@gmail.com</a> wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi, just a quick Q:<br>
Any plans to add to core lang strong typedef(aka it
creates new type not an alias of a existing one). <br>
</blockquote>
<div><br>
</div>
<div>My question is: if we can finally overload operator
dot, would we need a specific mechanism for strong
typedefs?</div>
<div><br>
</div>
<div><a moz-do-not-send=3D"true"
href=3D"http://isocpp.org/files/papers/N4173.pdf"
target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4173.pdf\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4173.pdf\46sa\75D\46sntz\0751\46=
usg\75AFQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';return
true;">http://isocpp.org/files/<wbr>papers/N4173.pdf</a=
></div>
<div><br>
</div>
<div>=C2=A0</div>
</div>
<br>
</blockquote>
<br>
My question would be: do we want to make much complex than
needed the definition of a strong type?<br>
Maybe with overload operator dot, the strong type alias
would be only syntactic sugar.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Well, designing a specific feature that goes into core, if
we have the tools availabel (operator dot) maybe a lib
solution (template with policies?)</div>
<div>is better. You don't marry to a template, but you marry the
compiler to a language feature. Besides that, it is easier</div>
<div>to make a feature into the lib than into core, I guess, for
the marriage reason :)</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
</blockquote>
Agreed completely. I didn't said that it was a simple task to
introduce a new core feature to the standard. What I'm asking is if
we want that users use simple things via simple syntax.<br>
<br>
<br>
Vicente<br>
</body>
</html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------080304080502010702000204--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 11 Dec 2014 08:24:04 +0100
Raw View
This is a multi-part message in MIME format.
--------------020904030500000802050203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/12/14 08:09, german.gomez@personifyinc.com a =C3=A9crit :
>
>
> On Thursday, December 11, 2014 2:01:47 PM UTC+7, Vicente J. Botet=20
> Escriba wrote:
>
> Le 11/12/14 03:38, german...@personifyinc.com <javascript:> a =C3=A9c=
rit :
>>
>>
>> On Friday, January 4, 2013 6:22:36 PM UTC+7, nx02co...@gmail.com
>> wrote:
>>
>> Hi, just a quick Q:
>> Any plans to add to core lang strong typedef(aka it creates
>> new type not an alias of a existing one).
>>
>>
>> My question is: if we can finally overload operator dot, would we
>> need a specific mechanism for strong typedefs?
>>
>> http://isocpp.org/files/papers/N4173.pdf
>> <http://isocpp.org/files/papers/N4173.pdf>
>>
>>
>
> My question would be: do we want to make much complex than needed
> the definition of a strong type?
> Maybe with overload operator dot, the strong type alias would be
> only syntactic sugar.
>
>
> Well, designing a specific feature that goes into core, if we have the=20
> tools availabel (operator dot) maybe a lib solution (template with=20
> policies?)
> is better. You don't marry to a template, but you marry the compiler=20
> to a language feature. Besides that, it is easier
> to make a feature into the lib than into core, I guess, for the=20
> marriage reason :)
>
>
>
Agreed completely. I didn't said that it was a simple task to introduce=20
a new core feature to the standard. What I'm asking is if we want that=20
users use simple things via simple syntax.
Vicente
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--------------020904030500000802050203
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 11/12/14 08:09,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:german.gomez@per=
sonifyinc.com">german.gomez@personifyinc.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:47713b59-b451-4814-9a4e-76e0a901f96a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Thursday, December 11, 2014 2:01:47 PM UTC+7, Vicente J.
Botet Escriba wrote:
<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>Le 11/12/14 03:38, <a moz-do-not-send=3D"true"
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"2xEh8xjwTDsJ"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;">german..=
..@personifyinc.com</a>
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Friday, January 4, 2013 6:22:36 PM UTC+7, <a
moz-do-not-send=3D"true">nx02co...@gmail.com</a> wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi, just a quick Q:<br>
Any plans to add to core lang strong typedef(aka it
creates new type not an alias of a existing one). <br>
</blockquote>
<div><br>
</div>
<div>My question is: if we can finally overload operator
dot, would we need a specific mechanism for strong
typedefs?</div>
<div><br>
</div>
<div><a moz-do-not-send=3D"true"
href=3D"http://isocpp.org/files/papers/N4173.pdf"
target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4173.pdf\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4173.pdf\46sa\75D\46sntz\0751\46=
usg\75AFQjCNGgP3m1Bqix7_T3dW1qWprVmqyNrA';return
true;">http://isocpp.org/files/<wbr>papers/N4173.pdf</a=
></div>
<div><br>
</div>
<div>=C2=A0</div>
</div>
<br>
</blockquote>
<br>
My question would be: do we want to make much complex than
needed the definition of a strong type?<br>
Maybe with overload operator dot, the strong type alias
would be only syntactic sugar.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Well, designing a specific feature that goes into core, if
we have the tools availabel (operator dot) maybe a lib
solution (template with policies?)</div>
<div>is better. You don't marry to a template, but you marry the
compiler to a language feature. Besides that, it is easier</div>
<div>to make a feature into the lib than into core, I guess, for
the marriage reason :)</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
</blockquote>
Agreed completely. I didn't said that it was a simple task to
introduce a new core feature to the standard. What I'm asking is if
we want that users use simple things via simple syntax.<br>
<br>
<br>
Vicente<br>
</body>
</html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------020904030500000802050203--
.
Author: vvenedict@gmail.com
Date: Thu, 11 Dec 2014 16:57:36 -0800 (PST)
Raw View
------=_Part_91_1921680490.1418345856919
Content-Type: text/plain; charset=UTF-8
#define BOOST_STRONG_TYPEDEF2(T, D) \
struct D \
: boost::totally_ordered1< D \
, boost::totally_ordered2< D, T \
> > \
{ \
typedef T type \
T t; \
explicit D(const T t_) : t(t_) {}; \
D(){}; \
D(const D & t_) : t(t_.t){} \
D & operator=(const D & rhs) { t = rhs.t; return *this;} \
template<typename U> \
typename boost::enable_if<boost::is_same<U,T>, D>::type & \
operator=(const U & rhs ) { t = rhs; return *this;} \
operator const T & () const {return t; } \
operator T & () { return t; } \
bool operator==(const D & rhs) const { return t == rhs.t; } \
bool operator<(const D & rhs) const { return t < rhs.t; } \
};
1.) nice to have typdef of actual type and 2.) also your strong type converts between each other strong type if underlying type is the same:
BOOST_STRONG_TYPEDEF2(long, EntityId)
BOOST_STRONG_TYPEDEF2(long, AcctNo)
int main(int argc, char** argv) {
AcctNo acct_no;
EntityId id ;
acct_no = id ; //<-- original original implementation allows conversion , however see what can be achieved with SFINAE in my version
return 0;
}
--
---
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/.
------=_Part_91_1921680490.1418345856919--
.
Author: vvenedict@gmail.com
Date: Thu, 11 Dec 2014 17:02:31 -0800 (PST)
Raw View
------=_Part_74_1927359511.1418346151767
Content-Type: text/plain; charset=UTF-8
proposing to change BOOST_STRONG_TYPEDEF's operator :
D & operator=(const T & rhs) { t = rhs; return *this;}
to
template<typename U>
typename boost::enable_if<boost::is_same<U,T>, D>::type &
operator=(const U & rhs ) { t = rhs; return *this;}
This will prevent from conversion of different strong types with same underlying type!!!
--
---
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/.
------=_Part_74_1927359511.1418346151767--
.
Author: vvenedict@gmail.com
Date: Thu, 11 Dec 2014 18:50:26 -0800 (PST)
Raw View
------=_Part_191_1762636076.1418352626578
Content-Type: text/plain; charset=UTF-8
D(){};
should be fixed to
D() : t() {};
in order for underlying primitives types to be default initialized, because compiler does not initialize them it.
--
---
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/.
------=_Part_191_1762636076.1418352626578--
.
Author: vvenedict@gmail.com
Date: Thu, 11 Dec 2014 19:01:25 -0800 (PST)
Raw View
------=_Part_176_1509596725.1418353285155
Content-Type: text/plain; charset=UTF-8
Actually I take it back , as it forces for non-pod types of 't' to have default ctor , my bad sorry
--
---
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/.
------=_Part_176_1509596725.1418353285155--
.
Author: vvenedict@gmail.com
Date: Thu, 11 Dec 2014 22:59:43 -0800 (PST)
Raw View
------=_Part_329_1701644893.1418367583164
Content-Type: text/plain; charset=UTF-8
Are you maintaining your macro in boost ? If
So can I propose to fix it ? so that it won't be able to assign one strong type to another having same underlying type .
Please reply if patch can be released , see my posts bow
--
---
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/.
------=_Part_329_1701644893.1418367583164--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 12 Dec 2014 22:25:06 +0100
Raw View
This is a multi-part message in MIME format.
--------------010505010203000608080203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 12/12/14 07:59, vvenedict@gmail.com a =C3=A9crit :
> Are you maintaining your macro in boost ? If
> So can I propose to fix it ? so that it won't be able to assign one stron=
g type to another having same underlying type .
> Please reply if patch can be released , see my posts bow
>
Please, switch to the Boost ML for patches for Boost.
Vicente
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--------------010505010203000608080203
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 12/12/14 07:59, <a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:vvenedict@gmail.com">vvenedict@gmail.com</a=
>
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:ac5c3423-08eb-47ef-9f10-a153891f4731@isocpp.org"
type=3D"cite">
<pre wrap=3D"">Are you maintaining your macro in boost ? If=20
So can I propose to fix it ? so that it won't be able to assign one strong =
type to another having same underlying type .
Please reply if patch can be released , see my posts bow=20
</pre>
</blockquote>
<font size=3D"+1">Please, switch to the Boost ML for patches for
Boost.</font> <br>
<br>
Vicente<br>
</body>
</html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010505010203000608080203--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Fri, 13 Mar 2015 12:21:05 -0700 (PDT)
Raw View
------=_Part_383_868740399.1426274465360
Content-Type: multipart/alternative;
boundary="----=_Part_384_178570040.1426274465360"
------=_Part_384_178570040.1426274465360
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 8, 2013 at 10:17:29 AM UTC-8, C Bush wrote:
>
> I have also been interested in this issue, partially inspired by a
> segment of Bjarne Stroustrup's "Going Native" keynote in which he
> discusses the programming error at the root of a certain Mars probe's
> failure - calculations in one unit system were passed to a function
> that expected calculations in another. I think we could all benefit
> from a simple way to make differentiated PODs (and, I guess, more
> complex types). Now if only coming up with a 'simple solution' were...
> well, you know.
>
As far as I'm concerned, the definitive solution for this is boost units
library. Here are a few observations on it.
a) The tutorial documentation is terrible
b) the reference documentation is not much better
c) The above required me spend more than a few days spelunking the
documentation, examples, library code, etc.
d) It's very wide ranging and includes almost everything
e) Implemenation is an incredible piece of template meta program
f) has worked very well for me.
Sooooo - great software - which a huge hurdle to is usage.
If anyone cares - I may well be giving a tutorial introduction to this
library at CPP Con 2015.
Robert Ramey
--
---
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/.
------=_Part_384_178570040.1426274465360
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, January 8, 2013 at 10:17:29 AM UTC-8, =
C Bush wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I have also been =
interested in this issue, partially inspired by a
<br>segment of Bjarne Stroustrup's "Going Native" keynote in which he
<br>discusses the programming error at the root of a certain Mars probe's
<br>failure - calculations in one unit system were passed to a function
<br>that expected calculations in another. I think we could all benefit
<br>from a simple way to make differentiated PODs (and, I guess, more
<br>complex types). Now if only coming up with a 'simple solution' were...
<br>well, you know.
<br></blockquote><div><br></div><div>As far as I'm concerned, the definitiv=
e solution for this is boost units library. Here are a few observations on =
it.</div><div><br></div><div>a) The tutorial documentation is terrible</div=
><div>b) the reference documentation is not much better </div><div>c) =
The above required me spend more than a few days spelunking the documentati=
on, examples, library code, etc.</div><div>d) It's very wide ranging and in=
cludes almost everything</div><div>e) Implemenation is an incredible piece =
of template meta program</div><div>f) has worked very well for me.</div><di=
v><br></div><div>Sooooo - great software - which a huge hurdle to is usage.=
</div><div><br></div><div>If anyone cares - I may well be giving &nb=
sp;a tutorial introduction to this library at CPP Con 2015.</div><div><br><=
/div><div>Robert Ramey</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_384_178570040.1426274465360--
------=_Part_383_868740399.1426274465360--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 13 Mar 2015 23:44:07 -0700 (PDT)
Raw View
------=_Part_2021_393165655.1426315447660
Content-Type: multipart/alternative;
boundary="----=_Part_2022_1358410515.1426315447660"
------=_Part_2022_1358410515.1426315447660
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 12:21:05 PM UTC-7, Robert Ramey wrote:
>
> d) It's very wide ranging and includes almost everything
> e) Implemenation is an incredible piece of template meta program
>
This is what makes it almost a complete non-starter. Including a few tens
or hundreds of thousands of lines of complicated templates that must be
instantiated just to get the compiler to avoid implicitly copying/casting
between a couple of "different" integers or simple PODs is utterly
unacceptable to a great number of key C++ users.
Many game companies can (and very, very often do) just prefer C99 over this
kind of massive bloating. Using Boost for opaque typedefs is not unlike
using boost::bind for lambdas; it's a neat proof of concept, but ultimately
something the compiler needed to just do itself. It's not just the syntax,
or the incomprehensible template errors of the library solution, or the
slower compilation times of a pile of templates bigger and more complicated
than the program itself, or the wizards-only internals, but a confluence of
these issues.
--
---
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/.
------=_Part_2022_1358410515.1426315447660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 13, 2015 at 12:21:05 PM UTC-7, Robert Ram=
ey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>d) It's very wide ranging and includes almost everything</div><div>e) Impl=
emenation is an incredible piece of template meta program</div></div></bloc=
kquote><div><br></div><div>This is what makes it almost a complete non-star=
ter. Including a few tens or hundreds of thousands of lines of complicated =
templates that must be instantiated just to get the compiler to avoid impli=
citly copying/casting between a couple of "different" integers or simple PO=
Ds is utterly unacceptable to a great number of key C++ users.</div><div><b=
r></div><div>Many game companies can (and very, very often do) just prefer =
C99 over this kind of massive bloating. Using Boost for opaque typedefs is =
not unlike using boost::bind for lambdas; it's a neat proof of concept, but=
ultimately something the compiler needed to just do itself. It's not just =
the syntax, or the incomprehensible template errors of the library solution=
, or the slower compilation times of a pile of templates bigger and more co=
mplicated than the program itself, or the wizards-only internals, but a con=
fluence of these issues.</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2022_1358410515.1426315447660--
------=_Part_2021_393165655.1426315447660--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sat, 14 Mar 2015 10:29:54 +0000
Raw View
--Apple-Mail-C39DDB68-0746-4545-B7A4-F14841E5565D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
+1
> On 14 Mar 2015, at 06:44, Sean Middleditch <sean.middleditch@gmail.com> w=
rote:
>=20
>> On Friday, March 13, 2015 at 12:21:05 PM UTC-7, Robert Ramey wrote:
>> d) It's very wide ranging and includes almost everything
>> e) Implemenation is an incredible piece of template meta program
>=20
> This is what makes it almost a complete non-starter. Including a few tens=
or hundreds of thousands of lines of complicated templates that must be in=
stantiated just to get the compiler to avoid implicitly copying/casting bet=
ween a couple of "different" integers or simple PODs is utterly unacceptabl=
e to a great number of key C++ users.
>=20
> Many game companies can (and very, very often do) just prefer C99 over th=
is kind of massive bloating. Using Boost for opaque typedefs is not unlike =
using boost::bind for lambdas; it's a neat proof of concept, but ultimately=
something the compiler needed to just do itself. It's not just the syntax,=
or the incomprehensible template errors of the library solution, or the sl=
ower compilation times of a pile of templates bigger and more complicated t=
han the program itself, or the wizards-only internals, but a confluence of =
these issues.
> --=20
>=20
> ---=20
> 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-propo=
sals/.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail-C39DDB68-0746-4545-B7A4-F14841E5565D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>+1<br><br><br></div><div><br>On 14=
Mar 2015, at 06:44, Sean Middleditch <<a href=3D"mailto:sean.middleditc=
h@gmail.com">sean.middleditch@gmail.com</a>> wrote:<br><br></div><blockq=
uote type=3D"cite"><div><div dir=3D"ltr">On Friday, March 13, 2015 at 12:21=
:05 PM UTC-7, Robert Ramey wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div>d) It's very wide ranging and includes almost ever=
ything</div><div>e) Implemenation is an incredible piece of template meta p=
rogram</div></div></blockquote><div><br></div><div>This is what makes it al=
most a complete non-starter. Including a few tens or hundreds of thousands =
of lines of complicated templates that must be instantiated just to get the=
compiler to avoid implicitly copying/casting between a couple of "differen=
t" integers or simple PODs is utterly unacceptable to a great number of key=
C++ users.</div><div><br></div><div>Many game companies can (and very, ver=
y often do) just prefer C99 over this kind of massive bloating. Using Boost=
for opaque typedefs is not unlike using boost::bind for lambdas; it's a ne=
at proof of concept, but ultimately something the compiler needed to just d=
o itself. It's not just the syntax, or the incomprehensible template errors=
of the library solution, or the slower compilation times of a pile of temp=
lates bigger and more complicated than the program itself, or the wizards-o=
nly internals, but a confluence of these issues.</div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</div></blockquote></body></html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail-C39DDB68-0746-4545-B7A4-F14841E5565D--
.