-- 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

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

Ganesh

  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

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

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

  // Virtual dispatch needs to work, no matter what bits are in foo.
  x.bar();