Date: Mon, 26 Jan 2026 10:54:52 +0000
On Mon, Jan 26, 2026 at 10:47 AM Frederick Virchanza Gotham wrote:
>
> In the Chromium codebase, inside "pc/video_rtp_receiver.cc", there is
> a member function that returns a vector by value:
>
> std::vector<scoped_refptr<MediaStreamInterface>>
> VideoRtpReceiver::streams() const;
>
> The "scoped_refptr" class is polymorphic.
I just looked at the code on Google Source and it turns out the
destructor isn't virtual after all -- i.e. it's not polymorphic.
I'll keep searching.
I'm curious though . . . if polymorphic objects are very seldom (or
never) kept in containers, then why was there so much talk about
trivial location for polymorphic types (i.e. the need for
'restart_lifetime' to re-sign the vptr)?
I still think it's a defect though that "is_trivially_constructible_v"
evaluates to false for all final classes.
>
> In the Chromium codebase, inside "pc/video_rtp_receiver.cc", there is
> a member function that returns a vector by value:
>
> std::vector<scoped_refptr<MediaStreamInterface>>
> VideoRtpReceiver::streams() const;
>
> The "scoped_refptr" class is polymorphic.
I just looked at the code on Google Source and it turns out the
destructor isn't virtual after all -- i.e. it's not polymorphic.
I'll keep searching.
I'm curious though . . . if polymorphic objects are very seldom (or
never) kept in containers, then why was there so much talk about
trivial location for polymorphic types (i.e. the need for
'restart_lifetime' to re-sign the vptr)?
I still think it's a defect though that "is_trivially_constructible_v"
evaluates to false for all final classes.
Received on 2026-01-26 10:55:07
