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

Groups > comp.lang.c > #112240 > unrolled thread

[poll/chitchat] What's the best main(){...} ?

Back to article view | Back to comp.lang.c

Contents

  [poll/chitchat] What's the best main(){...} ? luser droog <luser.droog@gmail.com> - 2017-06-14 22:30 -0700
    Re: [poll/chitchat] What's the best main(){...} ? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-15 06:14 +0000
      Re: [poll/chitchat] What's the best main(){...} ? luser droog <luser.droog@gmail.com> - 2017-06-15 00:06 -0700
      Re: [poll/chitchat] What's the best main(){...} ? scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 12:43 +0000
        Re: [poll/chitchat] What's the best main(){...} ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 06:32 -0700
          Re: [poll/chitchat] What's the best main(){...} ? scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 14:03 +0000
            Re: [poll/chitchat] What's the best main(){...} ? James Kuyper <jameskuyper@verizon.net> - 2017-06-15 10:07 -0400
        Re: [poll/chitchat] What's the best main(){...} ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 15:47 +0100
        Re: [poll/chitchat] What's the best main(){...} ? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:47 -0700
      Re: [poll/chitchat] What's the best main(){...} ? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-16 18:32 +0800
    Re: [poll/chitchat] What's the best main(){...} ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 06:31 -0700
    Re: [poll/chitchat] What's the best main(){...} ? David Brown <david.brown@hesbynett.no> - 2017-06-15 16:18 +0200
      Re: [poll/chitchat] What's the best main(){...} ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 07:35 -0700
        Re: [poll/chitchat] What's the best main(){...} ? David Brown <david.brown@hesbynett.no> - 2017-06-15 17:35 +0200
          Re: [poll/chitchat] What's the best main(){...} ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 08:41 -0700
            Re: [poll/chitchat] What's the best main(){...} ? David Brown <david.brown@hesbynett.no> - 2017-06-15 21:18 +0200
              Re: [poll/chitchat] What's the best main(){...} ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 12:39 -0700
              Re: [poll/chitchat] What's the best main(){...} ? David Kleinecke <dkleinecke@gmail.com> - 2017-06-15 19:58 -0700
          Re: [poll/chitchat] What's the best main(){...} ? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-15 17:01 +0100
            Re: [poll/chitchat] What's the best main(){...} ? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-15 16:13 +0000
              Re: [poll/chitchat] What's the best main(){...} ? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-15 17:42 +0100
                Re: [poll/chitchat] What's the best main(){...} ? David Brown <david.brown@hesbynett.no> - 2017-06-15 21:21 +0200
                  Re: [poll/chitchat] What's the best main(){...} ? Gareth Owen <gwowen@gmail.com> - 2017-06-15 20:48 +0100
                  Re: [poll/chitchat] What's the best main(){...} ? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-15 20:55 +0100

Page 1 of 2  [1] 2  Next page →

#112240 — [poll/chitchat] What's the best main(){...} ?

The sine qua non of a C program is its entry point, main().
Much discussion and argumentation have gone into the details
of the declaration part. But I'm much more interested in the
body. What's your favorite or ideal example of the perfect
main() function?

Here's mine. For a hypothetical program to do something or other.

int main(){
    return init()
        && run();
}

[toc] | [next] | [standalone]

#112241

On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
> The sine qua non of a C program is its entry point, main().
> Much discussion and argumentation have gone into the details
> of the declaration part. But I'm much more interested in the
> body. What's your favorite or ideal example of the perfect
> main() function?
>
> Here's mine. For a hypothetical program to do something or other.
>
> int main(){
>     return init()
>         && run();
> }
Well,
int main(int argc, char* argv[]) {
    return init(argc,argv) && run();
}

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#112242

On Thursday, June 15, 2017 at 1:14:11 AM UTC-5, Melzzzzz wrote:
> On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
> > The sine qua non of a C program is its entry point, main().
> > Much discussion and argumentation have gone into the details
> > of the declaration part. But I'm much more interested in the
> > body. What's your favorite or ideal example of the perfect
> > main() function?
> >
> > Here's mine. For a hypothetical program to do something or other.
> >
> > int main(){
> >     return init()
> >         && run();
> > }
> Well,
> int main(int argc, char* argv[]) {
>     return init(argc,argv) && run();
> }
> 

