Re: CRT, Member Initialisation, static data, constant data, global objects

From: Thomas Matthews (Thomas_MatthewsSpitsOnSpamBots_at_sbcglobal.net)
Date: 12/15/03 

Date: Mon, 15 Dec 2003 16:28:05 GMT

Tim wrote:

> Please advise if you can.
>
> Presumably initialisation of members in member initialisation lists is
> perfomed by 'C' run-time startup. If the CRT was never started-up would
> those members be garbage?
Depends on the hardware. Some memory initializes itself to zeros, some
to all ones. But then if the memory was used before this program was
executed, yes, there would be garbage (unknown, random values).

> Which of these fundamental language support
> features could I expect to be absent (and anything else I might have
> missed):
>
> static data zeroing
> global data zeroing
>
> static data initialisation
> constant data initialisation
> global data initialisation
> scoped satic data initialisation
>
> static object construction
> global object construction
> scoped object construction
>
> initialisation of members in member lists
All of the above would not happen if the C++ Run-Time Library
was not invoked (CRTL or CRT). The above takes executable code
to perform. Somehow, the variables must be initialized.

>
> new
> delete
As for these, depends on the implementation.

> I'm having to fix an embedded PowerPC-based platform that I never worked on
> and which has many thousands of lines of lamentable source; the only
> function it calls from the assembly startup code is Init_CPP_Constructors
> which, in-turn, calls each constructor in an array of constructors in a
> 'ctors' segment. I see no other CRT startup calls; in fact, I don't even
> think this is CRT code; I think it's simply a hand-made 'bare-bones'
> startup.
Sounds more like a hook that a compiler manuf. provides for more
flexibility. Sounds familiar, perhaps Metware High C/C++ compiler?
You may also want to post to news:comp.arch.embedded.

> If so, would I be correct in assuming that a hefty chunk of support
> features will be absent?
Read your compiler documentation. You haven't specified which compiler
you are using.

> The firmware actually uses enums, not constant data
> and only has a few static variables and global data. It also has one class
> with members initialised in the list; the rest have members initialised in
> the constructors. My assumption is that there are quite a few oppertunuties
> for disaster here; would you agree?
Can't agree or disagree since you haven't posted the code.

> If anyone's wondering why I don't simply have a look using a debugger...
> there isn't one... nor any trace port; I't a question of downloading to
> flash and using a red LED or a green LED for diagnostic 'messages'. However,
> I've just got home so even that isn't an option right now. Your help will be
> greatly appreciated; your sympathy more than welcome :-)
If you don't have a debugger, you should have an emulator. Writing code
then "plugging it in" to see if it works is not the best or optimimum
process for developing quality code.

Search the web for:
   In-Circuit Emulator (ICE)
   Emulator (followed by your processor)

>
> Regards
>
>
> Tim
>
>

At my company, the hardware folk have designed a development board
that contains all of the components for the production version, but
also a JTAG port for a debugger and test-point pins. When the code
is working using this board, they place the code into a production
version. The production version has no method for debugging the
code. 

-- 
Thomas Matthews
C++ newsgroup welcome message:
          http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq:   http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
          http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
     http://www.josuttis.com  -- C++ STL Library book

Relevant Pages