Will tis program work.............
Itried to compile it with g++ and it didn't work
Code:#include<iostream.h>
int main()
{
const int i = 10;
int &j = i;
cout<<"i = "<<i<<"j = "<<j;
j = 20;
cout<<"i = "<<i<<"j = "<<j;
return 0;
}
Printable View
Will tis program work.............
Itried to compile it with g++ and it didn't work
Code:#include<iostream.h>
int main()
{
const int i = 10;
int &j = i;
cout<<"i = "<<i<<"j = "<<j;
j = 20;
cout<<"i = "<<i<<"j = "<<j;
return 0;
}
so why do you want to modify the const?
What errors were you getting?
also, use <iostream>
Its in a book which says it will work and the out put is 10 10 10 20
The attempt to initialise an int& with a const int looks illegal to me. What book is that?Quote:
Its in a book which says it will work and the out put is 10 10 10 20
That is impossible. That would suggest that i and j occupy seperate memory space, which they do not because j is a reference to i. (an illegal one at the moment though, because j would have to be a reference to const int)Quote:
Originally Posted by kishore
This would be completely correct if the ampersand was removed.
This sounds akin to this:
http://www.daniweb.com/techtalkforum...059#post234059
1. They use cast removing const. In the example above there is no cast.Quote:
Originally Posted by Dave_Sinkula
2. The value after modification is the same - no matter how they retrieve it though the pointer or through the var itself. In the description abouve the value retrieved through the reference is different from the velue retrieved through the var itself.
Both these issues make me doubt that the example can be compiled and run with the described results
Isn't const more like a keyword that lets the compiler find errors such as this?
Code:const int a = 42;
int b = 100;
if (a = b)
Yes, const tells the compiler that the value returned will not be changed.
That's one of it's uses, anon.
In this case, the code started with a const int i (which the compiler must view as having a value that can't change), and attempted to create a non-const reference to it (which the compiler is required to reject because it would allow changing a value that can't change). Converting a constant into a non-constant is not something the compiler will allow voluntarily.
The example in the link given by Dave is a little different, as vart said. Apart from the minor fact it manipulated a pointer and dereferenced it (rather than playing with a reference), it used an explicit cast to bludgeon the compiler into submission -- so it forced the compiler to allow removal of the "const" qualifier.
If a book has claimed that the code quoted by kishore should print 10 10 10 20, then that book is badly broken. The code should not have even compiled. If a cast had been used to force the compiler into submission. For example;
it will technically yield undefined behaviour (which is why the conversion was disallowed in the first place, and the original code should not have compiled). However, if it was just to print 4 values, it would print 10 10 20 20.Code:#include <iostream>
int main()
{
const int i = 10;
int &j = (int &)i; // explicit conversion here
std::cout<<"i = "<<i<<"j = "<<j;
j = 20;
std::cout<<"i = "<<i<<"j = "<<j;
return 0;
}
Based on the syntax of the OP's code snippet, perhaps the idea of the writers was within the previous C++ standard before they were changed. I do know one of the standard changes was to leave the trailing .h from all headers excluding windows.h. I do not know for sure that the const issue debated was a standard change. Perhaps somone can help clear this book error up.
The meaning of const, and its affect on references, was established quite well, early on. The meaning has not changed much since the ARM (Annotated Reference Manual) which was the book written by Stroustrup and Eliis to guide the (then) proposed development of the standard. About the only appreciable change I recall in the standardisation process was tightening up the requirement that a reference must be initialised so it was a reference to something.
The naming of standard headers without the .h came fairly late (about 95), but only affected those headers which were specifically part of the C++ standard. It did not affect the headers inherited from C (stdio.h, etc), but usage of those was deprecated in the C++ standard. It had no effect on proprietary headers such as windows.h.
My bet would be that the book being used by kishore was one who's author did not understand what references were about -- in particular that, unlike pointers, they cannot be reseated. In the early 90's there were a number of texts that demonstrated that sort of misunderstanding by their authors.
I threw away that book today.........
it was named "Let Us C++" by Yeshwank Kanitkar
the guy who wrote "Let Us C"
this guy uses TurboC++ and BorlandC++
he is a well known writer of books on C & C++ in INDIA
thank you guys for your valuable comments and suggestions......
This outputs what your book said (maybe it was in your book because the author wanted to show that even this doesn't work for const variables):
I am not sure if there's a good and easy way to ACTUALLY change the const value...Code:#include <iostream>
int main(){
const int i = 10;
int *j = (int*)&i;
std::cout<<"i = "<<i<<"j = "<<*j;
*j = 20;
std::cout<<"i = "<<i<<"j = "<<*j;
std::cin.get();
return 0;
}
When it turns out I'd need to do that, I would delete the const keyword from the declaration...Quote:
I am not sure if there's a good and easy way to ACTUALLY change the const value...
You put it there yourself to help compiler find errors in the code, so why would you want to bypass it?
It works on TurboC++ 3.0
which uses a temprory variable if the types of the variable and its reference don't match...........
.....and is practically guaranteed to allow subtle bugs in the program!?Quote:
Originally Posted by kishore
If you have a const, and you try to modify its reference, then you are making a logical error. It's a good thing compilers can catch this.
I use const references very often to pass large classes to functions that shouldn't modify them. If the compiler allowed me to modify the object, that would mean that the function could be seriously flawed without anybody noticing it.
that's actually undefined behaviour according to the standard
this means that while it might work on your particular compiler, another compiler is free to put const values into rom and crash horribly when you try to write to it. Actually undefined means it can actually do anything! (sending porn to your boss, deleting your hard disk, these are perfectly acceptable in the eyes of the standard! :D )Quote:
Originally Posted by section 7.1.5.1
bottom line: don't use const_cast to modify a const pointer or reference unless you're damn sure that whatever it points to isn't const!