Yes. Good call. I thought of that shortly after posting.

What if it uses the arguments to choose input and output
files. Rather than pass them in global variables, they
might be better held in main.

 #include <stdio.h>

 int main(int argc, char* argv[]) {
     FILE *input, *output;
     return init(argc,argv,&input,&output) && run(input,output);
 }

[toc] | [prev] | [next] | [standalone]

#112249

Melzzzzz <Melzzzzz@zzzzz.com> writes:
>On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
>> The sine qua non of a C program is its entry point, main().
>> Much discussion and argumentation have gone into the details
>> of the declaration part. But I'm much more interested in the
>> body. What's your favorite or ideal example of the perfect
>> main() function?
>>
>> Here's mine. For a hypothetical program to do something or other.
>>
>> int main(){
>>     return init()
>>         && run();
>> }
>Well,
>int main(int argc, char* argv[]) {
>    return init(argc,argv) && run();
>}

Or if you want a non-boolean exit code from run
to be used as the exit value:

int
main(int argc, const char * const *argv)
{
    return init(argc, argv), run();
}

[toc] | [prev] | [next] | [standalone]

#112253

On Thursday, June 15, 2017 at 8:44:00 AM UTC-4, Scott Lurndal wrote:
> Melzzzzz <Melzzzzz@zzzzz.com> writes:
> >On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
> >> The sine qua non of a C program is its entry point, main().
> >> Much discussion and argumentation have gone into the details
> >> of the declaration part. But I'm much more interested in the
> >> body. What's your favorite or ideal example of the perfect
> >> main() function?
> >>
> >> Here's mine. For a hypothetical program to do something or other.
> >>
> >> int main(){
> >>     return init()
> >>         && run();
> >> }
> >Well,
> >int main(int argc, char* argv[]) {
> >    return init(argc,argv) && run();
> >}
> 
> Or if you want a non-boolean exit code from run
> to be used as the exit value:
> 
> int
> main(int argc, const char * const *argv)
> {
>     return init(argc, argv), run();
> }

Why do you define the argv[] values as const?  You can overwrite
their content.  It's sometimes useful for parsing out options,
to replace their leading "/" or "-" with a code indicating it's
been processed, such as "\" or "+".

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112254

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On Thursday, June 15, 2017 at 8:44:00 AM UTC-4, Scott Lurndal wrote:
>> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>> >On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
>> >> The sine qua non of a C program is its entry point, main().
>> >> Much discussion and argumentation have gone into the details
>> >> of the declaration part. But I'm much more interested in the
>> >> body. What's your favorite or ideal example of the perfect
>> >> main() function?
>> >>
>> >> Here's mine. For a hypothetical program to do something or other.
>> >>
>> >> int main(){
>> >>     return init()
>> >>         && run();
>> >> }
>> >Well,
>> >int main(int argc, char* argv[]) {
>> >    return init(argc,argv) && run();
>> >}
>> 
>> Or if you want a non-boolean exit code from run
>> to be used as the exit value:
>> 
>> int
>> main(int argc, const char * const *argv)
>> {
>>     return init(argc, argv), run();
>> }
>
>Why do you define the argv[] values as const?  You can overwrite
>their content.  It's sometimes useful for parsing out options,
>to replace their leading "/" or "-" with a code indicating it's
>been processed, such as "\" or "+".

Because there is no guarantee that I'm aware of that one can
overwrite the content, mistakes can be costly, it is trivally easy to make a copy
if necessary, and it is sometimes required to pass the original
arguments to a newly created (forked) process in POSIX compliant
code.

[toc] | [prev] | [next] | [standalone]

#112255

On 06/15/2017 10:03 AM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On Thursday, June 15, 2017 at 8:44:00 AM UTC-4, Scott Lurndal wrote:
...
>>> int
>>> main(int argc, const char * const *argv)
>>> {
>>>     return init(argc, argv), run();
>>> }
>>
>> Why do you define the argv[] values as const?  You can overwrite
>> their content.  It's sometimes useful for parsing out options,
>> to replace their leading "/" or "-" with a code indicating it's
>> been processed, such as "\" or "+".
> 
> Because there is no guarantee that I'm aware of that one can
> overwrite the content, ...

