5 ms·
With regards to the const part of the discussion - Does anyone knows any research or even a state of affairs of const inference in language design? The idea i
by jhg 16y ago
With regards to the const part of the discussion -
Does anyone knows any research or even a state of affairs of const inference in language design?
The idea is similar to type inference whereby a compiler (or some other tool in a chain) would take care of understanding which arguments/variables/functions are going to be const and generate appropriate warnings based on that. For example,
void foo(int * a) { (*a)++; }
void bar(int * b) { foo(b); }
void baz(const int * c) { bar(c); }
A compiler would generate a warning when baz function, because foo() includes a non-const operation on its argument, bar() is non-const for the same reason, and so it cannot be called for a const pointer.
- jpr 16y agoI'm not sure what you mean, since current compilers already warn if you write that code.
- jhg 16y agoHmm, OK. Try a different example - the compiler should allow the following code without any warnings: void foo(int * a) { } void bar(int * b) { foo(b); } void baz(const int * c) { bar(c); } Point being is that the compiler should warn of the const violation based on whether a function argument or a class member is getting touched in the function code. In fact, the example above is more relevant, because what I am ultimately aiming for is to not need to make member functions const, and yet be able to call them for const class instances.