>> In the modules that see the field as 'const', the compiler will feel free to load it into a register in any function that accesses it. >From your reply I did not quite understood the context whether you were referring to pointer(the struct member itself) being const or the pointer contents to be the const, as in my case(e.g. "const int * p;" vs "int * const p;"). The pointer(or struct member) is actually allowed to change in all files, while the contents of the pointer are const in the READONLY files. So I am thinking that the compiler should not cache any data it is pointing to? So, 1)Were you referring to the pointer or pointer contents being const? 2)I uploaded the code written in C++, but I would rather see a solution in C. So I guess that volatile is another option(of course if after all it is still necessary). Thank you, Ansis Dave Korn-6 wrote: > > > First point: the main gcc list is for discussions about programming the > internals of the compiler itself; discussions about how to /use/ the > compiler > should go to the gcc-help list, so I've redirected this reply. > > Secondly ... > > ansis atteka wrote: > >> I already have approach, but I am not quite sure whether it is >> safe(especially regarding the compiler optimizations). Below are uplaoded >> files. >> >> In this case util.cpp is not allowed to edit S.y contents, while rw.cpp >> is >> allowed to do that. File h.hpp contains the struct which is customized at >> the preprocessor execution time by looking at the READONLY define. > > > No, this is not safe. Trust me, I speak from experience, having made > and > had to debug the same mistake myself many years ago! In the modules that > see > the field as 'const', the compiler will feel free to load it into a > register > in any function that accesses it, and if the register is saved across > function > calls, it will feel free to save the value in that register across > function > calls and keep using it after the function call, safe in the knowledge > that > the value of the field in the actual struct in memory cannot have changed > because it is const. But if that function call is to a function in > another > module (which was compiled without the const) then that function call > could > change the field in the struct in memory, and the compiler would never > know > that the value it has cached in a register in the calling function is now > out > of date. > > Long story short: don't do it. Use C++ member visibility and make the > functions that want to access it members or friends, or some other robust > technique like that(*). > > cheers, > DaveK > -- > (*) - I have left this as a footnote because it should not be done, but > what I > did years ago was to hack my way around it by making the variable 'const > volatile'. This is an ugly and pessimal hack at best, and there's no need > to > resort to it in C++. The whole thing was in fact just a convenient step > in > refactoring a massive legacy application that had a whole bunch of globals > that I needed to get under control and make sure they were all only ever > changed through accessors, so that as a second step I could then add > getters > and hide all the global declarations away for good, removing the const > hack in > the process. > > > -- View this message in context: http://old.nabble.com/Re%3A-Making-a-struct-field-constant%2C-when-this-struct-is-imported--to-a--particular-Cpp-files-tp26326501p26335935.html Sent from the gcc - Help mailing list archive at Nabble.com.
