"Srini" <sr*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Hi David,
Thanks for your reply.
I see what you're doing in your example. My reasoning for taking the
address of the
inline member functions, as a workaround was this. Something similar to
const variables.
const vars are never allocated on the stack. Instead they are held in
the compiler symbol
table.
I believe that the compiler can implement const values however it likes.
Obviously, it makes sense for the compiler to generate code with these
values embedded in code as hard-wired constants if that is the most
efficient implementation on a given processor.
Unless we try to take its address.
Taking the address would not necessarily make any difference except where
the address is used.
Even then, the compiler would
guarantee that
the variable remains constant if we never make use of the pointer.
const int a = 100;
int *ptr = const_cast<int *>(&a);
If we never use "ptr", the compiler would still guarantee that
something like this
is flagged as an error.
Well, if you do try to modify 'a' through your pointer it is undefined
behaviour.
a = 200; // sorry mate - can't do that!
Of course. The constness of 'a' is unrelated to its address being taken
somewhere. Your pointer 'ptr' merely forces the compiler to provide an
addressable instance of 'a' somewhere. It doesn't mean that all uses of 'a'
will be forced to fetch that addressable value from memory.
In the same lines, inlines are also held in the compiler symbol table.
If I take the
address of that function, the compiler would put it in object file.
But, as in case of
const vars, would the compiler inline the calls to that function?
I know that const and inline are two entirely different concepts - this
was just my thought.
Can you please comment on this?
As I said, if you get linker errors on inline functions it means that the
compiler saw the declarations but not the definitions. I've no doubt that
the functions would not be inlined if you make the errors go away by taking
the address. I also suggest that taking the address would not necessarily
make the linker errors go away, even if they went away in your case. I'm not
sure that just because you've taken the address is it guaranteed that the
function provided for the address-of operation will be recognized by the
linker as the function to call for the inline calls for which the compiler
could not find the definitions.
BTW, I don't agree that it is better programming practice to separate
declarations and definitions than to keep them together. I would think that
most programmers keep inline declarations and definitions in the same header
file, and I don't see a problem with that. Do you?
DW
