Topic: base class aliases
Author: rouslankorneychuk@gmail.com
Date: Fri, 27 Dec 2013 23:50:37 -0800 (PST)
Raw View
------=_Part_202_12434256.1388217037416
Content-Type: text/plain; charset=ISO-8859-1
I have a simple proposal that I think can be explained with an example. How
about something like this?:
class A : public *B = C* {
A() : B(3) {}
void do_something() {
/* ... */
B::do_something();
}
};
which would be equivalent to:
class A : public C {
typedef C B;
A() : B(3) {}
void do_something() {
/* ... */
B::do_something();
}
};
This would be useful when dealing with unwieldy template instantiations as
base classes:
template<typename T,typename Pasta> class monstrous : public something =
::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>
{};
Sure, you could use a typedef like my second code sample does, but you
would still have to repeat all the template arguments once, which is not
only redundant, but an opportunity for mistakes (mainly when updating code).
--
---
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_202_12434256.1388217037416
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have a simple proposal that I think can be explained wit=
h an example. How about something like this?:<br><br><span style=3D"font-fa=
mily: courier new,monospace;">class A : public <u>B =3D C</u> {<br> &n=
bsp; A() : B(3) {}<br><br> void do_something() {<br=
> /* ... */<br> =
B::do_something();<br> }<br>};</=
span><br><br>which would be equivalent to:<br><br><span style=3D"font-famil=
y: courier new,monospace;">class A : public C {<br> typed=
ef C B;<br><br> A() : B(3) {}<br><br> v=
oid do_something() {<br> /* ... *=
/<br> B::do_something();<br> =
; }<br>};</span><br><br>This would be useful when dealing with =
unwieldy template instantiations as base classes:<br><br><span style=3D"fon=
t-family: courier new,monospace;">template<typename T,typename Pasta>=
class monstrous : public something =3D ::something<monstrous<T,Pasta=
>,allocator<monstrous<T,Pasta>>,comparison<monstrous<T=
,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>> {}=
;</span><br><br>Sure, you could use a typedef like my second code sample do=
es, but you would still have to repeat all the template arguments once, whi=
ch is not only redundant, but an opportunity for mistakes (mainly when upda=
ting code).<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_202_12434256.1388217037416--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 28 Dec 2013 09:55:05 +0200
Raw View
On 28 December 2013 09:50, <rouslankorneychuk@gmail.com> wrote:
> I have a simple proposal that I think can be explained with an example. How
> about something like this?:
>
> class A : public B = C {
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
> which would be equivalent to:
>
> class A : public C {
> typedef C B;
>
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
> This would be useful when dealing with unwieldy template instantiations as
> base classes:
>
> template<typename T,typename Pasta> class monstrous : public something =
> ::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>
> {};
>
> Sure, you could use a typedef like my second code sample does, but you would
> still have to repeat all the template arguments once, which is not only
> redundant, but an opportunity for mistakes (mainly when updating code).
Please explain why you don't just put the typedef outside the class.
--
---
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: rouslankorneychuk@gmail.com
Date: Sat, 28 Dec 2013 00:07:56 -0800 (PST)
Raw View
------=_Part_105_5179939.1388218076988
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, December 28, 2013 2:55:05 AM UTC-5, Ville Voutilainen wrote:
> Please explain why you don't just put the typedef outside the class.
>
because the template arguments include both the class and the class'
template arguments (in the third code sample, where it would be useful)
--
---
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_105_5179939.1388218076988
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 28, 2013 2:55:05 AM UTC-5, Ville Vou=
tilainen wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Please expl=
ain why you don't just put the typedef outside the class.
<br></blockquote><div><br>because the template arguments include both the c=
lass and the class' template arguments (in the third code sample, where it =
would be useful)<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_105_5179939.1388218076988--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 28 Dec 2013 10:31:47 +0200
Raw View
On 28 December 2013 10:07, <rouslankorneychuk@gmail.com> wrote:
> On Saturday, December 28, 2013 2:55:05 AM UTC-5, Ville Voutilainen wrote:
>>
>> Please explain why you don't just put the typedef outside the class.
>
>
> because the template arguments include both the class and the class'
> template arguments (in the third code sample, where it would be useful)
You can still forward-declare the class and do the typedef without having
to do the typedef in the class, and with an alias template you can use the
template arguments of the class in the type alias.
--
---
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: rouslankorneychuk@gmail.com
Date: Sat, 28 Dec 2013 00:54:20 -0800 (PST)
Raw View
------=_Part_1642_7392608.1388220860723
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, December 28, 2013 3:31:47 AM UTC-5, Ville Voutilainen wrote:
>
> On 28 December 2013 10:07, <rouslank...@gmail.com <javascript:>> wrote:
> > On Saturday, December 28, 2013 2:55:05 AM UTC-5, Ville Voutilainen
> wrote:
> >>
> >> Please explain why you don't just put the typedef outside the class.
> >
> >
> > because the template arguments include both the class and the class'
> > template arguments (in the third code sample, where it would be useful)
>
> You can still forward-declare the class and do the typedef without having
> to do the typedef in the class, and with an alias template you can use the
> template arguments of the class in the type alias.
>
Sure, but you don't save very much doing it that way (the worst part being
you have to type out your template arguments three times).
--
---
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_1642_7392608.1388220860723
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 28, 2013 3:31:47 AM UTC-5, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 December =
2013 10:07, <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"9A2mSEjXX2AJ" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">rouslank...@gmai=
l.com</a>> wrote:
<br>> On Saturday, December 28, 2013 2:55:05 AM UTC-5, Ville Voutilainen=
wrote:
<br>>>
<br>>> Please explain why you don't just put the typedef outside the =
class.
<br>>
<br>>
<br>> because the template arguments include both the class and the clas=
s'
<br>> template arguments (in the third code sample, where it would be us=
eful)
<br>
<br>You can still forward-declare the class and do the typedef without havi=
ng
<br>to do the typedef in the class, and with an alias template you can use =
the
<br>template arguments of the class in the type alias.
<br></blockquote><div><br>Sure, but you don't save very much doing it that =
way (the worst part being you have to type out your template arguments thre=
e times).<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1642_7392608.1388220860723--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 28 Dec 2013 11:51:52 +0200
Raw View
On 28 December 2013 10:54, <rouslankorneychuk@gmail.com> wrote:
>> You can still forward-declare the class and do the typedef without having
>> to do the typedef in the class, and with an alias template you can use the
>> template arguments of the class in the type alias.
> Sure, but you don't save very much doing it that way (the worst part being
> you have to type out your template arguments three times).
Argh, indeed. Then, the next question: is this common enough to warrant a
language change? Sure it's useful for the case it's designed to solve, but
is it worth its cost? Do you have an implementation?
--
---
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: rouslankorneychuk@gmail.com
Date: Sat, 28 Dec 2013 02:36:14 -0800 (PST)
Raw View
------=_Part_1601_5038737.1388226974492
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, December 28, 2013 4:51:52 AM UTC-5, Ville Voutilainen wrote:
>
> On 28 December 2013 10:54, <rouslank...@gmail.com <javascript:>> wrote:
> >> You can still forward-declare the class and do the typedef without
> having
> >> to do the typedef in the class, and with an alias template you can use
> the
> >> template arguments of the class in the type alias.
> > Sure, but you don't save very much doing it that way (the worst part
> being
> > you have to type out your template arguments three times).
>
>
> Argh, indeed. Then, the next question: is this common enough to warrant a
> language change? Sure it's useful for the case it's designed to solve, but
> is it worth its cost? Do you have an implementation?
>
I don't have anything resembling an implementation. Should I try and
implement a patch for gcc or clang (it's not something I have ever done
before)?
As for whether it's common enough, I'm not sure how common it would have to
be. It is something I noticed would be useful in one of my own projects.
Though it looks like gcc's implementation of the standard library would
benefit from this. When I run
grep -r 'typedef .* _Base;' /usr/include/c++/4.7.2
on my system, I get 85 results.
--
---
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_1601_5038737.1388226974492
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 28, 2013 4:51:52 AM UTC-5, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 December =
2013 10:54, <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"mH3NJmtHLPgJ" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">rouslank...@gmai=
l.com</a>> wrote:
<br>>> You can still forward-declare the class and do the typedef wit=
hout having
<br>>> to do the typedef in the class, and with an alias template you=
can use the
<br>>> template arguments of the class in the type alias.
<br>> Sure, but you don't save very much doing it that way (the worst pa=
rt being
<br>> you have to type out your template arguments three times).
<br>
<br>
<br>Argh, indeed. Then, the next question: is this common enough to warrant=
a
<br>language change? Sure it's useful for the case it's designed to solve, =
but
<br>is it worth its cost? Do you have an implementation?
<br></blockquote><div><br>I don't have anything resembling an implementatio=
n. Should I try and implement a patch for gcc or clang (it's not something =
I have ever done before)?<br><br>As for whether it's common enough, I'm not=
sure how common it would have to be. It is something I noticed would be us=
eful in one of my own projects. Though it looks like gcc's implementation o=
f the standard library would benefit from this. When I run<br><br><span sty=
le=3D"font-family: courier new,monospace;">grep -r 'typedef .* _Base;' /usr=
/include/c++/4.7.2</span><br><br>on my system, I get 85 results.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1601_5038737.1388226974492--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 28 Dec 2013 20:54:21 +0800
Raw View
On 12/28/13 3:55 PM, Ville Voutilainen wrote:
> On 28 December 2013 09:50, <rouslankorneychuk@gmail.com> wrote:
>> I have a simple proposal that I think can be explained with an example. How
>> about something like this?:
>>
>> class A : public B = C {
>> A() : B(3) {}
>>
>> void do_something() {
>> /* ... */
>> B::do_something();
>> }
>> };
>>
>> which would be equivalent to:
>>
>> class A : public C {
>> typedef C B;
>>
>> A() : B(3) {}
>>
>> void do_something() {
>> /* ... */
>> B::do_something();
>> }
>> };
>>
>> This would be useful when dealing with unwieldy template instantiations as
>> base classes:
>>
>> template<typename T,typename Pasta> class monstrous : public something =
>> ::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>
>> {};
>>
>> Sure, you could use a typedef like my second code sample does, but you would
>> still have to repeat all the template arguments once, which is not only
>> redundant, but an opportunity for mistakes (mainly when updating code).
>
> Please explain why you don't just put the typedef outside the class.
Because it's type-dependent. Arguably it could be done with an alias
template:
template<typename T,typename Pasta>
using monstrous_base =
::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>;
template<typename T,typename Pasta>
class monstrous : public monstrous_base< T, Pasta > {
I prefer to avoid such namespace pollution though.
On the other hand, the idiom is only necessary when two direct bases
specialize the same template (or templates with the same name). When
there is only one, you can just use the injected-class-name.
typedef typename monstrous::something B;
This is my preferred idiom. A using declaration should also do the
trick, but it seems to be less compatible, and both GCC and Clang require
using typename monstrous::something::something; // Reduplicated something.
I think, when there are multiple base classes specializing the same
template, it is usually reasonable to specify the specializations as
external metafunctions.
On a related note though, it would be nice to have the
injected-class-name in scope for the base specifiers, for the sake of CRTP.
--
---
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: cornedbee@google.com
Date: Wed, 8 Jan 2014 03:31:28 -0800 (PST)
Raw View
------=_Part_191_19264253.1389180688322
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, December 28, 2013 10:51:52 AM UTC+1, Ville Voutilainen wrote:
>
> Argh, indeed. Then, the next question: is this common enough to warrant a
> language change? Sure it's useful for the case it's designed to solve, but
> is it worth its cost? Do you have an implementation?
>
This is a very common thing in Boost code.
One workaround is employed by Boost.Iterator, where e.g. the
iterator_facade template contains an iterator_facade_ alias of its own
type. This allows the deriving class to write my_class::iterator_facade_ to
reach the base. The my_class:: is necessary to make the lookup dependent.
This requires the base class to be designed for being derived from in this
way, of course. CRTP mixins should always do this, and yet they do not
offer such a typedef as a rule. (Note to self: go through own code and
follow this pattern. Get rid of lots of repetition.)
This language feature would work even if the base class author didn't
include the typedef.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_191_19264253.1389180688322
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, December 28, 2013 10:51:52 AM UTC+1, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Argh, =
indeed. Then, the next question: is this common enough to warrant a
<br>language change? Sure it's useful for the case it's designed to solve, =
but
<br>is it worth its cost? Do you have an implementation?
<br></blockquote><div><br></div><div>This is a very common thing in Boost c=
ode.</div><div><br></div><div>One workaround is employed by Boost.Iterator,=
where e.g. the iterator_facade template contains an iterator_facade_ alias=
of its own type. This allows the deriving class to write my_class::iterato=
r_facade_ to reach the base. The my_class:: is necessary to make the lookup=
dependent.</div><div><br></div><div>This requires the base class to be des=
igned for being derived from in this way, of course. CRTP mixins should alw=
ays do this, and yet they do not offer such a typedef as a rule. (Note to s=
elf: go through own code and follow this pattern. Get rid of lots of repeti=
tion.)</div><div><br></div><div>This language feature would work even if th=
e base class author didn't include the typedef.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_191_19264253.1389180688322--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 08 Jan 2014 20:43:16 +0800
Raw View
On 1/8/14 7:31 PM, cornedbee@google.com wrote:
> This is a very common thing in Boost code.
>
> One workaround is employed by Boost.Iterator, where e.g. the
> iterator_facade template contains an iterator_facade_ alias of its own
> type. This allows the deriving class to write my_class::iterator_facade_ to
> reach the base. The my_class:: is necessary to make the lookup dependent.
That sounds like a workaround to a platform-specific bug with
injected-class-names.
> This requires the base class to be designed for being derived from in this
> way, of course. CRTP mixins should always do this, and yet they do not
> offer such a typedef as a rule. (Note to self: go through own code and
> follow this pattern. Get rid of lots of repetition.)
It sounds like an anti-pattern to me. Double check that the
injected-class-name doesn't work on your supported platforms before
adding typedefs to duplicate it.
I regularly rely on the injected-class-name to identify the type of a
templated base class subobject. As noted in my previous message, the
technique doesn't work if two mixins came from the same template, but
then neither does the pattern you mention.
--
---
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: cornedbee@google.com
Date: Wed, 8 Jan 2014 05:11:08 -0800 (PST)
Raw View
------=_Part_5932_11539313.1389186668833
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krauss wrote:
>
> On 1/8/14 7:31 PM, corn...@google.com <javascript:> wrote:
> > This is a very common thing in Boost code.
> >
> > One workaround is employed by Boost.Iterator, where e.g. the
> > iterator_facade template contains an iterator_facade_ alias of its own
> > type. This allows the deriving class to write my_class::iterator_facade_
> to
> > reach the base. The my_class:: is necessary to make the lookup
> dependent.
>
> That sounds like a workaround to a platform-specific bug with
> injected-class-names.
>
What part? The typedef or the qualification? After testing, I agree that
the typedef is probably a workaround, but the qualification is necessary:
$ cat crtpbase.cc
template <typename T>
struct base {
typedef T value_type;
};
template <typename T>
struct derived : base<T> {
typename base::value_type t;
};
int main() {
derived<int> d;
d.t = 99;
}
$ clang -fsyntax-only crtpbase.cc
crtpbase.cc:8:12: error: expected a class or namespace
typename base::value_type t;
^
crtpbase.cc:8:18: error: expected a qualified name after 'typename'
typename base::value_type t;
^
crtpbase.cc:8:28: error: expected ';' at end of declaration list
typename base::value_type t;
^
;
3 errors generated.
But this at least means that no special preparation on part of the base
class is necessary. So this new feature would only give significant savings
for the case where you have the same base class multiple times.
--
---
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_5932_11539313.1389186668833
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1/8/14 7:31 PM, <a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"H6p-DhKOrE=
EJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;">corn...@google.com</a> wrote:
<br>> This is a very common thing in Boost code.
<br>>
<br>> One workaround is employed by Boost.Iterator, where e.g. the
<br>> iterator_facade template contains an iterator_facade_ alias of its=
own
<br>> type. This allows the deriving class to write my_class::iterator_f=
acade_ to
<br>> reach the base. The my_class:: is necessary to make the lookup dep=
endent.
<br>
<br>That sounds like a workaround to a platform-specific bug with=20
<br>injected-class-names.
<br></blockquote><div><br></div><div>What part? The typedef or the qualific=
ation? After testing, I agree that the typedef is probably a workaround, bu=
t the qualification is necessary:</div><div> </div><div><div>$ cat crt=
pbase.cc </div><div>template <typename T></div><div>struct base =
{</div><div> typedef T value_type;</div><div>};</div><div><br></div><=
div>template <typename T></div><div>struct derived : base<T> {<=
/div><div> typename base::value_type t;</div><div>};</div><div><br></=
div><div>int main() {</div><div> derived<int> d;</div><div>&nbs=
p; d.t =3D 99;</div><div>}</div><div><br></div><div>$ clang -fsyntax-only c=
rtpbase.cc </div><div>crtpbase.cc:8:12: error: expected a class or nam=
espace</div><div> typename base::value_type t;</div><div>  =
; ^</div><div>crtpbase.cc:8:18: error: expected =
a qualified name after 'typename'</div><div> typename base::value_typ=
e t;</div><div> &nbs=
p;^</div><div>crtpbase.cc:8:28: error: expected ';' at end of declaration l=
ist</div><div> typename base::value_type t;</div><div> &=
nbsp; =
^</div><div> =
;</div><div>3 errors generated.</d=
iv></div><div><br></div><div><br></div><div>But this at least means that no=
special preparation on part of the base class is necessary. So this new fe=
ature would only give significant savings for the case where you have the s=
ame base class multiple times.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5932_11539313.1389186668833--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 8 Jan 2014 12:00:56 -0500
Raw View
--001a1135e344c51ef504ef786f10
Content-Type: text/plain; charset=ISO-8859-1
Summarizing, just to be sure we are on the same page.
template <typename T>
struct derived : base<T> {
using base_t = base<T>; // [*]
};
What you are asking for is to provide a language level mechanism so that
'base' can be used inside of 'derived' without template arguments (i.e.
drop the <T> from the line marked with [*]). The example code above is
quite intentional in that it provides a simple mechanism that can be (and
is widely) used to remove all the required template arguments from within
the 'derived' template. That is, the proposal you are doing would be to
replace the code above with:
template <typename T>
struct derived : base_t = base<T> {
};
Noting that, even if we consider that to be an advantage, it is only so
when inheriting from a template base that is dependent on the template
arguments of the class template being defined. If instead of 'base<T>' you
had 'base<int>', the first phase lookup would be able to find 'base' as the
injected type name inside 'base<int>'.
template <typename T>
struct derived : base<int> {
derived() : base() {} // no need to type 'base<int>'
};
I personally don't find this as a huge improvement, but that is just my
opinion; but at the same time I made a proposal that I am sure almost no
one cares about...
David
On Wed, Jan 8, 2014 at 8:11 AM, <cornedbee@google.com> wrote:
> On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krauss wrote:
>
>> On 1/8/14 7:31 PM, corn...@google.com wrote:
>> > This is a very common thing in Boost code.
>> >
>> > One workaround is employed by Boost.Iterator, where e.g. the
>> > iterator_facade template contains an iterator_facade_ alias of its own
>> > type. This allows the deriving class to write
>> my_class::iterator_facade_ to
>> > reach the base. The my_class:: is necessary to make the lookup
>> dependent.
>>
>> That sounds like a workaround to a platform-specific bug with
>> injected-class-names.
>>
>
> What part? The typedef or the qualification? After testing, I agree that
> the typedef is probably a workaround, but the qualification is necessary:
>
> $ cat crtpbase.cc
> template <typename T>
> struct base {
> typedef T value_type;
> };
>
> template <typename T>
> struct derived : base<T> {
> typename base::value_type t;
> };
>
> int main() {
> derived<int> d;
> d.t = 99;
> }
>
> $ clang -fsyntax-only crtpbase.cc
> crtpbase.cc:8:12: error: expected a class or namespace
> typename base::value_type t;
> ^
> crtpbase.cc:8:18: error: expected a qualified name after 'typename'
> typename base::value_type t;
> ^
> crtpbase.cc:8:28: error: expected ';' at end of declaration list
> typename base::value_type t;
> ^
> ;
> 3 errors generated.
>
>
> But this at least means that no special preparation on part of the base
> class is necessary. So this new feature would only give significant savings
> for the case where you have the same base class multiple times.
>
> --
>
> ---
> 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/.
--001a1135e344c51ef504ef786f10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Summarizing, just to be sure we are on the same page.<br><=
br>template <typename T><br>struct derived : base<T> {<br>=A0 =
=A0using base_t =3D base<T>; =A0 =A0// [*]<br><div>};<br><br>What you=
are asking for is to provide a language level mechanism so that 'base&=
#39; can be used inside of 'derived' without template arguments (i.=
e. drop the <T> from the line marked with [*]). The example code abov=
e is quite intentional in that it provides a simple mechanism that can be (=
and is widely) used to remove all the required template arguments from with=
in the 'derived' template. That is, the proposal you are doing woul=
d be to replace the code above with:<br>
<br>template <typename T><br>struct derived : base_t =3D base<T>=
; {</div><div>};<br><br>Noting that, even if we consider that to be an adva=
ntage, it is only so when inheriting from a template base that is dependent=
on the template arguments of the class template being defined. If instead =
of 'base<T>' you had 'base<int>', the first pha=
se lookup would be able to find 'base' as the injected type name in=
side 'base<int>'.<br>
<br>template <typename T><br>struct derived : base<int> {<br>=
=A0 =A0 derived() : base() {} =A0 =A0 =A0 =A0 =A0// no need to type 'ba=
se<int>'<br>};</div><div class=3D"gmail_extra"><br>I personally d=
on't find this as a huge improvement, but that is just my opinion; but =
at the same time I made a proposal that I am sure almost no one cares about=
....<br>
<br>=A0 =A0David<br><br><div class=3D"gmail_quote">On Wed, Jan 8, 2014 at 8=
:11 AM, <span dir=3D"ltr"><<a href=3D"mailto:cornedbee@google.com" targ=
et=3D"_blank">cornedbee@google.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr">On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krau=
ss wrote:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/8/1=
4 7:31 PM, <a>corn...@google.com</a> wrote:
<br>> This is a very common thing in Boost code.
<br>>
<br>> One workaround is employed by Boost.Iterator, where e.g. the
<br>> iterator_facade template contains an iterator_facade_ alias of its=
own
<br>> type. This allows the deriving class to write my_class::iterator_f=
acade_ to
<br>> reach the base. The my_class:: is necessary to make the lookup dep=
endent.
<br>
<br>That sounds like a workaround to a platform-specific bug with=20
<br>injected-class-names.
<br></blockquote><div><br></div></div><div>What part? The typedef or the qu=
alification? After testing, I agree that the typedef is probably a workarou=
nd, but the qualification is necessary:</div><div>=A0</div><div><div>$ cat =
crtpbase.cc=A0</div>
<div>template <typename T></div><div>struct base {</div><div>=A0 type=
def T value_type;</div><div>};</div><div><br></div><div>template <typena=
me T></div><div>struct derived : base<T> {</div><div>=A0 typename =
base::value_type t;</div>
<div>};</div><div><br></div><div>int main() {</div><div>=A0 derived<int&=
gt; d;</div><div>=A0 d.t =3D 99;</div><div>}</div><div><br></div><div>$ cla=
ng -fsyntax-only crtpbase.cc=A0</div><div>crtpbase.cc:8:12: error: expected=
a class or namespace</div>
<div>=A0 typename base::value_type t;</div><div>=A0 =A0 =A0 =A0 =A0 =A0^</d=
iv><div>crtpbase.cc:8:18: error: expected a qualified name after 'typen=
ame'</div><div>=A0 typename base::value_type t;</div><div>=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0^</div><div>
crtpbase.cc:8:28: error: expected ';' at end of declaration list</d=
iv><div>=A0 typename base::value_type t;</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0;</div><div>3 errors generated.</div>
</div><div><br></div><div><br></div><div>But this at least means that no sp=
ecial preparation on part of the base class is necessary. So this new featu=
re would only give significant savings for the case where you have the same=
base class multiple times.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<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" 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></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135e344c51ef504ef786f10--
.
Author: rouslankorneychuk@gmail.com
Date: Wed, 8 Jan 2014 14:27:49 -0800 (PST)
Raw View
------=_Part_248_12576464.1389220069925
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 8, 2014 12:00:56 PM UTC-5, David Rodr=EDguez Ibeas=20
wrote:
>
> Summarizing, just to be sure we are on the same page.
>
> template <typename T>
> struct derived : base<T> {
> using base_t =3D base<T>; // [*]
> };
>
> What you are asking for is to provide a language level mechanism so that=
=20
> 'base' can be used inside of 'derived' without template arguments (i.e.=
=20
> drop the <T> from the line marked with [*]). The example code above is=20
> quite intentional in that it provides a simple mechanism that can be (and=
=20
> is widely) used to remove all the required template arguments from within=
=20
> the 'derived' template. That is, the proposal you are doing would be to=
=20
> replace the code above with:
>
> template <typename T>
> struct derived : base_t =3D base<T> {
> };
>
> Noting that, even if we consider that to be an advantage, it is only so=
=20
> when inheriting from a template base that is dependent on the template=20
> arguments of the class template being defined. If instead of 'base<T>' yo=
u=20
> had 'base<int>', the first phase lookup would be able to find 'base' as t=
he=20
> injected type name inside 'base<int>'.
>
> template <typename T>
> struct derived : base<int> {
> derived() : base() {} // no need to type 'base<int>'
> };
>
> I personally don't find this as a huge improvement, but that is just my=
=20
> opinion; but at the same time I made a proposal that I am sure almost no=
=20
> one cares about...
>
> David
>
> On Wed, Jan 8, 2014 at 8:11 AM, <corn...@google.com <javascript:>> wrote:
>
>> On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krauss wrote:
>>
>>> On 1/8/14 7:31 PM, corn...@google.com wrote:=20
>>> > This is a very common thing in Boost code.=20
>>> >=20
>>> > One workaround is employed by Boost.Iterator, where e.g. the=20
>>> > iterator_facade template contains an iterator_facade_ alias of its ow=
n=20
>>> > type. This allows the deriving class to write=20
>>> my_class::iterator_facade_ to=20
>>> > reach the base. The my_class:: is necessary to make the lookup=20
>>> dependent.=20
>>>
>>> That sounds like a workaround to a platform-specific bug with=20
>>> injected-class-names.=20
>>>
>>
>> What part? The typedef or the qualification? After testing, I agree that=
=20
>> the typedef is probably a workaround, but the qualification is necessary=
:
>> =20
>> $ cat crtpbase.cc=20
>> template <typename T>
>> struct base {
>> typedef T value_type;
>> };
>>
>> template <typename T>
>> struct derived : base<T> {
>> typename base::value_type t;
>> };
>>
>> int main() {
>> derived<int> d;
>> d.t =3D 99;
>> }
>>
>> $ clang -fsyntax-only crtpbase.cc=20
>> crtpbase.cc:8:12: error: expected a class or namespace
>> typename base::value_type t;
>> ^
>> crtpbase.cc:8:18: error: expected a qualified name after 'typename'
>> typename base::value_type t;
>> ^
>> crtpbase.cc:8:28: error: expected ';' at end of declaration list
>> typename base::value_type t;
>> ^
>> ;
>> 3 errors generated.
>>
>>
>> But this at least means that no special preparation on part of the base=
=20
>> class is necessary. So this new feature would only give significant savi=
ngs=20
>> for the case where you have the same base class multiple times.
>>
> =20
That was the idea. I was using the CRTP in my code with templates that had=
=20
a lot of parameters and thought there should be a better way, but then=20
David Krauss showed an alternative using injected-class-names that I hadn't=
=20
thought of, making this feature a lot less compelling.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_248_12576464.1389220069925
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 8, 2014 12:00:56 PM UTC-5, David Rod=
r=EDguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Summarizing, just to be sure we are on the same page.<br><br>templ=
ate <typename T><br>struct derived : base<T> {<br> =
using base_t =3D base<T>; // [*]<br><div>};<br><br>What =
you are asking for is to provide a language level mechanism so that 'base' =
can be used inside of 'derived' without template arguments (i.e. drop the &=
lt;T> from the line marked with [*]). The example code above is quite in=
tentional in that it provides a simple mechanism that can be (and is widely=
) used to remove all the required template arguments from within the 'deriv=
ed' template. That is, the proposal you are doing would be to replace the c=
ode above with:<br>
<br>template <typename T><br>struct derived : base_t =3D base<T>=
; {</div><div>};<br><br>Noting that, even if we consider that to be an adva=
ntage, it is only so when inheriting from a template base that is dependent=
on the template arguments of the class template being defined. If instead =
of 'base<T>' you had 'base<int>', the first phase lookup would =
be able to find 'base' as the injected type name inside 'base<int>'.<=
br>
<br>template <typename T><br>struct derived : base<int> {<br>&n=
bsp; derived() : base() {} // no n=
eed to type 'base<int>'<br>};</div><div><br>I personally don't find t=
his as a huge improvement, but that is just my opinion; but at the same tim=
e I made a proposal that I am sure almost no one cares about...<br>
<br> David<br><br><div class=3D"gmail_quote">On Wed, Jan 8, 201=
4 at 8:11 AM, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Wzol741TMmUJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">c=
orn...@google.com</a>></span> 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">On Wednesday, January 8, 2014 1:43:16 PM UTC+1, David Krau=
ss wrote:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/8/14 7:31 PM, <a=
>corn...@google.com</a> wrote:
<br>> This is a very common thing in Boost code.
<br>>
<br>> One workaround is employed by Boost.Iterator, where e.g. the
<br>> iterator_facade template contains an iterator_facade_ alias of its=
own
<br>> type. This allows the deriving class to write my_class::iterator_f=
acade_ to
<br>> reach the base. The my_class:: is necessary to make the lookup dep=
endent.
<br>
<br>That sounds like a workaround to a platform-specific bug with=20
<br>injected-class-names.
<br></blockquote><div><br></div></div><div>What part? The typedef or the qu=
alification? After testing, I agree that the typedef is probably a workarou=
nd, but the qualification is necessary:</div><div> </div><div><div>$ c=
at crtpbase.cc </div>
<div>template <typename T></div><div>struct base {</div><div> t=
ypedef T value_type;</div><div>};</div><div><br></div><div>template <typ=
ename T></div><div>struct derived : base<T> {</div><div> typ=
ename base::value_type t;</div>
<div>};</div><div><br></div><div>int main() {</div><div> derived<i=
nt> d;</div><div> d.t =3D 99;</div><div>}</div><div><br></div><div=
>$ clang -fsyntax-only crtpbase.cc </div><div>crtpbase.cc:8:12: error:=
expected a class or namespace</div>
<div> typename base::value_type t;</div><div> &nb=
sp; ^</div><div>crtpbase.cc:8:18: error: expected a qualified =
name after 'typename'</div><div> typename base::value_type t;</div><d=
iv> ^</div><di=
v>
crtpbase.cc:8:28: error: expected ';' at end of declaration list</div><div>=
typename base::value_type t;</div><div> &=
nbsp; ^</div>=
<div> =
;</div><div>3 errors generated.</div>
</div><div><br></div><div><br></div><div>But this at least means that no sp=
ecial preparation on part of the base class is necessary. So this new featu=
re would only give significant savings for the case where you have the same=
base class multiple times.</div>
</div></blockquote></div></div></div></blockquote><div> <br>That was t=
he idea. I was using the CRTP in my code with templates that had a lot of p=
arameters and thought there should be a better way, but then David Krauss s=
howed an alternative using injected-class-names that I hadn't thought of, m=
aking this feature a lot less compelling.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_248_12576464.1389220069925--
.
Author: piotr.rak@gmail.com
Date: Sun, 2 Feb 2014 17:45:53 -0800 (PST)
Raw View
------=_Part_682_18367133.1391391953740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
I am not sure it is obvious to you, but you can do something very close=20
just injecting this name using default template arguments;
W dniu sobota, 28 grudnia 2013 08:50:37 UTC+1 u=C5=BCytkownik=20
rouslank...@gmail.com napisa=C5=82:
>
> I have a simple proposal that I think can be explained with an example.=
=20
> How about something like this?:
>
>
Your example:
=20
> class A : public *B =3D C* {
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
>
becomes:
template <typename B =3D C> class A : public *B* {
A() : B(3) {}
void do_something() {
/* ... */
B::do_something();
}
};
which would be equivalent to:
>
> class A : public C {
> typedef C B;
>
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
> This would be useful when dealing with unwieldy template instantiations a=
s=20
> base classes:
>
> template<typename T,typename Pasta> class monstrous : public something =
=3D=20
> ::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<m=
onstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>=20
> {};
>
> Sure, you could use a typedef like my second code sample does, but you=20
> would still have to repeat all the template arguments once, which is not=
=20
> only redundant, but an opportunity for mistakes (mainly when updating cod=
e).
>
=20
And this monster:
template<typename T,typename Pasta, typename something_=3D=20
::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>
,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>>=20
class monstrous : public something_ {};
=20
(I'd really encourage alias for such cases anyway - be it even template=
=20
of template to break recursion)
It has clear down side of of adding yet another template paramater, but for=
=20
me in most cases was "Good Enough TM".
Also not perfect if you need out-of-line method definitions (gnu/c++11=20
extern template + explicit template instantiations might help bit then, but=
=20
it is workaround and another inconvinience).
I used it for CRTP, where ability to specify base class for some edge case,=
=20
turned out to be useful.
Cheers,
/Piotr
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_682_18367133.1391391953740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>I am not sure it is obvious to you,=
but you can do something very close just injecting this name using default=
template arguments;<br><br>W dniu sobota, 28 grudnia 2013 08:50:37 UTC+1 u=
=C5=BCytkownik rouslank...@gmail.com napisa=C5=82:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">I have a simple proposal that I think =
can be explained with an example. How about something like this?:<br><br></=
div></blockquote><div><span style=3D"font-size: 13px;"><br></span></div><di=
v><span style=3D"font-size: 13px;">Your example:</span></div><div> </d=
iv><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 styl=
e=3D"font-family:courier new,monospace">class A : public <u>B =3D C</u> {<b=
r> A() : B(3) {}<br><br> void do_someth=
ing() {<br> /* ... */<br> &n=
bsp; B::do_something();<br> =
}<br>};</span><br><br></div></blockquote><div><br></div><div>becomes:</div=
><div><br></div><div><span style=3D"font-family: 'courier new', monospace;"=
>template <typename B =3D C> class A : public </span><u style=3D=
"font-family: 'courier new', monospace;">B</u><span style=3D"font-family: '=
courier new', monospace;"> {</span><br style=3D"font-family: 'courier =
new', monospace;"><span style=3D"font-family: 'courier new', monospace;">&n=
bsp; A() : B(3) {}</span><br style=3D"font-family: 'courier new=
', monospace;"><br style=3D"font-family: 'courier new', monospace;"><span s=
tyle=3D"font-family: 'courier new', monospace;"> void do_=
something() {</span><br style=3D"font-family: 'courier new', monospace;"><s=
pan style=3D"font-family: 'courier new', monospace;"> &nbs=
p; /* ... */</span><br style=3D"font-family: 'courier new=
', monospace;"><span style=3D"font-family: 'courier new', monospace;"> =
; B::do_something();</span><br style=3D=
"font-family: 'courier new', monospace;"><span style=3D"font-family: 'couri=
er new', monospace;"> }</span><br style=3D"font-family: '=
courier new', monospace;"><span style=3D"font-family: 'courier new', monosp=
ace;">};</span><br></div><div><span style=3D"font-family: 'courier new', mo=
nospace;"><br></span></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">which would be equivalent to:<br><br><span style=3D"font-fami=
ly:courier new,monospace">class A : public C {<br> typede=
f C B;<br><br> A() : B(3) {}<br><br> vo=
id do_something() {<br> /* ... */=
<br> B::do_something();<br> =
}<br>};</span><br><br>This would be useful when dealing with u=
nwieldy template instantiations as base classes:<br><br><span style=3D"font=
-family:courier new,monospace">template<typename T,typename Pasta> cl=
ass monstrous : public something =3D ::something<monstrous<T,Pasta>=
;<wbr>,allocator<monstrous<T,Pasta>><wbr>,comparison<monstro=
us<T,Pasta><wbr>,and_so_on<Pasta>,and_so_<wbr>forth<T,etc<=
;T>>> {};</span><br><br>Sure, you could use a typedef like my seco=
nd code sample does, but you would still have to repeat all the template ar=
guments once, which is not only redundant, but an opportunity for mistakes =
(mainly when updating code).</div></blockquote><div> </div><div>And th=
is monster:</div><div><br></div><div><span style=3D"font-family: 'courier n=
ew', monospace;">template<typename T,typename Pasta, typename something_=
=3D </span><span style=3D"font-size: 13px; font-family: 'courier new',=
monospace;">::something<monstrous<T,Pasta></span><wbr style=3D"fo=
nt-size: 13px; font-family: 'courier new', monospace;"><span style=3D"font-=
size: 13px; font-family: 'courier new', monospace;">,allocator<monstrous=
<T,Pasta>></span><wbr style=3D"font-size: 13px; font-family: 'cour=
ier new', monospace;"><span style=3D"font-size: 13px; font-family: 'courier=
new', monospace;">,comparison<monstrous<T,Pasta></span><wbr style=
=3D"font-size: 13px; font-family: 'courier new', monospace;"><span style=3D=
"font-size: 13px; font-family: 'courier new', monospace;">,and_so_on<Pas=
ta>,and_so_</span><wbr style=3D"font-size: 13px; font-family: 'courier n=
ew', monospace;"><span style=3D"font-size: 13px; font-family: 'courier new'=
, monospace;">forth<T,etc<T>>></span><span style=3D"font-siz=
e: 13px; font-family: 'courier new', monospace;">> class monstrous : pub=
lic something_</span><span style=3D"font-size: 13px; font-family: 'courier =
new', monospace;"> {};</span></div><div> </div></div><div> (=
I'd really encourage alias for such cases anyway - be it <span style=
=3D"font-size: 13px;">even</span><span style=3D"font-size: 13px;"> </s=
pan><span style=3D"font-size: 13px;"> template of template to break re=
cursion)</span></div><div><br></div><div>It has clear down side of of addin=
g yet another template paramater, but for me in most cases was "Good Enough=
TM".</div><div>Also not perfect if you need out-of-line method definitions=
(gnu/c++11 extern template + explicit template instantiations might help b=
it then, but it is workaround and another inconvinience).</div><div><br></d=
iv><div>I used it for <span style=3D"font-size: 13px;">CRTP, where abi=
lity to specify base class for some edge case, turned out to be useful.</sp=
an></div><div><br></div><div><span style=3D"font-size: 13px;"><br></span></=
div><div><span style=3D"font-size: 13px;">Cheers,</span></div><div><span st=
yle=3D"font-size: 13px;">/Piotr</span></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_682_18367133.1391391953740--
.
Author: Boris Rasin <rasin.boris@gmail.com>
Date: Tue, 4 Feb 2014 07:56:01 -0800 (PST)
Raw View
------=_Part_420_15811801.1391529361947
Content-Type: text/plain; charset=UTF-8
Even when type name of the base class is short, there is still a benefit in
referring to it using some generic alias.
This improves readability of the code, clearly communicating intend to
access scope of immediate base class, not scope of specific class.
This also improves maintainability of the code, preventing (often hard to
detect) errors when base class is changed, code copy/pasted to another
class, etc.
Something like Java's "super" keyword would be a good solution if it wasn't
for C++'s multiple inheritance.
--
---
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_420_15811801.1391529361947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Even when type name of the base class is short, there is s=
till a benefit in referring to it using some generic alias.<br>This improve=
s readability of the code, clearly communicating intend to access scope of =
immediate base class, not scope of specific class.<br>This also improves ma=
intainability of the code, preventing (often hard to detect) errors when ba=
se class is changed, code copy/pasted to another class, etc.<br><br>Somethi=
ng like Java's "super" keyword would be a good solution if it wasn't for C+=
+'s multiple inheritance.<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_420_15811801.1391529361947--
.
Author: morwenn29@gmail.com
Date: Tue, 4 Feb 2014 13:02:29 -0800 (PST)
Raw View
------=_Part_2767_31179718.1391547749263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mardi 4 f=C3=A9vrier 2014 16:56:01 UTC+1, Boris Rasin a =C3=A9crit :
>
> Even when type name of the base class is short, there is still a benefit=
=20
> in referring to it using some generic alias.
> This improves readability of the code, clearly communicating intend to=20
> access scope of immediate base class, not scope of specific class.
> This also improves maintainability of the code, preventing (often hard to=
=20
> detect) errors when base class is changed, code copy/pasted to another=20
> class, etc.
>
> Something like Java's "super" keyword would be a good solution if it=20
> wasn't for C++'s multiple inheritance.
>
Well, there could be rules, like "super" works if there is only one base=20
class, otherwise, "super..." could refer to all the base classes, and you=
=20
could pick one of them using something like super<0> or something like=20
that. Given the rich syntaw of C++, there are probably several ways to=20
create something that could look like something the users already know and=
=20
still be usable without a problem :)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2767_31179718.1391547749263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le mardi 4 f=C3=A9vrier 2014 16:56:01 UTC+1, Boris Rasin a=
=C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Even when type name of the base class is short, there is still a benef=
it in referring to it using some generic alias.<br>This improves readabilit=
y of the code, clearly communicating intend to access scope of immediate ba=
se class, not scope of specific class.<br>This also improves maintainabilit=
y of the code, preventing (often hard to detect) errors when base class is =
changed, code copy/pasted to another class, etc.<br><br>Something like Java=
's "super" keyword would be a good solution if it wasn't for C++'s multiple=
inheritance.<br></div></blockquote><div><br>Well, there could be rules, li=
ke "super" works if there is only one base class, otherwise, "super..." cou=
ld refer to all the base classes, and you could pick one of them using some=
thing like super<0> or something like that. Given the rich syntaw of =
C++, there are probably several ways to create something that could look li=
ke something the users already know and still be usable without a problem :=
)<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2767_31179718.1391547749263--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Tue, 4 Feb 2014 14:36:59 -0800
Raw View
--001a113309649e508a04f19c4947
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Why do we need to implement a crazy workaround for something that users can
already specify? If you really want to use the word super for this, just
add a typedef.
If it doesn't allow users to accomplish anything "new" it is going to be a
tough sell for an already very complex language.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Tue, Feb 4, 2014 at 1:02 PM, <morwenn29@gmail.com> wrote:
> Le mardi 4 f=C3=A9vrier 2014 16:56:01 UTC+1, Boris Rasin a =C3=A9crit :
>>
>> Even when type name of the base class is short, there is still a benefit
>> in referring to it using some generic alias.
>> This improves readability of the code, clearly communicating intend to
>> access scope of immediate base class, not scope of specific class.
>> This also improves maintainability of the code, preventing (often hard t=
o
>> detect) errors when base class is changed, code copy/pasted to another
>> class, etc.
>>
>> Something like Java's "super" keyword would be a good solution if it
>> wasn't for C++'s multiple inheritance.
>>
>
> Well, there could be rules, like "super" works if there is only one base
> class, otherwise, "super..." could refer to all the base classes, and you
> could pick one of them using something like super<0> or something like
> that. Given the rich syntaw of C++, there are probably several ways to
> create something that could look like something the users already know an=
d
> still be usable without a problem :)
>
> --
>
> ---
> 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/.
--001a113309649e508a04f19c4947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why do we need to implement a crazy workaround for somethi=
ng that users can already specify? If you really want to use the word super=
for this, just add a typedef.<div><br></div><div>If it doesn't allow u=
sers to accomplish anything "new" it is going to be a tough sell =
for an already very complex language.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Tue, Feb 4, 2014 at 1:02 PM, <span d=
ir=3D"ltr"><<a href=3D"mailto:morwenn29@gmail.com" target=3D"_blank">mor=
wenn29@gmail.com</a>></span> 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">Le mardi 4 f=C3=A9vrier 2014 16:56:01 UTC+1, Boris Rasin a=
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
Even when type name of the base class is short, there is still a benefit in=
referring to it using some generic alias.<br>
This improves readability of the code, clearly communicating intend to acce=
ss scope of immediate base class, not scope of specific class.<br>This also=
improves maintainability of the code, preventing (often hard to detect) er=
rors when base class is changed, code copy/pasted to another class, etc.<br=
>
<br>Something like Java's "super" keyword would be a good sol=
ution if it wasn't for C++'s multiple inheritance.<br></div></block=
quote><div><br>Well, there could be rules, like "super" works if =
there is only one base class, otherwise, "super..." could refer t=
o all the base classes, and you could pick one of them using something like=
super<0> or something like that. Given the rich syntaw of C++, there=
are probably several ways to create something that could look like somethi=
ng the users already know and still be usable without a problem :)<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=C2=A0<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" 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>
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113309649e508a04f19c4947--
.
Author: Boris Rasin <rasin.boris@gmail.com>
Date: Wed, 5 Feb 2014 01:36:49 -0800 (PST)
Raw View
------=_Part_3449_8824404.1391593009666
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 5, 2014 12:36:59 AM UTC+2, Billy O'Neal wrote:
>
> Why do we need to implement a crazy workaround for something that users
> can already specify? If you really want to use the word super for this,
> just add a typedef.
>
> If it doesn't allow users to accomplish anything "new" it is going to be a
> tough sell for an already very complex language.
>
Because such typedefs cause (often significant) code duplication.
--
---
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_3449_8824404.1391593009666
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, February 5, 2014 12:36:59 AM UTC+2, Bill=
y O'Neal 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=
">Why do we need to implement a crazy workaround for something that users c=
an already specify? If you really want to use the word super for this, just=
add a typedef.<div><br></div><div>If it doesn't allow users to accomplish =
anything "new" it is going to be a tough sell for an already very complex l=
anguage.</div></div></blockquote><div><br>Because such typedefs <span>cause=
</span>(often significant) code duplication.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3449_8824404.1391593009666--
.
Author: Piotr Rak <piotr.rak@gmail.com>
Date: Wed, 5 Feb 2014 14:31:03 -0800 (PST)
Raw View
------=_Part_724_1406928.1391639463264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 5 lutego 2014 10:36:49 UTC+1 u=C5=BCytkownik Boris Rasin=
napisa=C5=82:
>
>
> On Wednesday, February 5, 2014 12:36:59 AM UTC+2, Billy O'Neal wrote:
>>
>> Why do we need to implement a crazy workaround for something that users=
=20
>> can already specify? If you really want to use the word super for this,=
=20
>> just add a typedef.
>>
>> If it doesn't allow users to accomplish anything "new" it is going to be=
=20
>> a tough sell for an already very complex language.
>>
>
> Because such typedefs cause (often significant) code duplication.
>
I agree with both of you -=20
true we are not making language simpler adding another way of doing=20
things, and also DRY - to C++ grammar
but also DRY ie Do not Reapet Yourself should be embraced as much as=20
possible
Yet the only way (maybe not only, but a one I'd support/encourage) I feel=
=20
such proposal moving forward is comming up with rule similar to one we=20
already have for class name in class template:
template <typename T> class C
{
void bar() {}
void baz(C&); // We don't have to use C<T> here because Foo name is=20
injected in this scope.
};
so if for lets say for unambigous case like:
template <typename T> class A : public B<T>
{
void foo(B&);
};
name B would be injected name with implicit meaning B<T> we should get away=
=20
with that.
It should not break any exising code, and I don't see any obvious problem=
=20
with relaxing rules in such way.
I have not tried with comming with exact and flawless wording, it might=20
turned out to be more tricky, as it's usually for me.
Ofc for case like:
class C : B<int>, B<void*>
{
};
typename B should be ambigous.
and for cases:
class C : B<int>
{
using B =3D Foo;
void foo(B); // B is alias of Foo here, and hides injected base class=20
name.
};
So rather than adding yet another grammar production rule as alias=20
assignment you suggested in your orginal proposal, I'd be in favour of=20
extending/relaxing exising semantic rules for injected classname, whenever=
=20
it is possible to keep it DRY. No matter how compiler writers will hate us=
=20
for making yet another crazy rule to complicate already insane, umm, sorry=
=20
non-trivial name lookup rules :)
Cheers,
/Piotr
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_724_1406928.1391639463264
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 5 lutego 2014 10:36:49 UTC+1 u=
=C5=BCytkownik Boris Rasin napisa=C5=82:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><br>On Wednesday, February 5, 2014 12:36:59 AM U=
TC+2, Billy O'Neal 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">Why do we need to implement a crazy workaround for something that =
users can already specify? If you really want to use the word super for thi=
s, just add a typedef.<div><br></div><div>If it doesn't allow users to acco=
mplish anything "new" it is going to be a tough sell for an already very co=
mplex language.</div></div></blockquote><div><br>Because such typedefs <spa=
n>cause </span>(often significant) code duplication.</div></div></blockquot=
e><div><br></div><div>I agree with both of you - </div><div> &nb=
sp;true we are not making language simpler adding another way of doin=
g things, and also DRY - <span style=3D"font-size: 13px;">to C++ gramm=
ar</span></div><div><span style=3D"font-size: 13px;"> but also =
DRY ie Do not Reapet Yourself should be embraced as much as possible</span>=
</div><div><span style=3D"font-size: 13px;"><br></span></div><div><span sty=
le=3D"font-size: 13px;">Yet t</span><span style=3D"font-size: 13px;">he onl=
y way (maybe not only, but a one I'd support/encourage) I feel such proposa=
l moving forward is comming up with rule similar to one we already have for=
class name in class template:</span></div><div><br></div><div>template <=
;typename T> class C</div><div>{</div><div> void bar() {}</d=
iv><div> void baz(C&); // We don't have to use C<T> h=
ere because Foo name is injected in this scope.</div><div>};</div><div><br>=
</div><div>so if for lets say for unambigous case like:</div><div><br></div=
><div>template <typename T> class A : public B<T></div><div>{</=
div><div> void foo(B&);</div><div>};</div><div><br></div><d=
iv>name B would be injected name with implicit meaning B<T> we should=
get away with that.</div><div>It should not break any exising code, and I =
don't see any obvious problem with relaxing rules in such way.</div><div><b=
r></div><div>I have not tried with comming with exact and flawless <sp=
an style=3D"font-size: 13px;"> </span><span style=3D"font-size: 13px;"=
>wording,</span><span style=3D"font-size: 13px;"> </span><span style=
=3D"font-size: 13px;">it might turned out to be more tricky, as it's usuall=
y for me.</span></div><div><br></div><div>Ofc for case like:</div><div><br>=
</div><div>class C : B<int>, B<void*></div><div>{</div><div>};<=
/div><div><br></div><div>typename B should be ambigous.</div><div><br></div=
><div>and for cases:</div><div><br></div><div>class C : B<int></div><=
div>{</div><div> using B =3D Foo;</div><div> void foo(B); // B =
is alias of Foo here, and hides injected base class name.</div><div>};</div=
><div><br></div><div>So rather than adding yet another grammar production r=
ule as alias assignment you suggested in your orginal proposal, I'd be in f=
avour of extending/relaxing exising semantic rules for injected classname, =
whenever it is possible to keep it DRY. No matter how compiler writers will=
hate us for making yet another crazy rule to complicate already insane, um=
m, sorry non-trivial name lookup rules :)</div><div><br></div><div>Cheers,<=
/div><div>/Piotr</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_724_1406928.1391639463264--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 5 Feb 2014 16:45:27 -0600
Raw View
--001a11c266c4c6757904f1b0859b
Content-Type: text/plain; charset=ISO-8859-1
On 5 February 2014 16:31, Piotr Rak <piotr.rak@gmail.com> wrote:
>
> So rather than adding yet another grammar production rule as alias
> assignment you suggested in your orginal proposal, I'd be in favour of
> extending/relaxing exising semantic rules for injected classname, whenever
> it is possible to keep it DRY. No matter how compiler writers will hate us
> for making yet another crazy rule to complicate already insane, umm, sorry
> non-trivial name lookup rules :)
>
Sounds interesting. Assuming there are no issues with it (I'm no core
expert), I feel it would be a worthwhile addition to the language. This
pattern does come up often enough that I'd be in favor of a proposal like
this.
If it is an injected name, is it useable outside the class? For instance:
struct D : B<int> { /* ... */ };
D::B hello; // valid? Private type? Dependent on public/private
inheritance?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c266c4c6757904f1b0859b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 5 February 2014 16:31, Piotr Rak <span dir=3D"ltr"><=
<a href=3D"mailto:piotr.rak@gmail.com" target=3D"_blank">piotr.rak@gmail.co=
m</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div>So rather than adding yet another grammar product=
ion rule as alias assignment you suggested in your orginal proposal, I'=
d be in favour of extending/relaxing exising semantic rules for injected cl=
assname, whenever it is possible to keep it DRY. No matter how compiler wri=
ters will hate us for making yet another crazy rule to complicate already i=
nsane, umm, sorry non-trivial name lookup rules :)<br clear=3D"all">
</div></div></blockquote><div><br></div><div>Sounds interesting.=A0 Assumin=
g there are no issues with it (I'm no core expert), I feel it would be =
a worthwhile addition to the language.=A0 This pattern does come up often e=
nough that I'd be in favor of a proposal like this.<br>
<br></div><div>If it is an injected name, is it useable outside the class?=
=A0 For instance:<br><br></div><div>struct D : B<int> { /* ... */ };<=
br><br></div><div>D::B hello; // valid?=A0 Private type?=A0 Dependent on pu=
blic/private inheritance?<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c266c4c6757904f1b0859b--
.
Author: Piotr Rak <piotr.rak@gmail.com>
Date: Wed, 5 Feb 2014 15:08:36 -0800 (PST)
Raw View
------=_Part_3376_22371322.1391641716834
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=C5=BCytkownik Nevin ":-)"=
Liber=20
napisa=C5=82:
>
> On 5 February 2014 16:31, Piotr Rak <piot...@gmail.com <javascript:>>wrot=
e:
>
>>
>> So rather than adding yet another grammar production rule as alias=20
>> assignment you suggested in your orginal proposal, I'd be in favour of=
=20
>> extending/relaxing exising semantic rules for injected classname, whenev=
er=20
>> it is possible to keep it DRY. No matter how compiler writers will hate =
us=20
>> for making yet another crazy rule to complicate already insane, umm, sor=
ry=20
>> non-trivial name lookup rules :)
>>
>
> Sounds interesting. Assuming there are no issues with it (I'm no core=20
> expert), I feel it would be a worthwhile addition to the language. This=
=20
> pattern does come up often enough that I'd be in favor of a proposal like=
=20
> this.
>
> If it is an injected name, is it useable outside the class? For instance=
:
>
> struct D : B<int> { /* ... */ };
>
> D::B hello; // valid? Private type? Dependent on public/private=20
> inheritance?
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404
>
D::B shouldn't be valid same way as for out of line:
template<typename T_>
C<T_>& C<T_>::operator=3D ...
you can't just say C...
So it is name injected only in class scope, same as this class name is.
After not very long thinking about it, I can't see obvious a flaw, but...
Also when I was learning C++ I remember about thinking why it doesn't=20
already work.
Probably best reality test would be extending clang/gcc to support it and=
=20
playing bit with it. Might try to do that during weekend, if RL won't get=
=20
into way (no promises).
Cheers,
/Piotr
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3376_22371322.1391641716834
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=
=C5=BCytkownik Nevin ":-)" Liber napisa=C5=82:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">On 5 February 2014 16:31, Piotr Rak <span =
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"FUQ349-DKZUJ" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">piot...@gmail.com</a>&=
gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><br><div>So rather than adding yet another grammar product=
ion rule as alias assignment you suggested in your orginal proposal, I'd be=
in favour of extending/relaxing exising semantic rules for injected classn=
ame, whenever it is possible to keep it DRY. No matter how compiler writers=
will hate us for making yet another crazy rule to complicate already insan=
e, umm, sorry non-trivial name lookup rules :)<br clear=3D"all">
</div></div></blockquote><div><br></div><div>Sounds interesting. Assu=
ming there are no issues with it (I'm no core expert), I feel it would be a=
worthwhile addition to the language. This pattern does come up often=
enough that I'd be in favor of a proposal like this.<br>
<br></div><div>If it is an injected name, is it useable outside the class?&=
nbsp; For instance:<br><br></div><div>struct D : B<int> { /* ... */ }=
;<br><br></div><div>D::B hello; // valid? Private type? Depende=
nt on public/private inheritance?<br>
</div></div>-- <br> Nevin ":-)" Liber <mailto:<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"FUQ349-DKZUJ" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">ne...@eviloverlord.com</a><wbr>> (847) 691-1=
404</div></div></blockquote><div><br></div><div>D::B shouldn't be valid sam=
e way as for out of line:</div><div><br></div><div>template<typename T_&=
gt;</div><div>C<T_>& C<T_>::operator=3D ...</div><div><br><=
/div><div>you can't just say C...</div><div>So it is name injected only in =
class scope, same as this class name is.</div><div><br></div><div>After not=
very long thinking about it, I can't see obvious a flaw, but...</div><div>=
Also when I was learning C++ I remember about thinking why it doesn't alrea=
dy work.</div><div><br></div><div>Probably best reality test would be exten=
ding clang/gcc to support it and playing bit with it. Might try to do that =
during weekend, if RL won't get into way (no promises).</div><div><br></div=
><div>Cheers,</div><div>/Piotr</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3376_22371322.1391641716834--
.
Author: Piotr Rak <piotr.rak@gmail.com>
Date: Wed, 5 Feb 2014 15:27:57 -0800 (PST)
Raw View
------=_Part_4194_17423257.1391642877375
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am sorry I did not addess all your questions.
W dniu czwartek, 6 lutego 2014 00:08:36 UTC+1 u=C5=BCytkownik Piotr Rak nap=
isa=C5=82:
>
>
>
> W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=C5=BCytkownik Nevin ":-=
)" Liber=20
> napisa=C5=82:
>>
>> On 5 February 2014 16:31, Piotr Rak <piot...@gmail.com> wrote:
>>
>>>
>>> So rather than adding yet another grammar production rule as alias=20
>>> assignment you suggested in your orginal proposal, I'd be in favour of=
=20
>>> extending/relaxing exising semantic rules for injected classname, whene=
ver=20
>>> it is possible to keep it DRY. No matter how compiler writers will hate=
us=20
>>> for making yet another crazy rule to complicate already insane, umm, so=
rry=20
>>> non-trivial name lookup rules :)
>>>
>>
>> Sounds interesting. Assuming there are no issues with it (I'm no core=
=20
>> expert), I feel it would be a worthwhile addition to the language. This=
=20
>> pattern does come up often enough that I'd be in favor of a proposal lik=
e=20
>> this.
>>
>> If it is an injected name, is it useable outside the class? For instanc=
e:
>>
>> struct D : B<int> { /* ... */ };
>>
>> D::B hello; // valid? Private type? Dependent on public/private=20
>> inheritance?
>>
>
We should not care about public/private/protected inheritance, as this name=
=20
would be visible only at class scope.
Also I don't see reason why D::B should be valid; If i would see D::B i=20
would think of member of class D, not it's direct base.=20
--=20
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
>>
>
> D::B shouldn't be valid same way as for out of line:
>
> template<typename T_>
> C<T_>& C<T_>::operator=3D ...
>
> you can't just say C...
> So it is name injected only in class scope, same as this class name is.
>
> After not very long thinking about it, I can't see obvious a flaw, but...
> Also when I was learning C++ I remember about thinking why it doesn't=20
> already work.
>
> Probably best reality test would be extending clang/gcc to support it and=
=20
> playing bit with it. Might try to do that during weekend, if RL won't get=
=20
> into way (no promises).
>
> Cheers,
> /Piotr
> =20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4194_17423257.1391642877375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am sorry I did not addess all your questions.<div><br>W =
dniu czwartek, 6 lutego 2014 00:08:36 UTC+1 u=C5=BCytkownik Piotr Rak napis=
a=C5=82:<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"><br><=
br>W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=C5=BCytkownik Nevin ":=
-)" Liber napisa=C5=82:<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">On 5 February 2014 16:31, Piotr Rak <span dir=3D"ltr"><<a>piot...@g=
mail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><br><div>So rather than adding yet another grammar product=
ion rule as alias assignment you suggested in your orginal proposal, I'd be=
in favour of extending/relaxing exising semantic rules for injected classn=
ame, whenever it is possible to keep it DRY. No matter how compiler writers=
will hate us for making yet another crazy rule to complicate already insan=
e, umm, sorry non-trivial name lookup rules :)<br clear=3D"all">
</div></div></blockquote><div><br></div><div>Sounds interesting. Assu=
ming there are no issues with it (I'm no core expert), I feel it would be a=
worthwhile addition to the language. This pattern does come up often=
enough that I'd be in favor of a proposal like this.<br>
<br></div><div>If it is an injected name, is it useable outside the class?&=
nbsp; For instance:<br><br></div><div>struct D : B<int> { /* ... */ }=
;<br><br></div><div>D::B hello; // valid? Private type? Depende=
nt on public/private inheritance?<br></div></div></div></div></blockquote><=
/div></blockquote><div><br></div><div>We should not care about public/priva=
te/protected inheritance, as this name would be visible only at class scope=
..</div><div>Also I don't see reason why D::B should be valid; If i would se=
e D::B i would think of member of class D, not it's direct base.<span style=
=3D"font-size: 13px;"> </span></div><div><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"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>
</div></div>-- <br> Nevin ":-)" Liber <mailto:<a>ne...@evilov=
erlord.com</a><wbr>> (847) 691-1404</div></div></blockquote><div><=
br></div><div>D::B shouldn't be valid same way as for out of line:</div><di=
v><br></div><div>template<typename T_></div><div>C<T_>& C&l=
t;T_>::operator=3D ...</div><div><br></div><div>you can't just say C...<=
/div><div>So it is name injected only in class scope, same as this class na=
me is.</div><div><br></div><div>After not very long thinking about it, I ca=
n't see obvious a flaw, but...</div><div>Also when I was learning C++ I rem=
ember about thinking why it doesn't already work.</div><div><br></div><div>=
Probably best reality test would be extending clang/gcc to support it and p=
laying bit with it. Might try to do that during weekend, if RL won't get in=
to way (no promises).</div><div><br></div><div>Cheers,</div><div>/Piotr</di=
v><div> </div></div></blockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4194_17423257.1391642877375--
.
Author: Piotr Rak <piotr.rak@gmail.com>
Date: Wed, 5 Feb 2014 16:03:33 -0800 (PST)
Raw View
------=_Part_7432_20930210.1391645013585
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 6 lutego 2014 00:27:57 UTC+1 u=C5=BCytkownik Piotr Rak nap=
isa=C5=82:
>
> I am sorry I did not addess all your questions.
>
> W dniu czwartek, 6 lutego 2014 00:08:36 UTC+1 u=C5=BCytkownik Piotr Rak n=
apisa=C5=82:
>>
>>
>>
>> W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=C5=BCytkownik Nevin ":=
-)" Liber=20
>> napisa=C5=82:
>>>
>>> On 5 February 2014 16:31, Piotr Rak <piot...@gmail.com> wrote:
>>>
>>>>
>>>> So rather than adding yet another grammar production rule as alias=20
>>>> assignment you suggested in your orginal proposal, I'd be in favour of=
=20
>>>> extending/relaxing exising semantic rules for injected classname, when=
ever=20
>>>> it is possible to keep it DRY. No matter how compiler writers will hat=
e us=20
>>>> for making yet another crazy rule to complicate already insane, umm, s=
orry=20
>>>> non-trivial name lookup rules :)
>>>>
>>>
>>> Sounds interesting. Assuming there are no issues with it (I'm no core=
=20
>>> expert), I feel it would be a worthwhile addition to the language. Thi=
s=20
>>> pattern does come up often enough that I'd be in favor of a proposal li=
ke=20
>>> this.
>>>
>>> If it is an injected name, is it useable outside the class? For=20
>>> instance:
>>>
>>> struct D : B<int> { /* ... */ };
>>>
>>> D::B hello; // valid? Private type? Dependent on public/private=20
>>> inheritance?
>>>
>>
> We should not care about public/private/protected inheritance, as this=20
> name would be visible only at class scope.
> Also I don't see reason why D::B should be valid; If i would see D::B i=
=20
> would think of member of class D, not it's direct base.=20
>
I rushed with anwser, you meant refering to base class using qualified=20
lookup, I wouldn't go there, but I would leave that open for now, but if=20
there is nothing wrong there it might be fine too, no strong opinion yet.
Thanks for noticing that, I haven't considered it, and sorry for noise on=
=20
list.
> --=20
>>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
>>>
>>
>> D::B shouldn't be valid same way as for out of line:
>>
>> template<typename T_>
>> C<T_>& C<T_>::operator=3D ...
>>
>> you can't just say C...
>> So it is name injected only in class scope, same as this class name is.
>>
>> After not very long thinking about it, I can't see obvious a flaw, but..=
..
>> Also when I was learning C++ I remember about thinking why it doesn't=20
>> already work.
>>
>> Probably best reality test would be extending clang/gcc to support it an=
d=20
>> playing bit with it. Might try to do that during weekend, if RL won't ge=
t=20
>> into way (no promises).
>>
>> Cheers,
>> /Piotr
>> =20
>>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_7432_20930210.1391645013585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu czwartek, 6 lutego 2014 00:27:57 UTC+1 u=C5=
=BCytkownik Piotr Rak napisa=C5=82:<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">I am sorry I did not addess all your questions.<div>=
<br>W dniu czwartek, 6 lutego 2014 00:08:36 UTC+1 u=C5=BCytkownik Piotr Rak=
napisa=C5=82:<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"><br>=
<br>W dniu =C5=9Broda, 5 lutego 2014 23:45:27 UTC+1 u=C5=BCytkownik Nevin "=
:-)" Liber napisa=C5=82:<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">On 5 February 2014 16:31, Piotr Rak <span dir=3D"ltr"><<a>piot...@=
gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><br><div>So rather than adding yet another grammar product=
ion rule as alias assignment you suggested in your orginal proposal, I'd be=
in favour of extending/relaxing exising semantic rules for injected classn=
ame, whenever it is possible to keep it DRY. No matter how compiler writers=
will hate us for making yet another crazy rule to complicate already insan=
e, umm, sorry non-trivial name lookup rules :)<br clear=3D"all">
</div></div></blockquote><div><br></div><div>Sounds interesting. Assu=
ming there are no issues with it (I'm no core expert), I feel it would be a=
worthwhile addition to the language. This pattern does come up often=
enough that I'd be in favor of a proposal like this.<br>
<br></div><div>If it is an injected name, is it useable outside the class?&=
nbsp; For instance:<br><br></div><div>struct D : B<int> { /* ... */ }=
;<br><br></div><div>D::B hello; // valid? Private type? Depende=
nt on public/private inheritance?<br></div></div></div></div></blockquote><=
/div></blockquote><div><br></div><div>We should not care about public/priva=
te/protected inheritance, as this name would be visible only at class scope=
..</div><div>Also I don't see reason why D::B should be valid; If i would se=
e D::B i would think of member of class D, not it's direct base.<span style=
=3D"font-size:13px"> </span></div></div></div></blockquote><div><span =
style=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-size: =
13px;">I rushed with anwser, you meant refering to base class using qualifi=
ed lookup, I wouldn't go there, but I would leave that open for now, but if=
there is nothing wrong there it might be fine too, no strong opinion yet.<=
/span><br></div><div>Thanks for noticing that, I haven't considered it, and=
<span style=3D"font-size: 13px;">sorry for noise on list.</span></div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div><br></div><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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div>
</div></div>-- <br> Nevin ":-)" Liber <mailto:<a>ne...@evilov=
erlord.com</a><wbr>> (847) 691-1404</div></div></blockquote><div><=
br></div><div>D::B shouldn't be valid same way as for out of line:</div><di=
v><br></div><div>template<typename T_></div><div>C<T_>& C&l=
t;T_>::operator=3D ...</div><div><br></div><div>you can't just say C...<=
/div><div>So it is name injected only in class scope, same as this class na=
me is.</div><div><br></div><div>After not very long thinking about it, I ca=
n't see obvious a flaw, but...</div><div>Also when I was learning C++ I rem=
ember about thinking why it doesn't already work.</div><div><br></div><div>=
Probably best reality test would be extending clang/gcc to support it and p=
laying bit with it. Might try to do that during weekend, if RL won't get in=
to way (no promises).</div><div><br></div><div>Cheers,</div><div>/Piotr</di=
v><div> </div></div></blockquote></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7432_20930210.1391645013585--
.
Author: Boris Rasin <rasin.boris@gmail.com>
Date: Thu, 6 Feb 2014 04:42:10 -0800 (PST)
Raw View
------=_Part_5610_8872418.1391690530330
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This does not address the core of the issue.
As I already said:
Even when type name of the base class is short, there is still a benefit in=
=20
referring to it using some generic alias.
This improves readability of the code, clearly communicating intent to=20
reference scope of immediate base class, not scope of specific class.
This also improves maintainability of the code, preventing (often hard to=
=20
detect) errors when base class is changed, code copy/pasted to another=20
class, etc.
On Thursday, February 6, 2014 12:31:03 AM UTC+2, Piotr Rak wrote:
>
>
>
> W dniu =C5=9Broda, 5 lutego 2014 10:36:49 UTC+1 u=C5=BCytkownik Boris Ras=
in napisa=C5=82:
>>
>>
>> On Wednesday, February 5, 2014 12:36:59 AM UTC+2, Billy O'Neal wrote:
>>>
>>> Why do we need to implement a crazy workaround for something that users=
=20
>>> can already specify? If you really want to use the word super for this,=
=20
>>> just add a typedef.
>>>
>>> If it doesn't allow users to accomplish anything "new" it is going to b=
e=20
>>> a tough sell for an already very complex language.
>>>
>>
>> Because such typedefs cause (often significant) code duplication.
>>
>
> I agree with both of you -=20
> true we are not making language simpler adding another way of doing=
=20
> things, and also DRY - to C++ grammar
> but also DRY ie Do not Reapet Yourself should be embraced as much as=
=20
> possible
>
> Yet the only way (maybe not only, but a one I'd support/encourage) I feel=
=20
> such proposal moving forward is comming up with rule similar to one we=20
> already have for class name in class template:
>
> template <typename T> class C
> {
> void bar() {}
> void baz(C&); // We don't have to use C<T> here because Foo name is=20
> injected in this scope.
> };
>
> so if for lets say for unambigous case like:
>
> template <typename T> class A : public B<T>
> {
> void foo(B&);
> };
>
> name B would be injected name with implicit meaning B<T> we should get=20
> away with that.
> It should not break any exising code, and I don't see any obvious problem=
=20
> with relaxing rules in such way.
>
> I have not tried with comming with exact and flawless wording, it might=
=20
> turned out to be more tricky, as it's usually for me.
>
> Ofc for case like:
>
> class C : B<int>, B<void*>
> {
> };
>
> typename B should be ambigous.
>
> and for cases:
>
> class C : B<int>
> {
> using B =3D Foo;
> void foo(B); // B is alias of Foo here, and hides injected base class=
=20
> name.
> };
>
> So rather than adding yet another grammar production rule as alias=20
> assignment you suggested in your orginal proposal, I'd be in favour of=20
> extending/relaxing exising semantic rules for injected classname, wheneve=
r=20
> it is possible to keep it DRY. No matter how compiler writers will hate u=
s=20
> for making yet another crazy rule to complicate already insane, umm, sorr=
y=20
> non-trivial name lookup rules :)
>
> Cheers,
> /Piotr
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5610_8872418.1391690530330
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This does not address the core of the issue.<br>As I alrea=
dy said:<br><br>Even when type name of the base class is short, there is st=
ill a benefit in referring to it using some generic alias.<br>This
improves readability of the code, clearly communicating intent to referenc=
e scope of immediate base class, not scope of specific class.<br>This
also improves maintainability of the code, preventing (often hard to=20
detect) errors when base class is changed, code copy/pasted to another=20
class, etc.<br><br>On Thursday, February 6, 2014 12:31:03 AM UTC+2, Piotr R=
ak 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"><br>=
<br>W dniu =C5=9Broda, 5 lutego 2014 10:36:49 UTC+1 u=C5=BCytkownik Boris R=
asin napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br>On Wednesday, February 5, 2014 12:36:59 AM UTC+2, Billy O'Neal wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why do we need to im=
plement a crazy workaround for something that users can already specify? If=
you really want to use the word super for this, just add a typedef.<div><b=
r></div><div>If it doesn't allow users to accomplish anything "new" it is g=
oing to be a tough sell for an already very complex language.</div></div></=
blockquote><div><br>Because such typedefs <span>cause </span>(often signifi=
cant) code duplication.</div></div></blockquote><div><br></div><div>I agree=
with both of you - </div><div> true we are not making lan=
guage simpler adding another way of doing things, and also DRY - =
;<span style=3D"font-size:13px">to C++ grammar</span></div><div><span style=
=3D"font-size:13px"> but also DRY ie Do not Reapet Yourself sho=
uld be embraced as much as possible</span></div><div><span style=3D"font-si=
ze:13px"><br></span></div><div><span style=3D"font-size:13px">Yet t</span><=
span style=3D"font-size:13px">he only way (maybe not only, but a one I'd su=
pport/encourage) I feel such proposal moving forward is comming up with rul=
e similar to one we already have for class name in class template:</span></=
div><div><br></div><div>template <typename T> class C</div><div>{</di=
v><div> void bar() {}</div><div> void baz(C&); =
// We don't have to use C<T> here because Foo name is injected in thi=
s scope.</div><div>};</div><div><br></div><div>so if for lets say for unamb=
igous case like:</div><div><br></div><div>template <typename T> class=
A : public B<T></div><div>{</div><div> void foo(B&);=
</div><div>};</div><div><br></div><div>name B would be injected name with i=
mplicit meaning B<T> we should get away with that.</div><div>It shoul=
d not break any exising code, and I don't see any obvious problem with rela=
xing rules in such way.</div><div><br></div><div>I have not tried with comm=
ing with exact and flawless <span style=3D"font-size:13px"> </spa=
n><span style=3D"font-size:13px">wording,</span><span style=3D"font-size:13=
px"> </span><span style=3D"font-size:13px">it might turned out to be m=
ore tricky, as it's usually for me.</span></div><div><br></div><div>Ofc for=
case like:</div><div><br></div><div>class C : B<int>, B<void*>=
</div><div>{</div><div>};</div><div><br></div><div>typename B should be amb=
igous.</div><div><br></div><div>and for cases:</div><div><br></div><div>cla=
ss C : B<int></div><div>{</div><div> using B =3D Foo;</div><div=
> void foo(B); // B is alias of Foo here, and hides injected base cla=
ss name.</div><div>};</div><div><br></div><div>So rather than adding yet an=
other grammar production rule as alias assignment you suggested in your org=
inal proposal, I'd be in favour of extending/relaxing exising semantic rule=
s for injected classname, whenever it is possible to keep it DRY. No matter=
how compiler writers will hate us for making yet another crazy rule to com=
plicate already insane, umm, sorry non-trivial name lookup rules :)</div><d=
iv><br></div><div>Cheers,</div><div>/Piotr</div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5610_8872418.1391690530330--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 06 Feb 2014 11:19:35 -0500
Raw View
On 2014-02-06 07:42, Boris Rasin wrote:
> This does not address the core of the issue.
> As I already said:
>
> Even when type name of the base class is short, there is still a benefit in
> referring to it using some generic alias.
> This improves readability of the code, clearly communicating intent to
> reference scope of immediate base class, not scope of specific class.
> This also improves maintainability of the code, preventing (often hard to
> detect) errors when base class is changed, code copy/pasted to another
> class, etc.
....and doesn't need to be changed if the base class type changes.
What about:
basetype(*this, 2); // third base of 'this' (start at 0, not 1)
basetype(this, 1); // implicitly removes indirections
basetype(this); // always choose first base if not specified
basetype(*p); // can use on arbitrary class/struct pointer
basetype(Foo); // can also specify a class/struct type
basetype(); // if no param, use enclosing scope type
basetype(1); // like above, second base
So you could write e.g.:
class Bar : Foo
{
...
};
Bar::flub()
{
// all of these are equivalent
basetype()::flub();
basetype(this)::flub();
basetype(*this, 0)::flub();
basetype(Bar)::flub();
// error; not a class type
basetype(int)::flub();
// error; no such base
basetype(1)::flub();
}
Main disadvantage is that it it still introducing a new keyword.
(Hopefully one that has been less used than 'super', though.)
--
Matthew
--
---
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: Boris Rasin <rasin.boris@gmail.com>
Date: Thu, 6 Feb 2014 08:47:22 -0800 (PST)
Raw View
------=_Part_604_20931528.1391705242300
Content-Type: text/plain; charset=UTF-8
On Thursday, February 6, 2014 6:19:35 PM UTC+2, Matthew Woehlke wrote:
>
> What about:
>
> basetype(*this, 2); // third base of 'this' (start at 0, not 1)
> basetype(this, 1); // implicitly removes indirections
> basetype(this); // always choose first base if not specified
> basetype(*p); // can use on arbitrary class/struct pointer
> basetype(Foo); // can also specify a class/struct type
> basetype(); // if no param, use enclosing scope type
> basetype(1); // like above, second base
>
Perhaps it would be better to extend <type_traits> with another compiler
assisted standard library component similar to std::underlying_type<T>, for
example. Something like std::base_type<T>.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_604_20931528.1391705242300
Content-Type: text/html; charset=UTF-8
<div dir="ltr">On Thursday, February 6, 2014 6:19:35 PM UTC+2, Matthew Woehlke wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What about:
<br>
<br>basetype(*this, 2); // third base of 'this' (start at 0, not 1)
<br>basetype(this, 1); // implicitly removes indirections
<br>basetype(this); // always choose first base if not specified
<br>basetype(*p); // can use on arbitrary class/struct pointer
<br>basetype(Foo); // can also specify a class/struct type
<br>basetype(); // if no param, use enclosing scope type
<br>basetype(1); // like above, second base
<br></blockquote><div><br>Perhaps it would be better to extend <type_traits> with another compiler assisted standard library component similar to std::underlying_type<T>, for example. Something like std::base_type<T>.<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_604_20931528.1391705242300--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 06 Feb 2014 12:24:22 -0500
Raw View
On 2014-02-06 11:47, Boris Rasin wrote:
> On Thursday, February 6, 2014 6:19:35 PM UTC+2, Matthew Woehlke wrote:
>> What about:
>>
>> basetype(*this, 2); // third base of 'this' (start at 0, not 1)
>> basetype(this, 1); // implicitly removes indirections
>> basetype(this); // always choose first base if not specified
>> basetype(*p); // can use on arbitrary class/struct pointer
>> basetype(Foo); // can also specify a class/struct type
>> basetype(); // if no param, use enclosing scope type
>> basetype(1); // like above, second base
>
> Perhaps it would be better to extend <type_traits> with another compiler
> assisted standard library component similar to std::underlying_type<T>, for
> example. Something like std::base_type<T>.
Would this be usable with no parameters, though? If not, I don't see it
as a substantial improvement on existing methods.
--
Matthew
--
---
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: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 7 Feb 2014 03:36:49 +0100
Raw View
--089e01634ec2a705c704f1c7dc83
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 6, 2014 at 5:19 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> basetype(*this, 2); // third base of 'this' (start at 0, not 1)
> basetype(this, 1); // implicitly removes indirections
> basetype(this); // always choose first base if not specified
> basetype(*p); // can use on arbitrary class/struct pointer
> basetype(Foo); // can also specify a class/struct type
> basetype(); // if no param, use enclosing scope type
> basetype(1); // like above, second base
>
When thinking about multiple inheritance and looking at this, I have no
idea if you mean for example at the first
line if it's the third base in the inheritance graph in depth or taking
into account the breadth (when one of the type inherit several types at
once).
Basically, how would that work with multiple inhertiance?
--
---
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/.
--089e01634ec2a705c704f1c7dc83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Feb 6, 2014 at 5:19 PM, Matthew Woehlke <span dir=3D"ltr"><<a hr=
ef=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@use=
rs.sourceforge.net</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"><div id=3D":1hg" style=3D"overflow:hidden">b=
asetype(*this, 2); // third base of 'this' (start at 0, not 1)<br>
basetype(this, 1); // implicitly removes indirections<br>
basetype(this); // always choose first base if not specified<br>
basetype(*p); // can use on arbitrary class/struct pointer<br>
basetype(Foo); // can also specify a class/struct type<br>
basetype(); // if no param, use enclosing scope type<br>
basetype(1); // like above, second base<br></div></blockquote></div><br>Whe=
n thinking about multiple inheritance and looking at this, I have no idea i=
f you mean for example at the first=C2=A0<br>line if it's the third bas=
e in the inheritance =C2=A0graph in depth or taking into account the breadt=
h (when one of the type inherit several types at once).<br>
<br></div><div class=3D"gmail_extra">Basically, how would that work with mu=
ltiple inhertiance?</div><div class=3D"gmail_extra"><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01634ec2a705c704f1c7dc83--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 07 Feb 2014 11:39:03 -0500
Raw View
On 2014-02-06 21:36, Klaim - Jo=C3=ABl Lamotte wrote:
> On Thu, Feb 6, 2014 at 5:19 PM, Matthew Woehlke <
> mw_triad@users.sourceforge.net> wrote:
>
>> basetype(*this, 2); // third base of 'this' (start at 0, not 1)
>> basetype(this, 1); // implicitly removes indirections
>> basetype(this); // always choose first base if not specified
>> basetype(*p); // can use on arbitrary class/struct pointer
>> basetype(Foo); // can also specify a class/struct type
>> basetype(); // if no param, use enclosing scope type
>> basetype(1); // like above, second base
>>
>
> When thinking about multiple inheritance and looking at this, I have no
> idea if you mean for example at the first
> line if it's the third base in the inheritance graph in depth or taking
> into account the breadth (when one of the type inherit several types at
> once).
It's the third class listed as a direct ancestor of the specified type.=20
Traversing the inheritance tree would be extremely dangerous, because a=20
change to some ancestor's base class(es) would radically change the=20
meaning of your code. There is no good reason why 'basetype' should do that=
..
If you *really* want the second base class of the first base class of=20
the second base class, then say that:
basetype(basetype(basetype(2)), 2)
Yes, it's hard to read, but honestly, how often do you care about the=20
base class of a base class? (And when you do, do you really not want to=20
name the class explicitly?)
TBH, while constructs like the above should definitely work (after all,=20
it should accept any expression which evaluates to either a class/struct=20
type, or an identifier having a class/struct type after removal of=20
indirections), I suspect that it would be quite rare to actually use=20
such in practice.
--=20
Matthew
--=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: Fri, 07 Feb 2014 18:48:02 -0800
Raw View
Em sex 07 fev 2014, =E0s 11:39:03, Matthew Woehlke escreveu:
> If you *really* want the second base class of the first base class of
> the second base class, then say that:
>=20
> basetype(basetype(basetype(2)), 2)
>=20
> Yes, it's hard to read, but honestly, how often do you care about the
> base class of a base class? (And when you do, do you really not want to
> name the class explicitly?)
Think of Git parsing:
master^2^^2
It's ugly, but it gets you there.
If someone really wants the recursive version, it should always go via the=
=20
first parent, again like Git:
master~3
By the way, it might be good to qualify the base as virtual or non-virtual.
--=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: Boris Rasin <rasin.boris@gmail.com>
Date: Sun, 9 Feb 2014 02:05:55 -0800 (PST)
Raw View
------=_Part_64_13727054.1391940355901
Content-Type: text/plain; charset=UTF-8
On Thursday, February 6, 2014 7:24:22 PM UTC+2, Matthew Woehlke wrote:
>
> On 2014-02-06 11:47, Boris Rasin wrote:
> > Perhaps it would be better to extend <type_traits> with another compiler
> > assisted standard library component similar to std::underlying_type<T>,
> for
> > example. Something like std::base_type<T>.
>
> Would this be usable with no parameters, though? If not, I don't see it
> as a substantial improvement on existing methods.
>
Template parameters can already be omitted within the class, so there is no
need to change anything in this regard.
Here is how I imagine it would be used:
template <typename X, int Y>
class B : public A<X, Y, int, float, std::allocator<char>>
{
typedef std::base_type<B>:: type base;
};
--
---
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_64_13727054.1391940355901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 6, 2014 7:24:22 PM UTC+2, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-02-06 11:4=
7, Boris Rasin wrote:
<br>> Perhaps it would be better to extend <type_traits> with anot=
her compiler
<br>> assisted standard library component similar to std::underlying_typ=
e<T>, for
<br>> example. Something like std::base_type<T>.
<br>
<br>Would this be usable with no parameters, though? If not, I don't see it=
=20
<br>as a substantial improvement on existing methods.<br></blockquote><div>=
<br>Template parameters can already be omitted within the class, so there i=
s no need to change anything in this regard.<br>Here is how I imagine it wo=
uld be used:<br><br>template <typename X, int Y><br>class B : public =
A<X, Y, int, float, std::allocator<char>><br>{<br> typede=
f std::base_type<B>:: type base;<br>};<br><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_64_13727054.1391940355901--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 10 Feb 2014 11:57:35 -0500
Raw View
On 2014-02-07 21:48, Thiago Macieira wrote:
> Em sex 07 fev 2014, =C3=A0s 11:39:03, Matthew Woehlke escreveu:
>> If you *really* want the second base class of the first base class of
>> the second base class, then say that:
>>
>> basetype(basetype(basetype(2)), 2)
>>
>> Yes, it's hard to read, but honestly, how often do you care about the
>> base class of a base class? (And when you do, do you really not want to
>> name the class explicitly?)
>
> Think of Git parsing:
>
> master^2^^2
>
> It's ugly, but it gets you there.
>
> If someone really wants the recursive version, it should always go via th=
e
> first parent, again like Git:
>
> master~3
I'm not sure what, if anything, you are suggesting?
Seeing this, however, it occurs to me that if cases like the above are=20
sufficiently common, we could extend the syntax like:
basetype(expr, 0, 1, 0, 2)
....which says (reading right to left) 'the third base class of the first=20
base class of the second base class of the first base class of the type=20
of "expr"'. Note that first base classes must be specified in this instance=
..
I still think going more than one level up the hierarchy is going to be=20
quite unusual and/or that it is better to name the intended class in=20
such case. Most of the time you'd be using "basetype()", occasionally=20
you'd be using one of "basetype(expr)", "basetype(num)" or the=20
combination "basetype(expr, num)" (where 'expr' does not itself contain=20
"basetype(...)"), and very rarely anything else.
--=20
Matthew
--=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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 10 Feb 2014 12:02:18 -0500
Raw View
On 2014-02-09 05:05, Boris Rasin wrote:
> On Thursday, February 6, 2014 7:24:22 PM UTC+2, Matthew Woehlke wrote:
>> On 2014-02-06 11:47, Boris Rasin wrote:
>>> Perhaps it would be better to extend <type_traits> with another compiler
>>> assisted standard library component similar to std::underlying_type<T>,
>>> for example. Something like std::base_type<T>.
>>
>> Would this be usable with no parameters, though? If not, I don't see it
>> as a substantial improvement on existing methods.
>
> Template parameters can already be omitted within the class, so there is no
> need to change anything in this regard.
No, you misunderstand. I don't mean parameters of the types of the
parameters of std::base_type, I mean the parameters to std::base_type
itself. IOW, can I write "std::base_type" by itself (or maybe
"std::base_type<>") and have it automagically be the base type of 'this'?
IOW, I think it is most valuable to have something that lets me write e.g.:
Bar Foo::bar(...) // arguments elided
{
basetype()::bar(...);
}
....and similarly makes it unnecessary to write type aliases in a class
definition because the alias would be redundant with "basetype()" (or
"basetype(1)", etc. in case of multiple inheritance). These are more
characters than e.g. "super", but few enough that I think most people
would prefer to spell it out in the interest of obviousness, whereas
with e.g. "std::base_type<this>" you're starting to exceed that
threshold. Especially in cases that the type name is (a) required (i.e.
can't use "this") and (b) very long.
> Here is how I imagine it would be used:
> typedef std::base_type<B>:: type base;
Per above, the objective as I see it is to provide something that avoids
programmers feeling it necessary to use such typedefs.
--
Matthew
--
---
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: Boris Rasin <rasin.boris@gmail.com>
Date: Tue, 11 Feb 2014 12:28:50 -0800 (PST)
Raw View
------=_Part_741_18394127.1392150530481
Content-Type: text/plain; charset=UTF-8
On Monday, February 10, 2014 7:02:18 PM UTC+2, Matthew Woehlke wrote:
>
> On 2014-02-09 05:05, Boris Rasin wrote:
> > Here is how I imagine it would be used:
> > typedef std::base_type<B>::type base;
>
> Per above, the objective as I see it is to provide something that avoids
> programmers feeling it necessary to use such typedefs.
>
Most of my class definitions already start with a bunch of typedefs, so for
me such typedef is a satisfactory solution. Also, in case of multiple
inheritance, readability and maintainability is much better if we use
aliases, not indexes, to reference base classes:
class B : public A, public Events<B>
{
typedef std::base_type<B,0>::type base;
typedef std::base_type<B,1>::type base_events;
};
Referring throughout B's implementation to "base_events" is a much better
option than referring to "super<1>" or something like that.
--
---
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_741_18394127.1392150530481
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 10, 2014 7:02:18 PM UTC+2, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-02-09 05:05=
, Boris Rasin wrote:
<br>> Here is how I imagine it would be used:
<br>> typedef std::base_type<B>::type base;<br>
<br>Per above, the objective as I see it is to provide something that avoid=
s=20
<br>programmers feeling it necessary to use such typedefs.<br></blockquote>=
<div><br>Most of my class definitions already start with a bunch of typedef=
s, so for me such typedef is a satisfactory solution. Also, in case of mult=
iple inheritance, readability and maintainability is much better if we use =
aliases, not indexes, to reference base classes:<br><br>class B : public A,=
public Events<B><br>{<br> typedef std::base_type<B,0>::t=
ype base;<br> typedef std::base_type<B,1>::type base_events;<br=
>};<br><br>Referring throughout B's implementation to "base_events" is a mu=
ch better option than referring to "super<1>" or something like that.=
<br><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_741_18394127.1392150530481--
.
Author: robert.kawulak@gmail.com
Date: Sun, 16 Mar 2014 20:41:42 -0700 (PDT)
Raw View
------=_Part_2449_16577491.1395027702780
Content-Type: text/plain; charset=UTF-8
I really like the OP's proposal - it's simple and clear, and I've found
myself wanting something like this multiple times.
Note that the injected-class-name trick, apart from being less explicit,
won't work in a case when the base class is a metafunction invocation
result:
template<typename T>
class A : public B = F<T>::type
{
...
};
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2449_16577491.1395027702780
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">
<p>I really like the OP's proposal - it's simple and clear, and I've found
myself wanting something like this multiple times.</p>
<p>Note that the injected-class-name trick, apart from being less explicit,
won't work in a case when the base class is a metafunction invocation resul=
t:</p>
<p class=3D"MsoNormal" style=3D"background:#FAFAFA"><span style=3D"font-siz=
e:10.0pt;
font-family:"Courier New";color:#000088">template</span><span sty=
le=3D"font-size:
10.0pt;font-family:"Courier New";color:#666600"><</span><span =
style=3D"font-size:10.0pt;font-family:"Courier New";color:#000088=
">typename</span><span style=3D"font-size:10.0pt;font-family:"Courier =
New";color:black"> T</span><span style=3D"font-size:10.0pt;font-family=
:"Courier New";color:#666600">></span><span style=3D"font-size=
:10.0pt;font-family:"Courier New";color:black"><br>
</span><span style=3D"font-size:10.0pt;font-family:"Courier New";=
color:#000088">class</span><span style=3D"font-size:10.0pt;font-family:&quo=
t;Courier New";color:black"> A </span><span style=3D"font-size:10.0pt;=
font-family:"Courier New";color:#666600">:</span><span style=3D"f=
ont-size:10.0pt;font-family:"Courier New";color:black"> </span><s=
pan style=3D"font-size:10.0pt;font-family:"Courier New";color:#00=
0088">public</span><span style=3D"font-size:10.0pt;font-family:"Courie=
r New";color:black"> B </span><span style=3D"font-size:10.0pt;font-fam=
ily:"Courier New";color:#666600">=3D</span><span style=3D"font-si=
ze:10.0pt;font-family:"Courier New";color:black"> F</span><span s=
tyle=3D"font-size:10.0pt;font-family:"Courier New";color:#666600"=
><</span><span style=3D"font-size:10.0pt;font-family:"Courier New&q=
uot;;color:black">T</span><span style=3D"font-size:10.0pt;font-family:"=
;Courier New";color:#666600">>::</span><span style=3D"font-size:10.=
0pt;font-family:"Courier New";color:black">type<br>
</span><span style=3D"font-size:10.0pt;font-family:"Courier New";=
color:#666600">{</span><span style=3D"font-size:10.0pt;font-family:"Co=
urier New";color:black"><br>
</span><span style=3D"font-size:10.0pt;font-family:"Cour=
ier New";
color:#666600">...</span><span style=3D"font-size:10.0pt;font-family:"=
Courier New";
color:black"><br>
</span><span style=3D"font-size:10.0pt;font-family:"Courier New";=
color:#666600">};</span><br></p><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 />
------=_Part_2449_16577491.1395027702780--
.
Author: <robert.kawulak@gmail.com>
Date: Tue, 18 Mar 2014 23:17:06 +0100
Raw View
This is a multi-part message in MIME format.
------=_NextPart_000_00A2_01CF4300.2F7AC630
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
(Please excuse me if you received this message several times =E2=80=93 due =
to some quirk in Google Groups it appears as =E2=80=9Cdeleted=E2=80=9D and =
I=E2=80=99m not sure if it has been delivered at all.)
I really like the OP's proposal - it's simple and clear, and I've found mys=
elf wanting something like this multiple times.
Note that the injected-class-name trick, apart from being less explicit, wo=
n't work in a case when the base class is a metafunction invocation result:
template<typename T>
class A : public B =3D F<T>::type
{
...
};
--=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/.
------=_NextPart_000_00A2_01CF4300.2F7AC630
Content-Type: text/html; boundary="----=_Part_2448_30744203.1395027702778"; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-compose;}
..MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DPL link=3Dblue vlink=
=3Dpurple><div class=3DWordSection1><div><p><span lang=3DEN-GB>(Please excu=
se me if you received this message several times =E2=80=93 due to some quir=
k in Google Groups it appears as =E2=80=9Cdeleted=E2=80=9D and I=E2=80=99m =
not sure if it has been delivered at all.)<o:p></o:p></span></p><p><span la=
ng=3DEN-GB>I really like the OP's proposal - it's simple and clear, and I'v=
e found myself wanting something like this multiple times.<o:p></o:p></span=
></p><p><span lang=3DEN-GB>Note that the injected-class-name trick, apart f=
rom being less explicit, won't work in a case when the base class is a meta=
function invocation result:<o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;background:#FAFAFA'>=
<span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New";colo=
r:#000088'>template</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font=
-family:"Courier New";color:#666600'><</span><span lang=3DEN-GB style=3D=
'font-size:10.0pt;font-family:"Courier New";color:#000088'>typename</span><=
span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New";color=
:black'> T</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"=
Courier New";color:#666600'>></span><span lang=3DEN-GB style=3D'font-siz=
e:10.0pt;font-family:"Courier New";color:black'><br></span><span lang=3DEN-=
GB style=3D'font-size:10.0pt;font-family:"Courier New";color:#000088'>class=
</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier Ne=
w";color:black'> A </span><span lang=3DEN-GB style=3D'font-size:10.0pt;font=
-family:"Courier New";color:#666600'>:</span><span lang=3DEN-GB style=3D'fo=
nt-size:10.0pt;font-family:"Courier New";color:black'> </span><span lang=3D=
EN-GB style=3D'font-size:10.0pt;font-family:"Courier New";color:#000088'>pu=
blic</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courie=
r New";color:black'> B </span><span lang=3DEN-GB style=3D'font-size:10.0pt;=
font-family:"Courier New";color:#666600'>=3D</span><span lang=3DEN-GB style=
=3D'font-size:10.0pt;font-family:"Courier New";color:black'> F</span><span =
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New";color:#666=
600'><</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"C=
ourier New";color:black'>T</span><span lang=3DEN-GB style=3D'font-size:10.0=
pt;font-family:"Courier New";color:#666600'>>::</span><span lang=3DEN-GB=
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>type<br><=
/span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New=
";color:#666600'>{</span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-=
family:"Courier New";color:black'><br> </span><span lang=3DEN-=
GB style=3D'font-size:10.0pt;font-family:"Courier New";color:#666600'>...</=
span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"=
;color:black'><br></span><span lang=3DEN-GB style=3D'font-size:10.0pt;font-=
family:"Courier New";color:#666600'>};</span><span lang=3DEN-GB><o:p></o:p>=
</span></p></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_NextPart_000_00A2_01CF4300.2F7AC630--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 19 Mar 2014 11:50:15 -0400
Raw View
--001a11c33ef2d9dff304f4f79b53
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Mar 16, 2014 at 11:41 PM, <robert.kawulak@gmail.com> wrote:
> I really like the OP's proposal - it's simple and clear, and I've found
> myself wanting something like this multiple times.
>
> Note that the injected-class-name trick, apart from being less explicit,
> won't work in a case when the base class is a metafunction invocation
> result:
>
> template<typename T>
> class A : public B = F<T>::type
> {
> ...
> };
>
>
>
Yes, back to the original proposal - I like it. I think
- typedef'ing the base class is common, and useful
- other languages have 'super', but we can't (easily) due to multiple
inheritance
so a solution to this would definitely get used.
As for:
> If it doesn't allow users to accomplish anything "new" it is going to be
a tough sell for an already very complex language.
Nothing we add accomplishes anything new. We could code in assembly and
accomplish the same thing. The question is about expressiveness.
Having said that, I don't think it is a killer feature. We can do
without. But it is nice, and it expresses a common idiom.
As for things like std::base_type<>,
I think this will be needed for introspection, if/when we get
introspection. However, I hope to never see it used _beyond_ introspection.
ie if you know the name of the base class, use the real name (and/or
typedef it). Don't go around using std::base_type<2> in your code. How
meaningless.
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/.
--001a11c33ef2d9dff304f4f79b53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Mar 16, 2014 at 11:41 PM, <span dir=3D"ltr"><<a href=3D=
"mailto:robert.kawulak@gmail.com" target=3D"_blank">robert.kawulak@gmail.co=
m</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">
<p>I really like the OP's proposal - it's simple and clear, and I&#=
39;ve found
myself wanting something like this multiple times.</p>
<p>Note that the injected-class-name trick, apart from being less explicit,
won't work in a case when the base class is a metafunction invocation r=
esult:</p>
<p class=3D"MsoNormal" style=3D"background:none repeat scroll 0% 0% rgb(250=
,250,250)"><span style=3D"font-size:10pt;font-family:"Courier New"=
;;color:rgb(0,0,136)">template</span><span style=3D"font-size:10pt;font-fam=
ily:"Courier New";color:rgb(102,102,0)"><</span><span style=3D=
"font-size:10pt;font-family:"Courier New";color:rgb(0,0,136)">typ=
ename</span><span style=3D"font-size:10pt;font-family:"Courier New&quo=
t;"> T</span><span style=3D"font-size:10pt;font-family:"Courier New&qu=
ot;;color:rgb(102,102,0)">></span><span style=3D"font-size:10pt;font-fam=
ily:"Courier New""><br>
</span><span style=3D"font-size:10pt;font-family:"Courier New";co=
lor:rgb(0,0,136)">class</span><span style=3D"font-size:10pt;font-family:&qu=
ot;Courier New""> A </span><span style=3D"font-size:10pt;font-family:&=
quot;Courier New";color:rgb(102,102,0)">:</span><span style=3D"font-si=
ze:10pt;font-family:"Courier New""> </span><span style=3D"font-si=
ze:10pt;font-family:"Courier New";color:rgb(0,0,136)">public</spa=
n><span style=3D"font-size:10pt;font-family:"Courier New""> B </s=
pan><span style=3D"font-size:10pt;font-family:"Courier New";color=
:rgb(102,102,0)">=3D</span><span style=3D"font-size:10pt;font-family:"=
Courier New""> F</span><span style=3D"font-size:10pt;font-family:"=
;Courier New";color:rgb(102,102,0)"><</span><span style=3D"font-siz=
e:10pt;font-family:"Courier New"">T</span><span style=3D"font-siz=
e:10pt;font-family:"Courier New";color:rgb(102,102,0)">>::</sp=
an><span style=3D"font-size:10pt;font-family:"Courier New"">type<=
br>
</span><span style=3D"font-size:10pt;font-family:"Courier New";co=
lor:rgb(102,102,0)">{</span><span style=3D"font-size:10pt;font-family:"=
;Courier New""><br>
=A0 =A0 </span><span style=3D"font-size:10pt;font-family:"Courier New&=
quot;;color:rgb(102,102,0)">...</span><span style=3D"font-size:10pt;font-fa=
mily:"Courier New""><br>
</span><span style=3D"font-size:10pt;font-family:"Courier New";co=
lor:rgb(102,102,0)">};</span><br></p><br></div><div class=3D""><div class=
=3D"h5">
<p></p><br></div></div></blockquote></div><br><br></div><div class=3D"gmail=
_extra">Yes, back to the original proposal - I like it.=A0 I think<br><br><=
/div><div class=3D"gmail_extra">- typedef'ing the base class is common,=
and useful<br>
</div><div class=3D"gmail_extra">- other languages have 'super', bu=
t we can't (easily) due to multiple inheritance<br><br></div><div class=
=3D"gmail_extra">so a solution to this would definitely get used.<br><br></=
div>
<div class=3D"gmail_extra">As for:<br><div><br>> If it doesn't allow=
users to accomplish anything "new" it is going to be a tough sel=
l for an already very complex language.<br><br></div><div>Nothing we add ac=
complishes anything new.=A0 We could code in assembly and accomplish the sa=
me thing.=A0 The question is about expressiveness.<br>
</div><div>Having said that, I don't think it is a killer feature.=A0 W=
e can do without.=A0 But it is nice, and it expresses a common idiom.<br><b=
r></div><div>As for things like std::base_type<>, <br><br>I think thi=
s will be needed for introspection, if/when we get introspection.=A0 Howeve=
r, I hope to never see it used _beyond_ introspection.<br>
</div><div>ie if you know the name of the base class, use the real name (an=
d/or typedef it).=A0 Don't go around using std::base_type<2> in y=
our code.=A0 How meaningless.<br></div><br></div><div class=3D"gmail_extra"=
>Tony<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 />
--001a11c33ef2d9dff304f4f79b53--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 19 Mar 2014 13:54:15 -0400
Raw View
On 2014-03-19 11:50, Tony V E wrote:
> As for things like std::base_type<>,
>
> I think this will be needed for introspection, if/when we get
> introspection. However, I hope to never see it used _beyond_ introspection.
> ie if you know the name of the base class, use the real name (and/or
> typedef it). Don't go around using std::base_type<2> in your code. How
> meaningless.
....but I can apply the same argument to the original proposal... why
should I *ever* refer to a base class via an alias (of any form) when I
know what it is?
1. It's shorter / more convenient.
2. It reduces the code that needs to change if the name of the base
class changes.
Both those are equally applicable to any form of aliasing. Indeed, that
other languages *have* a 'super' suggests that there is value to
something like 'basetype'...
--
Matthew
--
---
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: Tony V E <tvaneerd@gmail.com>
Date: Wed, 19 Mar 2014 15:07:23 -0400
Raw View
--089e01228132d9560204f4fa5c1c
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 19, 2014 at 1:54 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-03-19 11:50, Tony V E wrote:
>
>> As for things like std::base_type<>,
>>
>> I think this will be needed for introspection, if/when we get
>> introspection. However, I hope to never see it used _beyond_
>> introspection.
>> ie if you know the name of the base class, use the real name (and/or
>> typedef it). Don't go around using std::base_type<2> in your code. How
>> meaningless.
>>
>
> ...but I can apply the same argument to the original proposal... why
> should I *ever* refer to a base class via an alias (of any form) when I
> know what it is?
>
> 1. It's shorter / more convenient.
> 2. It reduces the code that needs to change if the name of the base class
> changes.
>
>
An alias gives something a *name*. Not just a (typically) shorter name,
but hopefully a more-meaningful name in context. Giving it meaning is
often more useful than just refactoring for DRY, etc.
> Both those are equally applicable to any form of aliasing. Indeed, that
> other languages *have* a 'super' suggests that there is value to something
> like 'basetype'...
>
>
Yes, super is useful in the generic sense. Like a virtual function that
does something, but first (or last) calls the base class version of the
function.
virtual doFoo()
{
super::doFoo();
custom_stuff();
}
That's a common pattern in java. Also a terrible pattern (see, instead
http://www.gotw.ca/publications/mill18.htm and the Non-Virtual Interface
pattern).
But yes, super is useful here. And also used generically, ie, "whatever
super is, I don't care, just make sure it is called first".
But I worry that
virtual doFoo()
{
base_type<2>::doFoo();
custom_stuff();
}
is fragile and scary. Just reorder the base classes to change behaviour,
or, if lucky, fail to compile (when base_type<2>::doFoo() doesn't exist).
I'd prefer
virtual doFoo()
{
foo_base::doFoo();
custom_stuff();
}
where foo_base = base_type<2> is set up somewhere.
I could also see a generic:
virtual doFoo()
{
for all i base_type<i>::doFoo();
custom_stuff();
}
given some syntax. But I'm not sure how useful that would be. Typically
multiple inheritance is because *1* of those bases defines the virtual
function, not all of them.
But I can imagine a general case of iterating over all base classes, for...
something. Most likely magic compile time meta programming stuff.
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/.
--089e01228132d9560204f4fa5c1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Mar 19, 2014 at 1:54 PM, Matthew Woehlke <span dir=3D"ltr">=
<<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</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 class=3D"">On 2014-0=
3-19 11:50, Tony V E 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">
As for things like std::base_type<>,<br>
<br>
I think this will be needed for introspection, if/when we get<br>
introspection. =A0However, I hope to never see it used _beyond_ introspecti=
on.<br>
ie if you know the name of the base class, use the real name (and/or<br>
typedef it). =A0Don't go around using std::base_type<2> in your c=
ode. =A0How<br>
meaningless.<br>
</blockquote>
<br></div>
....but I can apply the same argument to the original proposal... why should=
I *ever* refer to a base class via an alias (of any form) when I know what=
it is?<br>
<br>
1. It's shorter / more convenient.<br>
2. It reduces the code that needs to change if the name of the base class c=
hanges.<br>
<br></blockquote><div><br></div><div>An alias gives something a *name*.=A0 =
Not just a (typically) shorter name, but hopefully a more-meaningful name i=
n context.=A0 Giving it meaning is often more useful than just refactoring =
for DRY, etc.<br>
</div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Both those are equally applicable to any form of aliasing. Indeed, that oth=
er languages *have* a 'super' suggests that there is value to somet=
hing like 'basetype'...<span class=3D""><font color=3D"#888888"><br=
>
<br></font></span></blockquote><div><br></div><div>Yes, super is useful in =
the generic sense.=A0 Like a virtual function that does something, but firs=
t (or last) calls the base class version of the function.<br><br></div><div=
>
virtual doFoo()<br>{<br></div><div>=A0=A0 super::doFoo();<br></div><div>=A0=
=A0 custom_stuff();<br>}<br><br></div><div>That's a common pattern in j=
ava.=A0 Also a terrible pattern (see, instead <a href=3D"http://www.gotw.ca=
/publications/mill18.htm">http://www.gotw.ca/publications/mill18.htm</a> an=
d the Non-Virtual Interface pattern).<br>
</div><div>But yes, super is useful here.=A0 And also used generically, ie,=
"whatever super is, I don't care, just make sure it is called fir=
st".<br><br>But I worry that<br><br></div><div>virtual doFoo()<br>{<br=
>
</div><div>=A0=A0 base_type<2>::doFoo();<br></div><div>=A0=A0 custom_=
stuff();<br>}<br><br></div><div>is fragile and scary.=A0 Just reorder the b=
ase classes to change behaviour, or, if lucky, fail to compile (when base_t=
ype<2>::doFoo() doesn't exist).=A0 I'd prefer <br>
</div><div><br><div>virtual doFoo()<br>{<br></div><div>=A0=A0 foo_base::doF=
oo();<br></div>=A0=A0 custom_stuff();<br>}<br><br></div><div>where foo_base=
=3D base_type<2> is set up somewhere.<br><br></div><div>I could also=
see a generic:<br>
<br><div>virtual doFoo()<br>{<br></div><div>=A0=A0 for all i base_type<i=
>::doFoo();<br><br></div>=A0=A0 custom_stuff();<br>}<br><br></div><div>g=
iven some syntax.=A0 But I'm not sure how useful that would be.=A0 Typi=
cally multiple inheritance is because *1* of those bases defines the virtua=
l function, not all of them.<br>
</div><div>But I can imagine a general case of iterating over all base clas=
ses, for... something.=A0 Most likely magic compile time meta programming s=
tuff.<br></div><div><br></div><div>Tony<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 />
--089e01228132d9560204f4fa5c1c--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 19 Mar 2014 15:31:18 -0400
Raw View
On 2014-03-19 15:07, Tony V E wrote:
> But I worry that
>
> virtual doFoo()
> {
> base_type<2>::doFoo();
> custom_stuff();
> }
>
> is fragile and scary. Just reorder the base classes to change behaviour,
> or, if lucky, fail to compile (when base_type<2>::doFoo() doesn't exist).
Sure, but this is true for any flavor of 'super'.
> I'd prefer
>
> virtual doFoo()
> {
> foo_base::doFoo();
> custom_stuff();
> }
>
> where foo_base = base_type<2> is set up somewhere.
If you have basetype, you can say 'using foo_base = basetype(2);' in the
class declaration.
(And you could also do '#define super basetype()' :-).)
--
Matthew
--
---
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: Robert Kawulak <robert.kawulak@gmail.com>
Date: Wed, 26 Mar 2014 03:33:58 +0100
Raw View
Rouslan,
Are you planning to submit a formal proposal to the committee? I'd strongly
encourage you to do so because the feature seems to be useful, easy to add and
doesn't break backward compatibility.
Best regards,
Robert
--
---
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: rouslankorneychuk@gmail.com
Date: Wed, 26 Mar 2014 13:51:54 -0700 (PDT)
Raw View
------=_Part_400_9669328.1395867114862
Content-Type: text/plain; charset=UTF-8
On Tuesday, March 25, 2014 10:33:58 PM UTC-4, Robert Kawulak wrote:
>
> Rouslan,
>
> Are you planning to submit a formal proposal to the committee? I'd
> strongly
> encourage you to do so because the feature seems to be useful, easy to add
> and
> doesn't break backward compatibility.
>
>
I wasn't until now. I'm going to work something up and post it on github
first.
--
---
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_400_9669328.1395867114862
Content-Type: text/html; charset=UTF-8
<div dir="ltr">On Tuesday, March 25, 2014 10:33:58 PM UTC-4, Robert Kawulak wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Rouslan,
<br>
<br>Are you planning to submit a formal proposal to the committee? I'd strongly
<br>encourage you to do so because the feature seems to be useful, easy to add and
<br>doesn't break backward compatibility.
<br>
<br></blockquote><div><br> I wasn't until now. I'm going to work something up and post it on github first.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_400_9669328.1395867114862--
.
Author: rouslankorneychuk@gmail.com
Date: Wed, 26 Mar 2014 20:24:44 -0700 (PDT)
Raw View
------=_Part_2438_19998244.1395890684835
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, February 2, 2014 8:45:53 PM UTC-5, Piotr Rak wrote:
>
> Hi,
>
> I am not sure it is obvious to you, but you can do something very close=
=20
> just injecting this name using default template arguments;
>
> W dniu sobota, 28 grudnia 2013 08:50:37 UTC+1 u=C5=BCytkownik=20
> rouslank...@gmail.com napisa=C5=82:
>>
>> I have a simple proposal that I think can be explained with an example.=
=20
>> How about something like this?:
>>
>>
> Your example:
> =20
>
>> class A : public *B =3D C* {
>> A() : B(3) {}
>>
>> void do_something() {
>> /* ... */
>> B::do_something();
>> }
>> };
>>
>>
> becomes:
>
> template <typename B =3D C> class A : public *B* {
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
> which would be equivalent to:
>>
>> class A : public C {
>> typedef C B;
>>
>> A() : B(3) {}
>>
>> void do_something() {
>> /* ... */
>> B::do_something();
>> }
>> };
>>
>> This would be useful when dealing with unwieldy template instantiations=
=20
>> as base classes:
>>
>> template<typename T,typename Pasta> class monstrous : public something =
=3D=20
>> ::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>,comparison<=
monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>=20
>> {};
>>
>> Sure, you could use a typedef like my second code sample does, but you=
=20
>> would still have to repeat all the template arguments once, which is not=
=20
>> only redundant, but an opportunity for mistakes (mainly when updating co=
de).
>>
> =20
> And this monster:
>
> template<typename T,typename Pasta, typename something_=3D=20
> ::something<monstrous<T,Pasta>,allocator<monstrous<T,Pasta>>
> ,comparison<monstrous<T,Pasta>,and_so_on<Pasta>,and_so_forth<T,etc<T>>>>=
=20
> class monstrous : public something_ {};
> =20
> (I'd really encourage alias for such cases anyway - be it even template=
=20
> of template to break recursion)
>
> It has clear down side of of adding yet another template paramater, but=
=20
> for me in most cases was "Good Enough TM".
> Also not perfect if you need out-of-line method definitions (gnu/c++11=20
> extern template + explicit template instantiations might help bit then, b=
ut=20
> it is workaround and another inconvinience).
>
> I used it for CRTP, where ability to specify base class for some edge=20
> case, turned out to be useful.
>
>
I don't understand how you got this to work. I was working on the formal=20
proposal and wanted to list all the alternatives, but when I tried this=20
trick in a compiler, it wouldn't compile because "monstrous" (actually I=20
tried a simpler example with different names but I'll refer to the=20
equivalent names here) was not declared by that point. If I add a forward=
=20
declaration then it won't have the default value yet, so "something_" has=
=20
to be added explicitly (i.e. monstrous<T,Pasta,something_>) but it's not=20
declared yet either. I tried GCC 4.7.2 and GCC "4.9.0 20140321=20
(experimental)".
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2438_19998244.1395890684835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 2, 2014 8:45:53 PM UTC-5, Piotr Rak wr=
ote:<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">Hi,<div><=
br></div><div>I am not sure it is obvious to you, but you can do something =
very close just injecting this name using default template arguments;<br><b=
r>W dniu sobota, 28 grudnia 2013 08:50:37 UTC+1 u=C5=BCytkownik <a>rouslank=
....@gmail.com</a> napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">I have a simple proposal that I think can be explained with an=
example. How about something like this?:<br><br></div></blockquote><div><s=
pan style=3D"font-size:13px"><br></span></div><div><span style=3D"font-size=
:13px">Your example:</span></div><div> </div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><span style=3D"font-family:courier new,mono=
space">class A : public <u>B =3D C</u> {<br> A() : B(3) {=
}<br><br> void do_something() {<br> &nbs=
p; /* ... */<br>  =
; B::do_something();<br> }<br>};</span><br><br></div></bl=
ockquote><div><br></div><div>becomes:</div><div><br></div><div><span style=
=3D"font-family:'courier new',monospace">template <typename B =3D C> =
class A : public </span><u style=3D"font-family:'courier new',monospac=
e">B</u><span style=3D"font-family:'courier new',monospace"> {</span><=
br style=3D"font-family:'courier new',monospace"><span style=3D"font-family=
:'courier new',monospace"> A() : B(3) {}</span><br style=
=3D"font-family:'courier new',monospace"><br style=3D"font-family:'courier =
new',monospace"><span style=3D"font-family:'courier new',monospace"> &=
nbsp; void do_something() {</span><br style=3D"font-family:'courier n=
ew',monospace"><span style=3D"font-family:'courier new',monospace"> &n=
bsp; /* ... */</span><br style=3D"font-family=
:'courier new',monospace"><span style=3D"font-family:'courier new',monospac=
e"> B::do_something();</span><br =
style=3D"font-family:'courier new',monospace"><span style=3D"font-family:'c=
ourier new',monospace"> }</span><br style=3D"font-family:=
'courier new',monospace"><span style=3D"font-family:'courier new',monospace=
">};</span><br></div><div><span style=3D"font-family:'courier new',monospac=
e"><br></span></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">which would be equivalent to:<br><br><span style=3D"font-family:courier n=
ew,monospace">class A : public C {<br> typedef C B;<br><b=
r> A() : B(3) {}<br><br> void do_someth=
ing() {<br> /* ... */<br> &n=
bsp; B::do_something();<br> =
}<br>};</span><br><br>This would be useful when dealing with unwieldy temp=
late instantiations as base classes:<br><br><span style=3D"font-family:cour=
ier new,monospace">template<typename T,typename Pasta> class monstrou=
s : public something =3D ::something<monstrous<T,Pasta><wbr>,alloc=
ator<monstrous<T,Pasta>><wbr>,comparison<monstrous<T,Past=
a><wbr>,and_so_on<Pasta>,and_so_<wbr>forth<T,etc<T>>&g=
t; {};</span><br><br>Sure, you could use a typedef like my second code samp=
le does, but you would still have to repeat all the template arguments once=
, which is not only redundant, but an opportunity for mistakes (mainly when=
updating code).</div></blockquote><div> </div><div>And this monster:<=
/div><div><br></div><div><span style=3D"font-family:'courier new',monospace=
">template<typename T,typename Pasta, typename something_=3D </span=
><span style=3D"font-size:13px;font-family:'courier new',monospace">::somet=
hing<<wbr>monstrous<T,Pasta></span><span style=3D"font-size:13px;f=
ont-family:'courier new',monospace">,allocator<<wbr>monstrous<T,Pasta=
>></span><span style=3D"font-size:13px;font-family:'courier new',mono=
space">,<wbr>comparison<monstrous<T,Pasta></span><span style=3D"fo=
nt-size:13px;font-family:'courier new',monospace">,<wbr>and_so_on<Pasta&=
gt;,and_so_</span><span style=3D"font-size:13px;font-family:'courier new',m=
onospace">forth<<wbr>T,etc<T>>></span><span style=3D"font-si=
ze:13px;font-family:'courier new',monospace">> class monstrous : public =
something_</span><span style=3D"font-size:13px;font-family:'courier new',mo=
nospace"> {};</span></div><div> </div></div><div> (I'd reall=
y encourage alias for such cases anyway - be it <span style=3D"font-si=
ze:13px">even</span><span style=3D"font-size:13px"> </span><span style=
=3D"font-size:13px"> template of template to break recursion)</span></=
div><div><br></div><div>It has clear down side of of adding yet another tem=
plate paramater, but for me in most cases was "Good Enough TM".</div><div>A=
lso not perfect if you need out-of-line method definitions (gnu/c++11 exter=
n template + explicit template instantiations might help bit then, but it i=
s workaround and another inconvinience).</div><div><br></div><div>I used it=
for <span style=3D"font-size:13px">CRTP, where ability to specify bas=
e class for some edge case, turned out to be useful.</span></div><div><br><=
/div></div></blockquote><div><br>I don't understand how you got this to wor=
k. I was working on the formal proposal and wanted to list all the alternat=
ives, but when I tried this trick in a compiler, it wouldn't compile becaus=
e "monstrous" (actually I tried a simpler example with different names but =
I'll refer to the equivalent names here) was not declared by that point. If=
I add a forward declaration then it won't have the default value yet, so "=
something_" has to be added explicitly (i.e. monstrous<T,Pasta,something=
_>) but it's not declared yet either. I tried GCC 4.7.2 and GCC "4.9.0 2=
0140321 (experimental)".<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_2438_19998244.1395890684835--
.
Author: rouslankorneychuk@gmail.com
Date: Thu, 27 Mar 2014 19:44:32 -0700 (PDT)
Raw View
------=_Part_216_2383884.1395974672687
Content-Type: text/plain; charset=UTF-8
Okay, I have a first draft at http://rouslan.github.io/base-class-aliases
any problems or suggestions?
--
---
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_216_2383884.1395974672687
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Okay, I have a first draft at <a href="http://rouslan.github.io/base-class-aliases">http://rouslan.github.io/base-class-aliases</a><br><br>any problems or suggestions?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_216_2383884.1395974672687--
.
Author: Robert Kawulak <robert.kawulak@gmail.com>
Date: Fri, 28 Mar 2014 14:07:21 +0100
Raw View
> Okay, I have a first draft at http://rouslan.github.io/base-class-aliases
One thing I'm missing after a brief look is the discussion on accessibility=
of the alias itself. There are at least 4 obvious options:
1. always public
2. always protected
3. always private
4. same as the related base class accessibility
Options 1 and 2 doesn't seem reasonable and IMO 4 is the most useful and le=
ast surprising.
"Variable types" section title is misleading (reads as if it's about variab=
les) - maybe it could be renamed to "Unknown base class names" and extended=
with a metafunction result base class example. In "Multiple inheritAnce wi=
th the same base class name" (that could become "Ambiguous base class names=
", also note the typo) the point is that the injected type name might be am=
biguous, but 'type' is not the injected name in this case - the example sho=
uld rather be:
class A : public B<X>, public B<Y> {
Best regards,
Robert
--=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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 28 Mar 2014 15:16:15 +0200
Raw View
On 28 March 2014 15:07, Robert Kawulak <robert.kawulak@gmail.com> wrote:
>> Okay, I have a first draft at http://rouslan.github.io/base-class-aliase=
s
>
> One thing I'm missing after a brief look is the discussion on accessibili=
ty of the alias itself. There are at least 4 obvious options:
> 1. always public
> 2. always protected
> 3. always private
> 4. same as the related base class accessibility
> Options 1 and 2 doesn't seem reasonable and IMO 4 is the most useful and =
least surprising.
It seems clear to me that 4 is what we want.
>
> "Variable types" section title is misleading (reads as if it's about vari=
ables) - maybe it could be renamed to "Unknown base class names" and extend=
ed with a metafunction result base class example. In "Multiple inheritAnce =
with the same base class name" (that could become "Ambiguous base class nam=
es", also note the typo) the point is that the injected type name might be =
ambiguous, but 'type' is not the injected name in this case - the example s=
hould rather be:
>
> class A : public B<X>, public B<Y> {
The example in the multiple inheritance section doesn't look right to
me. It says
"class A : public B<Hit,Me>::type, public C<I,Dare,Ya>::type {
/* ... */
};
Here the name type is ambiguous."
I don't see how the "name type" is in any way ambiguous, and I don't
see how this
proposal solves a problem here.
Has this proposal been implemented?
--=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: Tony V E <tvaneerd@gmail.com>
Date: Fri, 28 Mar 2014 11:41:00 -0400
Raw View
--001a113459e651d83a04f5ac875e
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Mar 27, 2014 at 10:44 PM, <rouslankorneychuk@gmail.com> wrote:
> Okay, I have a first draft at http://rouslan.github.io/base-class-aliases
>
> any problems or suggestions?
>
> --
>
>
>
"A very long instantiation such as this particularily undesirable to have
to repeat. The injected name something cannot be used because the
definition of its class is not avaible before monstrous is defined."
- The first sentence no verb.
- spelling: particularily -> particularly, avaible -> available
typedef typename monstrous::something;
- missing the new name?
--
---
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/.
--001a113459e651d83a04f5ac875e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Mar 27, 2014 at 10:44 PM, <span dir=3D"ltr"><<a href=3D=
"mailto:rouslankorneychuk@gmail.com" target=3D"_blank">rouslankorneychuk@gm=
ail.com</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">Okay, I =
have a first draft at <a href=3D"http://rouslan.github.io/base-class-aliase=
s" target=3D"_blank">http://rouslan.github.io/base-class-aliases</a><br>
<br>any problems or suggestions?<br></div><div class=3D""><div class=3D"h5"=
>
<p></p>
-- <br>
<br><br></div></div></blockquote><div><br>
<p>"A very long instantiation such as this particularily undesirable t=
o have to
repeat. The injected name <code>something</code> cannot be used because th=
e
definition of its class is not avaible before <code>monstrous</code> is
defined."</p><p>- The first sentence no verb.<br></p><p>- spelling: pa=
rticularily -> particularly, avaible -> available</p><p><br></p><pre>=
typedef typename monstrous::something;</pre><p>- missing the new name?<=
br>
</p><p><br></p><p><br></p><p><br></p><p><br></p><p><br></p><p><br></p>=A0</=
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 />
--001a113459e651d83a04f5ac875e--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 28 Mar 2014 12:17:41 -0400
Raw View
--001a11c134c2868bcb04f5ad0ae7
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 28, 2014 at 9:16 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> The example in the multiple inheritance section doesn't look right to
> me. It says
>
> "class A : public B<Hit,Me>::type, public C<I,Dare,Ya>::type {
> /* ... */
> };
>
> Here the name type is ambiguous."
>
> I don't see how the "name type" is in any way ambiguous, and I don't
> see how this
> proposal solves a problem here.
>
I believe the example is incorrect, but a similar example would be:
class A : public B<int>, public B<double> { ... };
Where the injected name is in both bases 'B' so, the use of 'B' is
ambiguous. I believe the suggested change would allow you to do:
class A : public Bi = B<int>, public Bd = B<double> { ... };
Where the first base type is now unambiguously accessible as 'Bi' and the
second as 'Bd'.
David
--
---
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/.
--001a11c134c2868bcb04f5ad0ae7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 28, 2014 at 9:16 AM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@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"><div class=3D"">The example in the multiple =
inheritance section doesn't look right to<br></div>
me. It says<br>
<br>
"class A : public B<Hit,Me>::type, public C<I,Dare,Ya>::ty=
pe {<br>
=A0 =A0 /* ... */<br>
};<br>
<br>
Here the name type is ambiguous."<br>
<br>
I don't see how the "name type" is in any way ambiguous, and =
I don't<br>
see how this<br>
proposal solves a problem here.<br></blockquote><div><br></div><div>I belie=
ve the example is incorrect, but a similar example would be:<br><br>class A=
: public B<int>, public B<double> { ... };<br><br>Where the in=
jected name is in both bases 'B' so, the use of 'B' is ambi=
guous. I believe the suggested change would allow you to do:<br>
<br>class A : public Bi =3D B<int>, public Bd =3D B<double> { .=
... };=A0<br><br>Where the first base type is now unambiguously accessible a=
s 'Bi' and the second as 'Bd'.<br><br>=A0 =A0David</div></d=
iv></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 />
--001a11c134c2868bcb04f5ad0ae7--
.
Author: rouslankorneychuk@gmail.com
Date: Fri, 28 Mar 2014 15:14:20 -0700 (PDT)
Raw View
------=_Part_458_1403809.1396044860781
Content-Type: text/plain; charset=UTF-8
Okay, how about now?
http://rouslan.github.io/base-class-aliases
I made the suggested changes (and fixed one other little mistake that
wasn't mentioned) and ran it through spell check this time.
With the "public B<Hit,Me>::type, public C<I,Dare,Ya>::type" part, I
figured a name clash would more likely come from B and C defining a nested
classes named "type" similar to what the type traits classes do, but
evidently this wasn't clear so I changed it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_458_1403809.1396044860781
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Okay, how about now?<br>http://rouslan.github.io/base-clas=
s-aliases<br><br>I made the suggested changes (and fixed one other little m=
istake that wasn't mentioned) and ran it through spell check this time.<br>=
<br>With the "public B<Hit,Me>::type, public C<I,Dare,Ya>::type=
" part, I figured a name clash would more likely come from B and C defining=
a nested classes named "type" similar to what the type traits classes do, =
but evidently this wasn't clear so I changed it.<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 />
------=_Part_458_1403809.1396044860781--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 28 Mar 2014 16:11:27 -0700
Raw View
--001a113376fe4328e504f5b2d2be
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 28, 2014 at 3:14 PM, <rouslankorneychuk@gmail.com> wrote:
> Okay, how about now?
> http://rouslan.github.io/base-class-aliases
>
> I made the suggested changes (and fixed one other little mistake that
> wasn't mentioned) and ran it through spell check this time.
>
> With the "public B<Hit,Me>::type, public C<I,Dare,Ya>::type" part, I
> figured a name clash would more likely come from B and C defining a nested
> classes named "type" similar to what the type traits classes do, but
> evidently this wasn't clear so I changed it.
>
The proposal isn't very clear about what kind of entity is introduced by a
base-alias. Does it declare a class member? If so, what is the access of
that member?
Based on section II, it looks like the intent is that it declares a member,
and that member is private for a class definition and public for a struct
definition. You should explicitly state this somewhere.
(I also have some nits about the wording changes, but I don't think it
makes sense to talk about those until/unless this gets to CWG.)
--
---
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/.
--001a113376fe4328e504f5b2d2be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 28, 2014 at 3:14 PM, <span dir=3D"ltr"><<a href=3D"mailto:rousl=
ankorneychuk@gmail.com" target=3D"_blank">rouslankorneychuk@gmail.com</a>&g=
t;</span> 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">Okay, how about now?<br><a =
href=3D"http://rouslan.github.io/base-class-aliases" target=3D"_blank">http=
://rouslan.github.io/base-class-aliases</a><br>
<br>I made the suggested changes (and fixed one other little mistake that w=
asn't mentioned) and ran it through spell check this time.<br><br>With =
the "public B<Hit,Me>::type, public C<I,Dare,Ya>::type&quo=
t; part, I figured a name clash would more likely come from B and C definin=
g a nested classes named "type" similar to what the type traits c=
lasses do, but evidently this wasn't clear so I changed it.</div>
</blockquote><div><br></div><div>The proposal isn't very clear about wh=
at kind of entity is introduced by a base-alias. Does it declare a class me=
mber? If so, what is the access of that member?</div><div><br></div><div>
Based on section II, it looks like the intent is that it declares a member,=
and that member is private for a class definition and public for a struct =
definition. You should explicitly state this somewhere.</div><div><br></div=
>
<div>(I also have some nits about the wording changes, but I don't thin=
k it makes sense to talk about those until/unless this gets to CWG.)</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 />
--001a113376fe4328e504f5b2d2be--
.
Author: rouslankorneychuk@gmail.com
Date: Fri, 28 Mar 2014 16:18:32 -0700 (PDT)
Raw View
------=_Part_963_2197778.1396048712937
Content-Type: text/plain; charset=UTF-8
On Friday, March 28, 2014 9:07:21 AM UTC-4, Robert Kawulak wrote:
>
> > Okay, I have a first draft at
> http://rouslan.github.io/base-class-aliases
>
> One thing I'm missing after a brief look is the discussion on
> accessibility of the alias itself. There are at least 4 obvious options:
> 1. always public
> 2. always protected
> 3. always private
> 4. same as the related base class accessibility
> Options 1 and 2 doesn't seem reasonable and IMO 4 is the most useful and
> least surprising.
>
>
D'oh, I just realised what you mean (I was thinking of something slightly
different before). I updated the paper with #4 as the rule. I also added
what the solutions to the example problems can look like.
--
---
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_963_2197778.1396048712937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 28, 2014 9:07:21 AM UTC-4, Robert Kawulak=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> Okay, I have a fir=
st draft at <a href=3D"http://rouslan.github.io/base-class-aliases" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Frouslan.github.io%2Fbase-class-aliases\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNFK2r7PPiLXnS4OsC7kuifVT2B8Vw';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Frouslan.github.io%2Fbase-class-a=
liases\46sa\75D\46sntz\0751\46usg\75AFQjCNFK2r7PPiLXnS4OsC7kuifVT2B8Vw';ret=
urn true;">http://rouslan.github.io/base-<wbr>class-aliases</a>
<br>
<br>One thing I'm missing after a brief look is the discussion on accessibi=
lity of the alias itself. There are at least 4 obvious options:
<br>1. always public
<br>2. always protected
<br>3. always private
<br>4. same as the related base class accessibility
<br>Options 1 and 2 doesn't seem reasonable and IMO 4 is the most useful an=
d least surprising.
<br>
<br></blockquote><div><br>D'oh, I just realised what you mean (I was thinki=
ng of something slightly different before). I updated the paper with #4 as =
the rule. I also added what the solutions to the example problems can look =
like.<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_963_2197778.1396048712937--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Fri, 28 Mar 2014 16:44:54 -0700 (PDT)
Raw View
Would it be worth considering alternative syntaxes? I feel the equals sign in a base-specifier might be better used for something else, eg base initializers (by analogy to inline member initializers).
For example, using the syntax class-or-decltype identifier[opt]:
template<typename T,typename Pasta> class monstrous :
public something<
monstrous<T,Pasta>,
allocator<monstrous<T,Pasta>>,
comparison<monstrous<T,Pasta>,
and_so_on<Pasta>,
and_so_forth<T,etc<T>>> base_t {
/* ... */
};
This style would be familiar from typedef and from function declarations, and would leave the equals sign available for future use.
--
---
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: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sat, 29 Mar 2014 01:09:38 +0100
Raw View
> D'oh, I just realised what you mean (I was thinking of something
> slightly different before). I updated the paper with #4 as the rule.
Actually, I think it was almost right before, and more than now - now it's =
really confusing because it suggests that the derived class' definition inj=
ects the alias into the base class definition. What I meant was rather to s=
tate explicitly what are the rules for the alias accessibility (possibly as=
a subsection with the alternatives listed, but one sentence describing opt=
ion 4 would also be fine). The example should look as before, but the typed=
ef declaration should be public, not private, to match the rule.
The wording is a bit fuzzy at places and the paper could be structured a bi=
t better, but it's nice to see it getting shape. Keep it going! :)
Best regards,
Robert
--=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: rouslankorneychuk@gmail.com
Date: Fri, 28 Mar 2014 18:12:20 -0700 (PDT)
Raw View
------=_Part_951_18588332.1396055540631
Content-Type: text/plain; charset=UTF-8
On Friday, March 28, 2014 8:09:38 PM UTC-4, Robert Kawulak wrote:
>
> > D'oh, I just realised what you mean (I was thinking of something
> > slightly different before). I updated the paper with #4 as the rule.
>
> Actually, I think it was almost right before, and more than now - now it's
> really confusing because it suggests that the derived class' definition
> injects the alias into the base class definition. What I meant was rather
> to state explicitly what are the rules for the alias accessibility
> (possibly as a subsection with the alternatives listed, but one sentence
> describing option 4 would also be fine). The example should look as before,
> but the typedef declaration should be public, not private, to match the
> rule.
>
> The wording is a bit fuzzy at places and the paper could be structured a
> bit better, but it's nice to see it getting shape. Keep it going! :)
>
>
I see your point about it being confusing, so I changed it again and made
the base protected to further emphasize the point. Though you should note
that the introduction is not a formal specification, so it doesn't have to
describe every nuance. That falls under Technical Specifications.
Edward Catmur wrote:
> Would it be worth considering alternative syntaxes? I feel the equals
sign in a base-specifier might be better used for something else, eg base
initializers (by analogy to inline member initializers).
Personally, I like the equals sign because it matches the existing alias
syntax. You could still have base initializers by allowing brackets after
the base names (e.g.: "class A : public C = B(4)" or maybe "class A :
public (C = B)(4)" so it doesn't look like a value is being assigned to C),
but I don't really think it's a worthwhile feature (if you need multiple
constructors to initialize a base class with the same arguments, you can
have the constructors call another constructor the initializes the base
class, which is something you can do since C++11).
--
---
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_951_18588332.1396055540631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 28, 2014 8:09:38 PM UTC-4, Robert Kawulak=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> D'oh, I just reali=
sed what you mean (I was thinking of something
<br>> slightly different before). I updated the paper with #4 as the rul=
e.
<br>
<br>Actually, I think it was almost right before, and more than now - now i=
t's really confusing because it suggests that the derived class' definition=
injects the alias into the base class definition. What I meant was rather =
to state explicitly what are the rules for the alias accessibility (possibl=
y as a subsection with the alternatives listed, but one sentence describing=
option 4 would also be fine). The example should look as before, but the t=
ypedef declaration should be public, not private, to match the rule.
<br>
<br>The wording is a bit fuzzy at places and the paper could be structured =
a bit better, but it's nice to see it getting shape. Keep it going! :)
<br>
<br></blockquote><div><br>I see your point about it being confusing, so I c=
hanged it again and made the base protected to further emphasize the point.=
Though you should note that the introduction is not a formal specification=
, so it doesn't have to describe every nuance. That falls under Technical S=
pecifications.<br><br><br>Edward Catmur wrote:<br>> Would it be worth co=
nsidering alternative syntaxes? I feel the equals=20
sign in a base-specifier might be better used for something else, eg=20
base initializers (by analogy to inline member initializers).<br><br>Person=
ally, I like the equals sign because it matches the existing alias syntax. =
You could still have base initializers by allowing brackets after the base =
names (e.g.: "class A : public C =3D B(4)" or maybe "class A : public (C =
=3D B)(4)" so it doesn't look like a value is being assigned to C), but I d=
on't really think it's a worthwhile feature (if you need multiple construct=
ors to initialize a base class with the same arguments, you can have the co=
nstructors call another constructor the initializes the base class, which i=
s something you can do since C++11).<br></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 />
------=_Part_951_18588332.1396055540631--
.
Author: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sat, 29 Mar 2014 02:41:24 +0100
Raw View
> I see your point about it being confusing, so I changed it again
> and made the base protected to further emphasize the point.
Yes, now it looks really clear and consistent.
> Though you should note that the introduction is not a formal
> specification, so it doesn't have to describe every nuance.
> That falls under Technical Specifications.
Sure, that wasn't exactly my point. One thing was that the example in the i=
ntroduction was contradicting the alias accessibility rule, another one was=
to actually explicitly specify the accessibility rule somewhere (not neces=
sarily in the introduction, but it's also fine to mention it there).
> Personally, I like the equals sign because it matches the
> existing alias syntax. You could still have base initializers
> by allowing brackets after the base names
I agree on this. 'using =3D' is the modern typedef and '{}' is the modern i=
nitialiser, so a hypothetical base initialisation syntax would be more like=
ly to use '{}' rather than '=3D'.
Best regards,
Robert
--=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: Fri, 28 Mar 2014 18:54:08 -0700
Raw View
--089e013a0f8a0bd0f004f5b5185c
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 28, 2014 at 6:41 PM, Robert Kawulak <robert.kawulak@gmail.com>wrote:
> > I see your point about it being confusing, so I changed it again
> > and made the base protected to further emphasize the point.
>
> Yes, now it looks really clear and consistent.
>
> > Though you should note that the introduction is not a formal
> > specification, so it doesn't have to describe every nuance.
> > That falls under Technical Specifications.
>
> Sure, that wasn't exactly my point. One thing was that the example in the
> introduction was contradicting the alias accessibility rule, another one
> was to actually explicitly specify the accessibility rule somewhere (not
> necessarily in the introduction, but it's also fine to mention it there).
>
> > Personally, I like the equals sign because it matches the
> > existing alias syntax. You could still have base initializers
> > by allowing brackets after the base names
>
> I agree on this. 'using =' is the modern typedef and '{}' is the modern
> initialiser, so a hypothetical base initialisation syntax would be more
> likely to use '{}' rather than '='.
oO Are you suggesting:
struct A : B { initializer } { body };
? That seems like a *really* bad idea to me.
--
---
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/.
--089e013a0f8a0bd0f004f5b5185c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 28, 2014 at 6:41 PM, Robert Kawulak <span dir=3D"ltr"><<a href=
=3D"mailto:robert.kawulak@gmail.com" target=3D"_blank">robert.kawulak@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"><div class=3D"">> I see your point about =
it being confusing, so I changed it again<br>
> and made the base protected to further emphasize the point.<br>
<br>
</div>Yes, now it looks really clear and consistent.<br>
<div class=3D""><br>
> Though you should note that the introduction is not a formal<br>
> specification, so it doesn't have to describe every nuance.<br>
> That falls under Technical Specifications.<br>
<br>
</div>Sure, that wasn't exactly my point. One thing was that the exampl=
e in the introduction was contradicting the alias accessibility rule, anoth=
er one was to actually explicitly specify the accessibility rule somewhere =
(not necessarily in the introduction, but it's also fine to mention it =
there).<br>
<div class=3D""><br>
> Personally, I like the equals sign because it matches the<br>
> existing alias syntax. You could still have base initializers<br>
> by allowing brackets after the base names<br>
<br>
</div>I agree on this. 'using =3D' is the modern typedef and '{=
}' is the modern initialiser, so a hypothetical base initialisation syn=
tax would be more likely to use '{}' rather than '=3D'.</bl=
ockquote>
<div><br></div><div>oO Are you suggesting:</div><div><br></div><div>struct =
A : B { initializer } { body };</div><div><br></div><div>? That seems like =
a *really* bad idea to me.</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 />
--089e013a0f8a0bd0f004f5b5185c--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 28 Mar 2014 19:02:24 -0700
Raw View
--001a11c2c20aa1cd1404f5b53575
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 28, 2014 at 6:12 PM, <rouslankorneychuk@gmail.com> wrote:
> On Friday, March 28, 2014 8:09:38 PM UTC-4, Robert Kawulak wrote:
>>
>> > D'oh, I just realised what you mean (I was thinking of something
>> > slightly different before). I updated the paper with #4 as the rule.
>>
>> Actually, I think it was almost right before, and more than now - now
>> it's really confusing because it suggests that the derived class'
>> definition injects the alias into the base class definition. What I meant
>> was rather to state explicitly what are the rules for the alias
>> accessibility (possibly as a subsection with the alternatives listed, but
>> one sentence describing option 4 would also be fine). The example should
>> look as before, but the typedef declaration should be public, not private,
>> to match the rule.
>>
>> The wording is a bit fuzzy at places and the paper could be structured a
>> bit better, but it's nice to see it getting shape. Keep it going! :)
>>
>>
> I see your point about it being confusing, so I changed it again and made
> the base protected to further emphasize the point. Though you should note
> that the introduction is not a formal specification, so it doesn't have to
> describe every nuance. That falls under Technical Specifications.
>
I don't think your update to the Technical Specifications has helped. You
now seem to be saying that you inject a member into the base class? That
doesn't make much sense from a standardese perspective.
I'm also not really clear on why you'd want the name to have the same
access as the base specifier. In most of the use cases I can think of for
this feature, the alias is an implementation detail of the class, added for
convenience, even if the base itself is public. Another option would be to
not add a member for the name at all -- instead, just say that within the
scope of the class, the name is a typedef-name referring to the type
specified in the base-type-specifier (so the name can only be found by
unqualified lookup within the class and its members, and the user would
need to add a typedef if they wanted to expose the type in the class's
interface).
--
---
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/.
--001a11c2c20aa1cd1404f5b53575
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 28, 2014 at 6:12 PM, <span dir=3D"ltr"><<a href=3D"mailto:rousl=
ankorneychuk@gmail.com" target=3D"_blank">rouslankorneychuk@gmail.com</a>&g=
t;</span> 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"><div class=3D"">On Friday, =
March 28, 2014 8:09:38 PM UTC-4, Robert Kawulak wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">
> D'oh, I just realised what you mean (I was thinking of something
<br>> slightly different before). I updated the paper with #4 as the rul=
e.
<br>
<br>Actually, I think it was almost right before, and more than now - now i=
t's really confusing because it suggests that the derived class' de=
finition injects the alias into the base class definition. What I meant was=
rather to state explicitly what are the rules for the alias accessibility =
(possibly as a subsection with the alternatives listed, but one sentence de=
scribing option 4 would also be fine). The example should look as before, b=
ut the typedef declaration should be public, not private, to match the rule=
..
<br>
<br>The wording is a bit fuzzy at places and the paper could be structured =
a bit better, but it's nice to see it getting shape. Keep it going! :)
<br>
<br></blockquote></div><div><br>I see your point about it being confusing, =
so I changed it again and made the base protected to further emphasize the =
point. Though you should note that the introduction is not a formal specifi=
cation, so it doesn't have to describe every nuance. That falls under T=
echnical Specifications.</div>
</div></blockquote><div><br></div><div>I don't think your update to the=
Technical Specifications has helped. You now seem to be saying that you in=
ject a member into the base class? That doesn't make much sense from a =
standardese perspective.</div>
<div><br></div><div>I'm also not really clear on why you'd want the=
name to have the same access as the base specifier. In most of the use cas=
es I can think of for this feature, the alias is an implementation detail o=
f the class, added for convenience, even if the base itself is public. Anot=
her option would be to not add a member for the name at all -- instead, jus=
t say that within the scope of the class, the name is a typedef-name referr=
ing to the type specified in the base-type-specifier (so the name can only =
be found by unqualified lookup within the class and its members, and the us=
er would need to add a typedef if they wanted to expose the type in the cla=
ss's interface).</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 />
--001a11c2c20aa1cd1404f5b53575--
.
Author: rouslankorneychuk@gmail.com
Date: Fri, 28 Mar 2014 20:09:26 -0700 (PDT)
Raw View
------=_Part_952_29476404.1396062567104
Content-Type: text/plain; charset=UTF-8
On Friday, March 28, 2014 10:02:24 PM UTC-4, Richard Smith wrote:
> I don't think your update to the Technical Specifications has helped. You
> now seem to be saying that you inject a member into the base class? That
> doesn't make much sense from a standardese perspective.
>
What part gives you that impression? I mention the rule in "The semantics
are the same as if the name was defined with a typedef in the base class, *except
it is only introduced into the scope of the derived class* and is only
available after the base-alias is declared". Is it not clear?
On Friday, March 28, 2014 10:02:24 PM UTC-4, Richard Smith wrote:
> I'm also not really clear on why you'd want the name to have the same
> access as the base specifier. In most of the use cases I can think of for
> this feature, the alias is an implementation detail of the class, added for
> convenience, even if the base itself is public. Another option would be to
> not add a member for the name at all -- instead, just say that within the
> scope of the class, the name is a typedef-name referring to the type
> specified in the base-type-specifier (so the name can only be found by
> unqualified lookup within the class and its members, and the user would
> need to add a typedef if they wanted to expose the type in the class's
> interface).
>
The name is supposed to be nothing more than a substitute for the base
specifier, so I see no reason for it to have different access. An alias is
not an implementation detail, it's mainly a way to save typing. As for
making it only available inside the same class, that would effectively make
it always private, but why make it work differently from the original name
of the base class. If the base class name can be accessed in a derived
class or outside the class, why not its alias? In all three examples I give
in the Motivation section, the point was to give a name to a base class
that could not be referred to by its original name. Additionally, being
able to give a particular base class a second publicly accessible name
could be useful if a template or macro needs to operate on the base class
of the derived class' choosing.
--
---
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_952_29476404.1396062567104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 28, 2014 10:02:24 PM UTC-4, Richard Smith=
wrote:<br><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"><d=
iv><div class=3D"gmail_quote"><div>I don't think your update to the Technic=
al Specifications has helped. You now seem to be saying that you inject a m=
ember into the base class? That doesn't make much sense from a standardese =
perspective.</div>
</div></div></div></blockquote><div><br>What part gives you that impression=
? I mention the rule in "The semantics are the=20
same as if the name was defined with a <span class=3D"literal">typedef</spa=
n> in
the base class, <b>except it is only introduced into the scope of the deriv=
ed class</b>
and is only available after the <span class=3D"syntax">base-alias</span> is
declared". Is it not clear?<br><br></div><div>On Friday, March 28, 2014 10:=
02:24 PM UTC-4, Richard Smith wrote: <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></di=
v><div>I'm also not really clear on why you'd want the name to have the sam=
e access as the base specifier. In most of the use cases I can think of for=
this feature, the alias is an implementation detail of the class, added fo=
r convenience, even if the base itself is public. Another option would be t=
o not add a member for the name at all -- instead, just say that within the=
scope of the class, the name is a typedef-name referring to the type speci=
fied in the base-type-specifier (so the name can only be found by unqualifi=
ed lookup within the class and its members, and the user would need to add =
a typedef if they wanted to expose the type in the class's interface).</div=
></div></div></div></blockquote><div> <br>The name is supposed to be n=
othing more than a substitute for the base specifier, so I see no reason fo=
r it to have different access. An alias is not an implementation detail, it=
's mainly a way to save typing. As for making it only available inside the =
same class, that would effectively make it always private, but why make it =
work differently from the original name of the base class. If the base clas=
s name can be accessed in a derived class or outside the class, why not its=
alias? In all three examples I give in the Motivation section, the point w=
as to give a name to a base class that could not be referred to by its orig=
inal name. Additionally, being able to give a particular base class a secon=
d publicly accessible name could be useful if a template or macro needs to =
operate on the base class of the derived class' choosing.<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_952_29476404.1396062567104--
.
Author: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Date: Fri, 28 Mar 2014 22:14:08 -0700 (PDT)
Raw View
------=_Part_1599_27495889.1396070048299
Content-Type: text/plain; charset=UTF-8
On Friday, March 28, 2014 8:09:26 PM UTC-7, rouslank...@gmail.com wrote
>
>
> The name is supposed to be nothing more than a substitute for the base
> specifier, so I see no reason for it to have different access. An alias is
> not an implementation detail, it's mainly a way to save typing. As for
> making it only available inside the same class, that would effectively make
> it always private, but why make it work differently from the original name
> of the base class. If the base class name can be accessed in a derived
> class or outside the class, why not its alias? In all three examples I give
> in the Motivation section, the point was to give a name to a base class
> that could not be referred to by its original name. Additionally, being
> able to give a particular base class a second publicly accessible name
> could be useful if a template or macro needs to operate on the base class
> of the derived class' choosing.
>
I strongly agree with Richard Smith's suggestion that the alias name not
become a member, and instead be accessible only within the scope of the
class. This would be the same behavior as for template parameter names,
which is what I think most users would expect. (The one difference is that
in out-of-class member definitions the base class alias would presumably
still be accessible even though there is no lexical presence as there is
with template parameters.)
If the base class alias names were forced to be injected as members, users
might feel the need to obfuscate the alias names to avoid
conflicts/cluttering the interface with implementation details, which would
partially defeat the intended convenience of using an alias.
--
---
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_1599_27495889.1396070048299
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 28, 2014 8:09:26 PM UTC-7, rouslank...@gm=
ail.com 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">=
<div><br>The name is supposed to be nothing more than a substitute for the =
base specifier, so I see no reason for it to have different access. An alia=
s is not an implementation detail, it's mainly a way to save typing. As for=
making it only available inside the same class, that would effectively mak=
e it always private, but why make it work differently from the original nam=
e of the base class. If the base class name can be accessed in a derived cl=
ass or outside the class, why not its alias? In all three examples I give i=
n the Motivation section, the point was to give a name to a base class that=
could not be referred to by its original name. Additionally, being able to=
give a particular base class a second publicly accessible name could be us=
eful if a template or macro needs to operate on the base class of the deriv=
ed class' choosing.<br></div></div></blockquote><div><br>I strongly agree w=
ith Richard Smith's suggestion that the alias name not become a member, and=
instead be accessible only within the scope of the class. This would=
be the same behavior as for template parameter names, which is what I thin=
k most users would expect. (The one difference is that in out-of-clas=
s member definitions the base class alias would presumably still be accessi=
ble even though there is no lexical presence as there is with template para=
meters.)<br><br>If the base class alias names were forced to be injected as=
members, users might feel the need to obfuscate the alias names to avoid c=
onflicts/cluttering the interface with implementation details, which would =
partially defeat the intended convenience of using an alias.<br></div></di=
v>
<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_1599_27495889.1396070048299--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 13:54:44 +0800
Raw View
On 2014-03-29, at 1:14 PM, Jeremy Maitin-Shepard <jeremy@jeremyms.com> wrot=
e:
> I strongly agree with Richard Smith's suggestion that the alias name not =
become a member, and instead be accessible only within the scope of the cla=
ss. This would be the same behavior as for template parameter names, which=
is what I think most users would expect. (The one difference is that in o=
ut-of-class member definitions the base class alias would presumably still =
be accessible even though there is no lexical presence as there is with tem=
plate parameters.)
Making the alias into an accessible member is definitely a use-case, though=
.. It might be worthwhile to consider less restrictive name hiding than with=
template parameters, whose names are never hidden by anything ever.
I still don't see how the sugar is really motivated. Code with enough templ=
ates to be a use-case deserves the kind of organization that already solves=
this problem and others like it. Introducing a new kind of name into the l=
anguage only increases complexity for everything. Injected-class-names are =
already pretty much the most exotic kind of name we have.
If we're already at the point where existing complexity causes resistance t=
o extensions to name injection, perhaps the knock-on effect to future exten=
sions in this space should also be a consideration. If we're going to chang=
e this, it should add non-trivial functionality.
--=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: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sat, 29 Mar 2014 07:16:56 +0100
Raw View
> From: David Krauss
> I still don't see how the sugar is really motivated. Code with enough
templates
> to be a use-case deserves the kind of organization that already solves this
> problem and others like it.
I'm not sure I understand - could you specify what organization you have in mind
to solve this problem? Are you saying that it can be overcame by better
structuring the code?
> Introducing a new kind of name into the language only
> increases complexity for everything.
Let me put it that way: if a language forces you to repeat yourself then there's
definitely a room for improvement. IMO the pattern of typedeffing a base class
is prevalent enough and burdensome enough to justify this slight increase of
complexity.
Best regards,
Robert
--
---
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: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sat, 29 Mar 2014 07:20:41 +0100
Raw View
> From: Richard Smith
> oO Are you suggesting:
> struct A : B { initializer } { body };
> ? That seems like a *really* bad idea to me.
I agree that this could cause troubles, I didn't give too much thought into
this. Still, the base initialisation is still only a hypothetical idea that
doesn't necessarily justify selecting somehow worse syntax for a real proposal.
Best regards,
Robert
--
---
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: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 15:16:51 +0800
Raw View
--Apple-Mail=_3CD36CD3-1DCD-4106-9663-CDDBC44AD621
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-29, at 2:16 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
>> From: David Krauss
>> I still don't see how the sugar is really motivated. Code with enough
> templates
>> to be a use-case deserves the kind of organization that already solves this
>> problem and others like it.
>
> I'm not sure I understand - could you specify what organization you have in mind
> to solve this problem? Are you saying that it can be overcame by better
> structuring the code?
You can define a [template] alias before the class definition. If this pollutes the enclosing namespace, then confine it to a detail namespace.
I have no specific organizational idea in mind except knowing when to split off a new line of code with its own identifier.
>> Introducing a new kind of name into the language only
>> increases complexity for everything.
>
> Let me put it that way: if a language forces you to repeat yourself then there's
> definitely a room for improvement. IMO the pattern of typedeffing a base class
> is prevalent enough and burdensome enough to justify this slight increase of
> complexity.
As we can see from this debate, the pattern isn't quite uniform though. Sometimes you want an interface, sometimes a detail.
Referring back to my first message in this thread, the current pattern, which should be idiomatic, is not burdensomely repetitious:
typedef typename monstrous::something B;
(For context, monstrous is the derived and enclosing class, and something is the base class or class template.)
typedef typename introduces a member declaration, because it's declaring a member. A bit noisy in C++ but that's simply how we roll. The declaration should appear with the rest of its associated interface.
monstrous:: "repeats" the name the derived class, but semantically to the reader indicates reflection. So it's still meaningful. Most classes are named often in the course of their definition, and nothing is going to put a dent in that.
something nominates the base, and B declares the alias.
Viewed from the perspective of adding a declarative context to each base-specifier, yes a member declaration is verbose, but it's not more repetitive than any other member declaration.
--
---
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/.
--Apple-Mail=_3CD36CD3-1DCD-4106-9663-CDDBC44AD621
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–29, at 2:16 PM, Robert Kawulak <<a href=3D"mailto:robert.=
kawulak@gmail.com">robert.kawulak@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><blockquote type=
=3D"cite">From: David Krauss<br>I still don't see how the sugar is really m=
otivated. Code with enough<br></blockquote>templates<br><blockquote type=3D=
"cite">to be a use-case deserves the kind of organization that already solv=
es this<br>problem and others like it.<br></blockquote><br>I'm not sure I u=
nderstand - could you specify what organization you have in mind<br>to solv=
e this problem? Are you saying that it can be overcame by better<br>structu=
ring the code? <br></blockquote><div><br></div><div>You can define a [templ=
ate] alias before the class definition. If this pollutes the enclosing name=
space, then confine it to a <font face=3D"Courier">detail</font> namespace.=
</div><div><br></div><div>I have no specific organizational idea in mind ex=
cept knowing when to split off a new line of code with its own identifier.<=
/div><br><blockquote type=3D"cite"><blockquote type=3D"cite">Introducing a =
new kind of name into the language only<br>increases complexity for everyth=
ing.<br></blockquote><br>Let me put it that way: if a language forces you t=
o repeat yourself then there's<br>definitely a room for improvement. IMO th=
e pattern of typedeffing a base class<br>is prevalent enough and burdensome=
enough to justify this slight increase of<br>complexity.<br></blockquote><=
div><br></div><div>As we can see from this debate, the pattern isn’t =
quite uniform though. Sometimes you want an interface, sometimes a detail.<=
/div><div><br></div><div>Referring back to my first message in this thread,=
the current pattern, which should be idiomatic, is not burdensomely repeti=
tious:</div><div><br></div><div><font face=3D"Courier">typedef typename mon=
strous::something B;</font><br></div></div><div><br></div><div>(For context=
, <font face=3D"Courier">monstrous</font> is the derived and enclosing clas=
s, and <font face=3D"Courier">something</font> is the base class or class t=
emplate.)</div><div><br></div><div><span style=3D"font-family: Courier;">ty=
pedef typename</span> introduces a member declaration, because it&rsqu=
o;s declaring a member. A bit noisy in C++ but that’s simply how we r=
oll. The declaration should appear with the rest of its associated interfac=
e.</div><div><br></div><div><font face=3D"Courier">monstrous::</font> &ldqu=
o;repeats” the name the derived class, but semantically to the reader=
indicates reflection. So it's still meaningful. Most classes are named oft=
en in the course of their definition, and nothing is going to put a dent in=
that.</div><div><br></div><div><span style=3D"font-family: Courier;">somet=
hing</span> nominates the base, and <font face=3D"Courier">B</font> de=
clares the alias.</div><div><br></div><div>Viewed from the perspective of a=
dding a declarative context to each <i>base-specifier</i>, yes a member dec=
laration is verbose, but it’s not more repetitive than any other memb=
er declaration.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_3CD36CD3-1DCD-4106-9663-CDDBC44AD621--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 29 Mar 2014 11:52:28 +0200
Raw View
On 29 March 2014 09:16, David Krauss <potswa@gmail.com> wrote:
> You can define a [template] alias before the class definition. If this
> pollutes the enclosing namespace, then confine it to a detail namespace.
That would seem to be the current work-around, and the paper should explain
why that is not acceptable. In this email thread, it was pointed out that
that leads to repetition of template parameters, but I think that should
be spelled out in the proposal with examples.
Here's an alternate syntax for consideration:
template <class A, class B, class C> struct X
{
/* alias goes here */
template<class A, class B, class C> using Base = Y<A, B, C>;
/* public,protected,private*/ bases:
Base /* = initializer, {initializer}*/;
AnotherBase /* = initializer, {initializer}*/;
};
Such a syntax allows NDSMI for bases, and doesn't reinvent what existing
syntaxes mean. The alias is scoped in the class scope, so there's no pollution.
This would of course be a rather more involved change in the sense
that there's nothing
preventing
struct X
{
string datamember = "foo";
bases:
Y{datamember};
};
So you could have data members that are initialized before bases and
bases can use
those data members in their own initializers.
--
---
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: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 19:21:58 +0800
Raw View
--Apple-Mail=_AB28E43F-91FE-472B-8AD3-0D8F2EA01CEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-29, at 5:52 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> On 29 March 2014 09:16, David Krauss <potswa@gmail.com> wrote:
>> You can define a [template] alias before the class definition. If this
>> pollutes the enclosing namespace, then confine it to a detail namespace.
>=20
> That would seem to be the current work-around, and the paper should expla=
in
> why that is not acceptable.
It's not a workaround, it's the usual ideas at the usual level of expressiv=
eness.
> In this email thread, it was pointed out that
> that leads to repetition of template parameters, but I think that should
> be spelled out in the proposal with examples.
What I meant by "Code with enough templates to be a use-case deserves ... o=
rganization" is that when two bases specialize the same template, or the na=
me of a base class is unknown because it is a metafunction result, signific=
ant metaprocessing is going on. In such cases, the bases should be assigned=
names, just as we assign names to intermediate results before producing a =
final result. Yes, sometimes splitting complex lines of code results in mor=
e verboseness, but that is not the enemy.
For the usual cases, we have, again:
typedef typename monstrous::something B;
This covers 99% of use cases and template parameters are never repeated.
It is very important to keep this proposal in proper context. Yes the propo=
sal would make Boost a little shorter, but most libraries aren't Boost. (Al=
so, that statistic is probably skewed because Boost does a lot of metaproce=
ssing, very conservatively, with the same thing written multiple times in d=
ifferent ways for different platforms.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_AB28E43F-91FE-472B-8AD3-0D8F2EA01CEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–29, at 5:52 PM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 29 March=
2014 09:16, David Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gm=
ail.com</a>> wrote:<br><blockquote type=3D"cite">You can define a [templ=
ate] alias before the class definition. If this<br>pollutes the enclosing n=
amespace, then confine it to a detail namespace.<br></blockquote><br>That w=
ould seem to be the current work-around, and the paper should explain<br>wh=
y that is not acceptable. </blockquote><div><br></div><div><div>It’s =
not a workaround, it’s the usual ideas at the usual level of expressi=
veness.</div><div><br></div></div><blockquote type=3D"cite">In this email t=
hread, it was pointed out that<br>that leads to repetition of template para=
meters, but I think that should<br>be spelled out in the proposal with exam=
ples.<br></blockquote><div><br></div><div>What I meant by "Code with enough=
templates to be a use-case deserves … organization” is that w=
hen two bases specialize the same template, or the name of a base class is =
unknown because it is a metafunction result, significant metaprocessing is =
going on. In such cases, the bases should be assigned names, just as we ass=
ign names to intermediate results before producing a final result. Yes, som=
etimes splitting complex lines of code results in more verboseness, but tha=
t is not the enemy.</div><div><br></div><div>For the usual cases, we have, =
again:</div><div><br></div><div><div><font face=3D"Courier"><span class=3D"=
Apple-tab-span" style=3D"white-space:pre"> </span>typedef typename monstrou=
s::something B;</font></div></div><div><br></div><div>This covers 99% of us=
e cases and template parameters are never repeated.</div><div><br></div></d=
iv><div>It is very important to keep this proposal in proper context. Yes t=
he proposal would make Boost a little shorter, but most libraries aren&rsqu=
o;t Boost. (Also, that statistic is probably skewed because Boost does a lo=
t of metaprocessing, very conservatively, with the same thing written multi=
ple times in different ways for different platforms.)</div><div><br></div><=
/body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_AB28E43F-91FE-472B-8AD3-0D8F2EA01CEC--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 29 Mar 2014 14:04:37 +0200
Raw View
On 29 March 2014 13:21, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-03-29, at 5:52 PM, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>
> On 29 March 2014 09:16, David Krauss <potswa@gmail.com> wrote:
>
> You can define a [template] alias before the class definition. If this
> pollutes the enclosing namespace, then confine it to a detail namespace.
>
>
> That would seem to be the current work-around, and the paper should explain
> why that is not acceptable.
>
>
> It's not a workaround, it's the usual ideas at the usual level of
> expressiveness.
It's a work-around to the problem that the paper proposes solve. It's
a work-around
in the sense that it doesn't quite provide the convenience of what the
paper proposes.
I am not interested in word-plays.
> It is very important to keep this proposal in proper context. Yes the
> proposal would make Boost a little shorter, but most libraries aren't Boost.
I haven't seen any emphasis on boost in this proposal. The shorthand syntax
that the paper proposes seems generally applicable to me. How generally,
and whether that is sufficient motivation for a language change is the
interesting question.
--
---
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: David Krauss <potswa@gmail.com>
Date: Sat, 29 Mar 2014 20:58:02 +0800
Raw View
On 2014-03-29, at 8:04 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> It's a work-around to the problem that the paper proposes solve. It's
> a work-around
> in the sense that it doesn't quite provide the convenience of what the
> paper proposes.
> I am not interested in word-plays.
Ah, I didn't see the draft and thought it was still hypothetical.
The first motivational case there is solved by the use of injected-class-name that I mentioned. It is not fair to compare that to a repeated typedef. It is by far the most common of the cases.
>> It is very important to keep this proposal in proper context. Yes the
>> proposal would make Boost a little shorter, but most libraries aren't Boost.
>
> I haven't seen any emphasis on boost in this proposal. The shorthand syntax
> that the paper proposes seems generally applicable to me. How generally,
> and whether that is sufficient motivation for a language change is the
> interesting question.
Earlier in this thread, a grep of Boost was used as motivation.
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 29 Mar 2014 15:53:22 +0200
Raw View
On 29 March 2014 14:58, David Krauss <potswa@gmail.com> wrote:
>>> It is very important to keep this proposal in proper context. Yes the
>>> proposal would make Boost a little shorter, but most libraries aren't Boost.
>>
>> I haven't seen any emphasis on boost in this proposal. The shorthand syntax
>> that the paper proposes seems generally applicable to me. How generally,
>> and whether that is sufficient motivation for a language change is the
>> interesting question.
>
> Earlier in this thread, a grep of Boost was used as motivation.
Ok, I missed that. In general, this proposal is, if I understand
correctly, trying to
- propose a shortcut syntax that can be used in base-specifier in addition to
the remaining class definition
- and do that without polluting the surrounding namespace
In this proposal, I think I want to see a comparison of
1) an alias for the base in the same namespace as the class
2) an alias for the base in a detail namespace nested in the same
namespace as the class
3) the syntax as in the proposal
and then the motivation why (3) is necessary, because (2) seems to
mostly achieve the
goals, without requiring a language change.
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 12:44:10 -0400
Raw View
On 2014-03-28 19:44, Edward Catmur wrote:
> Would it be worth considering alternative syntaxes? I feel the
> equals sign in a base-specifier might be better used for something
> else, eg base initializers (by analogy to inline member
> initializers).
>
> For example, using the syntax class-or-decltype identifier[opt]:
>
> template<typename T,typename Pasta> class monstrous :
> public something<[...]> base_t {
> /* ... */
> };
My first thought was 'class foo : public monstrous as base'. It has the
advantage that you could add wording that the default access of 'base'
is the same as 'monstrous', but you could also allow writing e.g.
'public monstrous as protected base', i.e. explicitly specify the access
of the alias. (Actually, I guess you could do this with '=' also, come
to think of it.)
OTOH not sure how people would feel about 'as' :-).
(For that matter, you could also use some other 'operator', e.g. '::='.)
--
Matthew
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 12:56:37 -0400
Raw View
On 2014-03-28 22:02, Richard Smith wrote:
> I'm also not really clear on why you'd want the name to have the same
> access as the base specifier.
class foo : public bar = baz { ... };
void none(foo* f)
{
f->baz::twitch();
}
....why shouldn't I be allowed to write that?
--
Matthew
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 11:55:09 -0700
Raw View
--bcaec51b9cfd36858004f5eb9788
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Mar 31, 2014 at 9:56 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-03-28 22:02, Richard Smith wrote:
>
>> I'm also not really clear on why you'd want the name to have the same
>> access as the base specifier.
>>
>
> class foo : public bar = baz { ... };
>
> void none(foo* f)
> {
> f->baz::twitch();
> }
>
> ...why shouldn't I be allowed to write that?
(I assume you mean 'bar::' and not 'baz::'?)
Because 'bar' is (probably) an implementation detail of the class. Here's
what I expect the 90% use case to look like:
class foo : public super = something { ... }; // or 'base' or 'parent'
depending on personal preference
The name 'super' is *not* part of the class's public interface, it's just
an implementation detail. Why should this be forced to be public, just
because the base class itself is?
--
---
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/.
--bcaec51b9cfd36858004f5eb9788
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 31, 2014 at 9:56 AM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</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"><div class=3D"">On 2014-03-28 22:02, Richard=
Smith wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I'm also not really clear on why you'd want the name to have the sa=
me<br>
access as the base specifier.<br>
</blockquote>
<br></div>
=A0 class foo : public bar =3D baz { ... };<br>
<br>
=A0 void none(foo* f)<br>
=A0 {<br>
=A0 =A0 f->baz::twitch();<br>
=A0 }<br>
<br>
....why shouldn't I be allowed to write that?</blockquote><div><br></div=
><div>(I assume you mean 'bar::' and not 'baz::'?)</div><di=
v><br></div><div>Because 'bar' is (probably) an implementation deta=
il of the class. Here's what I expect the 90% use case to look like:</d=
iv>
<div><br></div><div>=A0 class foo : public super =3D something { ... }; // =
or 'base' or 'parent' depending on personal preference</div=
><div><br></div><div>The name 'super' is *not* part of the class=
9;s public interface, it's just an implementation detail. Why should th=
is be forced to be public, just because the base class itself is?</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 />
--bcaec51b9cfd36858004f5eb9788--
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 31 Mar 2014 21:00:09 +0200
Raw View
2013-12-28 8:50 GMT+01:00 <rouslankorneychuk@gmail.com>:
> I have a simple proposal that I think can be explained with an example. How
> about something like this?:
>
> class A : public B = C {
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
> which would be equivalent to:
>
> class A : public C {
> typedef C B;
>
> A() : B(3) {}
>
> void do_something() {
> /* ... */
> B::do_something();
> }
> };
>
I have an alternative syntax for discussion
class A : public C using B {
...
};
Alternatively:
class A : public C short B {
...
};
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 12:00:38 -0700
Raw View
--001a11369b06d4cf1d04f5ebaa8c
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Mar 29, 2014 at 2:52 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 29 March 2014 09:16, David Krauss <potswa@gmail.com> wrote:
> > You can define a [template] alias before the class definition. If this
> > pollutes the enclosing namespace, then confine it to a detail namespace.
>
> That would seem to be the current work-around, and the paper should explain
> why that is not acceptable. In this email thread, it was pointed out that
> that leads to repetition of template parameters, but I think that should
> be spelled out in the proposal with examples.
>
> Here's an alternate syntax for consideration:
>
> template <class A, class B, class C> struct X
> {
> /* alias goes here */
> template<class A, class B, class C> using Base = Y<A, B, C>;
> /* public,protected,private*/ bases:
> Base /* = initializer, {initializer}*/;
> AnotherBase /* = initializer, {initializer}*/;
>
> };
>
> Such a syntax allows NDSMI for bases, and doesn't reinvent what existing
> syntaxes mean. The alias is scoped in the class scope, so there's no
> pollution.
>
> This would of course be a rather more involved change in the sense
> that there's nothing
> preventing
>
> struct X
> {
> string datamember = "foo";
> bases:
> Y{datamember};
> };
>
> So you could have data members that are initialized before bases and
> bases can use
> those data members in their own initializers.
This seems like a nice feature. Another option springs to mind:
template<class A, class B, class C> {
using Base = Y<A, B, C>;
struct X : Base {
void f();
};
inline void X::f() { Base::f(); }
}
This would be equivalent to:
template<class A, class B, class C> using Base = Y<A, B, C>;
template<class A, class B, class C> struct X : Base<A, B, C> {
// ...
};
template<class A, class B, class C> inline void X<A, B, C>::f() { Base<A,
B, C>::f(); }
(Essentially, each declaration within the template block is a template with
the same template-parameter-list, and any time that unqualified lookup
finds a member of that block, it's rewritten to have a
template-argument-list naming those template parameters.)
--
---
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/.
--001a11369b06d4cf1d04f5ebaa8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 29, 2014 at 2:52 AM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.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 class=3D"">On 29 March 2014 09:16, David Krauss <<=
a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>> wrote:<br>
> You can define a [template] alias before the class definition. If this=
<br>
> pollutes the enclosing namespace, then confine it to a detail namespac=
e.<br>
<br>
</div>That would seem to be the current work-around, and the paper should e=
xplain<br>
why that is not acceptable. In this email thread, it was pointed out that<b=
r>
that leads to repetition of template parameters, but I think that should<br=
>
be spelled out in the proposal with examples.<br>
<br>
Here's an alternate syntax for consideration:<br>
<br>
template <class A, class B, class C> struct X<br>
{<br>
=A0 =A0 /* alias goes here */<br>
=A0 =A0 template<class A, class B, class C> using Base =3D Y<A, B,=
C>;<br>
/* public,protected,private*/ bases:<br>
=A0 =A0 Base /* =3D initializer, {initializer}*/;<br>
=A0 =A0 AnotherBase /* =3D initializer, {initializer}*/;<br>
<br>
};<br>
<br>
Such a syntax allows NDSMI for bases, and doesn't reinvent what existin=
g<br>
syntaxes mean. The alias is scoped in the class scope, so there's no po=
llution.<br>
<br>
This would of course be a rather more involved change in the sense<br>
that there's nothing<br>
preventing<br>
<br>
struct X<br>
{<br>
=A0 =A0 string datamember =3D "foo";<br>
bases:<br>
=A0 =A0 Y{datamember};<br>
};<br>
<br>
So you could have data members that are initialized before bases and<br>
bases can use<br>
those data members in their own initializers.</blockquote><div><br></div><d=
iv>This seems like a nice feature. Another option springs to mind:</div><di=
v><br></div><div>template<class A, class B, class C> {</div><div>
=A0 using Base =3D Y<A, B, C>;</div><div>=A0 struct X : Base {</div><=
div>=A0 =A0 void f();</div><div>=A0 };</div><div>=A0 inline void X::f() { B=
ase::f(); }</div><div>}</div><div><br></div><div>This would be equivalent t=
o:</div><div>
<br></div><div><div>template<class A, class B, class C> using Base =
=3D Y<A, B, C>;</div><div>template<class A, class B, class C> s=
truct X : Base<A, B, C> {</div><div>=A0 // ...</div><div>};</div></di=
v>
<div>template<class A, class B, class C> inline void X<A, B, C>=
::f() { Base<A, B, C>::f(); }<br></div><div><br></div><div>(Essential=
ly, each declaration within the template block is a template with the same =
template-parameter-list, and any time that unqualified lookup finds a membe=
r of that block, it's rewritten to have a template-argument-list naming=
those template parameters.)</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 />
--001a11369b06d4cf1d04f5ebaa8c--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 12:01:31 -0700
Raw View
--047d7bb04396f1dc6404f5ebad0a
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Mar 31, 2014 at 12:00 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
> 2013-12-28 8:50 GMT+01:00 <rouslankorneychuk@gmail.com>:
> > I have a simple proposal that I think can be explained with an example.
> How
> > about something like this?:
> >
> > class A : public B = C {
> > A() : B(3) {}
> >
> > void do_something() {
> > /* ... */
> > B::do_something();
> > }
> > };
> >
> > which would be equivalent to:
> >
> > class A : public C {
> > typedef C B;
> >
> > A() : B(3) {}
> >
> > void do_something() {
> > /* ... */
> > B::do_something();
> > }
> > };
> >
>
> I have an alternative syntax for discussion
>
> class A : public C using B {
> ...
> };
>
> Alternatively:
>
> class A : public C short B {
> ...
> };
>
class A : public C (or B for short) {
};
=)
--
---
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/.
--047d7bb04396f1dc6404f5ebad0a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 31, 2014 at 12:00 PM, Johannes Schaub <span dir=3D"ltr"><<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.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">2013-12-28 8:50 GMT+01:00 =A0<<a href=3D"=
mailto:rouslankorneychuk@gmail.com">rouslankorneychuk@gmail.com</a>>:<br=
>
<div class=3D"">> I have a simple proposal that I think can be explained=
with an example. How<br>
> about something like this?:<br>
><br>
> class A : public B =3D C {<br>
> =A0 =A0 A() : B(3) {}<br>
><br>
> =A0 =A0 void do_something() {<br>
> =A0 =A0 =A0 =A0 /* ... */<br>
> =A0 =A0 =A0 =A0 B::do_something();<br>
> =A0 =A0 }<br>
> };<br>
><br>
> which would be equivalent to:<br>
><br>
> class A : public C {<br>
> =A0 =A0 typedef C B;<br>
><br>
> =A0 =A0 A() : B(3) {}<br>
><br>
> =A0 =A0 void do_something() {<br>
> =A0 =A0 =A0 =A0 /* ... */<br>
> =A0 =A0 =A0 =A0 B::do_something();<br>
> =A0 =A0 }<br>
> };<br>
><br>
<br>
</div>I have an alternative syntax for discussion<br>
<br>
class A : public C using B {<br>
=A0 =A0...<br>
};<br>
<br>
Alternatively:<br>
<br>
class A : public C short B {<br>
=A0 =A0...<br>
<div class=3D"HOEnZb"><div class=3D"h5">};</div></div></blockquote><div><br=
></div><div>class A : public C (or B for short) {</div><div>};</div><div><b=
r></div><div>=3D)</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 />
--047d7bb04396f1dc6404f5ebad0a--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 31 Mar 2014 22:16:18 +0300
Raw View
On 31 March 2014 22:01, Richard Smith <richard@metafoo.co.uk> wrote:
>> Alternatively:
>>
>> class A : public C short B {
>> ...
>> };
>
>
> class A : public C (or B for short) {
> };
>
> =)
Wonderful! While (no pun intended) we're at it, please consider
allowing noexcept
to be written
do not throw while using this
or (again, no pun intended, not part of the noexcept alternative)
do not throw while using this, or else
The first one is not originally mine. I'll refrain from blaming
anyone in particular for it, lest innocent people suffer.
The second may well be mine.
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 15:51:29 -0400
Raw View
On 2014-03-31 14:55, Richard Smith wrote:
> On Mon, Mar 31, 2014 at 9:56 AM, Matthew Woehlke <
> mw_triad@users.sourceforge.net> wrote:
>
>> On 2014-03-28 22:02, Richard Smith wrote:
>>
>>> I'm also not really clear on why you'd want the name to have the same
>>> access as the base specifier.
>>>
>>
>> class foo : public bar = baz { ... };
>>
>> void none(foo* f)
>> {
>> f->baz::twitch();
>> }
>>
>> ...why shouldn't I be allowed to write that?
>
>
> (I assume you mean 'bar::' and not 'baz::'?)
Er... "yes". Actually I meant for 'baz' to be the alias and 'bar' to be
the monstrously long class name... but I guess I got them backwards in
the base class declaration.
> Because 'bar' is (probably) an implementation detail of the class. Here's
> what I expect the 90% use case to look like:
>
> class foo : public super = something { ... }; // or 'base' or 'parent'
> depending on personal preference
>
> The name 'super' is *not* part of the class's public interface,
To me, that reads as "the fact that foo derives from something is not
part of the class's public interface"...
In languages where 'super' is a keyword, it (i.e. "the identity of the
class's base class) most certainly *is* part of the public API, at least
for public inheritance. Making the alias private is like saying you can
refer to the base class outside of the derived class's scope by its
actual name, but not by the standard mechanism to query the base class.
Which would be weird. And possibly purpose-defeating.
> it's just an implementation detail. Why should this be forced to be
> public, just because the base class itself is?
....for exactly that reason: the base class *is* public.
--
Matthew
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 15:56:34 -0400
Raw View
On 2014-03-31 15:00, Johannes Schaub wrote:
> I have an alternative syntax for discussion
>
> class A : public C using B {
> ...
> };
>
> Alternatively:
>
> class A : public C short B {
> ...
> };
If you're going to go down this route *at all*, then seriously:
class A : public monstrous as B
It's short, obvious, grammatically correct (unlike either of the above),
and at least has some precedent.
(For that matter, there was a proposal somewhere for 'as' in another
context, which IMHO would lend even more weight to using "as" versus
some other new or bizarrely overloaded keyword.)
--
Matthew
--
---
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: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 31 Mar 2014 22:06:37 +0200
Raw View
2014-03-31 21:51 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2014-03-31 14:55, Richard Smith wrote:
>>
>> Because 'bar' is (probably) an implementation detail of the class. Here's
>> what I expect the 90% use case to look like:
>>
>> class foo : public super = something { ... }; // or 'base' or 'parent'
>> depending on personal preference
>>
>> The name 'super' is *not* part of the class's public interface,
>
>
> To me, that reads as "the fact that foo derives from something is not part
> of the class's public interface"...
>
> In languages where 'super' is a keyword, it (i.e. "the identity of the
> class's base class) most certainly *is* part of the public API, at least for
> public inheritance. Making the alias private is like saying you can refer to
> the base class outside of the derived class's scope by its actual name, but
> not by the standard mechanism to query the base class. Which would be weird.
> And possibly purpose-defeating.
>
What is the "standard mechanism to query the base class"? An alias
would not be that Standard mechanism, right?
I would not compare these alias names with the language keyword
"super" of other languages. This is something else, it seems.
--
---
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: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 31 Mar 2014 22:08:08 +0200
Raw View
2014-03-31 21:56 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2014-03-31 15:00, Johannes Schaub wrote:
>>
>> I have an alternative syntax for discussion
>>
>> class A : public C using B {
>> ...
>> };
>>
>> Alternatively:
>>
>> class A : public C short B {
>> ...
>> };
>
>
> If you're going to go down this route *at all*, then seriously:
>
> class A : public monstrous as B
>
> It's short, obvious, grammatically correct (unlike either of the above), and
> at least has some precedent.
>
Neither of our proposals are grammatically correct, as can be tested
by putting our snippets into a recent C++ compiler. My goal was to
reuse existing keywords.
--
---
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: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 31 Mar 2014 22:11:34 +0200
Raw View
2014-03-31 22:08 GMT+02:00 Johannes Schaub <schaub.johannes@googlemail.com>:
> 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
>> On 2014-03-31 15:00, Johannes Schaub wrote:
>>>
>>> I have an alternative syntax for discussion
>>>
>>> class A : public C using B {
>>> ...
>>> };
>>>
....
>> It's short, obvious, grammatically correct (unlike either of the above), and
>> at least has some precedent.
>>
The arguments for "public C using B" are
1) We have the base "C", but we are using the name B for it.
2) The alias introduced follows the keyword "using" in two other
contexts of the language.
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Mon, 31 Mar 2014 16:23:57 -0400
Raw View
On Mon, Mar 31, 2014 at 4:11 PM, Johannes Schaub
<schaub.johannes@googlemail.com> wrote:
> The arguments for "public C using B" are
>
> 1) We have the base "C", but we are using the name B for it.
> 2) The alias introduced follows the keyword "using" in two other
> contexts of the language.
We usually use `=` to introduce aliases, like
namespace alias_ns = ns;
using alias_type = tp;
I think this syntax resolve the "ambiguity" on access:
class A : base = public C {
and `base` is visible in the class scope. If you want this
name to have linkage other than "no linkage", typedef it
in the class body:
public:
using base_type = base;
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 31 Mar 2014 23:34:58 +0300
Raw View
On 31 March 2014 22:00, Richard Smith <richard@metafoo.co.uk> wrote:
>> Here's an alternate syntax for consideration:
>>
>> template <class A, class B, class C> struct X
>> {
>> /* alias goes here */
>> template<class A, class B, class C> using Base = Y<A, B, C>;
>> /* public,protected,private*/ bases:
>> Base /* = initializer, {initializer}*/;
>> AnotherBase /* = initializer, {initializer}*/;
>>
>> };
>>
>> Such a syntax allows NDSMI for bases, and doesn't reinvent what existing
>> syntaxes mean. The alias is scoped in the class scope, so there's no
>> pollution.
>>
>> This would of course be a rather more involved change in the sense
>> that there's nothing
>> preventing
>>
>> struct X
>> {
>> string datamember = "foo";
>> bases:
>> Y{datamember};
>> };
>>
>> So you could have data members that are initialized before bases and
>> bases can use
>> those data members in their own initializers.
>
>
> This seems like a nice feature. Another option springs to mind:
An implementation of it would surely be welcome. ;)
>
> template<class A, class B, class C> {
> using Base = Y<A, B, C>;
> struct X : Base {
> void f();
> };
> inline void X::f() { Base::f(); }
> }
>
> This would be equivalent to:
>
> template<class A, class B, class C> using Base = Y<A, B, C>;
> template<class A, class B, class C> struct X : Base<A, B, C> {
> // ...
> };
> template<class A, class B, class C> inline void X<A, B, C>::f() { Base<A, B,
> C>::f(); }
>
> (Essentially, each declaration within the template block is a template with
> the same template-parameter-list, and any time that unqualified lookup finds
> a member of that block, it's rewritten to have a template-argument-list
> naming those template parameters.)
Yeah, well, this is suitable for templates, but not for non-templates, right?
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 16:40:24 -0400
Raw View
On 2014-03-31 16:06, Johannes Schaub wrote:
> 2014-03-31 21:51 GMT+02:00 Matthew Woehlke wrote:
>> On 2014-03-31 14:55, Richard Smith wrote:
>>> Because 'bar' is (probably) an implementation detail of the class. Here's
>>> what I expect the 90% use case to look like:
>>>
>>> class foo : public super = something { ... }; // or 'base' or 'parent'
>>> depending on personal preference
>>>
>>> The name 'super' is *not* part of the class's public interface,
>>
>> To me, that reads as "the fact that foo derives from something is not part
>> of the class's public interface"...
>>
>> In languages where 'super' is a keyword, it (i.e. "the identity of the
>> class's base class) most certainly *is* part of the public API, at least for
>> public inheritance. Making the alias private is like saying you can refer to
>> the base class outside of the derived class's scope by its actual name, but
>> not by the standard mechanism to query the base class. Which would be weird.
>> And possibly purpose-defeating.
>
> What is the "standard mechanism to query the base class"? An alias
> would not be that Standard mechanism, right?
>
> I would not compare these alias names with the language keyword
> "super" of other languages. This is something else, it seems.
....except that people will use it to emulate such mechanism. As you did
in your example. (Hence my reaction.)
If you feel that strongly that it should be permissible that the alias
is private / protected, then I would extend the proposal to allow that.
But IMO the case where the alias is public should be at least supported,
if not default.
--
Matthew
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 31 Mar 2014 23:42:17 +0300
Raw View
On 31 March 2014 23:40, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> If you feel that strongly that it should be permissible that the alias is
> private / protected, then I would extend the proposal to allow that. But IMO
> the case where the alias is public should be at least supported, if not
> default.
Agreed. Not allowing the alias to be public is insane.
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 16:43:55 -0400
Raw View
On 2014-03-31 16:08, Johannes Schaub wrote:
> 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
>> On 2014-03-31 15:00, Johannes Schaub wrote:
>>>
>>> I have an alternative syntax for discussion
>>>
>>> class A : public C using B {
>>> ...
>>> };
>>>
>>> Alternatively:
>>>
>>> class A : public C short B {
>>> ...
>>> };
>>
>>
>> If you're going to go down this route *at all*, then seriously:
>>
>> class A : public monstrous as B
>>
>> It's short, obvious, grammatically correct (unlike either of the above), and
>> at least has some precedent.
>
> Neither of our proposals are grammatically correct,
I meant *English* grammar :-). (Well, I guess you could nitpick the "as"
grammar too, but it's a lot closer at least.)
--
Matthew
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 13:53:59 -0700
Raw View
--047d7b6783ce2d7c2f04f5ed4087
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Mar 31, 2014 at 1:34 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 31 March 2014 22:00, Richard Smith <richard@metafoo.co.uk> wrote:
> >> Here's an alternate syntax for consideration:
> >>
> >> template <class A, class B, class C> struct X
> >> {
> >> /* alias goes here */
> >> template<class A, class B, class C> using Base = Y<A, B, C>;
> >> /* public,protected,private*/ bases:
> >> Base /* = initializer, {initializer}*/;
> >> AnotherBase /* = initializer, {initializer}*/;
> >>
> >> };
> >>
> >> Such a syntax allows NDSMI for bases, and doesn't reinvent what existing
> >> syntaxes mean. The alias is scoped in the class scope, so there's no
> >> pollution.
> >>
> >> This would of course be a rather more involved change in the sense
> >> that there's nothing
> >> preventing
> >>
> >> struct X
> >> {
> >> string datamember = "foo";
> >> bases:
> >> Y{datamember};
> >> };
> >>
> >> So you could have data members that are initialized before bases and
> >> bases can use
> >> those data members in their own initializers.
> >
> >
> > This seems like a nice feature. Another option springs to mind:
>
> An implementation of it would surely be welcome. ;)
:)
> > template<class A, class B, class C> {
> > using Base = Y<A, B, C>;
> > struct X : Base {
> > void f();
> > };
> > inline void X::f() { Base::f(); }
> > }
> >
> > This would be equivalent to:
> >
> > template<class A, class B, class C> using Base = Y<A, B, C>;
> > template<class A, class B, class C> struct X : Base<A, B, C> {
> > // ...
> > };
> > template<class A, class B, class C> inline void X<A, B, C>::f() {
> Base<A, B,
> > C>::f(); }
> >
> > (Essentially, each declaration within the template block is a template
> with
> > the same template-parameter-list, and any time that unqualified lookup
> finds
> > a member of that block, it's rewritten to have a template-argument-list
> > naming those template parameters.)
>
>
> Yeah, well, this is suitable for templates, but not for non-templates,
> right?
For a non-template, you can write:
using Base = ...;
struct X : Base { ... };
The trouble, in both the template and non-template case, is that you can't
easily limit the scope of the name to the class. :(
--
---
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/.
--047d7b6783ce2d7c2f04f5ed4087
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 31, 2014 at 1:34 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@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"><div class=3D"">On 31 March 2014 22:00, Rich=
ard Smith <<a href=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.u=
k</a>> wrote:<br>
>> Here's an alternate syntax for consideration:<br>
>><br>
>> template <class A, class B, class C> struct X<br>
>> {<br>
>> =A0 =A0 /* alias goes here */<br>
>> =A0 =A0 template<class A, class B, class C> using Base =3D Y=
<A, B, C>;<br>
>> /* public,protected,private*/ bases:<br>
>> =A0 =A0 Base /* =3D initializer, {initializer}*/;<br>
>> =A0 =A0 AnotherBase /* =3D initializer, {initializer}*/;<br>
>><br>
>> };<br>
>><br>
>> Such a syntax allows NDSMI for bases, and doesn't reinvent wha=
t existing<br>
>> syntaxes mean. The alias is scoped in the class scope, so there=
9;s no<br>
>> pollution.<br>
>><br>
>> This would of course be a rather more involved change in the sense=
<br>
>> that there's nothing<br>
>> preventing<br>
>><br>
>> struct X<br>
>> {<br>
>> =A0 =A0 string datamember =3D "foo";<br>
>> bases:<br>
>> =A0 =A0 Y{datamember};<br>
>> };<br>
>><br>
>> So you could have data members that are initialized before bases a=
nd<br>
>> bases can use<br>
>> those data members in their own initializers.<br>
><br>
><br>
> This seems like a nice feature. Another option springs to mind:<br>
<br>
</div>An implementation of it would surely be welcome. ;)</blockquote><div>=
<br></div><div>:)</div><div>=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cl=
ass=3D"">
> template<class A, class B, class C> {<br>
> =A0 using Base =3D Y<A, B, C>;<br>
> =A0 struct X : Base {<br>
> =A0 =A0 void f();<br>
> =A0 };<br>
> =A0 inline void X::f() { Base::f(); }<br>
> }<br>
><br>
> This would be equivalent to:<br>
><br>
> template<class A, class B, class C> using Base =3D Y<A, B, C&=
gt;;<br>
> template<class A, class B, class C> struct X : Base<A, B, C&g=
t; {<br>
> =A0 // ...<br>
> };<br>
> template<class A, class B, class C> inline void X<A, B, C>=
::f() { Base<A, B,<br>
> C>::f(); }<br>
><br>
> (Essentially, each declaration within the template block is a template=
with<br>
> the same template-parameter-list, and any time that unqualified lookup=
finds<br>
> a member of that block, it's rewritten to have a template-argument=
-list<br>
> naming those template parameters.)<br>
<br>
<br>
</div>Yeah, well, this is suitable for templates, but not for non-templates=
, right?</blockquote><div><br></div><div>For a non-template, you can write:=
</div><div><br></div><div>using Base =3D ...;</div><div>struct X : Base { .=
... };</div>
<div><br></div><div>The trouble, in both the template and non-template case=
, is that you can't easily limit the scope of the name to the class. :(=
</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 />
--047d7b6783ce2d7c2f04f5ed4087--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 31 Mar 2014 16:56:18 -0400
Raw View
--001a11c2c20a6f8f2804f5ed481e
Content-Type: text/plain; charset=ISO-8859-1
Since we are picking colors for the bikeshed:
class X : public using base = Y {};
Which maps existing alias syntax. Defaults visibility to that of the base
(it is an alias, the base itself). Not sure how the different access
specifiers for the base vs. the alias would do.
David
On Mon, Mar 31, 2014 at 4:43 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-03-31 16:08, Johannes Schaub wrote:
>
>> 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.
>> net>:
>>
>>> On 2014-03-31 15:00, Johannes Schaub wrote:
>>>
>>>>
>>>> I have an alternative syntax for discussion
>>>>
>>>> class A : public C using B {
>>>> ...
>>>> };
>>>>
>>>> Alternatively:
>>>>
>>>> class A : public C short B {
>>>> ...
>>>> };
>>>>
>>>
>>>
>>> If you're going to go down this route *at all*, then seriously:
>>>
>>> class A : public monstrous as B
>>>
>>> It's short, obvious, grammatically correct (unlike either of the above),
>>> and
>>> at least has some precedent.
>>>
>>
>> Neither of our proposals are grammatically correct,
>>
>
> I meant *English* grammar :-). (Well, I guess you could nitpick the "as"
> grammar too, but it's a lot closer at least.)
>
> --
> Matthew
>
>
> --
>
> --- 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/.
--001a11c2c20a6f8f2804f5ed481e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Since we are picking colors for the bikeshed:<br><br>class=
X : public using base =3D Y {};<br><br>Which maps existing alias syntax. D=
efaults visibility to that of the base (it is an alias, the base itself). N=
ot sure how the different access specifiers for the base vs. the alias woul=
d do.<br>
<br>=A0 =A0David</div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Mon, Mar 31, 2014 at 4:43 PM, Matthew Woehlke <span dir=3D"ltr"=
><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw=
_triad@users.sourceforge.net</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"><div class=3D"">On 2014-03-31 16:08, Johanne=
s Schaub wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2014-03-31 21:56 GMT+02:00 Matthew Woehlke <<a href=3D"mailto:mw_triad@u=
sers.sourceforge.net" target=3D"_blank">mw_triad@users.sourceforge.<u></u>n=
et</a>>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 2014-03-31 15:00, Johannes Schaub wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I have an alternative syntax for discussion<br>
<br>
class A : public C using B {<br>
=A0 =A0 =A0...<br>
};<br>
<br>
Alternatively:<br>
<br>
class A : public C short B {<br>
=A0 =A0 =A0...<br>
};<br>
</blockquote>
<br>
<br>
If you're going to go down this route *at all*, then seriously:<br>
<br>
=A0 =A0class A : public monstrous as B<br>
<br>
It's short, obvious, grammatically correct (unlike either of the above)=
, and<br>
at least has some precedent.<br>
</blockquote>
<br>
Neither of our proposals are grammatically correct,<br>
</blockquote>
<br></div>
I meant *English* grammar :-). (Well, I guess you could nitpick the "a=
s" grammar too, but it's a lot closer at least.)<span class=3D"HOE=
nZb"><font color=3D"#888888"><br>
<br>
-- <br>
Matthew</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "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" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>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 />
--001a11c2c20a6f8f2804f5ed481e--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Mon, 31 Mar 2014 17:20:05 -0400
Raw View
On 03/31/2014 04:53 PM, Richard Smith wrote:
> On Mon, Mar 31, 2014 at 1:34 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>
> On 31 March 2014 22:00, Richard Smith <richard@metafoo.co.uk
> <mailto:richard@metafoo.co.uk>> wrote:
> >> Here's an alternate syntax for consideration:
> >>
> >> template <class A, class B, class C> struct X
> >> {
> >> /* alias goes here */
> >> template<class A, class B, class C> using Base = Y<A, B, C>;
> >> /* public,protected,private*/ bases:
> >> Base /* = initializer, {initializer}*/;
> >> AnotherBase /* = initializer, {initializer}*/;
> >>
> >> };
> >>
> >> Such a syntax allows NDSMI for bases, and doesn't reinvent what
> existing
> >> syntaxes mean. The alias is scoped in the class scope, so there's no
> >> pollution.
> >>
> >> This would of course be a rather more involved change in the sense
> >> that there's nothing
> >> preventing
> >>
> >> struct X
> >> {
> >> string datamember = "foo";
> >> bases:
> >> Y{datamember};
> >> };
> >>
> >> So you could have data members that are initialized before bases and
> >> bases can use
> >> those data members in their own initializers.
> >
> >
> > This seems like a nice feature. Another option springs to mind:
>
> An implementation of it would surely be welcome. ;)
>
>
> :)
>
> > template<class A, class B, class C> {
> > using Base = Y<A, B, C>;
> > struct X : Base {
> > void f();
> > };
> > inline void X::f() { Base::f(); }
> > }
> >
> > This would be equivalent to:
> >
> > template<class A, class B, class C> using Base = Y<A, B, C>;
> > template<class A, class B, class C> struct X : Base<A, B, C> {
> > // ...
> > };
> > template<class A, class B, class C> inline void X<A, B, C>::f() {
> Base<A, B,
> > C>::f(); }
> >
> > (Essentially, each declaration within the template block is a
> template with
> > the same template-parameter-list, and any time that unqualified
> lookup finds
> > a member of that block, it's rewritten to have a
> template-argument-list
> > naming those template parameters.)
>
>
> Yeah, well, this is suitable for templates, but not for
> non-templates, right?
>
>
> For a non-template, you can write:
>
> using Base = ...;
> struct X : Base { ... };
>
> The trouble, in both the template and non-template case, is that you
> can't easily limit the scope of the name to the class. :(
How about allowing the using declaration to be inline? This would allow
for '=' to be unambiguously used for both an alias specification and a
default base class initializer, but doesn't make the base class
initializer ambiguous with the class body. This seems a little wonky
since the '=' in each case is used for something very different, but the
uses are consistent with the rest of the language.
template<typename T>
struct Base {
Base(int, int);
};
struct X : using super = Base<int> = {42,11} {
X() {}
X(int i1, int i2) : super(i1,i2) {}
};
X x; // Base constructor is called with (42,11)
X x{1,2} // Base constructor is called with (1,2)
Each use of the '=' would be valid individually as well of course:
struct Y : using super = Base<int> {};
struct Z : Base<int> = {42,11}, private AnotherBase = {} {};
Tom.
--
---
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: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 31 Mar 2014 14:24:48 -0700 (PDT)
Raw View
------=_Part_519_10676611.1396301088339
Content-Type: text/plain; charset=UTF-8
Yet another option would be to wait for our upcoming reflection traits and
write:
template<class A, class B, class C>
struct X : monsterous<A,B,C, yada yada yada>
{
using base = std::base_class_type_t<X,0>;
void f();
};
inline void X::f() { base::f(); }
This isn't exactly a use case we had in mind, but it just might work (or
might be able to be made to work). Notably the current spec has X required
to be complete which could be a problem.
On Monday, March 31, 2014 9:00:38 PM UTC+2, Richard Smith wrote:
>
> On Sat, Mar 29, 2014 at 2:52 AM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 29 March 2014 09:16, David Krauss <pot...@gmail.com <javascript:>>
>> wrote:
>> > You can define a [template] alias before the class definition. If this
>> > pollutes the enclosing namespace, then confine it to a detail namespace.
>>
>> That would seem to be the current work-around, and the paper should
>> explain
>> why that is not acceptable. In this email thread, it was pointed out that
>> that leads to repetition of template parameters, but I think that should
>> be spelled out in the proposal with examples.
>>
>> Here's an alternate syntax for consideration:
>>
>> template <class A, class B, class C> struct X
>> {
>> /* alias goes here */
>> template<class A, class B, class C> using Base = Y<A, B, C>;
>> /* public,protected,private*/ bases:
>> Base /* = initializer, {initializer}*/;
>> AnotherBase /* = initializer, {initializer}*/;
>>
>> };
>>
>> Such a syntax allows NDSMI for bases, and doesn't reinvent what existing
>> syntaxes mean. The alias is scoped in the class scope, so there's no
>> pollution.
>>
>> This would of course be a rather more involved change in the sense
>> that there's nothing
>> preventing
>>
>> struct X
>> {
>> string datamember = "foo";
>> bases:
>> Y{datamember};
>> };
>>
>> So you could have data members that are initialized before bases and
>> bases can use
>> those data members in their own initializers.
>
>
> This seems like a nice feature. Another option springs to mind:
>
> template<class A, class B, class C> {
> using Base = Y<A, B, C>;
> struct X : Base {
> void f();
> };
> inline void X::f() { Base::f(); }
> }
>
> This would be equivalent to:
>
> template<class A, class B, class C> using Base = Y<A, B, C>;
> template<class A, class B, class C> struct X : Base<A, B, C> {
> // ...
> };
> template<class A, class B, class C> inline void X<A, B, C>::f() { Base<A,
> B, C>::f(); }
>
> (Essentially, each declaration within the template block is a template
> with the same template-parameter-list, and any time that unqualified lookup
> finds a member of that block, it's rewritten to have a
> template-argument-list naming those template parameters.)
>
--
---
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_519_10676611.1396301088339
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yet another option would be to wait for our upcoming refle=
ction traits and write:<div><br></div><div>template<class A, class B, cl=
ass C></div><div>struct X : monsterous<A,B,C, yada yada yada></div=
><div>{</div><div> using base =3D std::base_class_type_t<X,=
0>;</div><div><br></div><div> void f();</div><div>};</div><=
div><br></div><div>inline void X::f() { base::f(); }</div><div><br></div><d=
iv>This isn't exactly a use case we had in mind, but it just might work (or=
might be able to be made to work). Notably the current spec has X re=
quired to be complete which could be a problem.</div><div><br></div><div>On=
Monday, March 31, 2014 9:00:38 PM UTC+2, Richard Smith wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote">On Sat, Mar 29, 2014 at 2:52 AM, Ville Voutilainen <span dir=3D"ltr">=
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8Bcb=
48l9BJUJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></spa=
n> 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>On 29 March 2014 09:16, David Krauss <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8Bcb48l9BJUJ" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">pot...@gmail.com</a>> wrote:<br>
> You can define a [template] alias before the class definition. If this=
<br>
> pollutes the enclosing namespace, then confine it to a detail namespac=
e.<br>
<br>
</div>That would seem to be the current work-around, and the paper should e=
xplain<br>
why that is not acceptable. In this email thread, it was pointed out that<b=
r>
that leads to repetition of template parameters, but I think that should<br=
>
be spelled out in the proposal with examples.<br>
<br>
Here's an alternate syntax for consideration:<br>
<br>
template <class A, class B, class C> struct X<br>
{<br>
/* alias goes here */<br>
template<class A, class B, class C> using Base =3D Y<=
;A, B, C>;<br>
/* public,protected,private*/ bases:<br>
Base /* =3D initializer, {initializer}*/;<br>
AnotherBase /* =3D initializer, {initializer}*/;<br>
<br>
};<br>
<br>
Such a syntax allows NDSMI for bases, and doesn't reinvent what existing<br=
>
syntaxes mean. The alias is scoped in the class scope, so there's no pollut=
ion.<br>
<br>
This would of course be a rather more involved change in the sense<br>
that there's nothing<br>
preventing<br>
<br>
struct X<br>
{<br>
string datamember =3D "foo";<br>
bases:<br>
Y{datamember};<br>
};<br>
<br>
So you could have data members that are initialized before bases and<br>
bases can use<br>
those data members in their own initializers.</blockquote><div><br></div><d=
iv>This seems like a nice feature. Another option springs to mind:</div><di=
v><br></div><div>template<class A, class B, class C> {</div><div>
using Base =3D Y<A, B, C>;</div><div> struct X : Base {<=
/div><div> void f();</div><div> };</div><div> inli=
ne void X::f() { Base::f(); }</div><div>}</div><div><br></div><div>This wou=
ld be equivalent to:</div><div>
<br></div><div><div>template<class A, class B, class C> using Base =
=3D Y<A, B, C>;</div><div>template<class A, class B, class C> s=
truct X : Base<A, B, C> {</div><div> // ...</div><div>};</div><=
/div>
<div>template<class A, class B, class C> inline void X<A, B, C>=
::f() { Base<A, B, C>::f(); }<br></div><div><br></div><div>(Essential=
ly, each declaration within the template block is a template with the same =
template-parameter-list, and any time that unqualified lookup finds a membe=
r of that block, it's rewritten to have a template-argument-list naming tho=
se template parameters.)</div>
</div></div></div>
</blockquote></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_519_10676611.1396301088339--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 17:49:43 -0400
Raw View
On 2014-03-31 16:56, David Rodr=C3=ADguez Ibeas wrote:
> Since we are picking colors for the bikeshed:
>
> class X : public using base =3D Y {};
>
> Which maps existing alias syntax. Defaults visibility to that of the base
> (it is an alias, the base itself). Not sure how the different access
> specifiers for the base vs. the alias would do.
I suggeste:
// 'base' is public subclass, 'super' alias is public
class derived : using public super =3D public base
// 'base' is public subclass, 'super' alias is protected
class derived : using protected super =3D public base
....and then we can bikeshed about the access protection of the alias if=20
not explicitly specified.
--=20
Matthew
--=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: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 31 Mar 2014 19:24:45 -0700 (PDT)
Raw View
------=_Part_701_22085093.1396319085632
Content-Type: text/plain; charset=UTF-8
On Monday, March 31, 2014 4:43:55 PM UTC-4, Matthew Woehlke wrote:
>
> On 2014-03-31 16:08, Johannes Schaub wrote:
> > 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <
> mw_t...@users.sourceforge.net <javascript:>>:
> >> If you're going to go down this route *at all*, then seriously:
> >>
> >> class A : public monstrous as B
> >>
> >> It's short, obvious, grammatically correct (unlike either of the
> above), and
> >> at least has some precedent.
> >
> > Neither of our proposals are grammatically correct,
>
> I meant *English* grammar :-). (Well, I guess you could nitpick the "as"
> grammar too, but it's a lot closer at least.)
>
This is the syntax which makes the most sense to me.
class A : public monstrous as B
reads to me like this:
class A : [is] public[ly derived from the class] monstrous [which I am now
going to refer to] as B
It is done as a postfix to the current syntax, instead of inserting it in
the middle, which is very attractive to me. If I understand the current
grammar properly, this also means the "as" can be like final and override
and doesn't have to be a new keyword..
--
---
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_701_22085093.1396319085632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 31, 2014 4:43:55 PM UTC-4, Matthew Woehlk=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-03-31 16:08, J=
ohannes Schaub wrote:
<br>> 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"tbXH-w9HqPMJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">mw_t...@users.sourceforge.<wbr>net</a>>:
<br>>> If you're going to go down this route *at all*, then seriously=
:
<br>>>
<br>>> class A : public monstrous as B
<br>>>
<br>>> It's short, obvious, grammatically correct (unlike either of t=
he above), and
<br>>> at least has some precedent.
<br>>
<br>> Neither of our proposals are grammatically correct,
<br>
<br>I meant *English* grammar :-). (Well, I guess you could nitpick the "as=
"=20
<br>grammar too, but it's a lot closer at least.)
<br></blockquote><div> </div><div>This is the syntax which makes the m=
ost sense to me.</div><div><br></div><div>class A : public monstrous as B</=
div><div><br></div><div>reads to me like this:</div><div><br></div><div>cla=
ss A : [is] public[ly derived from the class] monstrous [which I am now goi=
ng to refer to<span style=3D"font-size: 13px;">]</span><span style=3D"font-=
size: 13px;"> as B</span></div><div><br></div><div>It is done as a pos=
tfix to the current syntax, instead of inserting it in the middle, which is=
very attractive to me. If I understand the current grammar properly,=
this also means the "as" can be like final and override and doesn't have t=
o be a new keyword..</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_701_22085093.1396319085632--
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Tue, 1 Apr 2014 11:55:20 +0200
Raw View
--001a11331a8c80063e04f5f82a59
Content-Type: text/plain; charset=ISO-8859-1
Am 31.03.2014 22:11 schrieb "Johannes Schaub" <
schaub.johannes@googlemail.com>:
>
> 2014-03-31 22:08 GMT+02:00 Johannes Schaub <schaub.johannes@googlemail.com
>:
> > 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <
mw_triad@users.sourceforge.net>:
> >> On 2014-03-31 15:00, Johannes Schaub wrote:
> >>>
> >>> I have an alternative syntax for discussion
> >>>
> >>> class A : public C using B {
> >>> ...
> >>> };
> >>>
> ...
> >> It's short, obvious, grammatically correct (unlike either of the
above), and
> >> at least has some precedent.
> >>
>
> The arguments for "public C using B" are
>
> 1) We have the base "C", but we are using the name B for it.
> 2) The alias introduced follows the keyword "using" in two other
> contexts of the language.
The intent of alias declarations was to allow not only denoting types but
in later Standards to add aliasing other entities aswell. So if you have
using foo = bar;
The identifier could introduce a template alias (I am sorry if this term
will cause rage, but in this case the order of words seems right =)),
variable alias, type alias (the only thing yet supported), namespace alias
and so on.
Hence the choice of "using" was taking these considerations into account.
--
---
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/.
--001a11331a8c80063e04f5f82a59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Am 31.03.2014 22:11 schrieb "Johannes Schaub" <<a href=3D"mail=
to:schaub.johannes@googlemail.com">schaub.johannes@googlemail.com</a>>:<=
br>
><br>
> 2014-03-31 22:08 GMT+02:00 Johannes Schaub <<a href=3D"mailto:schau=
b.johannes@googlemail.com">schaub.johannes@googlemail.com</a>>:<br>
> > 2014-03-31 21:56 GMT+02:00 Matthew Woehlke <<a href=3D"mailto:=
mw_triad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>>:<br>
> >> On 2014-03-31 15:00, Johannes Schaub wrote:<br>
> >>><br>
> >>> I have an alternative syntax for discussion<br>
> >>><br>
> >>> class A : public C using B {<br>
> >>> =A0 =A0 ...<br>
> >>> };<br>
> >>><br>
> ...<br>
> >> It's short, obvious, grammatically correct (unlike either=
of the above), and<br>
> >> at least has some precedent.<br>
> >><br>
><br>
> The arguments for =A0"public C using B" are<br>
><br>
> 1) We have the base "C", but we are using the name B for it.=
<br>
> 2) The alias introduced follows the keyword "using" in two o=
ther<br>
> contexts of the language.</p>
<p dir=3D"ltr">The intent of alias declarations was to allow not only denot=
ing types but in later Standards to add aliasing other entities aswell. So =
if you have</p>
<p dir=3D"ltr">=A0=A0=A0 using foo =3D bar;</p>
<p dir=3D"ltr">The identifier could introduce a template alias (I am sorry =
if this term will cause rage, but in this case the order of words seems rig=
ht =3D)), variable alias, type alias (the only thing yet supported), namesp=
ace alias and so on.</p>
<p dir=3D"ltr">Hence the choice of "using" was taking these consi=
derations into account.</p>
<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 />
--001a11331a8c80063e04f5f82a59--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Tue, 1 Apr 2014 09:28:17 -0700 (PDT)
Raw View
------=_Part_199_28801559.1396369698001
Content-Type: text/plain; charset=UTF-8
On Tuesday, April 1, 2014 5:55:20 AM UTC-4, Johannes Schaub wrote:
>
> The intent of alias declarations was to allow not only denoting types but
> in later Standards to add aliasing other entities aswell. So if you have
>
> using foo = bar;
>
> The identifier could introduce a template alias (I am sorry if this term
> will cause rage, but in this case the order of words seems right =)),
> variable alias, type alias (the only thing yet supported), namespace alias
> and so on.
>
> Hence the choice of "using" was taking these considerations into account.
>
I think it would help all of us avoid misunderstandings if we all used
better terms than foo and bar. I can't tell which is the real class and
which is the alias just by looking at it. I can assume based on current
usage of terms, but that's never a good thing. This is much easier to
understand "using baseclass = alias" or "using alias = baseclass".
--
---
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_199_28801559.1396369698001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, April 1, 2014 5:55:20 AM UTC-4, Johannes Schau=
b wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><span s=
tyle=3D"font-size: 13px;">The intent of alias declarations was to allow not=
only denoting types but in later Standards to add aliasing other entities =
aswell. So if you have</span><br></p>
<p dir=3D"ltr"> using foo =3D bar;</p>
<p dir=3D"ltr">The identifier could introduce a template alias (I am sorry =
if this term will cause rage, but in this case the order of words seems rig=
ht =3D)), variable alias, type alias (the only thing yet supported), namesp=
ace alias and so on.</p>
<p dir=3D"ltr">Hence the choice of "using" was taking these considerations =
into account.</p></blockquote><div><span style=3D"font-size: 13px;">I think=
it would help all of us avoid misunderstandings if we all used bette=
r terms than foo and bar. I can't tell which is the real class and wh=
ich is the alias just by looking at it. I can assume based on current=
usage of terms, but that's never a good thing. This is much easier t=
o understand </span><span style=3D"font-size: 13px;">"using baseclass =
=3D alias" or "using alias =3D baseclass".</span></div><div><br></div></div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_199_28801559.1396369698001--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 1 Apr 2014 12:36:11 -0400
Raw View
--001a1134effc14479e04f5fdc464
Content-Type: text/plain; charset=ISO-8859-1
I imagine that the least confusing option would be 'using alias = real' in
the sense that this is already the way you create a type alias:
using myvector = std::vector<int>;
On Tue, Apr 1, 2014 at 12:28 PM, Greg Marr <gregmmarr@gmail.com> wrote:
> On Tuesday, April 1, 2014 5:55:20 AM UTC-4, Johannes Schaub wrote:
>>
>> The intent of alias declarations was to allow not only denoting types but
>> in later Standards to add aliasing other entities aswell. So if you have
>>
>> using foo = bar;
>>
>> The identifier could introduce a template alias (I am sorry if this term
>> will cause rage, but in this case the order of words seems right =)),
>> variable alias, type alias (the only thing yet supported), namespace alias
>> and so on.
>>
>> Hence the choice of "using" was taking these considerations into account.
>>
> I think it would help all of us avoid misunderstandings if we all used
> better terms than foo and bar. I can't tell which is the real class and
> which is the alias just by looking at it. I can assume based on current
> usage of terms, but that's never a good thing. This is much easier to
> understand "using baseclass = alias" or "using alias = baseclass".
>
> --
>
> ---
> 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/.
--001a1134effc14479e04f5fdc464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I imagine that the least confusing option would be 'us=
ing alias =3D real' in the sense that this is already the way you creat=
e a type alias:<br><br>using myvector =3D std::vector<int>;<div><br><=
/div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
Apr 1, 2014 at 12:28 PM, Greg Marr <span dir=3D"ltr"><<a href=3D"mailto=
:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@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"><div dir=3D"ltr"><div class=3D"">On Tuesday,=
April 1, 2014 5:55:20 AM UTC-4, Johannes Schaub wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<p dir=3D"ltr"><span style=3D"font-size:13px">The intent of alias declarati=
ons was to allow not only denoting types but in later Standards to add alia=
sing other entities aswell. So if you have</span><br></p>
<p dir=3D"ltr">=A0=A0=A0 using foo =3D bar;</p>
<p dir=3D"ltr">The identifier could introduce a template alias (I am sorry =
if this term will cause rage, but in this case the order of words seems rig=
ht =3D)), variable alias, type alias (the only thing yet supported), namesp=
ace alias and so on.</p>
<p dir=3D"ltr">Hence the choice of "using" was taking these consi=
derations into account.</p></blockquote></div><div><span style=3D"font-size=
:13px">I think it would help all of us avoid misunderstandings if we all us=
ed =A0better terms than foo and bar. =A0I can't tell which is the real =
class and which is the alias just by looking at it. =A0I can assume based o=
n current usage of terms, but that's never a good thing. =A0This is muc=
h easier to understand=A0</span><span style=3D"font-size:13px">"using =
baseclass =3D alias" or "using alias =3D baseclass".</span><=
/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 />
--001a1134effc14479e04f5fdc464--
.