Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #387705
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: on allowing "int a" definition everywhere |
| Date | 2024-08-22 11:12 -0700 |
| Organization | None to speak of |
| Message-ID | <87cym0h1eh.fsf@nosuchdomain.example.com> (permalink) |
| References | (2 earlier) <pan$8a32c$1fb86219$8ea0c6ae$7c2d1765@invalid.invalid> <va4id0$3rc3n$1@dont-email.me> <pan$2be2c$5ea44d54$282eec3$b0bcf030@invalid.invalid> <87h6bchpzf.fsf@nosuchdomain.example.com> <87plq026li.fsf@bsb.me.uk> |
Ben Bacarisse <ben@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> The original code:
>>
>> if (FILE* f = fopen("file.txt", "r"))
>
> I think the proposal would be a declaration to precede an expression:
>
> if (FILE* f = fopen("file.txt", "r"); f)
I don't think so, or at least I don't think it's only that.
In C++17, the syntax for an if statement is (leaving some stuff out):
if ( init-statement[opt] condition ) statement
where an init-statement is an expression statement or a simple
declaration (which includes a trailing semicolon), and a condition is an
expression or a declarator with an initialization. So these are
equivalent in C++:
if (FILE* f = fopen("file.txt", "r"))
if (FILE* f = fopen("file.txt", "r"); f)
>> {
>> /*...*/ fclose(f);
>> }
>>
>> doesn't allow for taking some non-trivial action of the fopen() call
>> fails, but if a declaration in an if condition is visible in the else
>> clause, you could write something like:
>>
>> if (FILE* f = fopen("file.txt", "r")) {
>> /*...*/
>> fclose(f);
>> }
>> else {
>> perror("file.txt");
>> exit(EXIT_FAILURE); // or try something else
>> }
>
> What's the significance of the declared name being in scope in the else
> clause here?
My brain seems to have taken a detour while I was writing that.
fopen() returns either a valid pointer or NULL; if it fails, there's no
extra information in the pointer itself. But if a function's result on
failure includes information about how it failed, accessing the value in
the else clause is useful. (And C++ supports this.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-20 18:48 +0200
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-20 14:03 -0300
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-20 19:18 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-20 19:21 +0200
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-20 14:34 -0300
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-20 22:18 +0200
Re: on allowing "int a" definition everywhere Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-08-21 04:42 +0000
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-21 08:17 -0300
Re: on allowing "int a" definition everywhere Bart <bc@freeuk.com> - 2024-08-21 13:34 +0100
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-21 10:01 -0300
Re: on allowing "int a" definition everywhere Michael S <already5chosen@yahoo.com> - 2024-08-21 16:54 +0300
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-21 11:21 -0300
Re: on allowing "int a" definition everywhere Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-08-22 08:40 +0000
Re: on allowing "int a" definition everywhere Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-22 02:21 -0700
Re: on allowing "int a" definition everywhere Ben Bacarisse <ben@bsb.me.uk> - 2024-08-22 11:29 +0100
Re: on allowing "int a" definition everywhere Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-22 11:12 -0700
Re: on allowing "int a" definition everywhere Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-22 18:37 +0000
Re: on allowing "int a" definition everywhere Ben Bacarisse <ben@bsb.me.uk> - 2024-08-23 00:39 +0100
Re: on allowing "int a" definition everywhere Bart <bc@freeuk.com> - 2024-08-22 11:00 +0100
Re: on allowing "int a" definition everywhere Thiago Adams <thiago.adams@gmail.com> - 2024-08-22 08:10 -0300
Re: on allowing "int a" definition everywhere Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-08-22 17:06 +0000
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-23 12:47 +0200
Re: on allowing "int a" definition everywhere Bart <bc@freeuk.com> - 2024-08-23 12:25 +0100
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-23 13:32 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-23 17:57 +0200
Re: on allowing "int a" definition everywhere Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-21 03:30 +0000
Re: on allowing "int a" definition everywhere Ben Bacarisse <ben@bsb.me.uk> - 2024-08-21 09:19 +0100
Re: on allowing "int a" definition everywhere Ben Bacarisse <ben@bsb.me.uk> - 2024-08-21 10:11 +0100
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-25 12:40 +0200
Re: on allowing "int a" definition everywhere Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 06:52 +0000
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 10:46 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 11:03 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 11:08 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 11:47 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 11:52 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 13:56 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 20:04 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 20:44 +0200
Re: on allowing "int a" definition everywhere Bart <bc@freeuk.com> - 2024-08-27 19:59 +0100
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 21:36 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 22:02 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 23:42 +0200
Re: on allowing "int a" definition everywhere Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-02 03:32 +0000
Re: on allowing "int a" definition everywhere Bart <bc@freeuk.com> - 2024-09-02 10:53 +0100
Re: on allowing "int a" definition everywhere Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 04:54 +0000
Re: on allowing "int a" definition everywhere Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-03 06:12 +0000
Re: on allowing "int a" definition everywhere Michael S <already5chosen@yahoo.com> - 2024-09-03 12:20 +0300
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-27 21:09 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-29 09:24 +0200
Re: on allowing "int a" definition everywhere fir <fir@grunge.pl> - 2024-08-29 09:37 +0200
Re: on allowing "int a" definition everywhere Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 04:56 +0000
Re: on allowing "int a" definition everywhere Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-08-27 12:28 +0000
Re: on allowing "int a" definition everywhere Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-27 18:45 -0700
Re: on allowing "int a" definition everywhere Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-27 19:23 -0700
Re: on allowing "int a" definition everywhere Ben Bacarisse <ben@bsb.me.uk> - 2024-08-28 15:28 +0100
Re: on allowing "int a" definition everywhere Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 08:37 -0700
Re: on allowing "int a" definition everywhere Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 08:22 -0700
Re: on allowing "int a" definition everywhere Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-28 13:06 -0700
Re: on allowing "int a" definition everywhere Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 09:31 -0700
Re: on allowing "int a" definition everywhere David Brown <david.brown@hesbynett.no> - 2024-08-28 19:39 +0200
Re: on allowing "int a" definition everywhere James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-28 14:34 -0400
Re: on allowing "int a" definition everywhere Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-28 13:06 -0700
csiph-web