New paper N4526 to be submitted for Friday's mailing deadline

[Michael Wong]

I have been revising this paper along the way and have a new number for it from Lenexa already. So if there is now objection, I will be submitting N4526.
https://docs.google.com/document/d/1sdllzgrl4rLMn6jvV-AJB1Vp4p8l142iaj0RAtgEyAk/edit

[Nevin Liber]

On 21 May 2015 at 03:50, Michael Wong <fragga...@gmail.com> wrote:

I have been revising this paper along the way and have a new number for it from Lenexa already. So if there is now objection, I will be submitting N4526.
https://docs.google.com/document/d/1sdllzgrl4rLMn6jvV-AJB1Vp4p8l142iaj0RAtgEyAk/edit

In there I read:

Concerned about variant proposals resorting to RTTI. RTTI is verboten for game developers and dynamic dispatch is not ideal, so this variant would be a write-off.

 

What in the variant proposal n4450 resorts to RTTI?

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[Nicolas Guillemot]

Hi Nevin. That line refers to this thread: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/unofficial-real-time-cxx/7LTqttN_RVY

--
You received this message because you are subscribed to the Google Groups "unofficial-real-time-cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-ti...@googlegroups.com.
To post to this group, send email to unofficial-r...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAGg_6%2BPqEoZG5GYQe2uTR__hGbLXoSr6pLEm1tjr6JQPmHTt0w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Sean Middleditch]

On Thu, May 21, 2015 at 8:28 AM, Nevin Liber <ne...@eviloverlord.com> wrote:

> In there I read:
>>
>> Concerned about variant proposals resorting to RTTI. RTTI is verboten for
>> game developers and dynamic dispatch is not ideal, so this variant would be
>> a write-off.
>
>
> What in the variant proposal n4450 resorts to RTTI?

That concern may have been from me. The sample implementation I'd seen
from CPPCon presenters did the same thing that Boost.Variant does,
which uses type_info as the discriminator internally, and exposed that
detail inadvertently.

It looks like the N4450's "exposition only" sample interface is using
the type-to-int trick instead, which is good.

I talked to some authors at last CPPCon, so perhaps they took the
advice to heart? Or I'm just remembering a different implementation
(there were two or three different talks on or involving discriminated
unions at CPPCon, iirc, not all of which turned into papers).

[Nevin Liber]

On 21 May 2015 at 11:28, Sean Middleditch <se...@middleditch.us> wrote:

It looks like the N4450's "exposition only" sample interface is using
the type-to-int trick instead, which is good.

Cool.  I just want to make sure there are no new concerns we haven't yet with the variant proposal.

I will keep it in mind should someone wish to go in the type_info direction.  About the only thing we talked about in this area was pruning the type list, which we can't do better (in a library solution) than O(N^^2) w/o a constexpr type_info::before() or equivalent, and that won't be happening.

 

I talked to some authors at last CPPCon, so perhaps they took the
advice to heart? Or I'm just remembering a different implementation
(there were two or three different talks on or involving discriminated
unions at CPPCon, iirc, not all of which turned into papers).

I don't think Axel Neumann (author of the proposal) was at CppCon, but it's all a blur for me at this point. :-)