From: "Kenneth Porter" <shiva@well.com>
To: "c++-embedded@cygnus.com" <c++-embedded@cygnus.com>
Subject: Re: biggest deterrant to using C++?
Date: Mon, 24 Aug 1998 18:39:00 -0000 [thread overview]
Message-ID: <199808250049.UAA22357@mail1.ispnews.com> (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) {};
public:
static void InitThings(); // calls special ctor
virtual bool get();
};
static const Thing::ThingROMData thing1data = { 100 }; // this gets
ROM'd
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
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com
next 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199808250049.UAA22357@mail1.ispnews.com \
--to=shiva@well.com \
--cc=c++-embedded@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).