Re: nonstandard extensions

["Michael Bruck" <mbruck at gmx dot net>]

The reason I suggested the {} initialization was, that this could
have been adopted by every compiler without extra optimization 
magic and would be a good approach if you want to make 
some kind of standard out of it. The inlining thing is probably the
best solution if you want to do it without extensions and without
disturbing the constructor/destructor concept of C++.
But if you want to compile with -O0 for debugging, then
you have a problem if you don't move all the initializations 
into a separate object that can be compiled with -O.
For the inlining approach you also need some kind of optional 
warning that tells you when some ctors can't be inlined.

Both approaches have advantages and disadvantages ... I would
be happy if only one of them would work :)

Micha

----- Original Message ----- 
From: Joe Buck <jbuck@synopsys.com>
To: Michael Bruck <mbruck@gmx.net>
Cc: <egcs@egcs.cygnus.com>
Sent: Monday, May 10, 1999 6:16 PM
Subject: Re: nonstandard extensions


>
>> One common problem with using C++ in embedded programming 
>> is the fact that you can initialize classes with virtual members
>> only by using the constructor. In normal applications it makes no
>> big difference whether you initialize things at runtime, but for
>> embedded stuff you usually want to be able to put as much as
>> possible into .rodata and you can't afford the time that it takes
>> to copy data around at bootup.
>
>There's no reason that constructors can't be evaluated at compile time,
>however.
>
>> struct foo : public bar {
>>     foo(int _a) : apples(_a) {}
>>     int apples;
>> };
>> 
>> const foo        my_foo(4);
>> 
>> My question is now, whether it's possible to extend the compiler
>> in a way that it allows such structs to be initialized like normal
>> structs:
>
>No extension to the input language is necessary.  Rather, the compiler
>could recognize that it knows how to fill in .rodata by evaluating
>the constructor at compile time.  If this were done, we'd need to
>figure out what types of constructors can be handled in this way.
>It should be possible to handle inlined constructors that only do
>simple initializations of their members.
>