Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3991

Re: Non-constant initializers

Show all headers | View raw

On 5/14/2011 5:21 PM, Uncle Steve wrote:
> On Sat, May 14, 2011 at 04:14:20PM -0500, Shao Miller wrote:
>> On 5/14/2011 2:25 PM, Uncle Steve wrote:
>>> On Sat, May 14, 2011 at 02:30:58PM -0500, Shao Miller wrote:
>>>> On 5/14/2011 12:59 PM, Uncle Steve wrote:
>>>>> On Thu, May 12, 2011 at 06:53:02PM -0500, Shao Miller wrote:
>>>>>> Some more questions:
>>>>>>
>>>>>> - When do you wish this initialization to occur?  Prior to main()?
>>>>>
>>>>> In a perfect world.
>>>>>
>>>>
>>>> Ok.  So now: Why?  (Please see next response.)
>>>
>>>>>> - Could you employ and enjoy an init() function which would initialize
>>>>>> these objects, then make that the first call inside main()?
>>>>>>
>>>>
>>>> No answer to this one?  If the very first thing main() does is to call
>>>> an init() which populates your globals' values, then that init() makes
>>>> for a nicely-readable section of code to gather these items into one
>>>> place.
>>>
>>> You're making this too easy.  What could be cleaner than a variable
>>> declaration outside of main() which also initializes it to the value it
>>> should have before main() is called?
>>
>> Ok, so my impression now is that by "cleaner," you mean that such
>> reduces keyboard typing redundancy by having the value population appear
>> alongside the declaration, thus avoiding typing the identifier's name
>> again within an init() function.
>
> Yeah.

Well, you can get pretty wild with macros.  For example:

   #include <stdio.h>

   #define UNIT_DECL(type_, id_, init_) type_ id_;
   #define UNIT_INIT(type_, id_, init_) id_ = init_;

   #define GLOBALS(UNIT_) \
   \
   UNIT_(int, saved_setting, get_saved_setting()) \
   UNIT_(int, saved_setting2, get_saved_setting2())

   /* Declare globals */
   GLOBALS(UNIT_DECL)

   int get_saved_setting(void) {
       /* TODO: Actually fetch the saved setting */
       return 3;
     }

   int get_saved_setting2(void) {
       /* TODO: Actually fetch the saved setting */
       return 5;
     }

   void init(void) {
       /* Populate globals */
       GLOBALS(UNIT_INIT)
       return;
     }

   int main(void) {
       init();
       printf("saved_setting: %d\n", saved_setting);
       printf("saved_setting2: %d\n", saved_setting2);
       return 0;
     }

However the types used in the 'GLOBALS' #definition in this example are 
confined to simple types without parentheses and struct/union 
definition.  You'd have to 'typedef' anything complicated or make the 
macro even uglier to deal with types with parentheses (such as function 
pointer types) or with types while wanting to define a struct/union type 
within the declaration itself.

>
>>> I'm fully aware that I can
>>> assign a value to a variable any time I write code or macros to do it,
>>> but there are certain kinds of application parameters, for instance,
>>> which you may derive empirically, and assign once.  I should think
>>> that most programmers know about these types of variables.
>>
>> Ah, now this gives me the impression that not only are you interested in
>> restoring saved settings, but that you'd _also_ like to be able to
>> compute things using C functions, and have those computation results
>> available at compile-time.  Perhaps something like declaring an array
>> with a number of elements which is 'pow(5, 6)'.  Do I understand your
>> wish correctly?
>
> I didn't say anything about having function return values available
> at compile-time.  I can't even imagine why someone would want to do
> such a thing.
>

Ok.  I misunderstood "empirically"-"derive"d "and assign"ed "once" to 
mean using "computed for compile-time."  Sorry about that.

>>>>>> - In your code example, is howmuchfoo() supposed to be returning an
>>>>>> array of 'int' or a single 'int'?
>>>>>
>>>>> I don't see how that's relevant to the question.
>>>>>
>>>>
>>>> Well it's an opportunity to suggest that C functions do not return
>>>> arrays, as far as I know.  If howmuchfoo() was a macro that expanded to
>>>> an initializer list, then I believe that'd be fine.
>>>
>>> It could do just about anything if it was a C function, couldn't it?
>>>
>>
>> Perhaps not in a standard, portable sense.  As an example, we have
>> n1256.pdf, section 6.5.2.2, point 1:
>>
>>    "The expression that denotes the called function...shall have type
>> pointer to function returning void or returning an object type other
>> than an array type."
>
> Ok, I guess that's what it says.
>

A function can certainly return a pointer which points to the first 
element of an array.  Or a function could even return a pointer to a:

   struct sized_array {
       size_t size;
       char * array;
     };

Essentially, it wasn't clear to me what your code example was trying to 
do.  Based on your responses in this thread, it seems like you were keen on:

   int foops[] = howmuchfoo(void);

Doing something like:

   int * foops;
   foops = malloc(howmuchfoo());

At file-scope and performing the calls at a pre-main() time.  I'm not 
sure what you'd want 'sizeof foops' to evaluate to.  But please see "I 
wonder... #2" below.

>> It's also nicely symmetrical if you have a save_settings().  The
>> suggested init() might as well be called restore_settings() or
>> load_settings().
>
>> But your "see above" suggests (to me) that you are interested in
>> computations which are needed in order to affect _compile-time_
>> decisions, rather than _run-time_ decisions.
>
> That might be true.  I have a hash function that could be exactly
> tuned to have the optimum number of buckets.  In theory.
>

I'm not sure how that's congruent with:

> I didn't say anything about having function return values available
> at compile-time.  I can't even imagine why someone would want to do
> such a thing.
>

but perhaps that was imagining why someone would want to do such a 
thing.  I think there certainly are use cases.

>>>>>> - Would you be willing to use macros to accomplish this?
>>>>>
>>>>> I'll think about it.
>>>>>
>>>>
>>>> Ok.  Good fortune to you. :)
>>>
>>> I'm big on macros, but sometimes they clutter up the code with
>>> redundant code blocks that are deader than a doornail.  Maybe the
>>> compiler will weed them out with global CSE, maybe not.  If they
>>> aren't in the code to begin with, they can't possibly get into the
>>> instruction cache.
>>
>> One possible way to achieve _something_like_ the _look_ of the
>> declarations calling functions might be the following example "uncle.c":
>>
>> ...
>>
>> That's still kind of ugly. :)
>
> Yup.  Recursive includes are considered harmful to the normal human
> mind.  Banned in some jurisdictions where programmer-cruelty laws hold
> sway.

Well, some of that recursive-inclusion ugliness is due to trying to 
provide the example as a single, compilable file, which can be copied 
and pasted and compiled.

As two files, it could look like "uncle.h" and "uncle.c", given, in that 
order, below:
---
   #ifndef GLOBAL_INITS
   #  define TYPE(x) x
   #  define INIT(x) {0}
   #else
   #  define TYPE(x)
   #  define INIT(x) x
   #endif /* GLOBAL_INITS */

   /*** Globals */
   TYPE(int) saved_setting = INIT(get_saved_setting());
   TYPE(int) saved_setting2 = INIT(get_saved_setting2());

   #undef TYPE
   #undef INIT
---
   #include <stdio.h>

   #include "uncle.h"

   int get_saved_setting(void) {
       /* TODO: Actually fetch the saved setting */
       return 3;
     }

   int get_saved_setting2(void) {
       /* TODO: Actually fetch the saved setting */
       return 5;
     }

   void init(void) {
       #define GLOBAL_INITS 1
       #include "uncle.h"
       #undef GLOBAL_INITS
       return;
     }

   int main(void) {
       init();
       printf("saved_setting: %d\n", saved_setting);
       printf("saved_setting2: %d\n", saved_setting2);
       return 0;
     }
---

>
>> However this would not help with a wish to call C functions in order to
>> compute something which needs to influence compile-time decisions, such
>> as the size of an array declared at file-scope.  I think that folks
>> usually have a separate C program perform such computations, then output
>> C source, which is then compiled with the rest of your code; code
>> generation.
>
> Or you might want to size your buffers as a percentage of total
> physical RAM.  There are several scenarios where this would be
> convenient.

A run-time decision; right.  That scenario reads to me like it could 
warrant two globals:

   size_t buf_size;
   char * buf;

Where you'd populate 'buf_size' in an init() function and then malloc() 
the buffer (populating the 'buf' pointer) in the same init() function, also.

If C had a pre-main() time where globals could be initialized with the 
results of function calls, such a time period would still have to answer 
the questions put forward by Eric Sosman, else-thread, regarding the 
state of the environment at such a pre-main() time.

Along with his small sampling of questions, I wonder:

1. If such a function used for initialization never returned (infinite 
loop, for example), then main() would never be executed.  If such a 
function was your own, and included a bug which caused this, and the bug 
was based on the environment (such as reading saved settings from a 
file), then main() wouldn't even be able to report the program version 
or a usage statement to a user.  Would that be acceptable?

A: "Program just freezes."
B: "What version?  Use 'program -v' to find out."
A: "It freezes on 'program -v', so I don't know."

I don't remember C++ well enough to be able to suggest whether or not 
C++ programmers have to be careful about this type of thing with 
constructors, but that's off-topic, anyway.

2. If such a function used for initialization encountered another kind 
of error (insufficient memory while allocating an array object, for 
example), how could this communicated to program portions using those 
globals?  It would seem that it'd be up to main() or some other function 
called by main() (such as an init() function) to test the success of 
such initializations.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 22:59 +0000
  Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:07 +1200
    Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:17 +0000
      Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:20 +1200
        Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:30 +0000
          Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:34 +1200
            Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 16:52 -0700
              Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:13 +0000
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-14 01:28 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 13:52 -0400
                Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 01:54 +0000
                Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 01:07 -0700
                Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 09:22 +0000
                Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 17:14 +0000
            Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:11 +0000
  Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-12 18:08 -0500
    Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-12 19:22 -0400
      Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-12 18:53 -0500
        Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 13:59 -0400
          Re: Non-constant initializers Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 14:19 -0400
            Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 15:04 -0500
            Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 15:10 -0400
              Re: Non-constant initializers James Kuyper <jameskuyper@verizon.net> - 2011-05-14 16:01 -0400
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 16:57 -0400
          Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 14:30 -0500
            Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 15:25 -0400
              Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-14 13:05 -0700
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 17:00 -0400
              Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 16:14 -0500
                Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 16:49 -0500
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 18:21 -0400
                Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 21:26 -0500
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-15 14:01 -0400
              Re: Non-constant initializers Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 17:45 -0400
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 18:09 -0400
                Re: Non-constant initializers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-15 04:01 +0100
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-15 13:26 -0400
                Re: Non-constant initializers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 02:32 +0100
              Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-15 03:59 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 04:49 -0400
                Re: Non-constant initializers pete <pfiland@mindspring.com> - 2011-05-16 07:27 -0400
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 09:24 -0400
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:10 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 21:23 -0400
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:10 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 21:16 -0400
                Re: Non-constant initializers James Kuyper <jameskuyper@verizon.net> - 2011-05-16 21:37 -0400
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 22:42 -0400
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 02:40 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 22:50 -0400
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 04:14 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-17 17:37 -0400
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 22:22 +0000
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-17 18:33 -0400
                Re: Non-constant initializers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:58 -0700
                Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-18 12:45 -0400
                Re: Non-constant initializers "io_x" <a@b.c.invalid> - 2011-05-18 19:30 +0200
                Re: Non-constant initializers Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-18 20:01 +0100
                Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 02:21 +0000
                Re: bug-free C code (was: Non-constant initializers) Keith Thompson <kst-u@mib.org> - 2011-05-18 20:00 -0700
                Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 03:14 +0000
                Re: bug-free C code (was: Non-constant initializers) Keith Thompson <kst-u@mib.org> - 2011-05-19 07:49 -0700
                Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 15:16 +0000
                Re: bug-free C code Ben Pfaff <blp@cs.stanford.edu> - 2011-05-18 20:02 -0700
                Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-18 20:09 -0700
                Re: bug-free C code Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 23:24 -0400
                Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 06:39 +0000
                Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 08:05 -0700
                Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 16:22 +0000
                Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 11:36 -0700
                Re: bug-free C code Ben Pfaff <blp@cs.stanford.edu> - 2011-05-19 12:21 -0700
                Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 13:12 -0700
                Re: bug-free C code gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-19 21:52 +0000
                Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 22:16 +0000
                Re: bug-free C code Shao Miller <sha0.miller@gmail.com> - 2011-05-19 17:25 -0500
                Re: bug-free C code Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:32 -0400
                Re: bug-free C code gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-19 21:51 +0000
                Re: bug-free C code Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:30 -0400
                Re: bug-free C code "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-05-18 23:13 -0400
                Re: bug-free C code Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-19 08:23 +0100
      Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 00:15 +0000
      Re: Non-constant initializers "io_x" <a@b.c.invalid> - 2011-05-13 11:01 +0200
    Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 16:30 -0700
  Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 16:15 -0700
    Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:28 +0000
  Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 18:01 -0600
    Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 18:15 -0700
      Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 22:56 -0600
        Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 05:18 +0000
          Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-13 09:10 -0600
            Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 20:56 +0000
      Re: Non-constant initializers Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 23:47 -0700
        Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-19 08:15 -0700
    Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-13 23:57 +0000

csiph-web