Does the non-static data member need to be constexpr if it is virtual? Why?
-- Gaby
--
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
I would say it needs to be constexpr or static – at least for it to be stored in the vtable.
(ie assuming the vtable is shared by all instances of the class means that the value is shared by all instances of the class)
I would say it needs to be constexpr or static – at least for it to be stored in the vtable.
(ie assuming the vtable is shared by all instances of the class means that the value is shared by all instances of the class)
If it is going in the vtable, why is it a *non-static* data member?
-- Gaby
--
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
See
If the link doesn't work search for "virtual data members" in future proposals.
Cassio.
On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wrote:
> If it is going in the vtable, why is it a *non-static* data member?
It should be static.
This will be the first time we have a "virtual static" though.
Immutable isn’t the same as ‘constexpr’ though. You want immutable and statically initialized, and not a non-static data member – data that are shared across objects are “static”.
If I understand correctly, that would be the proper use of “static”: there is only one copy in the program.
-- Gaby
On 2015–03–19, at 5:43 AM, Bjarne Stroustrup <bja...@stroustrup.com> wrote:(3) what's the important use case?
On 2015–03–19, at 6:20 AM, Zhihao Yuan <z...@miator.net> wrote:If it's static, it doesn't need to be virtual; if it's virtual, it
doesn't need to be static.
On 2015–03–19, at 4:25 AM, 'Botond Ballo' wrote:
Has this, or something similar, ever been proposed? Is there any interest in it?
On 2015–03–19, at 5:53 AM, Brian Bi <bbi...@gmail.com> wrote:operator new and operator delete are already implicitly virtual and static, aren't they?
This is a whole lot of complexity just to do cheaper RTTI.
On 2015–03–19, at 9:30 AM, Nicol Bolas <jmck...@gmail.com> wrote:Setting aside the bikeshed issue of what words to use to declare it,we first need to define what exactly it is. It's also important to remember that "vtables" don't exist. They're an implementation detail; no compiler is required to use them to make virtual functions/derived classes work.
So, you seem to be talking about an object who's storage is directly associated to a type. But, unlike static data members, every type derived from it will have separate storage. So "static" is the wrong word.
While the object value is associated with the type, you want to access them as though they were a member of an instance of that type. And more to the point, you want the value returned to be the value fetched from the object associated with the object's dynamic type. Since a dynamic type is by definition a runtime fetch, it is certainly not "constexpr”.
Each class needs to initialize this value with its own parameters. But this doesn't happen at construction time; it happens somewhere else. Possibly before the execution of main(). Which means that it's like a static in terms of initialization and destruction.
I don't know. This is a whole lot of complexity just to do cheaper RTTI. Wouldn't it make more sense to just add cheaper RTTI to C++?
On 2015–03–19, at 12:55 PM, Thiago Macieira <thi...@macieira.org> wrote:That's where the constexpr keyword comes into play: you should be able to
store anything that is a literal type.
std::string is not a literal type.
using Protocol = /* whatever */;
class Handler {
public:
virtual constexpr Protocol low; // see note (1)
virtual constexpr Protocol high; // see note (1)
virtual void handle(Protocol protocol, Payload payload) = 0;
// …
};
class Dispatcher {
public:
void register(Handler *handler);
void deregister(Handler *handler);
// …
};
struct Shoe : Merchandise {
constexpr int price() override final { return 10;
}
enum class Type : int
{
SHOE,
};
struct Merchandise
{
virtual Type GetType() const = 0;
};
struct Shoe : public Merchandise
{
static virtual Type GetType() const override { return Type::SHOE; }
};
Type type1 = Shoe().GetType();
Type type2 = Shoe::GetType();
assert(type1 == type2);
The real reason I put that restriction in there in the first place was because people were still not comfortable with the idea that a compiler could run a function at compile-time. So, we wanted to make it as simple and as concrete as possible – just to deal with the various FUD being thrown around 10 years ago.
The simplest (and correct, IMO) fix is to remove that restriction. We already require compilers to track object’s dynamic type when doing constexpr evaluation. Please, don’t replace that restriction with another restriction. We’ve learned the value of constexpr for the last 10 years and we are now all conformable with the notion.
I am not expressing opinion about the ‘virtual fields’ themselves (which I must have heard of for the umpteenth time now, since at least 1995.)
-- Gaby
--
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
On 2016–02–19, at 6:45 AM, wkaras via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:Is it a viable alternative to just drop the rule that constexpr functions cannot be virtual, and add a rule that constexpr virtual functions cannot have parameters? This would permit the compiler to store a constant in the vtable rather than a function address. Would this cause too many corner cases for member function pointers?
(1) yes it should be immutable
(2) I described something like that in D&E (and maybe even in the ARM)
(3) what's the important use case?
On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvan...@blackberry.com> wrote:
I would say it needs to be constexpr or static – at least for it to be stored in the vtable.
(ie assuming the vtable is shared by all instances of the class means that the value is shared by all instances of the class)
Yes, exactly. Note that from a pragmatic standpoint, it's probably important for compilers to be able to store the vtable in read-only memory in order to protect against security attacks attempting to overwrite vtable entries at runtime.
From: Gabriel Dos Reis [mailto:g...@microsoft.com]
Sent: Wednesday, March 18, 2015 4:42 PM
To: 'std-pr...@isocpp.org'; C++std-ext; eh...@mozilla.com
Subject: [c++std-ext-16622] Re: [std-proposals] virtual constexpr fields
Does the non-static data member need to be constexpr if it is virtual? Why?
-- Gaby
From: 'Botond Ballo' via ISO C++ Standard - Future Proposals [mailto:std...@isocpp.org]
Sent: Wednesday, March 18, 2015 1:26 PM
To: C++std-ext; eh...@mozilla.com; ...@isocpp.org
Subject: [std-proposals] virtual constexpr fields
There are cases where you would like to associate constants with a given type. Here is how you can currently do it in C++:
struct Merchandise {
virtual int price() { return 0; }
};
struct Shoe : Merchandise {
virtual int price() { return 10;
}
If you could do it this way instead:
struct Merchandise {
virtual constexpr int price = 0;
};
struct Shoe : Merchandise {
virtual constexpr int price = 10;
}
then the compiler could store the constant value directly in the vtable. This would eliminate the double indirection involved in dereferencing a function vtable entry, the cost of running that function at runtime, and the code size of the function in the compiled binary.
Virtual fields would be limited to being constexpr, so that the value to be placed in the vtable, like other values in the vtable, can be determined at compile time.
Has this, or something similar, ever been proposed? Is there any interest in it?
-- Botond and Ehsan
--
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
I know this is an old thread, but I've got one use case.
Thiago, what I meant to say is that I am accepting command line input from a user and I can't use that to instantiate a template.
Thiago, what I meant to say is that I am accepting command line input from a user and I can't use that to instantiate a template.
class MyClass
{
public:
void Calculate(std::size_t orderOfMethod, otherParams)
{
switch(orderOfMethod)
{
case 0:
Calculate<0>(otherParams);
break;
case 1:
Calculate<1>(otherParams);
break;
...
}
template<std::size_t N>
void Calculate(otherParams)
{
double array1[N+1];
double array2[someConstexprFunction(N)];
//do stuff with arrays
}
};
This is not unreasonable because there are currently only 6 cases and it is unlikely that any others will be added.