public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
From: "Michael Bruck" <mbruck@rft.de>
To: <c++-embedded@cygnus.com>
Subject: Re: biggest deterrant to using C++?
Date: Wed, 26 Aug 1998 10:38:00 -0000	[thread overview]
Message-ID: <01bdd116$be971520$0b1cafc1@gretel.ins-coin.de> (raw)

>On Tue, 25 Aug 1998 20:53:39 +0200, Michael Bruck wrote:
>
>>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 :)
>
>Small classes with virtual methods just don't ROM effectively. Related

Hey, that's not a solution! The point is that they don't ROM effectivly
because the language designers didn't care about systems with
limited resources. (do I need to explain this more detailed ?) And
there are ways to easily change this.

>question: Do compilers put the vtable in the text segment so that it
>can be ROM'd?

g++ puts them into .rodata. I think that's something that every compiler
is able to do without any extra logic. But the probability that compiler XY
puts vtables into .text/.rodata is the same as for global consts.

>
>The case where I was asking the question involved a big command table
>with fixed-size string buffers for each command and a series of flag
>bytes. I currently build this in assembler and use a C routine to scan
>the tables. Assembler is used because the tables have 26 internal
>labels to allow quick jumping to command entries starting with a
>specific character. (I inherited this design. In retrospect I could use
>26 independent tables or use binary search, since the entries are of
>fixed size.) Obviously this is the kind of bulky data that could
>benefit from the architecture I described.
>

Usually one decides to use C++ to make development easier (f.e. using the
STL).
But I don't know how to make my libraries more portable, the sources more
readable and reduce the bugs when I use 50 lines of code just to wrap a
struct that should go into ROM.

In the case that you described above I can't see how you could use the new
concepts that C++ offers. (classes, inheritance ... maybe some STL
algorithms)
In my case I wanted to make use of them and it's impossible because of some
unimportant details.


Micha





             reply	other threads:[~1998-08-26 10:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-26 10:38 Michael Bruck [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-08-25 18:04 Kenneth Porter
1998-08-25 11:57 Michael Bruck
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:
  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='01bdd116$be971520$0b1cafc1@gretel.ins-coin.de' \
    --to=mbruck@rft.de \
    --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).