 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Frank-René Schäfer
Guest
|
 Posted: Sat Sep 24, 2005 4:20 am Post subject: tweaking the virtual function table pointer |
 |
|
Case:
-- class X has occupies tiny amount of memory:
sizeof(X) is only a little greater than sizeof(void*).
-- X instantiates thousands of objects and memory does matter.
-- The class has a virtual destructor, and therefore, a pointer
to a virtual function table.
-- This class, now, needs a boolean variable 'boolF' which would
cost at the very least 1 byte, which is a lot under the
circumstances described above.
--> idea: (1) copy the virtual function table at another place.
(2) let the virtual function pointer point to either
one of the virtual function tables (which are
identical), but:
The place where the pointer points to indicates the
state of the 'implicitly represented' variable
'boolF'.
Such a setup is profitable, if
N * sizeof(bool) > sizeof(virtual function table),
where N = estimated number of instantiated objects.
Does the standard impose the management of virtual function tables
strictly enough to elaborate on such a solution? Is such a
solution practical?
Thanks
Frank
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Bart van Ingen Schenau
Guest
|
| Posted: Sat Sep 24, 2005 4:28 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
Frank-René Schäfer wrote:
<snip - scheme to use multiple instances of a v-table to represent the
state of some data member>
| Quote: | Does the standard impose the management of virtual function tables
strictly enough to elaborate on such a solution?
|
The standard does not mandate the use of virtual function tables at all.
The standard only says that such-and-such construct must behaver in a
particular way. It is up to the compiler writers to figure out how they
can achieve the required behaviour.
It just so happens that v-tables are a straightforward way of
implementing the mechanics of virtual functions, but I don't think it
is the only way.
| Quote: | Is such a solution practical?
|
I don't think so. Your solution does not scale to multiple members that
can be encoded with this technique. Think about the number of v-tables
needed for 3 or 4 boolean fields.
And your solution applies only to a very specialised field, so compiler
writers will most likely ignore this kind of optimisation as long as
there are other optimisations possible that are more generally
applicable.
| Quote: |
Thanks
Frank
Bart v Ingen Schenau |
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Sat Sep 24, 2005 4:28 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
"Frank-René Schäfer" <frank_r_schaefer (AT) gmx (DOT) net> writes:
| Quote: | Does the standard impose the management of virtual function tables
strictly enough to elaborate on such a solution?
|
The standard says nothing about vtbls. An implementation is not even
required to use them. What you propose would be a conforming
implementation.
| Quote: | Is such a solution practical?
|
:)
In the sense of "will I ever be able to get a compiler vendor to
implement this?" I would guess no, because demand probably isn't high
enough. However, you might try one of the vendors targeting embedded
systems, such as Metrowerks.
Good Luck!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Sat Sep 24, 2005 4:31 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
Frank-René Schäfer wrote:
| Quote: |
Does the standard impose the management of virtual function tables
strictly enough to elaborate on such a solution? Is such a
solution practical?
|
AFAIK, the standard introduces the notion of virtual function but it
doesn't specify how the desired effect needs to be implemented. In
particular, it doesn't even say that it must be implemented using
virtual tables, even if that's the most obvious approach. Therefore, I
believe the answer to both your questions is no.
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
richard@ex-parrot.com
Guest
|
| Posted: Tue Sep 27, 2005 4:18 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
Frank-René Schäfer wrote:
[snip ingenious scheme to represent data with vptrs]
| Quote: | Is such a solution practical?
|
Let's look at this piece of code:
struct X {
virtual ~X() {}
bool b;
};
void fn(bool volatile&);
int main() {
X x;
fn(x.b);
}
How does the compiler get a reference to X::b? Presumably it'll have
to construct a temporary, something like this:
int main() {
X x;
bool tmp(x.b); fn(tmp); x.b = tmp;
}
What if fn() throws an exception? We still need to set x.b, so:
int main() {
X x;
bool tmp(x.b);
try { fn(tmp); } catch(...) { x.b = tmp; throw; }
x.b = tmp;
}
What about in multithreaded code? It should be possible to guarantee
that X::b has been set by a given point in fn(). (Depending on what
the platform guarantees about threading, this may require some form of
locking primitive.) How should the compiler cope with this
possibility?
--
Richard Smith
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Tony Delroy
Guest
|
| Posted: Tue Sep 27, 2005 4:22 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
Hi Frank,
I've found it useful in the past to avoid directly giving objects
runtime polymorphic behaviour (to save memory, due to shared memory
usage, concurrent access & packing), preferring to have a polymorphic
pointer-to-object class. If you do this, your thousands of objects
don't need virtual dispatch pointers, and yet you get the convenience
of run-time polymorphic handling. You use a simple factory method
(your classes can embed a type code much smaller than a void*) -
possibly returning a derived type cloned from a reference object (as
per the flyweight pattern).
Cheers,
Tony
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
wade@stoner.com
Guest
|
| Posted: Tue Sep 27, 2005 9:35 pm Post subject: Re: tweaking the virtual function table pointer |
|
|
Frank-René Schäfer wrote:
| Quote: | Such a setup is profitable, if
N * sizeof(bool) > sizeof(virtual function table),
where N = estimated number of instantiated objects.
|
This relation is only correct in the case that no other classes are
actually derived from X. Otherwise you've got to double all of the
derived classes' vtables also (or thunk accesses to the bool, so that
base class and derived class can use different implementations).
The implementation would also have to worry about the case where the
bool bits were set to an indeterminate value:
class X
{
bool foo;
virtual int bar(); // bar may not read-access foo
};
void foobar(X& x)
{
memset(&x.foo, rand(), sizeof(x.foo));
// Virtual dispatch needs to work, no matter what bits are in foo.
x.bar();
}
There are better space optimizations available. If the implementation
is able to determine (smart linker, build option, ...) that only a
small number of derived classes exist, it can save more space by using
a smaller vtable 'pointer'. For example if fewer than 255 concrete
classes are derived from X, the vtable pointer could be replaced by a
one-byte index into an array of vtable pointers. If no classes are
derived from X, then the vtable pointer may be implicit, requiring no
per-instance space at all.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
