Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #3855 > unrolled thread
| Started by | Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> |
|---|---|
| First post | 2011-05-12 22:59 +0000 |
| Last post | 2011-05-13 23:57 +0000 |
| Articles | 20 on this page of 94 — 22 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-14 15:04 -0500 |
| Message-ID | <iqmjof$7ip$1@dont-email.me> |
| In reply to | #3966 |
On 5/14/2011 1:19 PM, Eric Sosman wrote: > in -- which means that by exhibiting it you have conveyed no meaning > to anyone. It is as if you had offered `int foops[] = !<petunia/>;' > and expected people to understand you. LOL! It's raining outside. Thanks for making my day a little brighter. :)
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 15:10 -0400 |
| Message-ID | <351fe53469ed0a6-fdb69@gmail.com> |
| In reply to | #3966 |
On Sat, May 14, 2011 at 02:19:25PM -0400, Eric Sosman wrote: > On 5/14/2011 1:59 PM, Uncle Steve wrote: > >On Thu, May 12, 2011 at 06:53:02PM -0500, Shao Miller wrote: > >>On 5/12/2011 6:22 PM, Uncle Steve wrote: > >>>[...] I would like to declare: > >>> > >>>int foops[] = howmuchfoo(void); > >>> > >>>and have everything work as I expect... > >> [...] > >> > >>- 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. > > The point is that the one-line fragment you posted is not > valid C, not if `howmuchfoo(void)' is any kind of function at all. Yes, and I figured out that I had a misconception of how gcc handles non-constant initilizers. I've already admitted that I'm not coding anything specific at the moment, and instead /contemplating/ an approach to solving a particular problem, of which variable initialization is a part. > (If `howmuchfoo' is a function-like macro, it can of course expand > at compile-time into pretty much anything.) But if it's a function > call, the fragment is meaningless regardless of what scope it appears > in -- which means that by exhibiting it you have conveyed no meaning > to anyone. It is as if you had offered `int foops[] = !<petunia/>;' > and expected people to understand you. If you want to be understood, > you'll have to explain yourself more clearly. l I think that I'm being clear enough here. The problem may be that the subtleties associated with these issues are difficult to articulate. If you don't like my humor, say so. I don't have a pathological condition that requires that I include funnyisms in the text, but it does amuse me to do so. > Something that strikes me as odd is that you(?) started this > thread with the statement that you(?) sought a "maximally portable" > solution. Why, then, all this haring off after blatantly non- > portable approaches? Lost sight of the objective, or just trolling? I don't see where I've committed to any "blatantly" non-portable approaches. In actual point of fact I've been asking about certain compiler features and their actual prevalence in the field. I'm sorry I don't know any real programmers IRL, with whom I might have these talks with instead. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-14 16:01 -0400 |
| Message-ID | <iqmn34$4f2$1@dont-email.me> |
| In reply to | #3973 |
On 05/14/2011 03:10 PM, Uncle Steve wrote: > On Sat, May 14, 2011 at 02:19:25PM -0400, Eric Sosman wrote: >> On 5/14/2011 1:59 PM, Uncle Steve wrote: >>> On Thu, May 12, 2011 at 06:53:02PM -0500, Shao Miller wrote: >>>> On 5/12/2011 6:22 PM, Uncle Steve wrote: >>>>> [...] I would like to declare: >>>>> >>>>> int foops[] = howmuchfoo(void); >>>>> >>>>> and have everything work as I expect... >>>> [...] >>>> >>>> - 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. >> >> The point is that the one-line fragment you posted is not >> valid C, not if `howmuchfoo(void)' is any kind of function at all. > > Yes, and I figured out that I had a misconception of how gcc handles > non-constant initilizers. I've already admitted that I'm not coding > anything specific at the moment, and instead /contemplating/ an > approach to solving a particular problem, of which variable > initialization is a part. > >> (If `howmuchfoo' is a function-like macro, it can of course expand >> at compile-time into pretty much anything.) But if it's a function >> call, the fragment is meaningless regardless of what scope it appears >> in -- which means that by exhibiting it you have conveyed no meaning >> to anyone. It is as if you had offered `int foops[] = !<petunia/>;' >> and expected people to understand you. If you want to be understood, >> you'll have to explain yourself more clearly. > l > I think that I'm being clear enough here. You think incorrectly. howmuchfoo() can't be a function call. It could be a function-like macro, but if so, the possibilities are too open-ended to be discussed in the abstract; we need information about the nature of that macro before your question can be addressed. > ... The problem may be that > the subtleties associated with these issues are difficult to > articulate. If you don't like my humor, say so. It has nothing to do with your sense of humor. ... >> Something that strikes me as odd is that you(?) started this >> thread with the statement that you(?) sought a "maximally portable" >> solution. Why, then, all this haring off after blatantly non- >> portable approaches? Lost sight of the objective, or just trolling? > > I don't see where I've committed to any "blatantly" non-portable > approaches. In actual point of fact I've been asking about certain > compiler features and their actual prevalence in the field. By definition, compiler features mandated by the standard are available on every single fully conforming implementation. Therefore, code which relies on any feature that is less than universally prevalent (such as zero-length arrays) is non-portable. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 16:57 -0400 |
| Message-ID | <cb1ba96d02cfac0-94b64@gmail.com> |
| In reply to | #3975 |
On Sat, May 14, 2011 at 04:01:40PM -0400, James Kuyper wrote: > On 05/14/2011 03:10 PM, Uncle Steve wrote: > > On Sat, May 14, 2011 at 02:19:25PM -0400, Eric Sosman wrote: > >> On 5/14/2011 1:59 PM, Uncle Steve wrote: > >>> On Thu, May 12, 2011 at 06:53:02PM -0500, Shao Miller wrote: > >>>> On 5/12/2011 6:22 PM, Uncle Steve wrote: > >>>>> [...] I would like to declare: > >>>>> > >>>>> int foops[] = howmuchfoo(void); > >>>>> > >>>>> and have everything work as I expect... > >>>> [...] > >>>> > >>>> - 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. > >> > >> The point is that the one-line fragment you posted is not > >> valid C, not if `howmuchfoo(void)' is any kind of function at all. > > > > Yes, and I figured out that I had a misconception of how gcc handles > > non-constant initilizers. I've already admitted that I'm not coding > > anything specific at the moment, and instead /contemplating/ an > > approach to solving a particular problem, of which variable > > initialization is a part. > > > >> (If `howmuchfoo' is a function-like macro, it can of course expand > >> at compile-time into pretty much anything.) But if it's a function > >> call, the fragment is meaningless regardless of what scope it appears > >> in -- which means that by exhibiting it you have conveyed no meaning > >> to anyone. It is as if you had offered `int foops[] = !<petunia/>;' > >> and expected people to understand you. If you want to be understood, > >> you'll have to explain yourself more clearly. > > l > > I think that I'm being clear enough here. > > You think incorrectly. howmuchfoo() can't be a function call. It could *Now* I know it can't be a function call, but I didn't before. I thought I explained that already. > be a function-like macro, but if so, the possibilities are too > open-ended to be discussed in the abstract; we need information about > the nature of that macro before your question can be addressed. No, we need to consider things in the abstract so we may derive general principles. Is that too much to ask? > > ... The problem may be that > > the subtleties associated with these issues are difficult to > > articulate. If you don't like my humor, say so. > > It has nothing to do with your sense of humor. Heh, well that's good. > ... > >> Something that strikes me as odd is that you(?) started this > >> thread with the statement that you(?) sought a "maximally portable" > >> solution. Why, then, all this haring off after blatantly non- > >> portable approaches? Lost sight of the objective, or just trolling? > > > > I don't see where I've committed to any "blatantly" non-portable > > approaches. In actual point of fact I've been asking about certain > > compiler features and their actual prevalence in the field. > > By definition, compiler features mandated by the standard are available > on every single fully conforming implementation. Therefore, code which > relies on any feature that is less than universally prevalent (such as > zero-length arrays) is non-portable. I was just throwing that out there as an example. I don't really need zero-length arrays, but if they're available it looks cleaner to use them. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-14 14:30 -0500 |
| Message-ID | <iqmhp7$l57$1@dont-email.me> |
| In reply to | #3961 |
On 5/14/2011 12:59 PM, Uncle Steve wrote:
> On Thu, May 12, 2011 at 06:53:02PM -0500, Shao Miller wrote:
>> Are you the same person as "Fred the Freshwater Catfish"? Or are you
>> another person who also wishes to accomplish this type of thing?
>
> Apparently I've been caught out. Now my stalkers will know that I
> secretly lurk in c.l.c. occasionally.
>
If you are, that doesn't bother me. :) I was merely confirming as I
found the use of different posting names slightly confusing. So getting
back to the C...
>>> I'm looking to seed a few critical global variables with
>>> run-time computed values. Obviously, this will be the product of a
>>> function call. I would like to declare:
>>>
>>> int foops[] = howmuchfoo(void);
>>>
>>> and have everything work as I expect...
>>
>> 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.
>> - 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.
>> - Is your request a matter of being able to read, in your code, what
>> will be computed for an object in the immediate vicinity of the object,
>> rather than in another place (such as an init() function)?
>
> That all depends on what kind of data the variables are going to hold.
> One time, I might want to save/restore window size and positioning,
> and in another place, the volume setting of application sounds. It is
> impossible to say, a priori, what variables will be used/set where, at
> least at this stage of the design process.
>
My question there wasn't too clear and I apologize. What I am trying to
understand is why you might be inclined to avoid something like the
init() suggestion. Is it a matter of:
int saved_setting = get_saved_setting();
looking nicer, to you, at file scope, than:
int saved_setting;
/* ... */
void init(void) {
saved_setting = get_saved_setting();
/* ...Other globals populated... */
return;
}
/* ... */
int main(void) {
/* Populate globals */
init();
/* ... */
}
?
>> - Would you be willing to use macros to accomplish this?
>
> I'll think about it.
>
Ok. Good fortune to you. :)
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 15:25 -0400 |
| Message-ID | <70b21f510c7390e-cc0de@gmail.com> |
| In reply to | #3968 |
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:
> >>Are you the same person as "Fred the Freshwater Catfish"? Or are you
> >>another person who also wishes to accomplish this type of thing?
> >
> >Apparently I've been caught out. Now my stalkers will know that I
> >secretly lurk in c.l.c. occasionally.
> >
>
> If you are, that doesn't bother me. :) I was merely confirming as I
> found the use of different posting names slightly confusing. So getting
> back to the C...
Right.
> >>>I'm looking to seed a few critical global variables with
> >>>run-time computed values. Obviously, this will be the product of a
> >>>function call. I would like to declare:
> >>>
> >>>int foops[] = howmuchfoo(void);
> >>>
> >>>and have everything work as I expect...
> >>
> >>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? 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.
> >>- 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?
> >>- Is your request a matter of being able to read, in your code, what
> >>will be computed for an object in the immediate vicinity of the object,
> >>rather than in another place (such as an init() function)?
> >
> >That all depends on what kind of data the variables are going to hold.
> >One time, I might want to save/restore window size and positioning,
> >and in another place, the volume setting of application sounds. It is
> >impossible to say, a priori, what variables will be used/set where, at
> >least at this stage of the design process.
> >
>
> My question there wasn't too clear and I apologize. What I am trying to
> understand is why you might be inclined to avoid something like the
> init() suggestion. Is it a matter of:
>
> int saved_setting = get_saved_setting();
>
> looking nicer, to you, at file scope, than:
>
> int saved_setting;
> /* ... */
> void init(void) {
> saved_setting = get_saved_setting();
> /* ...Other globals populated... */
> return;
> }
> /* ... */
> int main(void) {
> /* Populate globals */
> init();
> /* ... */
> }
>
> ?
This is fine, and I've in fact done just that in code I've written
previously. But see above.
> >>- 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.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-14 13:05 -0700 |
| Message-ID | <lnoc35gi9h.fsf@nuthaus.mib.org> |
| In reply to | #3974 |
Uncle Steve <stevet810@gmail.com> writes:
> 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:
[...]
>> >>- 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? 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.
The clarity or simplicity of the concept is not the issue.
Yes, the ability to declare a variable outside main() with a
non-constant initializer (say, using a function call) can be
very useful.
But the fact is, standard C doesn't support this feature. If you
need it, you can use a workaround (several have been offered here),
or you can use a non-standard compiler extension if it's available,
or you can use a different language.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 17:00 -0400 |
| Message-ID | <fc9200654d92fcd-5eb20@gmail.com> |
| In reply to | #3976 |
On Sat, May 14, 2011 at 01:05:30PM -0700, Keith Thompson wrote: > Uncle Steve <stevet810@gmail.com> writes: > > 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: > [...] > >> >>- 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? 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. > > The clarity or simplicity of the concept is not the issue. > > Yes, the ability to declare a variable outside main() with a > non-constant initializer (say, using a function call) can be > very useful. > > But the fact is, standard C doesn't support this feature. If you > need it, you can use a workaround (several have been offered here), > or you can use a non-standard compiler extension if it's available, > or you can use a different language. So my question is really answered. Likely, I'll end up calling some function from main() and merely initialize pointers to NULL in the global section. No big deal, and thank you all for the suggestions. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-14 16:14 -0500 |
| Message-ID | <iqmnr0$6an$1@dont-email.me> |
| In reply to | #3974 |
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.
> 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?
>
>>>> - 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."
>>>> - Is your request a matter of being able to read, in your code, what
>>>> will be computed for an object in the immediate vicinity of the object,
>>>> rather than in another place (such as an init() function)?
>>>
>>> That all depends on what kind of data the variables are going to hold.
>>> One time, I might want to save/restore window size and positioning,
>>> and in another place, the volume setting of application sounds. It is
>>> impossible to say, a priori, what variables will be used/set where, at
>>> least at this stage of the design process.
>>>
>>
>> My question there wasn't too clear and I apologize. What I am trying to
>> understand is why you might be inclined to avoid something like the
>> init() suggestion. Is it a matter of:
>>
>> int saved_setting = get_saved_setting();
>>
>> looking nicer, to you, at file scope, than:
>>
>> int saved_setting;
>> /* ... */
>> void init(void) {
>> saved_setting = get_saved_setting();
>> /* ...Other globals populated... */
>> return;
>> }
>> /* ... */
>> int main(void) {
>> /* Populate globals */
>> init();
>> /* ... */
>> }
>>
>> ?
>
> This is fine, and I've in fact done just that in code I've written
> previously. But see above.
>
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.
>>>> - 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":
#ifndef GLOBAL_INITS
# define TYPE(x) x
# define INIT(x) {0}
#else
# undef TYPE
# define TYPE(x)
# undef INIT
# define INIT(x) x
#endif /* GLOBAL_INITS */
#ifndef GLOBAL_INITS
#include <stdio.h>
#endif /* GLOBAL_INITS */
/*** Globals */
TYPE(int) saved_setting = INIT(get_saved_setting());
TYPE(int) saved_setting2 = INIT(get_saved_setting2());
#ifndef GLOBAL_INITS
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.c"
#undef GLOBAL_INITS
return;
}
int main(void) {
init();
printf("saved_setting: %d\n", saved_setting);
printf("saved_setting2: %d\n", saved_setting2);
return 0;
}
#endif /* GLOBAL_INITS */
That's still kind of ugly. :)
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.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-14 16:49 -0500 |
| Message-ID | <iqmpss$b4d$1@dont-email.me> |
| In reply to | #3977 |
On 5/14/2011 4:14 PM, Shao Miller wrote:
> On 5/14/2011 2:25 PM, Uncle Steve wrote:
>> 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?
> ...
> 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.
>...
> 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.
As a silly example for why calling a C function to determine the size of
an array at file-scope might be problematic, were it a standard feature:
int compute_some_array_size(void);
char some_array[compute_some_array_size()];
int compute_some_array_size(void) {
if (sizeof some_array == 3)
return 5;
/* Otherwise */
return 3;
}
But perhaps you don't need to have an array at file-scope! You can have
a _pointer_ at file scope and you can malloc() the array using a size
based on the result of calling a C function!
Does that seem reasonable for such empirically-calculated items?
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 18:21 -0400 |
| Message-ID | <0896a686ef8c492-f7e5e@gmail.com> |
| In reply to | #3977 |
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.
> >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.
> >>>>- 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.
> >>>>- Is your request a matter of being able to read, in your code, what
> >>>>will be computed for an object in the immediate vicinity of the object,
> >>>>rather than in another place (such as an init() function)?
> >>>
> >>>That all depends on what kind of data the variables are going to hold.
> >>>One time, I might want to save/restore window size and positioning,
> >>>and in another place, the volume setting of application sounds. It is
> >>>impossible to say, a priori, what variables will be used/set where, at
> >>>least at this stage of the design process.
> >>>
> >>
> >>My question there wasn't too clear and I apologize. What I am trying to
> >>understand is why you might be inclined to avoid something like the
> >>init() suggestion. Is it a matter of:
> >>
> >> int saved_setting = get_saved_setting();
> >>
> >>looking nicer, to you, at file scope, than:
> >>
> >> int saved_setting;
> >> /* ... */
> >> void init(void) {
> >> saved_setting = get_saved_setting();
> >> /* ...Other globals populated... */
> >> return;
> >> }
> >> /* ... */
> >> int main(void) {
> >> /* Populate globals */
> >> init();
> >> /* ... */
> >> }
> >>
> >>?
> >
> >This is fine, and I've in fact done just that in code I've written
> >previously. But see above.
>
> 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.
> >>>>- 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":
>
> #ifndef GLOBAL_INITS
> # define TYPE(x) x
> # define INIT(x) {0}
> #else
> # undef TYPE
> # define TYPE(x)
> # undef INIT
> # define INIT(x) x
> #endif /* GLOBAL_INITS */
>
> #ifndef GLOBAL_INITS
> #include <stdio.h>
>
> #endif /* GLOBAL_INITS */
> /*** Globals */
> TYPE(int) saved_setting = INIT(get_saved_setting());
> TYPE(int) saved_setting2 = INIT(get_saved_setting2());
>
> #ifndef GLOBAL_INITS
> 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.c"
> #undef GLOBAL_INITS
> return;
> }
>
> int main(void) {
> init();
> printf("saved_setting: %d\n", saved_setting);
> printf("saved_setting2: %d\n", saved_setting2);
> return 0;
> }
>
> #endif /* GLOBAL_INITS */
>
> 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.
> 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.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-14 21:26 -0500 |
| Message-ID | <iqna42$mc9$1@dont-email.me> |
| In reply to | #3987 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-15 14:01 -0400 |
| Message-ID | <84fa21a704a47c5-4eedd@gmail.com> |
| In reply to | #3991 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-05-14 17:45 -0400 |
| Message-ID | <iqmt7i$42s$1@dont-email.me> |
| In reply to | #3974 |
On 5/14/2011 3:25 PM, Uncle Steve wrote:
> On Sat, May 14, 2011 at 02:30:58PM -0500, Shao Miller wrote:
>> [...]
>> 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? [...]
Since it's not C, it's infinitely UNclean in C terms. Also,
you'll find that languages permitting this sort of thing are all
festooned with great garlands of special rules about the order in
which these initializers get executed. Consider your hypothetical
file-scope function call, for example: Are stdin/out/err open and
ready for use when the function runs? What about the `FILE *foo;'
that you also fopen() at file-scope? Has the malloc() arena been
initialized yet? What about floating-point environment flags? And
so on, and so on.
>> 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?
C functions cannot return arrays, nor can they return array
initializers.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-14 18:09 -0400 |
| Message-ID | <92f904404cb7d63-61def@gmail.com> |
| In reply to | #3984 |
On Sat, May 14, 2011 at 05:45:49PM -0400, Eric Sosman wrote: > On 5/14/2011 3:25 PM, Uncle Steve wrote: > >On Sat, May 14, 2011 at 02:30:58PM -0500, Shao Miller wrote: > >>[...] > >>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? [...] > > Since it's not C, it's infinitely UNclean in C terms. Also, > you'll find that languages permitting this sort of thing are all > festooned with great garlands of special rules about the order in > which these initializers get executed. Consider your hypothetical > file-scope function call, for example: Are stdin/out/err open and > ready for use when the function runs? What about the `FILE *foo;' > that you also fopen() at file-scope? Has the malloc() arena been > initialized yet? What about floating-point environment flags? And > so on, and so on. I just know I'm going to get into trouble continuing with this. Might I suggest that it wouldn't be too terrible if the C compiler had provisions for well-defined user initialization code, happening after all the libc initialization, etc.? I know it's not in the standard, but it would be kind of nice to have. > >>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? > > C functions cannot return arrays, nor can they return array > initializers. Hmm. I'm not sure why you think that's important. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-15 04:01 +0100 |
| Message-ID | <0.6ca601d4a6214c706d15.20110515040125BST.878vu8y8e2.fsf@bsb.me.uk> |
| In reply to | #3986 |
Uncle Steve <stevet810@gmail.com> writes: > On Sat, May 14, 2011 at 05:45:49PM -0400, Eric Sosman wrote: >> On 5/14/2011 3:25 PM, Uncle Steve wrote: <snip> >> >It could do just about anything if it was a C function, couldn't it? >> >> C functions cannot return arrays, nor can they return array >> initializers. > > Hmm. I'm not sure why you think that's important. It's right there in the quotes. You asked if "it" (referring to your howmuchfoo function) "could do just about anything if it was a C function, couldn't it?". Eric answered by pointing out two things that it could *not* do. What's more, these are things that might be significant since the code fragment you showed: | int foops[] = howmuchfoo(void); suggested that howmuchfoo might be either returning an array or it might be trying to return an array initialiser. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-15 13:26 -0400 |
| Message-ID | <6a050bb5569ef14-16a9a@gmail.com> |
| In reply to | #3992 |
On Sun, May 15, 2011 at 04:01:25AM +0100, Ben Bacarisse wrote: > Uncle Steve <stevet810@gmail.com> writes: > > > On Sat, May 14, 2011 at 05:45:49PM -0400, Eric Sosman wrote: > >> On 5/14/2011 3:25 PM, Uncle Steve wrote: > <snip> > >> >It could do just about anything if it was a C function, couldn't it? > >> > >> C functions cannot return arrays, nor can they return array > >> initializers. > > > > Hmm. I'm not sure why you think that's important. > > It's right there in the quotes. You asked if "it" (referring to your > howmuchfoo function) "could do just about anything if it was a C > function, couldn't it?". Eric answered by pointing out two things that > it could *not* do. What's more, these are things that might be > significant since the code fragment you showed: > > | int foops[] = howmuchfoo(void); > > suggested that howmuchfoo might be either returning an array or it might > be trying to return an array initialiser. But only if it was a macro. I'm not likely to use that exact scenario in real code, perhaps I hammered out my initial example a little too quickly. I don't pretend to be an expert on C grammar. Too often the compiler identifies my typos and coding errors so I guess it may be obvious I don't use a syntax-highlighting editor. In any case, I'm not hung up on what kind of data is returned from a function call in this usage scenario. It may vary well come from a file containing random data owing to filesystem corruption from bashing my head on the keyboard of my notebook. ;) Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-16 02:32 +0100 |
| Message-ID | <0.1620adcbe0d5f774b4e8.20110516023206BST.87wrhrwhux.fsf@bsb.me.uk> |
| In reply to | #4031 |
Uncle Steve <stevet810@gmail.com> writes: > On Sun, May 15, 2011 at 04:01:25AM +0100, Ben Bacarisse wrote: >> Uncle Steve <stevet810@gmail.com> writes: >> >> > On Sat, May 14, 2011 at 05:45:49PM -0400, Eric Sosman wrote: >> >> On 5/14/2011 3:25 PM, Uncle Steve wrote: >> <snip> >> >> >It could do just about anything if it was a C function, couldn't it? >> >> >> >> C functions cannot return arrays, nor can they return array >> >> initializers. >> > >> > Hmm. I'm not sure why you think that's important. >> >> It's right there in the quotes. You asked if "it" (referring to your >> howmuchfoo function) "could do just about anything if it was a C >> function, couldn't it?". Eric answered by pointing out two things that >> it could *not* do. What's more, these are things that might be >> significant since the code fragment you showed: >> >> | int foops[] = howmuchfoo(void); >> >> suggested that howmuchfoo might be either returning an array or it might >> be trying to return an array initialiser. > > But only if it was a macro. Yes, that's been covered several times already. You specifically referred to "it" being a function -- hence Eric's answer and my attempt at clarification. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-15 03:59 +0000 |
| Message-ID | <slrnisudlh.2cpo.usenet-nospam@guild.seebs.net> |
| In reply to | #3974 |
On 2011-05-14, Uncle Steve <stevet810@gmail.com> wrote: > 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? Nearly anything? Most cesspits, for instance. > 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. Yes. I set them up at some point AFTER the program has started running, because before it's running the world is not in a known or well-defined state. > It could do just about anything if it was a C function, couldn't it? Well, that's the thing. How much do you know about the way in which the library initializes various internals which need to be in a particular state for your code to execute? > 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. I refer you to Rules 1 and 2 of optimization. Which is to say: Rule 1: Don't do it. Rule 2 (only for experts): Don't do it yet. For the sorts of things it makes sense to try to use as initializers, you can reasonably be confident that the value will be fully computed before your code is done compiling. There are, right now, probably as many as two dozen people in the world who have a legitimate reason to form thoughts like "what if this code ends up in the instruction cache?". You are not one of them. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-16 04:49 -0400 |
| Message-ID | <fd8c08cd3702e54-40650@gmail.com> |
| In reply to | #3996 |
Sorry, skipped your message this morning by accident. On Sun, May 15, 2011 at 03:59:14AM +0000, Seebs wrote: > On 2011-05-14, Uncle Steve <stevet810@gmail.com> wrote: > > 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? > > Nearly anything? Most cesspits, for instance. > > 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. > > Yes. I set them up at some point AFTER the program has started running, > because before it's running the world is not in a known or well-defined > state. Well, it's fairly difficult to approach this without making reference to a specific implementation. main() is supposed to be the defined entrypoint for C programs, and anything that happens before that is supposed (I assume) to set up the execution environment defined by the standard, and is implementation specific. OK. I get it. Sorry for my confusion over what the gcc info doc said. > > It could do just about anything if it was a C function, couldn't it? > > Well, that's the thing. How much do you know about the way in which > the library initializes various internals which need to be in a particular > state for your code to execute? I don't know anything about how the system libraries are initialized. Perhaps I should look; glibc, ulibc, bsd libc, etc. probably all do things differently (within reason), meaning I'd probably have to code a special case for every port of the app. if I was to use implementation- specific hooks. > > 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. > > I refer you to Rules 1 and 2 of optimization. > > Which is to say: > > Rule 1: Don't do it. > Rule 2 (only for experts): Don't do it yet. I rely on a consistent heuristic: develop efficient coding habits. Within the limits of my skill, this seems to work ok. I don't really agonize over loops as I might have when I was a teenager fooling around with asm on small machines. I know the other Rule of optimization: Rule 3: Write better algorithms. Which isn't to say that it can't be fun to find a clever way to shave cycles. There are an endless number of programming tricks that one can experiment with, on critical paths, if you've got the time. > For the sorts of things it makes sense to try to use as initializers, you > can reasonably be confident that the value will be fully computed before > your code is done compiling. For many scalars and string constants this is true, and I have no argument about that fact. What this is becoming, however, is a pedantic disagreement over the validity of function calls in the outermost scope of a C program. It seems a little arbitrary that function calls are only valid in the main() scope, or at least this is what I perceive as being what the standard says from your replies. Don't worry, I'm not going to press the C2015 Committee[1] to revise the standard. I simply don't care about it all that much, but it is worth noting. > There are, right now, probably as many as two dozen people in the world > who have a legitimate reason to form thoughts like "what if this code > ends up in the instruction cache?". You are not one of them. Alas, you have penetrated my disguise. I am not worthy to decide what code should or should not be in the instruction cache. I am sorry if I have offended your grace, or shamed the honored guild of instruction cachers with my unworthy considerations. In the Future, I will endeavor to think about memory as a transparent medium of data storage. [1] Joke. Not sure what the next revision of C will be called. I can't see there being many changes at this point, C should be about ready to be carved in stone by now. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web