"The parameters argc and argv and the strings pointed to by the argv
array shall be modifiable by the program, and retain their last-stored
values between program startup and program termination." (5.1.2.2.1p2)

[toc] | [prev] | [next] | [standalone]

#112260

scott@slp53.sl.home (Scott Lurndal) writes:

> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>>On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
>>> The sine qua non of a C program is its entry point, main().
>>> Much discussion and argumentation have gone into the details
>>> of the declaration part. But I'm much more interested in the
>>> body. What's your favorite or ideal example of the perfect
>>> main() function?
>>>
>>> Here's mine. For a hypothetical program to do something or other.
>>>
>>> int main(){
>>>     return init()
>>>         && run();
>>> }
>>Well,
>>int main(int argc, char* argv[]) {
>>    return init(argc,argv) && run();
>>}
>
> Or if you want a non-boolean exit code from run
> to be used as the exit value:
>
> int
> main(int argc, const char * const *argv)
> {
>     return init(argc, argv), run();
> }

Or, since run my depends of things parsed from init and globals are a
Bad Idea:

  int main(int argc, char **argv)
  {
      return run(init(argc, argv));
  }

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#112392

scott@slp53.sl.home (Scott Lurndal) writes:

> Melzzzzz <Melzzzzz@zzzzz.com> writes:
>
>> On 2017-06-15, luser droog <luser.droog@gmail.com> wrote:
>>
>>> The sine qua non of a C program is its entry point, main().
>>> Much discussion and argumentation have gone into the details
>>> of the declaration part.  But I'm much more interested in the
>>> body.  What's your favorite or ideal example of the perfect
>>> main() function?
>>>
>>> Here's mine.  For a hypothetical program to do something or other.
>>>
>>> int main(){
>>>     return init()
>>>         && run();
>>> }
>>
>> Well,
>> int main(int argc, char* argv[]) {
>>    return init(argc,argv) && run();
>> }
>
> Or if you want a non-boolean exit code from run
> to be used as the exit value:
>
> int
> main(int argc, const char * const *argv)
> {
>     return init(argc, argv), run();
> }

The 'const' qualifiers cannot be relied on to give
defined behavior.

[toc] | [prev] | [next] | [standalone]

#112332

On 15/6/2017 2:14 PM, Melzzzzz wrote:
> Well,
> int main(int argc, char* argv[]) {
>      return init(argc,argv) && run();
> }

Add my vote to this one. :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#112252

On Thursday, June 15, 2017 at 1:30:37 AM UTC-4, luser droog wrote:
> The sine qua non of a C program is its entry point, main().
> Much discussion and argumentation have gone into the details
> of the declaration part. But I'm much more interested in the
> body. What's your favorite or ideal example of the perfect
> main() function?
> 
> Here's mine. For a hypothetical program to do something or other.
> 
> int main(){
>     return init()
>         && run();
> }

