Re: passing ref to ptr again as ref to ptr....
On Apr 28, 11:12 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
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 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.
I'm sure I'm not. The issue has been discussed before.
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.
This is true for objects of different types as well, as long as
they are complete objects (e.g. not base classes or members of a
class or union). Except, of course, objects with different
complete types must be different objects.
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.
You need some casting, yes. In the case of objects, you don't,
because pointers to objects convert implicitly to void*. In the
case of pointers to function and all pointers to members, you
need some casting. But the guarantees still hold.
About the only case this might be useful in practice, I think,
is in some very advanced forms of template metaprogramming,
where you don't know the types to begin with (except that they
are e.g. pointers to a member function). And even then, I'm not
sure that it would be that useful. But the standard explicitly
guarantees it.
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.
You're right about that. The first depends on "weak
references"; the linker ignores any weak references if the
extern has already been resolved. Even if the functions aren't
identical. (That could be a result of undefined behavior, but
it could also be because you compiled some of the instances with
optimization, and others without.)
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.
Yes. It's also possible to arrange things so that the addresses
are different (e.g. by inserting more or less no-ops before the
function). But I've never seen a compiler which did this, and
given the size of memory today, I doubt that it's an
optimization with a particularly high priority. (It also has
the problem that it involves the linker, which means that there
can be political problems involved in implementing it.)
In the end, of course, the reason you factor out the common
behavior today is generally because you don't want complex code
to be generic (more difficult to debug and maintain), and you
definitely don't want it in a header (and most compilers still
don't implement export).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34