public inbox for
 help / color / mirror / Atom feed
From: "Michael Bruck" <>
To: <>
Subject: Re: biggest deterrant to using C++?
Date: Tue, 25 Aug 1998 11:57:00 -0000	[thread overview]
Message-ID: <01bdd059$ac5a2ea0$> (raw)

>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 thinks it's not a question of the compiler. If you depend on the
cleverness of the compiler to control the position of your data
you would be unable to use this at all because:
    a)  you don't know what the compiler on the other platform
    where you want to use your library too thinks about this,
    b) it's difficult to debug if you have to compile everything
    with -O100
    c) I don't like this solution :)

It would by better to be able to tell the compiler explitly what you want.
It's not that this is a problem to implement in the compiler. F.e. in the
following example I can't see any reason why the code should not work
except that the standard defines the second line as invalid:

struct { int a; } p = {1};
struct { int b; virtual f(); } q = {2};

If you think the {} syntax may be inappropriate for C++ and you would like
the constructor syntax, then you could tell the compiler via e special
that the compiler is trivial in the sense that it yields only expressions
that can
be evaluted at compile-time.

The question is whether the problem is worth to change the language or to
implement a nonstandard keyword.

>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

You waste the space for the pointer (Thing::data). This is ok 
if you have big classes (many values). But if you have two or
three bytes per class this is unacceptable. It also doesn't
make your programs easier to read (ok, with a 40KB 
macro-header :)

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

Regarding templates I came to the same conclusion.


             reply	other threads:[~1998-08-25 11:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-25 11:57 Michael Bruck [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-24 18:39 Kenneth Porter
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 \
    --in-reply-to='01bdd059$ac5a2ea0$' \ \ \

* 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).