I would suggest a different form:

    int main(int argc, char* argv[])
    {
        int retinit;

        // Success or failure during init
        if ((retinit = init(argc, argv)) < 0)
            return(retint);

        // Success or failure during run
        return(((run()) ? 0 : -9999);
    }

It allows you the ability to examine the value when debugging, and
to know which one failed.  Use standard -1, -2, -3 ... codes for
your init() failures, and then the -9999 indicates a run failure.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112258

On 15/06/17 07:30, luser droog wrote:
> The sine qua non of a C program is its entry point, main().
> Much discussion and argumentation have gone into the details
> of the declaration part. But I'm much more interested in the
> body. What's your favorite or ideal example of the perfect
> main() function?
> 
> Here's mine. For a hypothetical program to do something or other.
> 
> int main(){
>     return init()
>         && run();
> }
> 

My usual setup has a pattern like :

int main(void) {
	init();
	while (true) {
		run();
	}
}

[toc] | [prev] | [next] | [standalone]

#112259

On Thursday, June 15, 2017 at 10:18:53 AM UTC-4, David Brown wrote:
> My usual setup has a pattern like :
> 
> int main(void) {
> 	init();
> 	while (true) {
> 		run();
> 	}
> }

Does the usual support call at your support desk go something like
this:

    "Yes, I keep clicking the exit button, but it doesn't do
     anything.  It just stays in the program.  I have to use
     a task manager to get the app to forcibly terminate.  It's
     extremely frustrating."

??  Just asking.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112267

On 15/06/17 16:35, Rick C. Hodgin wrote:
> On Thursday, June 15, 2017 at 10:18:53 AM UTC-4, David Brown wrote:
>> My usual setup has a pattern like :
>>
>> int main(void) {
>> 	init();
>> 	while (true) {
>> 		run();
>> 	}
>> }
> 
> Does the usual support call at your support desk go something like
> this:
> 
>     "Yes, I keep clicking the exit button, but it doesn't do
>      anything.  It just stays in the program.  I have to use
>      a task manager to get the app to forcibly terminate.  It's
>      extremely frustrating."
> 

No.

Nor do customers ring and say that their robot submarine needs to be
turned on and off again to make it go for a second dive.

Different types of task have different requirements - very few of the
programs I write (for customers) are designed to do a task and then
stop.  Even the gui programs on PC's are typically run until the PC is
killed by a power cut (though they do have an option to exit!).

[toc] | [prev] | [next] | [standalone]

#112269

On Thursday, June 15, 2017 at 11:36:08 AM UTC-4, David Brown wrote:
> On 15/06/17 16:35, Rick C. Hodgin wrote:
> > On Thursday, June 15, 2017 at 10:18:53 AM UTC-4, David Brown wrote:
> >> My usual setup has a pattern like :
> >>
> >> int main(void) {
> >> 	init();
> >> 	while (true) {
> >> 		run();
> >> 	}
> >> }
> > 
> > Does the usual support call at your support desk go something like
> > this:
> > 
> >     "Yes, I keep clicking the exit button, but it doesn't do
> >      anything.  It just stays in the program.  I have to use
> >      a task manager to get the app to forcibly terminate.  It's
> >      extremely frustrating."
> > 
> 
> No.
> 
> Nor do customers ring and say that their robot submarine needs to be
> turned on and off again to make it go for a second dive.
> 
> Different types of task have different requirements - very few of the
> programs I write (for customers) are designed to do a task and then
> stop.  Even the gui programs on PC's are typically run until the PC is
> killed by a power cut (though they do have an option to exit!).

Well then.  My mistake.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112285

On 15/06/17 17:41, Rick C. Hodgin wrote:
> On Thursday, June 15, 2017 at 11:36:08 AM UTC-4, David Brown wrote:
>> On 15/06/17 16:35, Rick C. Hodgin wrote:
>>> On Thursday, June 15, 2017 at 10:18:53 AM UTC-4, David Brown wrote:
>>>> My usual setup has a pattern like :
>>>>
>>>> int main(void) {
>>>> 	init();
>>>> 	while (true) {
>>>> 		run();
>>>> 	}
>>>> }
>>>
>>> Does the usual support call at your support desk go something like
>>> this:
>>>
>>>      "Yes, I keep clicking the exit button, but it doesn't do
>>>       anything.  It just stays in the program.  I have to use
>>>       a task manager to get the app to forcibly terminate.  It's
>>>       extremely frustrating."
>>>
>>
>> No.
>>
>> Nor do customers ring and say that their robot submarine needs to be
>> turned on and off again to make it go for a second dive.
>>
>> Different types of task have different requirements - very few of the
>> programs I write (for customers) are designed to do a task and then
>> stop.  Even the gui programs on PC's are typically run until the PC is
>> killed by a power cut (though they do have an option to exit!).
> 
> Well then.  My mistake.
> 

It was not an unreasonable question.  But in embedded systems 
programming, it is normal for programs never to stop.  The same applies 
to operating systems - even if you tell your PC to "shutdown" or "halt", 
the OS does not return from "main".

[toc] | [prev] | [next] | [standalone]

#112288

On Thursday, June 15, 2017 at 3:18:37 PM UTC-4, David Brown wrote:
> It was not an unreasonable question...

I was solely going for humor.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112322

On Thursday, June 15, 2017 at 12:18:37 PM UTC-7, David Brown wrote:
> On 15/06/17 17:41, Rick C. Hodgin wrote:
> > On Thursday, June 15, 2017 at 11:36:08 AM UTC-4, David Brown wrote:
> >> On 15/06/17 16:35, Rick C. Hodgin wrote:
> >>> On Thursday, June 15, 2017 at 10:18:53 AM UTC-4, David Brown wrote:
> >>>> My usual setup has a pattern like :
> >>>>
> >>>> int main(void) {
> >>>> 	init();
> >>>> 	while (true) {
> >>>> 		run();
> >>>> 	}
> >>>> }
> >>>
> >>> Does the usual support call at your support desk go something like
> >>> this:
> >>>
> >>>      "Yes, I keep clicking the exit button, but it doesn't do
> >>>       anything.  It just stays in the program.  I have to use
> >>>       a task manager to get the app to forcibly terminate.  It's
> >>>       extremely frustrating."
> >>>
> >>
> >> No.
> >>
> >> Nor do customers ring and say that their robot submarine needs to be
> >> turned on and off again to make it go for a second dive.
> >>
> >> Different types of task have different requirements - very few of the
> >> programs I write (for customers) are designed to do a task and then
> >> stop.  Even the gui programs on PC's are typically run until the PC is
> >> killed by a power cut (though they do have an option to exit!).
> > 
> > Well then.  My mistake.
> > 
> 
> It was not an unreasonable question.  But in embedded systems 
> programming, it is normal for programs never to stop.  The same applies 
> to operating systems - even if you tell your PC to "shutdown" or "halt", 
> the OS does not return from "main".

I can remember an old BIOS that, if irritated enough, went into
a one instruction loop. That was IMO an excellent simulation of 
a stop.

I am irritated nowadays by faulty scripts that fail in loops
so tight that even the mouse wont respond. I have had to turn
the power off and back on to clear a couple of them up.

Of course, my problem may be my OS - Ubuntu.

[toc] | [prev] | [next] | [standalone]

#112270

On 15/06/17 16:35, David Brown wrote:
<snip>

> Different types of task have different requirements - very few of the
> programs I write (for customers) are designed to do a task and then
> stop.  Even the gui programs on PC's are typically run until the PC is
> killed by a power cut (though they do have an option to exit!).

Or they kill the PC themselves.

Recently Firefox has taken to shutting down my laptop if I have the 
temerity to watch a Youtube video. (But only sometimes, of course. 
Heaven forbid that the fault should be reproducible on demand!)

The weird thing is that, when I start the laptop up again and get back 
to editing the file I was working on when I decided to hang five and 
Firefox decided to double it to ten, gvim /doesn't/ complain about the 
swap file.

This suggests to me that Firefox might be shutting down cleanly (i.e. 
sending a "going down" signal to programs to give them a chance to play 
nice). It's hard to imagine how this could be put down to ordinary 
incompetence, but on the other hand it doesn't (quite) sound like 
deliberate malice either.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#112271

On 2017-06-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 15/06/17 16:35, David Brown wrote:
><snip>
>
>> Different types of task have different requirements - very few of the
>> programs I write (for customers) are designed to do a task and then
>> stop.  Even the gui programs on PC's are typically run until the PC is
>> killed by a power cut (though they do have an option to exit!).
>
> Or they kill the PC themselves.
>
> Recently Firefox has taken to shutting down my laptop if I have the 
> temerity to watch a Youtube video. (But only sometimes, of course. 
> Heaven forbid that the fault should be reproducible on demand!)
>
> The weird thing is that, when I start the laptop up again and get back 
> to editing the file I was working on when I decided to hang five and 
> Firefox decided to double it to ten, gvim /doesn't/ complain about the 
> swap file.
>
> This suggests to me that Firefox might be shutting down cleanly (i.e. 
> sending a "going down" signal to programs to give them a chance to play 
> nice). It's hard to imagine how this could be put down to ordinary 
> incompetence, but on the other hand it doesn't (quite) sound like 
> deliberate malice either.

Any youtube video? Perhaps low battery condition triggers shutdown or
such?

>


-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web