Re: passing ref to ptr again as ref to ptr....
On 28 Apr., 20:22, "Bo Persson" <b...@gmb.dk> wrote:
peter koch wrote:
On 28 Apr., 10:40, James Kanze <james.ka...@gmail.com> wrote:
On Apr 26, 9:38 am, "Bo Persson" <b...@gmb.dk> wrote:
osama...@gmail.com wrote:
[...]
I am implementing a lockless queue, which I don't think
the std::queue<T*> provides.
You'd have to see the documentation for your implementation, but
by default, std::queue is lockless, since there are no locks (or
threads) in the standard. Most of the implementations I'm
familiar with do not use locks even in multithreaded
environments.
And it probably is the wrong level anyway.
[snip]
If the types are different, and the compiler is conform, he
probably will.
On the compiler I use, templates will most often share code for
objects of the same size, as the linker will merge identical code
blocks.
I certainly hope not. That wouldn't be conform. (I presume, of
course, that the compiler will only do so if the objects are
PODs as well. Otherwise, the code won't be identical.)
I believe you are wrong.
For example,
struct two
{
short x;
short y;
};
std::vector<int> v1;
std::vector<long> v2;
std::vector<two> v3;
will only generate one set of code in the resulting .exe file.
Despite the fact that the member functions of v1, v2 and v3 are
guaranteed to have different addresses?
None of the compilers I use do this (at least not to my
knowledge).
That must be because you do not use VC 8.0 (or 9.0). And I really do
not see any reason to disallow std::vector<int>:push_back to have an
adress that equals e.g. std::vector<unsigned>:push_back. How are you
going to detect that in the first place?
Like James says, he can take the address of the functions and compare.
Different objects must have different addresses, including functions.
But you compare two different types. I do know that for two objects of
the same type, if their adress compares equal, the adresses must refer
to the same object. But thus is not the same situation: you can't
directly compare a void f(int) and a void f(long). Without really
knowing (and bothering!) the standard in this respect, I am quite
confident that to compare you do need some quite heavy casting.
The merging of the code is really designed to solve the problem of
having vector<int>::push_back instantiated in several different
translation units. The linker tries to fix this by only keeping one
copy of each identical code block. That this also merges code blocks
for different types of equal size, is by accident.
I believe you are wrong. This certainly is not by accident as there
are different mechanisms involved. To remove different occurences of
the same function, you typically mark the function as discardable:
when during linking, the second definition of the function shows up,
you discard the new function instead of giving an error-message.
For removing different functions that generate the same code, you
probably calculate the hash-value of the code. When you find two
functions with the same hash-value, you compare the individual
opcodes: if they are similar, one function is - as above discarded.
Notice that a true duplication of code (define a non-inline function
in a header and include that header in more then one compilation unit)
still gives linker-errors.
/Peter