Re: vtable pointers and default copy constructors..
* Martijn van Buul:
I'm having a peculiar problem at work. I've been googling for it, but haven't
found an authorative answer. In a nutshell (Long story follows),
what I'd like to know is:
If I have a C++ class which has several virtual functions and several
member variables, will the default copy constructor also copy the virtual
table pointer, or will it merely do a (shallow) copy of the member variables?
Compiler-specific.
I'm using gcc 4.1.1
Check that compiler's implementation if you want to bind yourself to
that particular version of that particular compiler.
(long version)
I work in the machine vision industry. Our systems consist of PC-style
computers, running a small proprietary RT os offering only the most basic
functionality. Most importantly, it's not really multi- processor, -core or
-threading aware, and support for this technology has been shoe-horned in by
running a second instance of the OS on the second core/cpu. Image capturing and
other IO is done on the first CPU, the actual processing is done round-robin on
what CPU time is still remaining on CPU#1 and on CPU#2. The problem originates
from the fact that communication between CPU #1 and #2 isn't clean, and objects
get passed by reference instead of value. This was done because of efficiency
considerations. This means that objects can be created on CPU #1, but executed
on CPU#2. This works OK with "simple" classes using no virtual functions,
templates or whatsoever, but wreaks havoc with classes that do. The instant
CPU#2 hits a virtual function, it will resolve this function using the supplied
vtable, which will contain pointers to the codespace of CPU#1, since it was
instantiated on this context, resulting in an access exception. So far, the
guideline has been simple: "Don't use virtual functions in any object that can
migrate from one CPU to another", but I'm currently facing a problem which
would greatly benefit from having virtual functions - so I'm trying to work
around this restriction. I should point out that, since the real-time nature of
the machine, there is no garbage collection nor virtual memory - especially on
cpu #2 - so anything involving dynamic memory allocation is off.
One conclusion from the above is that the two processors in their
current configuration don't share code memory but do share at least some
data memory.
What you can do is to pass just data, C++ POD objects.
Or you can do other things which is impossible to say since you don't
describe the (limitations of) the system, but I don't think that belongs
in clc++.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?