C++ Logo


Advanced search

Subject: [std-proposals] Deprecating volatile polymorphic class types
From: language.lawyer_at_[hidden]
Date: 2020-01-09 00:47:02

(Didn't risk to send this directly to Core/Ext...)

I find it weird that storage of objects of volatile polymorphic class types can be touched when a virtual function is invoked, which happens in all "typical" implementations which use vtables and vptrs stored in objects to implement polymorphic behavior.

Yes, I understand that it could be said something like:
http://eel.is/c++draft/defns.access is only applicable to scalar objects. No scalar object is associated with vptr (or padding bytes). Thus, when vptr (or padding) is touched by an implementation, this is not violation of http://eel.is/c++draft/intro.abstract#6.1. (Volatile) Scalar objects denoted by volatile glvalues shall be touched when and only when an access through volatile glvalue would have happened in abstract machine. But storage not associated with a scalar object? It can be touched at any time! This is not considered access. There are not restrictions on such "touches".

This is a valid argument, however, the fact that the storage of a volatile-qualified object can be arbitrarily touched is somehow counter-intuitive.

What if we just deprecate volatile-qualified polymorphic class types (as well as [[pointers|references] to|arrays of] them)?

STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups