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

Groups > comp.lang.c > #4032

Re: Non-constant initializers

Show all headers | View raw

On Sat, May 14, 2011 at 09:26:21PM -0500, Shao Miller wrote:
> 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.

That's fairly slick.  Mostly I typedef structures and follow a
consistent naming scheme, so I think I could use your construction.  I
just have to wrestle with the back-end a little more before it all
gels into something that fits in my existing code.
 
> >>>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.

You had me for a moment because I think I read that gcc will use
branch profiling feedback in its instruction scheduler(?) and that's
pretty much data computed for compile-time, except that it doesn't
directly relate to application logic.
 
> >>>>>>- 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.

Nothing quite so byzantine.  I'm thinking more along the lines of an
.ini file that is consulted by a lookup function.  I doubt there'd
really be much arbitrary binary data.
 
> >>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.

That's a bit of a grey area, but then maybe we're in violent
agreement.  I would never expect to have a function call launch in the
pre-processor pass of the compilation.  Assuming it compiles.
 
> >>>>>>- 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:
[snip]

I'm fine with that, I plan to give them both a close look later on
just to get a better feel for your approach.

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

At least two, don't forget that double-buffering schemes and the like
are really quite common.
 
> 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.

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

I think so.  At least in many scenarios.  This is also implementation
specific.  If the system libraries the code may be linked with are
already initialized the error recovery procedure can be fairly
complicated without worry:  open the tty directly, open a socket to
syslog, etc.  What is required is a guarantee that these application
variable initializations occurs immediately prior to the call to
main() by the .init code section, or whatever it is on your platform.
 
> A: "Program just freezes."
> B: "What version?  Use 'program -v' to find out."
> A: "It freezes on 'program -v', so I don't know."

Yes, I can see that the user might yell at the programmer if there is
no feedback and the application just stops working.

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

This is a complication, but you could commit to program execution
conditional on the success of the initialization sequence.  Anything
more complicated gets hairy.  I suppose I could just switch to C++,
which as others have said includes the necessary compiler support for
this operation.  But I'm comfortable with C enough to view the switch
to C++ with more than a little trepidation.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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