Topic: is_instantiation_of type trait
Author: Curious <aary@umich.edu>
Date: Mon, 20 Feb 2017 14:31:29 -0800 (PST)
Raw View
------=_Part_6578_771728765.1487629889577
Content-Type: multipart/alternative;
boundary="----=_Part_6579_425280322.1487629889578"
------=_Part_6579_425280322.1487629889578
Content-Type: text/plain; charset=UTF-8
I have seen some problems in the past associated with passing objects of
classes that are instantiations of templates with multiple parameter with
one or more than one default parameters. For example, if I have the
following function
void func(const std::vector<int>& vec) { ... }
I cannot call it like so
auto vec = std::vector<int, MyAllocator>{};
func(vec);
Because the type of the second parameter (i.e. the allocator) is different.
Maybe the following type trait can be useful for situations like this?
template <typename Type, template <typename...> class InstantiationType>
struct is_instantiation_of : std::integral_constant<bool, false> {};
template <template <typename...> class Thing, typename... Args>
struct is_instantiation_of<Thing<Args...>, Thing> :
std::integral_constant<bool, true> {};
This way one could write a function that accepts any type of vector like
this (without concepts)
template <typename Type, template <typename...> class Thing>
using EnableIfIsInstantiationOf =
std::enable_if_t<is_instantiation_of<Type, Thing>::value>;
template <typename Vector, EnableIfIsInstantiationOf<Vector, std::vector>*
= nullptr>
void func(const Vector& vec) { ... }
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org.
------=_Part_6579_425280322.1487629889578
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have seen some problems in the past associated with pass=
ing objects of classes that are instantiations of templates with multiple p=
arameter with one or more than one default parameters. =C2=A0For example, i=
f I have the following function<div><br></div><div><font face=3D"courier ne=
w, monospace">void func(const std::vector<int>& vec) { ... }</fon=
t></div><div><font face=3D"courier new, monospace"><br></font></div><div><f=
ont face=3D"arial, sans-serif">I cannot call it like so=C2=A0</font></div><=
div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"co=
urier new, monospace">auto vec =3D std::vector<int, MyAllocator>{};</=
font></div><div><font face=3D"courier new, monospace">func(vec);</font></di=
v><div><font face=3D"courier new, monospace"><br></font></div><div><font fa=
ce=3D"arial, sans-serif">Because the type of the second parameter (i.e. the=
allocator) is different. =C2=A0Maybe the following type trait can be usefu=
l for situations like this?</font></div><div><br></div><div><div><font face=
=3D"courier new, monospace">template <typename Type, template <typena=
me...> class InstantiationType></font></div><div><font face=3D"courie=
r new, monospace">struct is_instantiation_of : std::integral_constant<bo=
ol, false> {};</font></div><div><font face=3D"courier new, monospace"><b=
r></font></div><div><font face=3D"courier new, monospace">template <temp=
late <typename...> class Thing, typename... Args></font></div><div=
><font face=3D"courier new, monospace">struct is_instantiation_of<Thing&=
lt;Args...>, Thing>=C2=A0</font><span style=3D"font-family: 'cour=
ier new', monospace;">: std::integral_constant<bool, true> {};</s=
pan></div><div><br></div></div><div>This way one could write a function tha=
t accepts any type of vector like this (without concepts)</div><div><br></d=
iv><div><font face=3D"courier new, monospace">template <typename Type, t=
emplate <typename...> class Thing></font></div><div><font face=3D"=
courier new, monospace">using EnableIfIsInstantiationOf =3D std::enable_if_=
t<is_instantiation_of<Type, Thing>::value>;</font></div><div><f=
ont face=3D"courier new, monospace"><br></font></div><div><font face=3D"cou=
rier new, monospace">template <typename Vector,=C2=A0</font><span style=
=3D"font-family: 'courier new', monospace;">EnableIfIsInstantiation=
Of<Vector, std::vector>* =3D nullptr></span></div><div><span style=
=3D"font-family: 'courier new', monospace;">void func(const Vector&=
amp; vec) { ... }</span></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b=
%40isocpp.org</a>.<br />
------=_Part_6579_425280322.1487629889578--
------=_Part_6578_771728765.1487629889577--
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Mon, 20 Feb 2017 14:36:17 -0800
Raw View
--001a113ee5e254fb0e0548fde485
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 20, 2017 at 2:31 PM, Curious <aary@umich.edu> wrote:
> I have seen some problems in the past associated with passing objects of
> classes that are instantiations of templates with multiple parameter with
> one or more than one default parameters. For example, if I have the
> following function
>
> void func(const std::vector<int>& vec) { ... }
>
> I cannot call it like so
>
> auto vec = std::vector<int, MyAllocator>{};
> func(vec);
>
> Because the type of the second parameter (i.e. the allocator) is
> different. Maybe the following type trait can be useful for situations
> like this?
>
> template <typename Type, template <typename...> class InstantiationType>
> struct is_instantiation_of : std::integral_constant<bool, false> {};
>
> template <template <typename...> class Thing, typename... Args>
> struct is_instantiation_of<Thing<Args...>, Thing> :
> std::integral_constant<bool, true> {};
>
> This way one could write a function that accepts any type of vector like
> this (without concepts)
>
> template <typename Type, template <typename...> class Thing>
> using EnableIfIsInstantiationOf = std::enable_if_t<is_instantiation_of<Type,
> Thing>::value>;
>
> template <typename Vector, EnableIfIsInstantiationOf<Vector,
> std::vector>* = nullptr>
> void func(const Vector& vec) { ... }
>
Sorry maybe I'm missing something but why can't you just do this?
template <class T, class Alloc>
void func(const std::vector<T, Alloc>& vec) { ... }
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-
> 8d6a-764c8d45279b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
*Brian Bi*
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOXm_UymTZPdga7pXxvVEHjWx%2BO1HmZXphnaUzU0vYBQw%40mail.gmail.com.
--001a113ee5e254fb0e0548fde485
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:monospace,monospace"></span><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Feb 20, 2017 at =
2:31 PM, Curious <span dir=3D"ltr"><<a target=3D"_blank" href=3D"mailto:=
aary@umich.edu">aary@umich.edu</a>></span> wrote:<br><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">I have seen some problems=
in the past associated with passing objects of classes that are instantiat=
ions of templates with multiple parameter with one or more than one default=
parameters.=C2=A0 For example, if I have the following function<div><br></=
div><div><font face=3D"courier new, monospace">void func(const std::vector&=
lt;int>& vec) { ... }</font></div><div><font face=3D"courier new, mo=
nospace"><br></font></div><div><font face=3D"arial, sans-serif">I cannot ca=
ll it like so=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br><=
/font></div><div><font face=3D"courier new, monospace">auto vec =3D std::ve=
ctor<int, MyAllocator>{};</font></div><div><font face=3D"courier new,=
monospace">func(vec);</font></div><div><font face=3D"courier new, monospac=
e"><br></font></div><div><font face=3D"arial, sans-serif">Because the type =
of the second parameter (i.e. the allocator) is different.=C2=A0 Maybe the =
following type trait can be useful for situations like this?</font></div><d=
iv><br></div><div><div><font face=3D"courier new, monospace">template <t=
ypename Type, template <typename...> class InstantiationType></fon=
t></div><div><font face=3D"courier new, monospace">struct is_instantiation_=
of : std::integral_constant<bool, false> {};</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">template <template <typename...> class Thing, type=
name... Args></font></div><div><font face=3D"courier new, monospace">str=
uct is_instantiation_of<Thing<<wbr>Args...>, Thing>=C2=A0</font=
><span style=3D"font-family:"courier new",monospace">: std::integ=
ral_constant<bool, true> {};</span></div><div><br></div></div><div>Th=
is way one could write a function that accepts any type of vector like this=
(without concepts)</div><div><br></div><div><font face=3D"courier new, mon=
ospace">template <typename Type, template <typename...> class Thin=
g></font></div><div><font face=3D"courier new, monospace">using EnableIf=
IsInstantiationOf =3D std::enable_if_t<is_<wbr>instantiation_of<Type,=
Thing>::value>;</font></div><div><font face=3D"courier new, monospac=
e"><br></font></div><div><font face=3D"courier new, monospace">template <=
;typename Vector,=C2=A0</font><span style=3D"font-family:"courier new&=
quot;,monospace">EnableIfIsInstantiatio<wbr>nOf<Vector, std::vector>*=
=3D nullptr></span></div><div><span style=3D"font-family:"courier =
new",monospace">void func(const Vector& vec) { ... }</span></div><=
/div></blockquote><div><br><div><div>Sorry maybe I'm missing something =
but why can't you just do this?<br><br></div><span style=3D"font-family=
:monospace,monospace">template <class T, class Alloc><br></span></div=
><span style=3D"font-family:monospace,monospace">void func(const std::vecto=
r<T, Alloc>& vec) { ... }</span><br></div><blockquote style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex" class=3D"gmail_quote"><span class=3D"gmail-HOEnZb"><font color=3D"#888=
888">
<p></p>
-- <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 target=3D"_blank" href=3D"mailto:std-proposals+unsubscribe@isocp=
p.org">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a target=3D"_blank" href=3D"mailto:st=
d-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a target=3D"_blank" href=3D"https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-=
8d6a-764c8d45279b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/66dc=
aca8-65d4-4575-<wbr>8d6a-764c8d45279b%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D=
"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div>=
</div></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOXm_UymTZPdga7pXxvVEHjWx%2BO1H=
mZXphnaUzU0vYBQw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOXm_UymT=
ZPdga7pXxvVEHjWx%2BO1HmZXphnaUzU0vYBQw%40mail.gmail.com</a>.<br />
--001a113ee5e254fb0e0548fde485--
.
Author: Curious <aary@umich.edu>
Date: Mon, 20 Feb 2017 14:41:37 -0800 (PST)
Raw View
------=_Part_6549_568658887.1487630497462
Content-Type: multipart/alternative;
boundary="----=_Part_6550_1296596186.1487630497462"
------=_Part_6550_1296596186.1487630497462
Content-Type: text/plain; charset=UTF-8
I feel like it would be a much more readable alternative than that because
the solution of including the template parameters becomes a lot more
complicated when there are multiple arguments, and each have two-three
"hidden" template parameters.
Also I feel like it would help people write good specialized functions,
since there are a lot of functions that can be written to accept types with
different interfaces but do the same logical thing, for example, you can
think of a binary search function that would linearly iterate if a linked
list would be passed and randomly jump around when a vector is passed.
There are better iterator based solutions to the example I gave but I feel
like it conveys what I have in mind!
On Monday, February 20, 2017 at 5:36:20 PM UTC-5, Brian Bi wrote:
>
> On Mon, Feb 20, 2017 at 2:31 PM, Curious <aa...@umich.edu <javascript:>>
> wrote:
>
>> I have seen some problems in the past associated with passing objects of
>> classes that are instantiations of templates with multiple parameter with
>> one or more than one default parameters. For example, if I have the
>> following function
>>
>> void func(const std::vector<int>& vec) { ... }
>>
>> I cannot call it like so
>>
>> auto vec = std::vector<int, MyAllocator>{};
>> func(vec);
>>
>> Because the type of the second parameter (i.e. the allocator) is
>> different. Maybe the following type trait can be useful for situations
>> like this?
>>
>> template <typename Type, template <typename...> class InstantiationType>
>> struct is_instantiation_of : std::integral_constant<bool, false> {};
>>
>> template <template <typename...> class Thing, typename... Args>
>> struct is_instantiation_of<Thing<Args...>, Thing> :
>> std::integral_constant<bool, true> {};
>>
>> This way one could write a function that accepts any type of vector like
>> this (without concepts)
>>
>> template <typename Type, template <typename...> class Thing>
>> using EnableIfIsInstantiationOf =
>> std::enable_if_t<is_instantiation_of<Type, Thing>::value>;
>>
>> template <typename Vector, EnableIfIsInstantiationOf<Vector,
>> std::vector>* = nullptr>
>> void func(const Vector& vec) { ... }
>>
>
> Sorry maybe I'm missing something but why can't you just do this?
>
> template <class T, class Alloc>
> void func(const std::vector<T, Alloc>& vec) { ... }
>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> *Brian Bi*
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c246a159-006d-46cb-a664-c8a599a6e39b%40isocpp.org.
------=_Part_6550_1296596186.1487630497462
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I feel like it would be a much more readable alternative t=
han that because the solution of including the template parameters becomes =
a lot more complicated when there are multiple arguments, and each have two=
-three "hidden" template parameters.<div><br></div><div>Also I fe=
el like it would help people write good specialized functions, since there =
are a lot of functions that can be written to accept types with different i=
nterfaces but do the same logical thing, for example, you can think of a bi=
nary search function that would linearly iterate if a linked list would be =
passed and randomly jump around when a vector is passed. =C2=A0There are be=
tter iterator based solutions to the example I gave but I feel like it conv=
eys what I have in mind!<br><br>On Monday, February 20, 2017 at 5:36:20 PM =
UTC-5, Brian Bi 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"><span style=3D"font-family:monospace,monospace"></span><div><div c=
lass=3D"gmail_quote">On Mon, Feb 20, 2017 at 2:31 PM, Curious <span dir=3D"=
ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"D4970SXEBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">aa...@umich.edu</a>></span> wrote:<br><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" cl=
ass=3D"gmail_quote"><div dir=3D"ltr">I have seen some problems in the past =
associated with passing objects of classes that are instantiations of templ=
ates with multiple parameter with one or more than one default parameters.=
=C2=A0 For example, if I have the following function<div><br></div><div><fo=
nt face=3D"courier new, monospace">void func(const std::vector<int>&a=
mp; vec) { ... }</font></div><div><font face=3D"courier new, monospace"><br=
></font></div><div><font face=3D"arial, sans-serif">I cannot call it like s=
o=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></div>=
<div><font face=3D"courier new, monospace">auto vec =3D std::vector<int,=
MyAllocator>{};</font></div><div><font face=3D"courier new, monospace">=
func(vec);</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"arial, sans-serif">Because the type of the secon=
d parameter (i.e. the allocator) is different.=C2=A0 Maybe the following ty=
pe trait can be useful for situations like this?</font></div><div><br></div=
><div><div><font face=3D"courier new, monospace">template <typename Type=
, template <typename...> class InstantiationType></font></div><div=
><font face=3D"courier new, monospace">struct is_instantiation_of : std::in=
tegral_constant<bool, false> {};</font></div><div><font face=3D"couri=
er new, monospace"><br></font></div><div><font face=3D"courier new, monospa=
ce">template <template <typename...> class Thing, typename... Args=
></font></div><div><font face=3D"courier new, monospace">struct is_insta=
ntiation_of<Thing<<wbr>Args...>, Thing>=C2=A0</font><span style=
=3D"font-family:"courier new",monospace">: std::integral_constant=
<bool, true> {};</span></div><div><br></div></div><div>This way one c=
ould write a function that accepts any type of vector like this (without co=
ncepts)</div><div><br></div><div><font face=3D"courier new, monospace">temp=
late <typename Type, template <typename...> class Thing></font>=
</div><div><font face=3D"courier new, monospace">using EnableIfIsInstantiat=
ionOf =3D std::enable_if_t<is_<wbr>instantiation_of<Type, Thing>::=
value>;</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"courier new, monospace">template <typename Ve=
ctor,=C2=A0</font><span style=3D"font-family:"courier new",monosp=
ace">EnableIfIsInstantiatio<wbr>nOf<Vector, std::vector>* =3D nullptr=
></span></div><div><span style=3D"font-family:"courier new",mo=
nospace">void func(const Vector& vec) { ... }</span></div></div></block=
quote><div><br><div><div>Sorry maybe I'm missing something but why can&=
#39;t you just do this?<br><br></div><span style=3D"font-family:monospace,m=
onospace">template <class T, class Alloc><br></span></div><span style=
=3D"font-family:monospace,monospace">void func(const std::vector<T, Allo=
c>& vec) { ... }</span><br></div><blockquote style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><span><font color=3D"#888888">
<p></p>
-- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
D4970SXEBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"D4970SXEBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/66dcaca8-65d4-4575-<wbr>8d6a-=
764c8d45279b%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i><=
/font><br><div></div><div></div><div></div></div></div></div></div>
</div></div>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c246a159-006d-46cb-a664-c8a599a6e39b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c246a159-006d-46cb-a664-c8a599a6e39b=
%40isocpp.org</a>.<br />
------=_Part_6550_1296596186.1487630497462--
------=_Part_6549_568658887.1487630497462--
.
Author: richard@oehli.at
Date: Mon, 20 Feb 2017 14:42:08 -0800 (PST)
Raw View
------=_Part_1183_1783087733.1487630528582
Content-Type: text/plain; charset=UTF-8
This would work fine in this case.
You couldn't have forwarding references with this approach. For that you'd need some of this instance_of SFINAE trickery.
-Richard
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8cee8446-2524-4b6e-862f-b75a21bd4b11%40isocpp.org.
------=_Part_1183_1783087733.1487630528582--
.
Author: Curious <aary@umich.edu>
Date: Mon, 20 Feb 2017 14:46:14 -0800 (PST)
Raw View
------=_Part_6404_2098199593.1487630774241
Content-Type: multipart/alternative;
boundary="----=_Part_6405_1428902320.1487630774241"
------=_Part_6405_1428902320.1487630774241
Content-Type: text/plain; charset=UTF-8
Hey Richard,
Could you give me an example of what you mean? I can try finding a
solution to that and including that in the original solution.
Thanks!
On Monday, February 20, 2017 at 5:42:08 PM UTC-5, ric...@oehli.at wrote:
>
> This would work fine in this case.
> You couldn't have forwarding references with this approach. For that you'd
> need some of this instance_of SFINAE trickery.
>
> -Richard
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1e0ce657-c9f2-4aae-8f00-49de1e0008d2%40isocpp.org.
------=_Part_6405_1428902320.1487630774241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Richard,=C2=A0<div><br></div><div>Could you give me an=
example of what you mean? =C2=A0I can try finding a solution to that and i=
ncluding that in the original solution. =C2=A0</div><div><br></div><div>Tha=
nks!<br><br>On Monday, February 20, 2017 at 5:42:08 PM UTC-5, ric...@oehli.=
at wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This would work fine =
in this case. <br>You couldn't have forwarding references with this app=
roach. For that you'd need some of this instance_of SFINAE trickery.<p>=
-Richard</p></blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1e0ce657-c9f2-4aae-8f00-49de1e0008d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e0ce657-c9f2-4aae-8f00-49de1e0008d2=
%40isocpp.org</a>.<br />
------=_Part_6405_1428902320.1487630774241--
------=_Part_6404_2098199593.1487630774241--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 20 Feb 2017 20:58:27 -0800
Raw View
On segunda-feira, 20 de fevereiro de 2017 14:41:37 PST Curious wrote:
> Also I feel like it would help people write good specialized functions,
> since there are a lot of functions that can be written to accept types with
> different interfaces but do the same logical thing, for example, you can
> think of a binary search function that would linearly iterate if a linked
> list would be passed and randomly jump around when a vector is passed.
> There are better iterator based solutions to the example I gave but I feel
> like it conveys what I have in mind!
Isn't that what Concepts are for?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/26104184.L91FLTzXFm%40tjmaciei-mobl1.
.
Author: Curious <aary@umich.edu>
Date: Mon, 20 Feb 2017 21:04:49 -0800 (PST)
Raw View
------=_Part_1277_542334324.1487653489405
Content-Type: multipart/alternative;
boundary="----=_Part_1278_378434084.1487653489405"
------=_Part_1278_378434084.1487653489405
Content-Type: text/plain; charset=UTF-8
The way I understood it, concepts would still need a backend or be built on
top of type traits and SFINAE, is this not correct?
On Monday, February 20, 2017 at 11:58:32 PM UTC-5, Thiago Macieira wrote:
>
> On segunda-feira, 20 de fevereiro de 2017 14:41:37 PST Curious wrote:
> > Also I feel like it would help people write good specialized functions,
> > since there are a lot of functions that can be written to accept types
> with
> > different interfaces but do the same logical thing, for example, you can
> > think of a binary search function that would linearly iterate if a
> linked
> > list would be passed and randomly jump around when a vector is passed.
> > There are better iterator based solutions to the example I gave but I
> feel
> > like it conveys what I have in mind!
>
> Isn't that what Concepts are for?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6bd94047-810f-4e84-9a3c-e62c3c2f3860%40isocpp.org.
------=_Part_1278_378434084.1487653489405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The way I understood it, concepts would still need a backe=
nd or be built on top of type traits and SFINAE, is this not correct?<br><b=
r>On Monday, February 20, 2017 at 11:58:32 PM UTC-5, Thiago Macieira wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 20 de fevere=
iro de 2017 14:41:37 PST Curious wrote:
<br>> Also I feel like it would help people write good specialized funct=
ions,
<br>> since there are a lot of functions that can be written to accept t=
ypes with
<br>> different interfaces but do the same logical thing, for example, y=
ou can
<br>> think of a binary search function that would linearly iterate if a=
linked
<br>> list would be passed and randomly jump around when a vector is pas=
sed.
<br>> =C2=A0There are better iterator based solutions to the example I g=
ave but I feel
<br>> like it conveys what I have in mind!
<br>
<br>Isn't that what Concepts are for?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6bd94047-810f-4e84-9a3c-e62c3c2f3860%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bd94047-810f-4e84-9a3c-e62c3c2f3860=
%40isocpp.org</a>.<br />
------=_Part_1278_378434084.1487653489405--
------=_Part_1277_542334324.1487653489405--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 20 Feb 2017 21:20:57 -0800 (PST)
Raw View
------=_Part_7289_1327130966.1487654457687
Content-Type: multipart/alternative;
boundary="----=_Part_7290_468849491.1487654457688"
------=_Part_7290_468849491.1487654457688
Content-Type: text/plain; charset=UTF-8
On Monday, February 20, 2017 at 5:41:37 PM UTC-5, Curious wrote:
>
> I feel like it would be a much more readable alternative than that because
> the solution of including the template parameters becomes a lot more
> complicated when there are multiple arguments, and each have two-three
> "hidden" template parameters.
>
> Also I feel like it would help people write good specialized functions,
> since there are a lot of functions that can be written to accept types with
> different interfaces but do the same logical thing, for example, you can
> think of a binary search function that would linearly iterate if a linked
> list would be passed and randomly jump around when a vector is passed.
>
.... that makes no sense. A binary search function should be a *binary
search*. So it makes absolutely no sense for a binary search algorithm to
work on types that binary searches can't work on.
And it also doesn't make sense to have some kind of "omni-search" function,
because binary search only works if the container is *sorted*. When is not
something you can determine from its type.
There are better iterator based solutions to the example I gave but I feel
> like it conveys what I have in mind!
>
> On Monday, February 20, 2017 at 5:36:20 PM UTC-5, Brian Bi wrote:
>>
>> On Mon, Feb 20, 2017 at 2:31 PM, Curious <aa...@umich.edu> wrote:
>>
>>> I have seen some problems in the past associated with passing objects of
>>> classes that are instantiations of templates with multiple parameter with
>>> one or more than one default parameters. For example, if I have the
>>> following function
>>>
>>> void func(const std::vector<int>& vec) { ... }
>>>
>>> I cannot call it like so
>>>
>>> auto vec = std::vector<int, MyAllocator>{};
>>> func(vec);
>>>
>>> Because the type of the second parameter (i.e. the allocator) is
>>> different. Maybe the following type trait can be useful for situations
>>> like this?
>>>
>>> template <typename Type, template <typename...> class InstantiationType>
>>> struct is_instantiation_of : std::integral_constant<bool, false> {};
>>>
>>> template <template <typename...> class Thing, typename... Args>
>>> struct is_instantiation_of<Thing<Args...>, Thing> :
>>> std::integral_constant<bool, true> {};
>>>
>>> This way one could write a function that accepts any type of vector like
>>> this (without concepts)
>>>
>>> template <typename Type, template <typename...> class Thing>
>>> using EnableIfIsInstantiationOf =
>>> std::enable_if_t<is_instantiation_of<Type, Thing>::value>;
>>>
>>> template <typename Vector, EnableIfIsInstantiationOf<Vector,
>>> std::vector>* = nullptr>
>>> void func(const Vector& vec) { ... }
>>>
>>
>> Sorry maybe I'm missing something but why can't you just do this?
>>
>> template <class T, class Alloc>
>> void func(const std::vector<T, Alloc>& vec) { ... }
>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>>
>> --
>> *Brian Bi*
>>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01c2e748-f6e3-44b4-a38b-8b66f681c758%40isocpp.org.
------=_Part_7290_468849491.1487654457688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 20, 2017 at 5:41:37 PM UTC-5, Curious =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I feel =
like it would be a much more readable alternative than that because the sol=
ution of including the template parameters becomes a lot more complicated w=
hen there are multiple arguments, and each have two-three "hidden"=
; template parameters.<div><br></div><div>Also I feel like it would help pe=
ople write good specialized functions, since there are a lot of functions t=
hat can be written to accept types with different interfaces but do the sam=
e logical thing, for example, you can think of a binary search function tha=
t would linearly iterate if a linked list would be passed and randomly jump=
around when a vector is passed.</div></div></blockquote><div><br>... that =
makes no sense. A binary search function should be a <i>binary search</i>. =
So it makes absolutely no sense for a binary search algorithm to work on ty=
pes that binary searches can't work on.<br><br>And it also doesn't =
make sense to have some kind of "omni-search" function, because b=
inary search only works if the container is <i>sorted</i>. When is not some=
thing you can determine from its type.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div> There are better iterator base=
d solutions to the example I gave but I feel like it conveys what I have in=
mind!<br><br>On Monday, February 20, 2017 at 5:36:20 PM UTC-5, Brian Bi wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D=
"font-family:monospace,monospace"></span><div><div class=3D"gmail_quote">On=
Mon, Feb 20, 2017 at 2:31 PM, Curious <span dir=3D"ltr"><<a rel=3D"nofo=
llow">aa...@umich.edu</a>></span> wrote:<br><blockquote style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" =
class=3D"gmail_quote"><div dir=3D"ltr">I have seen some problems in the pas=
t associated with passing objects of classes that are instantiations of tem=
plates with multiple parameter with one or more than one default parameters=
..=C2=A0 For example, if I have the following function<div><br></div><div><f=
ont face=3D"courier new, monospace">void func(const std::vector<int>&=
amp; vec) { ... }</font></div><div><font face=3D"courier new, monospace"><b=
r></font></div><div><font face=3D"arial, sans-serif">I cannot call it like =
so=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></div=
><div><font face=3D"courier new, monospace">auto vec =3D std::vector<int=
, MyAllocator>{};</font></div><div><font face=3D"courier new, monospace"=
>func(vec);</font></div><div><font face=3D"courier new, monospace"><br></fo=
nt></div><div><font face=3D"arial, sans-serif">Because the type of the seco=
nd parameter (i.e. the allocator) is different.=C2=A0 Maybe the following t=
ype trait can be useful for situations like this?</font></div><div><br></di=
v><div><div><font face=3D"courier new, monospace">template <typename Typ=
e, template <typename...> class InstantiationType></font></div><di=
v><font face=3D"courier new, monospace">struct is_instantiation_of : std::i=
ntegral_constant<bool, false> {};</font></div><div><font face=3D"cour=
ier new, monospace"><br></font></div><div><font face=3D"courier new, monosp=
ace">template <template <typename...> class Thing, typename... Arg=
s></font></div><div><font face=3D"courier new, monospace">struct is_inst=
antiation_of<Thing<<wbr>Args...>, Thing>=C2=A0</font><span styl=
e=3D"font-family:"courier new",monospace">: std::integral_constan=
t<bool, true> {};</span></div><div><br></div></div><div>This way one =
could write a function that accepts any type of vector like this (without c=
oncepts)</div><div><br></div><div><font face=3D"courier new, monospace">tem=
plate <typename Type, template <typename...> class Thing></font=
></div><div><font face=3D"courier new, monospace">using EnableIfIsInstantia=
tionOf =3D std::enable_if_t<is_<wbr>instantiation_of<Type, Thing>:=
:value>;</font></div><div><font face=3D"courier new, monospace"><br></fo=
nt></div><div><font face=3D"courier new, monospace">template <typename V=
ector,=C2=A0</font><span style=3D"font-family:"courier new",monos=
pace">EnableIfIsInstantiatio<wbr>nOf<Vector, std::vector>* =3D nullpt=
r></span></div><div><span style=3D"font-family:"courier new",m=
onospace">void func(const Vector& vec) { ... }</span></div></div></bloc=
kquote><div><br><div><div>Sorry maybe I'm missing something but why can=
't you just do this?<br><br></div><span style=3D"font-family:monospace,=
monospace">template <class T, class Alloc><br></span></div><span styl=
e=3D"font-family:monospace,monospace">void func(const std::vector<T, All=
oc>& vec) { ... }</span><br></div><blockquote style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><span><font color=3D"#888888">
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/66dcaca8-65d4-4575-<wbr>8d6a-=
764c8d45279b%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i><=
/font><br><div></div><div></div><div></div></div></div></div></div>
</div></div>
</blockquote></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/01c2e748-f6e3-44b4-a38b-8b66f681c758%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01c2e748-f6e3-44b4-a38b-8b66f681c758=
%40isocpp.org</a>.<br />
------=_Part_7290_468849491.1487654457688--
------=_Part_7289_1327130966.1487654457687--
.
Author: Curious <aary@umich.edu>
Date: Mon, 20 Feb 2017 21:26:36 -0800 (PST)
Raw View
------=_Part_1263_1024257274.1487654797003
Content-Type: multipart/alternative;
boundary="----=_Part_1264_1015939967.1487654797003"
------=_Part_1264_1015939967.1487654797003
Content-Type: text/plain; charset=UTF-8
Well you can't really binary search a linked list can you? If you do try
and do that, it would degrade to worse than linear time.
Also when someone says binary search a range I think its safe to assume
that the range is already sorted.
"When is not something you can determine from its type." -- It's not
something you should be determining at runtime either, no binary search
function should start by inspecting the range to see if it's already
sorted.
On Tuesday, February 21, 2017 at 12:20:57 AM UTC-5, Nicol Bolas wrote:
>
> On Monday, February 20, 2017 at 5:41:37 PM UTC-5, Curious wrote:
>>
>> I feel like it would be a much more readable alternative than that
>> because the solution of including the template parameters becomes a lot
>> more complicated when there are multiple arguments, and each have two-three
>> "hidden" template parameters.
>>
>> Also I feel like it would help people write good specialized functions,
>> since there are a lot of functions that can be written to accept types with
>> different interfaces but do the same logical thing, for example, you can
>> think of a binary search function that would linearly iterate if a linked
>> list would be passed and randomly jump around when a vector is passed.
>>
>
> ... that makes no sense. A binary search function should be a *binary
> search*. So it makes absolutely no sense for a binary search algorithm to
> work on types that binary searches can't work on.
>
> And it also doesn't make sense to have some kind of "omni-search"
> function, because binary search only works if the container is *sorted*.
> When is not something you can determine from its type.
>
> There are better iterator based solutions to the example I gave but I feel
>> like it conveys what I have in mind!
>>
>> On Monday, February 20, 2017 at 5:36:20 PM UTC-5, Brian Bi wrote:
>>>
>>> On Mon, Feb 20, 2017 at 2:31 PM, Curious <aa...@umich.edu> wrote:
>>>
>>>> I have seen some problems in the past associated with passing objects
>>>> of classes that are instantiations of templates with multiple parameter
>>>> with one or more than one default parameters. For example, if I have the
>>>> following function
>>>>
>>>> void func(const std::vector<int>& vec) { ... }
>>>>
>>>> I cannot call it like so
>>>>
>>>> auto vec = std::vector<int, MyAllocator>{};
>>>> func(vec);
>>>>
>>>> Because the type of the second parameter (i.e. the allocator) is
>>>> different. Maybe the following type trait can be useful for situations
>>>> like this?
>>>>
>>>> template <typename Type, template <typename...> class InstantiationType>
>>>> struct is_instantiation_of : std::integral_constant<bool, false> {};
>>>>
>>>> template <template <typename...> class Thing, typename... Args>
>>>> struct is_instantiation_of<Thing<Args...>, Thing> :
>>>> std::integral_constant<bool, true> {};
>>>>
>>>> This way one could write a function that accepts any type of vector
>>>> like this (without concepts)
>>>>
>>>> template <typename Type, template <typename...> class Thing>
>>>> using EnableIfIsInstantiationOf =
>>>> std::enable_if_t<is_instantiation_of<Type, Thing>::value>;
>>>>
>>>> template <typename Vector, EnableIfIsInstantiationOf<Vector,
>>>> std::vector>* = nullptr>
>>>> void func(const Vector& vec) { ... }
>>>>
>>>
>>> Sorry maybe I'm missing something but why can't you just do this?
>>>
>>> template <class T, class Alloc>
>>> void func(const std::vector<T, Alloc>& vec) { ... }
>>>
>>>> --
>>>> 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-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> *Brian Bi*
>>>
>>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44cbdeab-7994-467d-98a7-c01879bd050e%40isocpp.org.
------=_Part_1264_1015939967.1487654797003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well you can't really binary search a linked list can =
you? =C2=A0If you do try and do that, it would degrade to worse than linear=
time.=C2=A0<br><br>Also when someone says binary search a range I think it=
s safe to assume that the range is already sorted.=C2=A0<div><br></div><div=
>"When is not something you can determine from its type." =C2=A0-=
- It's not something you should be determining at runtime either, no bi=
nary search function should start by inspecting the range to see if it'=
s already sorted.=C2=A0</div><div><br><div>On Tuesday, February 21, 2017 at=
12:20:57 AM UTC-5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">On Monday, February 20, 2017 at 5:41:37 PM UTC-5, =
Curious wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I fe=
el like it would be a much more readable alternative than that because the =
solution of including the template parameters becomes a lot more complicate=
d when there are multiple arguments, and each have two-three "hidden&q=
uot; template parameters.<div><br></div><div>Also I feel like it would help=
people write good specialized functions, since there are a lot of function=
s that can be written to accept types with different interfaces but do the =
same logical thing, for example, you can think of a binary search function =
that would linearly iterate if a linked list would be passed and randomly j=
ump around when a vector is passed.</div></div></blockquote><div><br>... th=
at makes no sense. A binary search function should be a <i>binary search</i=
>. So it makes absolutely no sense for a binary search algorithm to work on=
types that binary searches can't work on.<br><br>And it also doesn'=
;t make sense to have some kind of "omni-search" function, becaus=
e binary search only works if the container is <i>sorted</i>. When is not s=
omething you can determine from its type.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div> There are better iterator based =
solutions to the example I gave but I feel like it conveys what I have in m=
ind!<br><br>On Monday, February 20, 2017 at 5:36:20 PM UTC-5, Brian Bi wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"f=
ont-family:monospace,monospace"></span><div><div class=3D"gmail_quote">On M=
on, Feb 20, 2017 at 2:31 PM, Curious <span dir=3D"ltr"><<a rel=3D"nofoll=
ow">aa...@umich.edu</a>></span> wrote:<br><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" cl=
ass=3D"gmail_quote"><div dir=3D"ltr">I have seen some problems in the past =
associated with passing objects of classes that are instantiations of templ=
ates with multiple parameter with one or more than one default parameters.=
=C2=A0 For example, if I have the following function<div><br></div><div><fo=
nt face=3D"courier new, monospace">void func(const std::vector<int>&a=
mp; vec) { ... }</font></div><div><font face=3D"courier new, monospace"><br=
></font></div><div><font face=3D"arial, sans-serif">I cannot call it like s=
o=C2=A0</font></div><div><font face=3D"arial, sans-serif"><br></font></div>=
<div><font face=3D"courier new, monospace">auto vec =3D std::vector<int,=
MyAllocator>{};</font></div><div><font face=3D"courier new, monospace">=
func(vec);</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"arial, sans-serif">Because the type of the secon=
d parameter (i.e. the allocator) is different.=C2=A0 Maybe the following ty=
pe trait can be useful for situations like this?</font></div><div><br></div=
><div><div><font face=3D"courier new, monospace">template <typename Type=
, template <typename...> class InstantiationType></font></div><div=
><font face=3D"courier new, monospace">struct is_instantiation_of : std::in=
tegral_constant<bool, false> {};</font></div><div><font face=3D"couri=
er new, monospace"><br></font></div><div><font face=3D"courier new, monospa=
ce">template <template <typename...> class Thing, typename... Args=
></font></div><div><font face=3D"courier new, monospace">struct is_insta=
ntiation_of<Thing<<wbr>Args...>, Thing>=C2=A0</font><span style=
=3D"font-family:"courier new",monospace">: std::integral_constant=
<bool, true> {};</span></div><div><br></div></div><div>This way one c=
ould write a function that accepts any type of vector like this (without co=
ncepts)</div><div><br></div><div><font face=3D"courier new, monospace">temp=
late <typename Type, template <typename...> class Thing></font>=
</div><div><font face=3D"courier new, monospace">using EnableIfIsInstantiat=
ionOf =3D std::enable_if_t<is_<wbr>instantiation_of<Type, Thing>::=
value>;</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"courier new, monospace">template <typename Ve=
ctor,=C2=A0</font><span style=3D"font-family:"courier new",monosp=
ace">EnableIfIsInstantiatio<wbr>nOf<Vector, std::vector>* =3D nullptr=
></span></div><div><span style=3D"font-family:"courier new",mo=
nospace">void func(const Vector& vec) { ... }</span></div></div></block=
quote><div><br><div><div>Sorry maybe I'm missing something but why can&=
#39;t you just do this?<br><br></div><span style=3D"font-family:monospace,m=
onospace">template <class T, class Alloc><br></span></div><span style=
=3D"font-family:monospace,monospace">void func(const std::vector<T, Allo=
c>& vec) { ... }</span><br></div><blockquote style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><span><font color=3D"#888888">
<p></p>
-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/66dcaca8-65d4-4575-8d6a-764c8d45279b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/66dcaca8-65d4-4575-<wbr>8d6a-=
764c8d45279b%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i><=
/font><br><div></div><div></div><div></div></div></div></div></div>
</div></div>
</blockquote></div></div></blockquote></div></blockquote></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/44cbdeab-7994-467d-98a7-c01879bd050e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44cbdeab-7994-467d-98a7-c01879bd050e=
%40isocpp.org</a>.<br />
------=_Part_1264_1015939967.1487654797003--
------=_Part_1263_1024257274.1487654797003--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 20 Feb 2017 22:02:55 -0800 (PST)
Raw View
------=_Part_1051_1225949470.1487656975757
Content-Type: multipart/alternative;
boundary="----=_Part_1052_66195247.1487656975757"
------=_Part_1052_66195247.1487656975757
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 21, 2017 at 12:26:37 AM UTC-5, Curious wrote:
>
> Well you can't really binary search a linked list can you? If you do try
> and do that, it would degrade to worse than linear time.
>
Right. Which is why `std::binary_search` and `std::equal_range` require
random access iterators.
By permitting users to call these functions with the wrong kinds of types *at
all*, you are declaring such calls to be legitimate. Even if they're slow,
you're declaring that they are legitimate uses of the API.
Also when someone says binary search a range I think its safe to assume
> that the range is already sorted.
>
> "When is not something you can determine from its type." -- It's not
> something you should be determining at runtime either, no binary search
> function should start by inspecting the range to see if it's already sorted.
>
Right. Which is precisely why you have different functions for linear
search and binary search. The binary search should be a binary search and
the linear search should be a linear search.
The algorithm that gets used should not be based on the type you pass.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/72fad7b6-01e9-439d-9617-7af1ae740049%40isocpp.org.
------=_Part_1052_66195247.1487656975757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 21, 2017 at 12:26:37 AM UTC-5, Curiou=
s 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">Well =
you can't really binary search a linked list can you? =C2=A0If you do t=
ry and do that, it would degrade to worse than linear time.<br></div></bloc=
kquote><div><br>Right. Which is why `std::binary_search` and `std::equal_ra=
nge` require random access iterators.<br><br>By permitting users to call th=
ese functions with the wrong kinds of types <i>at all</i>, you are declarin=
g such calls to be legitimate. Even if they're slow, you're declari=
ng that they are legitimate uses of the API.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Also when someone says binary =
search a range I think its safe to assume that the range is already sorted.=
=C2=A0<div><br></div><div>"When is not something you can determine fro=
m its type." =C2=A0-- It's not something you should be determining=
at runtime either, no binary search function should start by inspecting th=
e range to see if it's already sorted.</div></div></blockquote><div dir=
=3D"ltr"><br>Right. Which is precisely why you have different functions for=
linear search and binary search. The binary search should be a binary sear=
ch and the linear search should be a linear search.<br><br>The algorithm th=
at gets used should not be based on the type you pass.<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>
</div></div>
</blockquote></div></div></blockquote></div></blockquote></div></div></div>=
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/72fad7b6-01e9-439d-9617-7af1ae740049%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72fad7b6-01e9-439d-9617-7af1ae740049=
%40isocpp.org</a>.<br />
------=_Part_1052_66195247.1487656975757--
------=_Part_1051_1225949470.1487656975757--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 20 Feb 2017 22:15:55 -0800
Raw View
On segunda-feira, 20 de fevereiro de 2017 21:04:49 PST Curious wrote:
> The way I understood it, concepts would still need a backend or be built on
> top of type traits and SFINAE, is this not correct?
And how is that different from what you proposed? You're talking about a
specific trait: an instantiation of a particular template class.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6389804.cBX2nG3Ayl%40tjmaciei-mobl1.
.
Author: Curious <aary@umich.edu>
Date: Tue, 21 Feb 2017 05:46:34 -0800 (PST)
Raw View
------=_Part_1277_576278403.1487684794271
Content-Type: multipart/alternative;
boundary="----=_Part_1278_698942668.1487684794272"
------=_Part_1278_698942668.1487684794272
Content-Type: text/plain; charset=UTF-8
I was thinking that this would be a good trait that can be put in the
standard library because it can potentially have a lot of uses, maybe in
implementing concepts.
On Tuesday, February 21, 2017 at 1:16:05 AM UTC-5, Thiago Macieira wrote:
>
> On segunda-feira, 20 de fevereiro de 2017 21:04:49 PST Curious wrote:
> > The way I understood it, concepts would still need a backend or be built
> on
> > top of type traits and SFINAE, is this not correct?
>
> And how is that different from what you proposed? You're talking about a
> specific trait: an instantiation of a particular template class.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/266d1a57-fba8-4770-b862-ce9877e48f50%40isocpp.org.
------=_Part_1278_698942668.1487684794272
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was thinking that this would be a good trait that can be=
put in the standard library because it can potentially have a lot of uses,=
maybe in implementing concepts.=C2=A0<br><br>On Tuesday, February 21, 2017=
at 1:16:05 AM UTC-5, Thiago Macieira wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On segunda-feira, 20 de fevereiro de 2017 21:04:49 PST Curiou=
s wrote:
<br>> The way I understood it, concepts would still need a backend or be=
built on
<br>> top of type traits and SFINAE, is this not correct?
<br>
<br>And how is that different from what you proposed? You're talking ab=
out a=20
<br>specific trait: an instantiation of a particular template class.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/266d1a57-fba8-4770-b862-ce9877e48f50%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/266d1a57-fba8-4770-b862-ce9877e48f50=
%40isocpp.org</a>.<br />
------=_Part_1278_698942668.1487684794272--
------=_Part_1277_576278403.1487684794271--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 21 Feb 2017 09:32:32 -0500
Raw View
--001a113d1bd21f83a005490b4055
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 20, 2017 at 5:31 PM, Curious <aary@umich.edu> wrote:
> I have seen some problems in the past associated with passing objects of
> classes that are instantiations of templates with multiple parameter with
> one or more than one default parameters. For example, if I have the
> following function
>
> void func(const std::vector<int>& vec) { ... }
>
> I cannot call it like so
>
> auto vec = std::vector<int, MyAllocator>{};
> func(vec);
>
> Because the type of the second parameter (i.e. the allocator) is
> different. Maybe the following type trait can be useful for situations
> like this?
>
> template <typename Type, template <typename...> class InstantiationType>
> struct is_instantiation_of : std::integral_constant<bool, false> {};
>
> template <template <typename...> class Thing, typename... Args>
> struct is_instantiation_of<Thing<Args...>, Thing> :
> std::integral_constant<bool, true> {};
>
> This way one could write a function that accepts any type of vector like
> this (without concepts)
>
> template <typename Type, template <typename...> class Thing>
> using EnableIfIsInstantiationOf = std::enable_if_t<is_instantiation_of<Type,
> Thing>::value>;
>
> template <typename Vector, EnableIfIsInstantiationOf<Vector,
> std::vector>* = nullptr>
> void func(const Vector& vec) { ... }
>
I find this useful but the cases you presented are not particularly
convincing because they are better handled without SFINAE. One place this
is useful is for *disabling* rather than enabling when a type is an
instantiation of a particular template (this is a common pattern even in
the standard library, where you have a T that shouldn't match something
like in_place_type_t<T> in a constructor. A different usage is when you are
dealing with a forwarding reference. For instance: template <class T,
std::enable_if_t<is_instantiation_of_v<std::decay_t<T>, std::variant>, int>
= 0> void foo(T&& a); In fact, the latter case is so common that you might
want a version that removes reference/cv automatically.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEkk8O%2BBu65tPpn8_grJqPsFwx2_LEoRWaXVwjTJ%3DHF0pQ%40mail.gmail.com.
--001a113d1bd21f83a005490b4055
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Feb 20, 2017 at 5:31 PM, Curious <span dir=3D"ltr"><<a href=3D"mailt=
o:aary@umich.edu" target=3D"_blank">aary@umich.edu</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I have =
seen some problems in the past associated with passing objects of classes t=
hat are instantiations of templates with multiple parameter with one or mor=
e than one default parameters.=C2=A0 For example, if I have the following f=
unction<div><br></div><div><font face=3D"courier new, monospace">void func(=
const std::vector<int>& vec) { ... }</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"arial, sans=
-serif">I cannot call it like so=C2=A0</font></div><div><font face=3D"arial=
, sans-serif"><br></font></div><div><font face=3D"courier new, monospace">a=
uto vec =3D std::vector<int, MyAllocator>{};</font></div><div><font f=
ace=3D"courier new, monospace">func(vec);</font></div><div><font face=3D"co=
urier new, monospace"><br></font></div><div><font face=3D"arial, sans-serif=
">Because the type of the second parameter (i.e. the allocator) is differen=
t.=C2=A0 Maybe the following type trait can be useful for situations like t=
his?</font></div><div><br></div><div><div><font face=3D"courier new, monosp=
ace">template <typename Type, template <typename...> class Instant=
iationType></font></div><div><font face=3D"courier new, monospace">struc=
t is_instantiation_of : std::integral_constant<bool, false> {};</font=
></div><div><font face=3D"courier new, monospace"><br></font></div><div><fo=
nt face=3D"courier new, monospace">template <template <typename...>=
; class Thing, typename... Args></font></div><div><font face=3D"courier =
new, monospace">struct is_instantiation_of<Thing<<wbr>Args...>, Th=
ing>=C2=A0</font><span style=3D"font-family:"courier new",mono=
space">: std::integral_constant<bool, true> {};</span></div><div><br>=
</div></div><div>This way one could write a function that accepts any type =
of vector like this (without concepts)</div><div><br></div><div><font face=
=3D"courier new, monospace">template <typename Type, template <typena=
me...> class Thing></font></div><div><font face=3D"courier new, monos=
pace">using EnableIfIsInstantiationOf =3D std::enable_if_t<is_<wbr>insta=
ntiation_of<Type, Thing>::value>;</font></div><div><font face=3D"c=
ourier new, monospace"><br></font></div><div><font face=3D"courier new, mon=
ospace">template <typename Vector,=C2=A0</font><span style=3D"font-famil=
y:"courier new",monospace">EnableIfIsInstantiatio<wbr>nOf<Vect=
or, std::vector>* =3D nullptr></span></div><div><span style=3D"font-f=
amily:"courier new",monospace">void func(const Vector& vec) {=
... }</span></div></div></blockquote><div><br></div><div>I find this usefu=
l but the cases you presented are not particularly convincing because they =
are better handled without SFINAE. One place this is useful is for *disabli=
ng* rather than enabling when a type is an instantiation of a particular te=
mplate (this is a common pattern even in the standard library, where you ha=
ve a T that shouldn't match something like in_place_type_t<T> in =
a constructor. A different usage is when you are dealing with a forwarding =
reference. For instance: template <class T, std::enable_if_t<is_insta=
ntiation_of_v<std::decay_t<T>, std::variant>, int> =3D 0>=
void foo(T&& a); In fact, the latter case is so common that you mi=
ght want a version that removes reference/cv automatically.</div></div><br>=
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEkk8O%2BBu65tPpn8_grJqPsFwx2_LE=
oRWaXVwjTJ%3DHF0pQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEkk8O%2=
BBu65tPpn8_grJqPsFwx2_LEoRWaXVwjTJ%3DHF0pQ%40mail.gmail.com</a>.<br />
--001a113d1bd21f83a005490b4055--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 21 Feb 2017 09:40:08 -0500
Raw View
--001a113d17da47bb7205490b5bcd
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 21, 2017 at 1:02 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, February 21, 2017 at 12:26:37 AM UTC-5, Curious wrote:
>>
>> Well you can't really binary search a linked list can you? If you do try
>> and do that, it would degrade to worse than linear time.
>>
>
> Right. Which is why `std::binary_search` and `std::equal_range` require
> random access iterators.
>
Nit: they actually only require forward iterators. There are several
algorithms that you likely only want to call with random access iterators,
but the standard allows forward iterators. Their complexity is logarithmic
in terms of number of applications of the predicate, but is linear with
respect to iteration.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnNQfMYotOu-%3DegFRfDBht_JLeePGCvuPwTZZBdm%3DN%3D5A%40mail.gmail.com.
--001a113d17da47bb7205490b5bcd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 21, 2017 at 1:02 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Tuesday, February 21, 2017 at 12:26:37 AM UTC-5, Curious wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Well you can't re=
ally binary search a linked list can you?=C2=A0 If you do try and do that, =
it would degrade to worse than linear time.<br></div></blockquote></span><d=
iv><br>Right. Which is why `std::binary_search` and `std::equal_range` requ=
ire random access iterators.<br></div></div></blockquote><div><br></div><di=
v>Nit: they actually only require forward iterators. There are several algo=
rithms that you likely only want to call with random access iterators, but =
the standard allows forward iterators. Their complexity is logarithmic in t=
erms of number of applications of the predicate, but is linear with respect=
to iteration.</div></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnNQfMYotOu-%3DegFRfDBht_JLeePG=
CvuPwTZZBdm%3DN%3D5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnNQf=
MYotOu-%3DegFRfDBht_JLeePGCvuPwTZZBdm%3DN%3D5A%40mail.gmail.com</a>.<br />
--001a113d17da47bb7205490b5bcd--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 21 Feb 2017 10:30:06 -0800
Raw View
On ter=C3=A7a-feira, 21 de fevereiro de 2017 05:46:34 PST Curious wrote:
> I was thinking that this would be a good trait that can be put in the
> standard library because it can potentially have a lot of uses, maybe in
> implementing concepts.
I'm not saying it's a bad trait to have. But not in the use-cases you=20
described.
I predict that most of the cases where you would have wanted your trait wou=
ld=20
be better served by concepts. You don't really want "any instantiation of=
=20
std::vector", you want instead a concept of vector, so that you can support=
=20
other vector types like QVector.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6932123.V5eSlSPzzO%40tjmaciei-mobl1.
.