public inbox for
 help / color / mirror / Atom feed
From: "Kenneth Porter" <>
To: "" <>
Subject: Re: biggest deterrant to using C++?
Date: Mon, 24 Aug 1998 18:39:00 -0000	[thread overview]
Message-ID: <> (raw)

On Mon, 24 Aug 1998 03:37:50 +0200, Michael Bruck wrote:

>const    atom_bomb    my_bomb(50, 100);
>I would like to have my_bomb somewhere in the ROM. And the example above
>should not generate any code as long as I don't call the constructors in 
>another context. What happens is, that the compiler always generates 
>a function for each source file that calls all the constructors and 
>then generates a section that contains the pointer to that function.
>These sections from all files are then linked together into a table of
>function pointers and the init-functions of all global objects are 
>called at program startup through this table. This is ok if my 
>constructors are doing something other than just copying around values.
>This would cause in most situations just some overhead, 
>but if you want to use ROM it's impossible to use (virtual) classes.

I doubt we'll see compilers soon that are clever enough to statically
init an object with a vpointer and only scalar initializers in the
ctor. 'Twould be nice, though!

I recall looking up this question a few weeks ago (can't remember
where) and I recall reading that the proper way to do this was to put
things with static data in ROM'd POD structs and including an instance
or reference to the struct in a small RAM-based class object. To hide
the POD internal structure, declare it within the class:

class Thing {
    struct ThingROMData {
        const int weight;
    const ThingROMData& data;
    Thing(const ThingROMData& _data) : data(_data) {};
    static void InitThings(); // calls special ctor
    virtual bool get();

static const Thing::ThingROMData thing1data = { 100 }; // this gets

The actual machinery of Thing initialization will be
application-specific, but this gives the basic idea of how to structure
the ROM part of the data.

In your example, since you want to parameterize the ctor, I'd suggest
using a macro to perform the parameterization (since macros are
expanded at compile time). I was going to suggest a template, but I
can't see how to use a template to instantiate a class instead of
creating a new type.

Kenneth Porter
Systems Engineer
Kensington Laboratories, Inc.
750 National Court
Richmond, CA 94804-2008
Voice: 510-620-0235
FAX: 510-233-5544

             reply	other threads:[~1998-08-24 18:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-24 18:39 Kenneth Porter [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-08-26 10:38 Michael Bruck
1998-08-25 18:04 Kenneth Porter
1998-08-25 11:57 Michael Bruck
1998-08-23 18:37 Michael Bruck
1998-08-17 16:43 Kenneth Porter
1998-08-14 16:04 Kenneth Porter
1998-08-14 10:18 Saffi Hartal
1998-08-12 10:44 Brendan Kehoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).