On 13 December 2011 22:39, Gabriel Dos Reis wrote:
>
> Leaving __is_final undocumented is probably a good compromise.
Checked in, without the doc update. Thanks, all.
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 1
Hi,
My comment isn't about the technical aspect of the patch itself -- it
is a simple patch. But we don't seem to understand yet the
implications of "final". As was observed on the standard reflectors,
the appropriate trait might actually need to be binary instead of
unary as this patch implem
On Tue, Dec 13, 2011 at 12:02 PM, Jonathan Wakely wrote:
> On 13 December 2011 17:01, Paolo Carlini wrote:
>> Hi,
>>>
>>> This patch seems pretty simple and safe. Are you (Gaby and Paolo) arguing
>>> that even so, it shouldn't go in?
>>
>> As far as I'm concerned, definetely not! I also think t
On Tue, Dec 13, 2011 at 10:43 AM, Jason Merrill wrote:
> On 12/12/2011 09:14 AM, Gabriel Dos Reis wrote:
>>
>> On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini
>> wrote:
>>
I think being able to detect a final class is good enough for now,
until we find out if there are real problems bein
On 12/13/2011 12:01 PM, Paolo Carlini wrote:
As far as I'm concerned, definetely not! I also think that it would be great
if, for 4.7, Jon could handle the library issues with EBO by exploiting it.
The patch is OK, then.
Jason
Hi,
> So the proposed patch just adds the __is_final intrinsic for use
> internally by the library, to allow library changes so the test cases
> in the bug report will pass. If preferred I won't even add __is_final
> to the extend.texi docs, to leave it as an undocumented extension that
> we coul
On 13 December 2011 17:01, Paolo Carlini wrote:
> Hi,
>>
>> This patch seems pretty simple and safe. Are you (Gaby and Paolo) arguing
>> that even so, it shouldn't go in?
>
> As far as I'm concerned, definetely not! I also think that it would be great
> if, for 4.7, Jon could handle the library
Hi,
>
> This patch seems pretty simple and safe. Are you (Gaby and Paolo) arguing
> that even so, it shouldn't go in?
As far as I'm concerned, definetely not! I also think that it would be great
if, for 4.7, Jon could handle the library issues with EBO by exploiting it. I
only meant to say th
On 12/12/2011 09:14 AM, Gabriel Dos Reis wrote:
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini wrote:
I think being able to detect a final class is good enough for now,
until we find out if there are real problems being encountered as
people make more use of C++11.
Maybe. But in my opinion w
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini wrote:
>> I think being able to detect a final class is good enough for now,
>> until we find out if there are real problems being encountered as
>> people make more use of C++11.
>
> Maybe. But in my opinion we should not rush. Something is wrong he
On 12/12/2011 12:19 PM, Jonathan Wakely wrote:
As regards the wider issue which is being discussed on the reflector -
beware, I didn't follow all the messages - 'final' disabling a nice
optimization like EBO makes me very nervous. Really, doesn't seem part
of the intended general philosophy in th
On 12/12/2011, Paolo Carlini wrote:
> On 12/11/2011 04:05 PM, Jonathan Wakely wrote:
>> ping
> In my opinion __is_final would be definitely useful in general, for 4.8,
> and 4.7 too, if isn't too late.
As we've got the final keyword in 4.7 I think we really want
__is_final in the front end too.
>
On 12/11/2011 04:05 PM, Jonathan Wakely wrote:
ping
In my opinion __is_final would be definitely useful in general, for 4.8,
and 4.7 too, if isn't too late.
As regards the wider issue which is being discussed on the reflector -
beware, I didn't follow all the messages - 'final' disabling a ni
ping
On 3 December 2011 12:04, Jonathan Wakely wrote:
> On 3 December 2011 12:00, Jonathan Wakely wrote:
>> This implements a new C++ trait, __is_final, to query the 'final'
>> specifier that 4.7 supports. The trait is needed for the library so we
>> can detect when it's not possible to derive fro
On 3 December 2011 12:00, Jonathan Wakely wrote:
> This implements a new C++ trait, __is_final, to query the 'final'
> specifier that 4.7 supports. The trait is needed for the library so we
> can detect when it's not possible to derive from a type in order to
> exploit the empty base-class optimisa
This implements a new C++ trait, __is_final, to query the 'final'
specifier that 4.7 supports. The trait is needed for the library so we
can detect when it's not possible to derive from a type in order to
exploit the empty base-class optimisation. This affects all
containers, std::shared_ptr, std:
16 matches
Mail list logo
