Topic: Covariancy and containers conversion
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 20 Apr 2014 20:46:46 -0300
Raw View
Hi,
I think this is already in other languages such as C#, and I think
it's something useful.
Think about this: if I can feed a "group of" animals, why can't I feed
a "group of" rabbits?
struct Animal
{
virtual void feed(Food);
};
struct Rabbit: Animal {};
void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah*/ =
}
void somewhere()
{
std::array<Rabbit*, 10> myRabbits;
feed10Animals(myRabbits); // here!
}
Of course this should apply to other containers as well, and moreover,
not only about containment,
I think the real underlying relationship is that there should be a way
to stablish this: that
a container of Derived pointers is a derived itself of a container of
Base pointers, so the
above example would be simply a regular upcast.
In a more general way,
if exists
template <class T> aContainer;
and
Derived is derived of Base
then
template <class Derived>
class aContainer<Derived*> : public aContainer<Base*>;
from the user's POV.
What do we need for this in terms of language tools?
Concepts? Reflection?
This thread is of course just to open a discussion.
Daniel.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 20 Apr 2014 17:54:37 -0700
Raw View
Em dom 20 abr 2014, =E0s 20:46:46, dgutson . escreveu:
> Hi,
>=20
> I think this is already in other languages such as C#, and I think
> it's something useful.
How do you do the contravariance?
> struct Animal
> {
> virtual void feed(Food);
> };
>=20
> struct Rabbit: Animal {};
>=20
> void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah*=
/ }
void replaceAnimal(std::array<Animal *, 10> &animals)
{
for (int i =3D 0; i < 10; ++i) {
delete animals[i];
animals[i] =3D new Tortoise;
};
}
> void somewhere()
> {
> std::array<Rabbit*, 10> myRabbits;
> feed10Animals(myRabbits); // here!
replaceAnimals(myRabbits);
> }
After the call above, std::array<Rabbit *, 10> contains pointers to Tortois=
e,=20
not to Rabbits. How do you propose this be prevented?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 20 Apr 2014 17:56:08 -0700
Raw View
--bcaec520ef3b01594804f782f7db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Apr 20, 2014 at 4:46 PM, dgutson . <danielgutson@gmail.com> wrote:
> Hi,
>
> I think this is already in other languages such as C#, and I think
> it's something useful.
>
> Think about this: if I can feed a "group of" animals, why can't I feed
> a "group of" rabbits?
>
> struct Animal
> {
> virtual void feed(Food);
> };
>
> struct Rabbit: Animal {};
>
> void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah*=
/
> }
>
> void somewhere()
> {
> std::array<Rabbit*, 10> myRabbits;
> feed10Animals(myRabbits); // here!
> }
>
>
> Of course this should apply to other containers as well, and moreover,
> not only about containment,
> I think the real underlying relationship is that there should be a way
> to stablish this: that
> a container of Derived pointers is a derived itself of a container of
> Base pointers, so the
> above example would be simply a regular upcast.
>
> In a more general way,
>
> if exists
> template <class T> aContainer;
> and
> Derived is derived of Base
> then
>
> template <class Derived>
> class aContainer<Derived*> : public aContainer<Base*>;
>
> from the user's POV.
>
I don't think this is as straightforward as just adding the right typing
rule. Even ignoring the possibility of different template specializations
behaving differently, it is not the case that B derives from A =3D> array<B=
*>
can be used as array<A*>, because they might be represented differently:
struct Animal : boost::noncopyable {};
struct Rabbit : boost::noncopyable, Animal {};
extern std::array<Rabbit*, 10> x;
Note: pointers in 'x' do *not* point to Animals.
What do we need for this in terms of language tools?
> Concepts? Reflection?
>
> This thread is of course just to open a discussion.
>
> Daniel.
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
>
> ---
> 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/.
>
--=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/.
--bcaec520ef3b01594804f782f7db
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 S=
un, Apr 20, 2014 at 4:46 PM, dgutson . <span dir=3D"ltr"><<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
=C2=A0 I think this is already in other languages such as C#, and I think<b=
r>
it's something useful.<br>
<br>
Think about this: if I can feed a "group of" animals, why can'=
;t I feed<br>
a "group of" rabbits?<br>
<br>
struct Animal<br>
{<br>
=C2=A0 =C2=A0 virtual void feed(Food);<br>
};<br>
<br>
struct Rabbit: Animal {};<br>
<br>
void Feed10Animals(std::array<Animal*, 10>& animals) { /* for bla=
blablah*/ }<br>
<br>
void somewhere()<br>
{<br>
=C2=A0 =C2=A0 std::array<Rabbit*, 10> myRabbits;<br>
=C2=A0 =C2=A0 feed10Animals(myRabbits); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // here!<br>
}<br>
<br>
<br>
Of course this should apply to other containers as well, and moreover,<br>
not only about containment,<br>
I think the real underlying relationship is that there should be a way<br>
to stablish this: that<br>
a container of Derived pointers is a derived itself of a container of<br>
Base pointers, so the<br>
above example would be simply a regular upcast.<br>
<br>
In a more general way,<br>
<br>
if exists<br>
=C2=A0 =C2=A0template <class T> aContainer;<br>
and<br>
=C2=A0 =C2=A0Derived is derived of Base<br>
then<br>
<br>
=C2=A0 =C2=A0template <class Derived><br>
=C2=A0 =C2=A0class aContainer<Derived*> : public aContainer<Base*&=
gt;;<br>
<br>
from the user's POV.<br></blockquote><div><br></div><div>I don't th=
ink this is as straightforward as just adding the right typing rule. Even i=
gnoring the possibility of different template specializations behaving diff=
erently, it is not the case that B derives from A =3D> array<B*> c=
an be used as array<A*>, because they might be represented differentl=
y:</div>
<div><br></div><div>struct Animal : boost::noncopyable {};</div><div>struct=
Rabbit : boost::noncopyable, Animal {};</div><div><br></div><div>extern st=
d::array<Rabbit*, 10> x;</div><div><br></div><div>Note: pointers in &=
#39;x' do *not* point to Animals.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
What do we need for this in terms of language tools?<br>
Concepts? Reflection?<br>
<br>
This thread is of course just to open a discussion.<br>
<br>
=C2=A0 =C2=A0 Daniel.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
--<br>
Who=E2=80=99s got the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>
Who=E2=80=99d never, ever start an argument?<br>
Who never shows a bit of temperament?<br>
Who's never wrong but always right?<br>
Who'd never dream of starting a fight?<br>
Who get stuck with all the bad luck?<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></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 />
--bcaec520ef3b01594804f782f7db--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 20 Apr 2014 22:42:04 -0300
Raw View
Guys,
thanks for answering, but please, note that in no way I want to
propose a solution because I don't have one. I want to first discuss
what should happen from the user's point of view, or, IOW, what could
be done first, and then what shouldn't be done; once established those
limits, maybe we could think of a set of solutions that satisfies both
requirements (DOs and DONTs).
So, please postpone thinking about implementation (and their potential
problems) and let's put the user hat on. As you can see, I don't claim
this to be at any close to a proposal, but a discussion.
Now, what about FIRST limiting this problem to the STL, smart pointers
and containers?
On Sun, Apr 20, 2014 at 9:56 PM, Richard Smith <richard@metafoo.co.uk> wrot=
e:
> On Sun, Apr 20, 2014 at 4:46 PM, dgutson . <danielgutson@gmail.com> wrote=
:
>>
>> Hi,
>>
>> I think this is already in other languages such as C#, and I think
>> it's something useful.
>>
>> Think about this: if I can feed a "group of" animals, why can't I feed
>> a "group of" rabbits?
>>
>> struct Animal
>> {
>> virtual void feed(Food);
>> };
>>
>> struct Rabbit: Animal {};
>>
>> void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah=
*/
>> }
>>
>> void somewhere()
>> {
>> std::array<Rabbit*, 10> myRabbits;
>> feed10Animals(myRabbits); // here!
>> }
>>
>>
>> Of course this should apply to other containers as well, and moreover,
>> not only about containment,
>> I think the real underlying relationship is that there should be a way
>> to stablish this: that
>> a container of Derived pointers is a derived itself of a container of
>> Base pointers, so the
>> above example would be simply a regular upcast.
>>
>> In a more general way,
>>
>> if exists
>> template <class T> aContainer;
>> and
>> Derived is derived of Base
>> then
>>
>> template <class Derived>
>> class aContainer<Derived*> : public aContainer<Base*>;
>>
>> from the user's POV.
>
>
> I don't think this is as straightforward as just adding the right typing
> rule. Even ignoring the possibility of different template specializations
> behaving differently, it is not the case that B derives from A =3D> array=
<B*>
> can be used as array<A*>, because they might be represented differently:
>
> struct Animal : boost::noncopyable {};
> struct Rabbit : boost::noncopyable, Animal {};
>
> extern std::array<Rabbit*, 10> x;
>
> Note: pointers in 'x' do *not* point to Animals.
>
>> What do we need for this in terms of language tools?
>> Concepts? Reflection?
>>
>> This thread is of course just to open a discussion.
>>
>> Daniel.
>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 20 Apr 2014 19:31:48 -0700
Raw View
Em dom 20 abr 2014, =E0s 22:42:04, dgutson . escreveu:
> Now, what about FIRST limiting this problem to the STL, smart pointers
> and containers?
My other email proved that it cannot and should not be done for containers.=
=20
That leaves smart pointers and the solution is already implemented there.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Sun, 20 Apr 2014 22:42:45 -0400
Raw View
--001a113a98e645c5f804f7847459
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
One place not previously mentioned is arguments to virtual functions. This,
I believe, is less problematic, although I am not sure what the added value
of the feature would be. That would be, enabling the following code
(covariance of return types already being supported):
struct A {};
struct B : A {};
struct base {
virtual A& f(B&);
};
struct derived : base {
virtual B& f(A&);
};
Now, the first issue is that this is a breaking change. In the current
language, 'derived::f' is not an override of 'base::f' and adding
contra-variance of argument types can break programs that depend on this.
David
On Sun, Apr 20, 2014 at 10:31 PM, Thiago Macieira <thiago@macieira.org>wrot=
e:
> Em dom 20 abr 2014, =C3=A0s 22:42:04, dgutson . escreveu:
> > Now, what about FIRST limiting this problem to the STL, smart pointers
> > and containers?
>
> My other email proved that it cannot and should not be done for container=
s.
> That leaves smart pointers and the solution is already implemented there.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>
--=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/.
--001a113a98e645c5f804f7847459
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One place not previously mentioned is arguments to virtual=
functions. This, I believe, is less problematic, although I am not sure wh=
at the added value of the feature would be. That would be, enabling the fol=
lowing code (covariance of return types already being supported):<div>
<br></div><div>struct A {};</div><div>struct B : A {};</div><div>struct bas=
e {</div><div>=C2=A0 =C2=A0virtual A& f(B&);</div><div>};</div><div=
>struct derived : base {</div><div>=C2=A0 =C2=A0virtual B& f(A&);</=
div><div>};</div>
<div><br></div><div>Now, the first issue is that this is a breaking change.=
In the current language, 'derived::f' is not an override of 'b=
ase::f' and adding contra-variance of argument types can break programs=
that depend on this.</div>
<div><br></div><div>=C2=A0 =C2=A0David</div><div><br></div></div><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Apr 20, 2014 at=
10:31 PM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@m=
acieira.org" target=3D"_blank">thiago@macieira.org</a>></span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em dom 20 abr 2014, =C3=A0s 22:42:04, dgutso=
n . escreveu:<br>
<div class=3D"">> Now, what about FIRST limiting this problem to the STL=
, smart pointers<br>
> and containers?<br>
<br>
</div>My other email proved that it cannot and should not be done for conta=
iners.<br>
That leaves smart pointers and the solution is already implemented there.<b=
r>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 535=
8<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--001a113a98e645c5f804f7847459--
.
Author: Casey Carter <cartec69@gmail.com>
Date: Mon, 21 Apr 2014 09:30:37 -0700 (PDT)
Raw View
------=_Part_2753_6675665.1398097837099
Content-Type: text/plain; charset=UTF-8
On Sunday, April 20, 2014 6:46:46 PM UTC-5, dgutson . wrote:
>
>
> Think about this: if I can feed a "group of" animals, why can't I feed
> a "group of" rabbits?
>
> struct Animal
> {
> virtual void feed(Food);
> };
>
> struct Rabbit: Animal {};
>
> void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah*/
> }
>
> void somewhere()
> {
> std::array<Rabbit*, 10> myRabbits;
> feed10Animals(myRabbits); // here!
> }
>
>
How does
template <typename Container>
void FeedAnimals(Container& c) {
std::for_each(begin(c), end(c), [](auto ptr){ ptr->feed(); });
}
with the addition of appropriate constraints - ideally via Concepts Lite -
not fill this need?
--
---
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_2753_6675665.1398097837099
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, April 20, 2014 6:46:46 PM UTC-5, dgutson . wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><br>Think about this: if I c=
an feed a "group of" animals, why can't I feed
<br>a "group of" rabbits?
<br>
<br>struct Animal
<br>{
<br> virtual void feed(Food);
<br>};
<br>
<br>struct Rabbit: Animal {};
<br>
<br>void Feed10Animals(std::array<<wbr>Animal*, 10>& animals) { /=
* for blablablah*/ }
<br>
<br>void somewhere()
<br>{
<br> std::array<Rabbit*, 10> myRabbits;
<br> feed10Animals(myRabbits); &nb=
sp; // here!
<br>}
<br><br></blockquote><div><br></div><div>How does</div><div><br></div><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Co=
ntainer</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">FeedAnimals</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Container</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">for_ea=
ch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">c</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">end</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> ptr</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> ptr</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">-></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">feed</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">});</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></d=
iv><div><br><span style=3D"font-size: 13px;">with the addition of appropria=
te constraints - ideally via Concepts Lite - not fill this need?</span><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_2753_6675665.1398097837099--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 21 Apr 2014 12:55:05 -0400
Raw View
--001a11c0ff12729b1b04f7905c32
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 21, 2014 at 12:30 PM, Casey Carter <cartec69@gmail.com> wrote:
> How does
>
> template <typename Container>
> void FeedAnimals(Container& c) {
> std::for_each(begin(c), end(c), [](auto ptr){ ptr->feed(); });
> }
>
>
> with the addition of appropriate constraints - ideally via Concepts Lite -
> not fill this need?
>
> Well, that is a different beast. You could argue, for example, that
'FeedAnimals' cannot be made a virtual function, or that the compiler will
generate code for each type stored in the container, even if in all cases
the same virtual member function could be called.
--
---
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/.
--001a11c0ff12729b1b04f7905c32
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, Apr 21, 2014 at 12:30 PM, Casey Carter <span dir=3D"ltr"><<a href=3D=
"mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D""><div>How does<br></div></=
div>
<div><br></div><div style=3D"background-color:rgb(250,250,250);border:1px s=
olid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color=
:rgb(0,0,136)">template</span><span style> </span><span style=3D"color:rgb(=
102,102,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><s=
pan style> </span><span style=3D"color:rgb(102,0,102)">Container</span><spa=
n style=3D"color:rgb(102,102,0)">></span><span style><br>
</span><span style=3D"color:rgb(0,0,136)">void</span><span style> </span><s=
pan style=3D"color:rgb(102,0,102)">FeedAnimals</span><span style=3D"color:r=
gb(102,102,0)">(</span><span style=3D"color:rgb(102,0,102)">Container</span=
><span style=3D"color:rgb(102,102,0)">&</span><span style> c</span><spa=
n style=3D"color:rgb(102,102,0)">)</span><span style> </span><span style=3D=
"color:rgb(102,102,0)">{</span><span style><br>
=C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span style>=
for_each</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"=
color:rgb(0,0,136)">begin</span><span style=3D"color:rgb(102,102,0)">(</spa=
n><span style>c</span><span style=3D"color:rgb(102,102,0)">),</span><span s=
tyle> </span><span style=3D"color:rgb(0,0,136)">end</span><span style=3D"co=
lor:rgb(102,102,0)">(</span><span style>c</span><span style=3D"color:rgb(10=
2,102,0)">),</span><span style> </span><span style=3D"color:rgb(102,102,0)"=
>[](</span><span style=3D"color:rgb(0,0,136)">auto</span><span style> ptr</=
span><span style=3D"color:rgb(102,102,0)">){</span><span style> ptr</span><=
span style=3D"color:rgb(102,102,0)">-></span><span style>feed</span><spa=
n style=3D"color:rgb(102,102,0)">();</span><span style> </span><span style=
=3D"color:rgb(102,102,0)">});</span><span style><br>
</span><span style=3D"color:rgb(102,102,0)">}</span><span style><br><br></s=
pan></div></code></div><div><br><span style=3D"font-size:13px">with the add=
ition of appropriate constraints - ideally via Concepts Lite - not fill thi=
s need?</span><br>
</div></div><div class=3D""><div class=3D"h5">
<p></p></div></div></blockquote></div>Well, that is a different beast. You =
could argue, for example, that 'FeedAnimals' cannot be made a virtu=
al function, or that the compiler will generate code for each type stored i=
n the container, even if in all cases the same virtual member function coul=
d be called.<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 />
--001a11c0ff12729b1b04f7905c32--
.
Author: xavi <gratal@gmail.com>
Date: Tue, 22 Apr 2014 20:12:31 +0200
Raw View
--001a113ab3ec3b9aea04f7a58f76
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
A possible solution would be at the iterator-level:
std::array<Rabbit*,n>::const_iterator could be convertible to
std::array<Animal*,m>::const_iterator. This could be applied to any
container.
Also, std::array<Rabbit,n>::iterator is already convertible to
std::array<Animal,m>::iterator in most (all?) implementations, since they
are just pointers, but this could also be extended to the rest of
containers.
This would allow a non-templated, non-inline implementation of
Feed10Animals, or any number of animals, while being safe, as long as it is
only allowed for const_iterators in the pointer case.
2014-04-21 18:55 GMT+02:00 David Rodr=C3=ADguez Ibeas <dibeas@ieee.org>:
> On Mon, Apr 21, 2014 at 12:30 PM, Casey Carter <cartec69@gmail.com> wrote=
:
>
>> How does
>>
>> template <typename Container>
>> void FeedAnimals(Container& c) {
>> std::for_each(begin(c), end(c), [](auto ptr){ ptr->feed(); });
>> }
>>
>>
>> with the addition of appropriate constraints - ideally via Concepts Lite
>> - not fill this need?
>>
>> Well, that is a different beast. You could argue, for example, that
> 'FeedAnimals' cannot be made a virtual function, or that the compiler wil=
l
> generate code for each type stored in the container, even if in all cases
> the same virtual member function could be called.
>
> --
>
> ---
> 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/.
>
--=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/.
--001a113ab3ec3b9aea04f7a58f76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A possible solution would be at the iterator-level: std::a=
rray<Rabbit*,n>::const_iterator could be convertible to std::array<=
;Animal*,m>::const_iterator. This could be applied to any container.<div=
>
Also, std::array<Rabbit,n>::iterator is already convertible to std::a=
rray<Animal,m>::iterator in most (all?) implementations, since they a=
re just pointers, but this could also be extended to the rest of containers=
..</div>
<div><br></div><div>This would allow a non-templated, non-inline implementa=
tion of Feed10Animals, or any number of animals, while being safe, as long =
as it is only allowed for const_iterators in the pointer case.</div></div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-04-21 18=
:55 GMT+02:00 David Rodr=C3=ADguez Ibeas <span dir=3D"ltr"><<a href=3D"m=
ailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>></span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D""><div class=3D"g=
mail_quote">On Mon, Apr 21, 2014 at 12:30 PM, Casey Carter <span dir=3D"ltr=
"><<a href=3D"mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmai=
l.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div>How does<br></div></div>
<div><br></div><div style=3D"background-color:rgb(250,250,250);border:1px s=
olid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color=
:rgb(0,0,136)">template</span><span> </span><span style=3D"color:rgb(102,10=
2,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><span> <=
/span><span style=3D"color:rgb(102,0,102)">Container</span><span style=3D"c=
olor:rgb(102,102,0)">></span><span><br>
</span><span style=3D"color:rgb(0,0,136)">void</span><span> </span><span st=
yle=3D"color:rgb(102,0,102)">FeedAnimals</span><span style=3D"color:rgb(102=
,102,0)">(</span><span style=3D"color:rgb(102,0,102)">Container</span><span=
style=3D"color:rgb(102,102,0)">&</span><span> c</span><span style=3D"c=
olor:rgb(102,102,0)">)</span><span> </span><span style=3D"color:rgb(102,102=
,0)">{</span><span><br>
=C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span>for_ea=
ch</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:=
rgb(0,0,136)">begin</span><span style=3D"color:rgb(102,102,0)">(</span><spa=
n>c</span><span style=3D"color:rgb(102,102,0)">),</span><span> </span><span=
style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rgb(102,102,0)=
">(</span><span>c</span><span style=3D"color:rgb(102,102,0)">),</span><span=
> </span><span style=3D"color:rgb(102,102,0)">[](</span><span style=3D"colo=
r:rgb(0,0,136)">auto</span><span> ptr</span><span style=3D"color:rgb(102,10=
2,0)">){</span><span> ptr</span><span style=3D"color:rgb(102,102,0)">-><=
/span><span>feed</span><span style=3D"color:rgb(102,102,0)">();</span><span=
> </span><span style=3D"color:rgb(102,102,0)">});</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">}</span><span><br><br></span></=
div></code></div><div><br><span style=3D"font-size:13px">with the addition =
of appropriate constraints - ideally via Concepts Lite - not fill this need=
?</span><br>
</div></div><div><div>
<p></p></div></div></blockquote></div></div>Well, that is a different beast=
.. You could argue, for example, that 'FeedAnimals' cannot be made a=
virtual function, or that the compiler will generate code for each type st=
ored in the container, even if in all cases the same virtual member functio=
n could be called.<br>
</div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--001a113ab3ec3b9aea04f7a58f76--
.
Author: xavi <gratal@gmail.com>
Date: Tue, 22 Apr 2014 20:23:46 +0200
Raw View
--047d7bdc80d87b45e904f7a5b723
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
And also, at the language level, if B inherits from A, is there any good
reason why the conversion from 'B * const *' to 'A * const *' is currently
forbidden?
I believe it is safe, and it would automatically allow the above conversion
for array const_iterators.
2014-04-22 20:12 GMT+02:00 xavi <gratal@gmail.com>:
> A possible solution would be at the iterator-level:
> std::array<Rabbit*,n>::const_iterator could be convertible to
> std::array<Animal*,m>::const_iterator. This could be applied to any
> container.
> Also, std::array<Rabbit,n>::iterator is already convertible to
> std::array<Animal,m>::iterator in most (all?) implementations, since they
> are just pointers, but this could also be extended to the rest of
> containers.
>
> This would allow a non-templated, non-inline implementation of
> Feed10Animals, or any number of animals, while being safe, as long as it =
is
> only allowed for const_iterators in the pointer case.
>
>
> 2014-04-21 18:55 GMT+02:00 David Rodr=C3=ADguez Ibeas <dibeas@ieee.org>:
>
> On Mon, Apr 21, 2014 at 12:30 PM, Casey Carter <cartec69@gmail.com> wrote=
:
>>
>>> How does
>>>
>>> template <typename Container>
>>> void FeedAnimals(Container& c) {
>>> std::for_each(begin(c), end(c), [](auto ptr){ ptr->feed(); });
>>> }
>>>
>>>
>>> with the addition of appropriate constraints - ideally via Concepts Lit=
e
>>> - not fill this need?
>>>
>>> Well, that is a different beast. You could argue, for example, that
>> 'FeedAnimals' cannot be made a virtual function, or that the compiler wi=
ll
>> generate code for each type stored in the container, even if in all case=
s
>> the same virtual member function could be called.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>
--=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/.
--047d7bdc80d87b45e904f7a5b723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">And also, at the language level, if B inherits from A, is =
there any good reason why the conversion from 'B * const *' to '=
;A * const *' is currently forbidden?<div>I believe it is safe, and it =
would automatically allow the above conversion for array const_iterators.</=
div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-04=
-22 20:12 GMT+02:00 xavi <span dir=3D"ltr"><<a href=3D"mailto:gratal@gma=
il.com" target=3D"_blank">gratal@gmail.com</a>></span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr">A possible solution would be at the iterator-level: std::a=
rray<Rabbit*,n>::const_iterator could be convertible to std::array<=
;Animal*,m>::const_iterator. This could be applied to any container.<div=
>
Also, std::array<Rabbit,n>::iterator is already convertible to std::a=
rray<Animal,m>::iterator in most (all?) implementations, since they a=
re just pointers, but this could also be extended to the rest of containers=
..</div>
<div><br></div><div>This would allow a non-templated, non-inline implementa=
tion of Feed10Animals, or any number of animals, while being safe, as long =
as it is only allowed for const_iterators in the pointer case.</div></div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-04-21 18=
:55 GMT+02:00 David Rodr=C3=ADguez Ibeas <span dir=3D"ltr"><<a href=3D"m=
ailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>></span>:<di=
v><div class=3D"h5">
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_quote"=
>On Mon, Apr 21, 2014 at 12:30 PM, Casey Carter <span dir=3D"ltr"><<a hr=
ef=3D"mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div>How does<br></div></div>
<div><br></div><div style=3D"background-color:rgb(250,250,250);border:1px s=
olid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color=
:rgb(0,0,136)">template</span><span> </span><span style=3D"color:rgb(102,10=
2,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><span> <=
/span><span style=3D"color:rgb(102,0,102)">Container</span><span style=3D"c=
olor:rgb(102,102,0)">></span><span><br>
</span><span style=3D"color:rgb(0,0,136)">void</span><span> </span><span st=
yle=3D"color:rgb(102,0,102)">FeedAnimals</span><span style=3D"color:rgb(102=
,102,0)">(</span><span style=3D"color:rgb(102,0,102)">Container</span><span=
style=3D"color:rgb(102,102,0)">&</span><span> c</span><span style=3D"c=
olor:rgb(102,102,0)">)</span><span> </span><span style=3D"color:rgb(102,102=
,0)">{</span><span><br>
=C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span>for_ea=
ch</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:=
rgb(0,0,136)">begin</span><span style=3D"color:rgb(102,102,0)">(</span><spa=
n>c</span><span style=3D"color:rgb(102,102,0)">),</span><span> </span><span=
style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rgb(102,102,0)=
">(</span><span>c</span><span style=3D"color:rgb(102,102,0)">),</span><span=
> </span><span style=3D"color:rgb(102,102,0)">[](</span><span style=3D"colo=
r:rgb(0,0,136)">auto</span><span> ptr</span><span style=3D"color:rgb(102,10=
2,0)">){</span><span> ptr</span><span style=3D"color:rgb(102,102,0)">-><=
/span><span>feed</span><span style=3D"color:rgb(102,102,0)">();</span><span=
> </span><span style=3D"color:rgb(102,102,0)">});</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">}</span><span><br><br></span></=
div></code></div><div><br><span style=3D"font-size:13px">with the addition =
of appropriate constraints - ideally via Concepts Lite - not fill this need=
?</span><br>
</div></div><div><div>
<p></p></div></div></blockquote></div></div>Well, that is a different beast=
.. You could argue, for example, that 'FeedAnimals' cannot be made a=
virtual function, or that the compiler will generate code for each type st=
ored in the container, even if in all cases the same virtual member functio=
n could be called.<br>
</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--047d7bdc80d87b45e904f7a5b723--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 22 Apr 2014 21:29:51 +0300
Raw View
On 22 April 2014 21:23, xavi <gratal@gmail.com> wrote:
> And also, at the language level, if B inherits from A, is there any good
> reason why the conversion from 'B * const *' to 'A * const *' is currently
> forbidden?
> I believe it is safe, and it would automatically allow the above conversion
> for array const_iterators.
Safe? If I have a B* const*, and I convert it to A* const*, I can put
a C-derived-from-A
where this A* const* points to. Now the code that expected to have a B will have
a C and hell breaks loose. It's not safe. See
http://www.stroustrup.com/bs_faq2.html#conversion, the same principle applies
even if the pointers are const, because the pointees are not.
--
---
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/.
.
Author: xavi <gratal@gmail.com>
Date: Tue, 22 Apr 2014 20:38:44 +0200
Raw View
--047d7bdc80d8f9a18604f7a5ec27
Content-Type: text/plain; charset=UTF-8
How exactly can you do what you say?
let's take the following code:
B* pointerToB=new B;
B* const * pointerToConstPointerToB=&pointerToB;
A* const * pointerToConstPointerToA=pointerToConstPointerToB; //currently
illegal, I claim it's safe
*pointerToConstPointerToA=new C; //illegal, since PointerToA is const. (I
believe that's what you mean).
**pointerToConstPointerToA=C(); //yes, that's possible as long as there is
a copy-assignment operator defined for A, but this is already possible by
the allowed conversion from B* to A*
What would allow what you say is the conversion from 'B** const' to 'A**
const', which is not safe, and should remain forbidden
2014-04-22 20:29 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 22 April 2014 21:23, xavi <gratal@gmail.com> wrote:
> > And also, at the language level, if B inherits from A, is there any good
> > reason why the conversion from 'B * const *' to 'A * const *' is
> currently
> > forbidden?
> > I believe it is safe, and it would automatically allow the above
> conversion
> > for array const_iterators.
>
>
> Safe? If I have a B* const*, and I convert it to A* const*, I can put
> a C-derived-from-A
> where this A* const* points to. Now the code that expected to have a B
> will have
> a C and hell breaks loose. It's not safe. See
> http://www.stroustrup.com/bs_faq2.html#conversion, the same principle
> applies
> even if the pointers are const, because the pointees are not.
>
> --
>
> ---
> 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/.
>
--
---
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/.
--047d7bdc80d8f9a18604f7a5ec27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How exactly can you do what you say?<div>let's take th=
e following code:</div><div><br></div><div>B* pointerToB=3Dnew B;</div><div=
>B* const * pointerToConstPointerToB=3D&pointerToB;</div><div>A* const =
* pointerToConstPointerToA=3DpointerToConstPointerToB; //currently illegal,=
I claim it's safe</div>
<div>*pointerToConstPointerToA=3Dnew C; //illegal, since PointerToA is cons=
t. (I believe that's what you mean).</div><div>**pointerToConstPointerT=
oA=3DC(); //yes, that's possible as long as there is a copy-assignment =
operator defined for A, but this is already possible by the allowed convers=
ion from B* to A*</div>
<div><br></div><div>What would allow what you say is the conversion from &#=
39;B** const' to 'A** const', which is not safe, and should rem=
ain forbidden</div></div><div class=3D"gmail_extra"><br><br><div class=3D"g=
mail_quote">
2014-04-22 20:29 GMT+02:00 Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">On 22 April 2014 21:23, xavi <<a href=3D"mailto:gratal@g=
mail.com">gratal@gmail.com</a>> wrote:<br>
> And also, at the language level, if B inherits from A, is there any go=
od<br>
> reason why the conversion from 'B * const *' to 'A * const=
*' is currently<br>
> forbidden?<br>
> I believe it is safe, and it would automatically allow the above conve=
rsion<br>
> for array const_iterators.<br>
<br>
<br>
</div>Safe? If I have a B* const*, and I convert it to A* const*, I can put=
<br>
a C-derived-from-A<br>
where this A* const* points to. Now the code that expected to have a B will=
have<br>
a C and hell breaks loose. It's not safe. See<br>
<a href=3D"http://www.stroustrup.com/bs_faq2.html#conversion" target=3D"_bl=
ank">http://www.stroustrup.com/bs_faq2.html#conversion</a>, the same princi=
ple applies<br>
even if the pointers are const, because the pointees are not.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--047d7bdc80d8f9a18604f7a5ec27--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 22 Apr 2014 21:52:45 +0300
Raw View
On 22 April 2014 21:38, xavi <gratal@gmail.com> wrote:
> How exactly can you do what you say?
> let's take the following code:
>
> B* pointerToB=new B;
> B* const * pointerToConstPointerToB=&pointerToB;
> A* const * pointerToConstPointerToA=pointerToConstPointerToB; //currently
> illegal, I claim it's safe
> *pointerToConstPointerToA=new C; //illegal, since PointerToA is const. (I
> believe that's what you mean).
> **pointerToConstPointerToA=C(); //yes, that's possible as long as there is a
> copy-assignment operator defined for A, but this is already possible by the
> allowed conversion from B* to A*
The latter was what I was after. But that indeed slices C to an A
anyway, so it's not
problematic. Well, not any more problematic than things we already have.
So, the one you point out as safe looks safe so far.
I'm not convinced such a pointer-semantics change is the right answer
to the topic
of the thread, though.
--
---
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/.
.
Author: xavi <gratal@gmail.com>
Date: Tue, 22 Apr 2014 20:55:42 +0200
Raw View
--001a11353208a66aed04f7a629c6
Content-Type: text/plain; charset=UTF-8
It offers an iterator-based solution to the topic of the thread.
On second thought, what I propose is actually only safe if A is the first
non-empty base class of B. Otherwise the addresses of B and A would be
different for a given object of type B.
2014-04-22 20:52 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 22 April 2014 21:38, xavi <gratal@gmail.com> wrote:
> > How exactly can you do what you say?
> > let's take the following code:
> >
> > B* pointerToB=new B;
> > B* const * pointerToConstPointerToB=&pointerToB;
> > A* const * pointerToConstPointerToA=pointerToConstPointerToB; //currently
> > illegal, I claim it's safe
> > *pointerToConstPointerToA=new C; //illegal, since PointerToA is const. (I
> > believe that's what you mean).
> > **pointerToConstPointerToA=C(); //yes, that's possible as long as there
> is a
> > copy-assignment operator defined for A, but this is already possible by
> the
> > allowed conversion from B* to A*
>
> The latter was what I was after. But that indeed slices C to an A
> anyway, so it's not
> problematic. Well, not any more problematic than things we already have.
>
> So, the one you point out as safe looks safe so far.
>
> I'm not convinced such a pointer-semantics change is the right answer
> to the topic
> of the thread, though.
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11353208a66aed04f7a629c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It offers an iterator-based solution to the topic of the t=
hread.<div><br></div><div>On second thought, what I propose is actually onl=
y safe if A is the first non-empty base class of B. Otherwise the addresses=
of B and A would be different for a given object of type B.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-04=
-22 20:52 GMT+02:00 Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mail=
to:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.c=
om</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 22 April 2014 21:38, xavi=
<<a href=3D"mailto:gratal@gmail.com">gratal@gmail.com</a>> wrote:<br=
>
> How exactly can you do what you say?<br>
> let's take the following code:<br>
><br>
> B* pointerToB=3Dnew B;<br>
> B* const * pointerToConstPointerToB=3D&pointerToB;<br>
> A* const * pointerToConstPointerToA=3DpointerToConstPointerToB; //curr=
ently<br>
> illegal, I claim it's safe<br>
> *pointerToConstPointerToA=3Dnew C; //illegal, since PointerToA is cons=
t. (I<br>
> believe that's what you mean).<br>
> **pointerToConstPointerToA=3DC(); //yes, that's possible as long a=
s there is a<br>
> copy-assignment operator defined for A, but this is already possible b=
y the<br>
> allowed conversion from B* to A*<br>
<br>
</div>The latter was what I was after. But that indeed slices C to an A<br>
anyway, so it's not<br>
problematic. Well, not any more problematic than things we already have.<br=
>
<br>
So, the one you point out as safe looks safe so far.<br>
<br>
I'm not convinced such a pointer-semantics change is the right answer<b=
r>
to the topic<br>
of the thread, though.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--001a11353208a66aed04f7a629c6--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 22 Apr 2014 22:05:41 +0300
Raw View
On 22 April 2014 21:55, xavi <gratal@gmail.com> wrote:
> It offers an iterator-based solution to the topic of the thread.
I don't think we should make such assumptions about what types
iterators actually
are, nor should we necessarily make such conversions happen between iterators
of different types, even if safe.
> On second thought, what I propose is actually only safe if A is the first
> non-empty base class of B. Otherwise the addresses of B and A would be
> different for a given object of type B.
Urgh.
--
---
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/.
.
Author: Fernando Pelliccioni <fpelliccioni@gmail.com>
Date: Tue, 22 Apr 2014 19:09:28 -0300
Raw View
--089e01494324a2454304f7a8de1d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Daniel,
I think this feature is type unsafe.
The eiffel programming language has this feature, but brings with a problem
they denominate "CatCall".
I think the problem was well described by Thiago.
Are you looking for heterogeneous containers?
If so, maybe this will help.
Concept-Based Polymorphism
https://parasol.tamu.edu/people/bs/622-GP/value-semantics.pdf
Best,
Fernando.
On Sun, Apr 20, 2014 at 8:46 PM, dgutson . <danielgutson@gmail.com> wrote:
> Hi,
>
> I think this is already in other languages such as C#, and I think
> it's something useful.
>
> Think about this: if I can feed a "group of" animals, why can't I feed
> a "group of" rabbits?
>
> struct Animal
> {
> virtual void feed(Food);
> };
>
> struct Rabbit: Animal {};
>
> void Feed10Animals(std::array<Animal*, 10>& animals) { /* for blablablah*=
/
> }
>
> void somewhere()
> {
> std::array<Rabbit*, 10> myRabbits;
> feed10Animals(myRabbits); // here!
> }
>
>
> Of course this should apply to other containers as well, and moreover,
> not only about containment,
> I think the real underlying relationship is that there should be a way
> to stablish this: that
> a container of Derived pointers is a derived itself of a container of
> Base pointers, so the
> above example would be simply a regular upcast.
>
> In a more general way,
>
> if exists
> template <class T> aContainer;
> and
> Derived is derived of Base
> then
>
> template <class Derived>
> class aContainer<Derived*> : public aContainer<Base*>;
>
> from the user's POV.
>
> What do we need for this in terms of language tools?
> Concepts? Reflection?
>
> This thread is of course just to open a discussion.
>
> Daniel.
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
>
> ---
> 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/.
>
--=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/.
--089e01494324a2454304f7a8de1d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Daniel,</div><div><br></div><div>I think this feat=
ure is type unsafe.</div><div>The eiffel programming language has this feat=
ure, but brings with a problem they denominate "CatCall".</div><d=
iv>
I think the problem was well described by Thiago.</div><div><br></div><div>=
Are you looking for heterogeneous containers?</div><div>If so, maybe this w=
ill help.</div><div><br></div><div><span class=3D"" style=3D"white-space:pr=
e"> </span>Concept-Based Polymorphism</div>
<div><span class=3D"" style=3D"white-space:pre"> </span><a href=3D"https:/=
/parasol.tamu.edu/people/bs/622-GP/value-semantics.pdf">https://parasol.tam=
u.edu/people/bs/622-GP/value-semantics.pdf</a></div><div><br></div><div>Bes=
t,</div>
<div>Fernando.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"=
gmail_quote">On Sun, Apr 20, 2014 at 8:46 PM, dgutson . <span dir=3D"ltr">&=
lt;<a href=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson=
@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
=C2=A0 I think this is already in other languages such as C#, and I think<b=
r>
it's something useful.<br>
<br>
Think about this: if I can feed a "group of" animals, why can'=
;t I feed<br>
a "group of" rabbits?<br>
<br>
struct Animal<br>
{<br>
=C2=A0 =C2=A0 virtual void feed(Food);<br>
};<br>
<br>
struct Rabbit: Animal {};<br>
<br>
void Feed10Animals(std::array<Animal*, 10>& animals) { /* for bla=
blablah*/ }<br>
<br>
void somewhere()<br>
{<br>
=C2=A0 =C2=A0 std::array<Rabbit*, 10> myRabbits;<br>
=C2=A0 =C2=A0 feed10Animals(myRabbits); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // here!<br>
}<br>
<br>
<br>
Of course this should apply to other containers as well, and moreover,<br>
not only about containment,<br>
I think the real underlying relationship is that there should be a way<br>
to stablish this: that<br>
a container of Derived pointers is a derived itself of a container of<br>
Base pointers, so the<br>
above example would be simply a regular upcast.<br>
<br>
In a more general way,<br>
<br>
if exists<br>
=C2=A0 =C2=A0template <class T> aContainer;<br>
and<br>
=C2=A0 =C2=A0Derived is derived of Base<br>
then<br>
<br>
=C2=A0 =C2=A0template <class Derived><br>
=C2=A0 =C2=A0class aContainer<Derived*> : public aContainer<Base*&=
gt;;<br>
<br>
from the user's POV.<br>
<br>
What do we need for this in terms of language tools?<br>
Concepts? Reflection?<br>
<br>
This thread is of course just to open a discussion.<br>
<br>
=C2=A0 =C2=A0 Daniel.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
--<br>
Who=E2=80=99s got the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>
Who=E2=80=99d never, ever start an argument?<br>
Who never shows a bit of temperament?<br>
Who's never wrong but always right?<br>
Who'd never dream of starting a fight?<br>
Who get stuck with all the bad luck?<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--089e01494324a2454304f7a8de1d--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 29 Apr 2014 21:12:56 +0430
Raw View
--f46d043891fff250f904f83120d9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Other posts pointed out the flaws with OP`s approach. But if in some
project strong need for such an approach is felt, a pure library solution
exists and can be used for user-defined template classes derived from std.
I don`t tend to discuss the details but take a look at shared_ptr.
regards,
FM.
2014-04-21 7:01 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
> Em dom 20 abr 2014, =C3=A0s 22:42:04, dgutson . escreveu:
> > Now, what about FIRST limiting this problem to the STL, smart pointers
> > and containers?
>
> My other email proved that it cannot and should not be done for container=
s.
> That leaves smart pointers and the solution is already implemented there.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--=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/.
--f46d043891fff250f904f83120d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div style dir=3D"ltr">Other posts pointed out the flaws w=
ith OP`s approach. But if in some project strong need for such an approach =
is felt, a pure library solution exists and can be used for user-defined te=
mplate classes derived from std. I don`t tend to discuss the details but ta=
ke a look at shared_ptr.</div>
<div style dir=3D"ltr"><br></div><div style dir=3D"ltr">regards,</div><div =
style dir=3D"ltr">FM.</div></div><div class=3D"gmail_extra"><br><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">2014-04-21 7:01 GMT+04:30 Thiago Macie=
ira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"=
_blank">thiago@macieira.org</a>></span>:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em dom 20 abr 2014, =C3=A0s 22:42:04, dgutso=
n . escreveu:<br>
<div class=3D"">> Now, what about FIRST limiting this problem to the STL=
, smart pointers<br>
> and containers?<br>
<br>
</div>My other email proved that it cannot and should not be done for conta=
iners.<br>
That leaves smart pointers and the solution is already implemented there.<b=
r>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 535=
8<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your ha=
ir in the dark night??<br>unless the candle of your face does turn a lamp u=
p on my way!!!<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 />
--f46d043891fff250f904f83120d9--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 29 Apr 2014 23:15:37 -0400
Raw View
--001a11c225686374d604f839f6bc
Content-Type: text/plain; charset=UTF-8
On Tue, Apr 22, 2014 at 2:12 PM, xavi <gratal@gmail.com> wrote:
> A possible solution would be at the iterator-level:
> std::array<Rabbit*,n>::const_iterator could be convertible to
> std::array<Animal*,m>::const_iterator. This could be applied to any
> container.
> Also, std::array<Rabbit,n>::iterator is already convertible to
> std::array<Animal,m>::iterator in most (all?) implementations, since they
> are just pointers, but this could also be extended to the rest of
> containers.
>
The pointers are convertible, but you can't increment them. ie most likely
sizeof(Animal) != sizeof(Rabbit), so incrementing an Animal pointer will
not get you to the next Rabbit, it will leave you somewhere in the middle
of the first Rabbit (sizeof(Animal) into the first Rabbit), but "thinking"
that it is pointing to the next Animal/Rabbit.
You would need a some kind of base_pointer+size to do what you want.
C++ (and C, which we can blame it on) might have been better off if
pointer-to-object and pointer-to-element-of-array were more distinct (and
only one-way convertible).
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c225686374d604f839f6bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Apr 22, 2014 at 2:12 PM, xavi <span dir=3D"ltr"><<a href=
=3D"mailto:gratal@gmail.com" target=3D"_blank">gratal@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">A possible solution would b=
e at the iterator-level: std::array<Rabbit*,n>::const_iterator could =
be convertible to std::array<Animal*,m>::const_iterator. This could b=
e applied to any container.<div>
Also, std::array<Rabbit,n>::iterator is already convertible to std::a=
rray<Animal,m>::iterator in most (all?) implementations, since they a=
re just pointers, but this could also be extended to the rest of containers=
..</div>
</div></blockquote><div><br></div><div><br></div><div>The pointers are conv=
ertible, but you can't increment them. =C2=A0ie most likely sizeof(Anim=
al) !=3D sizeof(Rabbit), so incrementing an Animal pointer will not get you=
to the next Rabbit, it will leave you somewhere in the middle of the first=
Rabbit (sizeof(Animal) into the first Rabbit), but "thinking" th=
at it is pointing to the next Animal/Rabbit.</div>
<div><br></div><div>You would need a some kind of base_pointer+size to do w=
hat you want.</div><div><br></div><div>C++ (and C, which we can blame it on=
) might have been better off if pointer-to-object and pointer-to-element-of=
-array were more distinct (and only one-way convertible).</div>
<div><br></div><div>Tony</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 />
--001a11c225686374d604f839f6bc--
.