A loop-hole with constant references
I am trying to design my own programming language/compiler
similar to C/C++, but I need to know a good way to handle
constant references -- this has been really bugging me!
Given the following C++ code:
.------------------------------------------
|int blah;
|
|void modify() {
| blah = blah + 1;
|}
|
|void foo(const int& var) {
| int x = var;
| modify(); // Assume the compiler cannot see a conflict here
| int y = var;
|}
|
|int main() {
| blah = 1;
| foo(blah);
| return 1; // Because something is wrong here :P
|}
'---------------------------------------------------
..Do x and y end up with different values, or the same values?
Why or why not (what kind of internal mechanisms make this so)?
I can only think of two scenarios, and I do not know which is accurate:
The "const" modifier prevents "var" from being modified IN THE FOO FUNCTION (for all that the compiler can SEE), BUT...
1) Since "var" aliases to "blah" in this case, and blah is modified (externally), the modification shows through -- x and y get different values.
2) This is achieved by evaluating the value being referenced first and storing it internally (or remembered by the compiler for inline functions) so that, no matter what, any reference to "var" will pull up the original value passed in -- x and y get the same values.
I am looking at 2 things here: what does C++ do and how/why, and what possibly is a better alternative?
(Normally, how the compiler implements it is of no consequence if your code is sound; but when one is designing a compiler, the decision has to be made!)
similar to C/C++, but I need to know a good way to handle
constant references -- this has been really bugging me!
Given the following C++ code:
.------------------------------------------
|int blah;
|
|void modify() {
| blah = blah + 1;
|}
|
|void foo(const int& var) {
| int x = var;
| modify(); // Assume the compiler cannot see a conflict here
| int y = var;
|}
|
|int main() {
| blah = 1;
| foo(blah);
| return 1; // Because something is wrong here :P
|}
'---------------------------------------------------
..Do x and y end up with different values, or the same values?
Why or why not (what kind of internal mechanisms make this so)?
I can only think of two scenarios, and I do not know which is accurate:
The "const" modifier prevents "var" from being modified IN THE FOO FUNCTION (for all that the compiler can SEE), BUT...
1) Since "var" aliases to "blah" in this case, and blah is modified (externally), the modification shows through -- x and y get different values.
2) This is achieved by evaluating the value being referenced first and storing it internally (or remembered by the compiler for inline functions) so that, no matter what, any reference to "var" will pull up the original value passed in -- x and y get the same values.
I am looking at 2 things here: what does C++ do and how/why, and what possibly is a better alternative?
(Normally, how the compiler implements it is of no consequence if your code is sound; but when one is designing a compiler, the decision has to be made!)
I would bet that x and y end up with different values because of the way C++ evaluates functions and their returns. In addition, because that function has no return there is no way to tell from prototypes alone whether or not the function would compile. (Since the code should be workable with only prototypes visible in the beginning)
My suggestion would be to test it. Tests always show you something useful.
By the way, you look like you wasted precious time on the ASCII formatting, use code tags next time and save yourself the trouble.
My suggestion would be to test it. Tests always show you something useful.
By the way, you look like you wasted precious time on the ASCII formatting, use code tags next time and save yourself the trouble.
| shkaboinka wrote: |
|---|
| ..Do x and y end up with different values, or the same values? Why or why not (what kind of internal mechanisms make this so) |
They do end up with different values, and this is the result I expected. If they don't end up with different values, then the compiler should have shown an error at compile time because you are trying to modify a const reference. But I don't see any possible solution for a compiler to find out such assignments. The only thing which would annoy me, if it would work the other way around (still think it's impossible to implement).
| tummychow wrote: |
|---|
| In addition, because that function has no return there is no way to tell from prototypes alone whether or not the function would compile. (Since the code should be workable with only prototypes visible in the beginning) |
?
I think your question is related to this one: http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.15
Sorry, R0mai, let me clarify.
Let's say that he prototyped modify, then defined foo, called modify in his main and then only thereafter defined modify. The compiler would assume that the call was legal because, with the prototype only (and not the definition) being visible in the compilation of foo, it would have no way to determine whether or not the values in modify were being changed. Therefore, since it could not draw such a distinction, I would place doubts that foo would illegalize the call.
constexpr keyword in C++0x ftw.
Let's say that he prototyped modify, then defined foo, called modify in his main and then only thereafter defined modify. The compiler would assume that the call was legal because, with the prototype only (and not the definition) being visible in the compilation of foo, it would have no way to determine whether or not the values in modify were being changed. Therefore, since it could not draw such a distinction, I would place doubts that foo would illegalize the call.
constexpr keyword in C++0x ftw.
@tummychow Either way if the compiler sees a defined function body, it generates the appropriate code for the body (it can do it since every type is exactly known), then it only thinks about generating the calling code when it sees a call to the function. It doesn't second check the function body, it doesn't need to.
Anyway, changing the current behavior wouldn't make sense in my opinion.
Anyway, changing the current behavior wouldn't make sense in my opinion.
The above observed behavior, BTW, is mandated by the standard.
This is a question of sequence points. The question is: can the compiler invert the
order of these two lines of code:
The answer is no, because there is a sequence point between the two lines.
Ok, it's Wikipedia, but here's a link:
http://en.wikipedia.org/wiki/Sequence_point
This is a question of sequence points. The question is: can the compiler invert the
order of these two lines of code:
|
|
The answer is no, because there is a sequence point between the two lines.
Ok, it's Wikipedia, but here's a link:
http://en.wikipedia.org/wiki/Sequence_point
Topic archived. No new replies allowed.