labels at the end of a function

[Lynn McGuire]

I just found out that a label at the end of a c/c++ function must have
an executable statement after it.

int aMethod ()
{
int aFakeVar = 0;

goto aLabel;

aLabel:

aFakeVar++;
}

Is there any way to get around the requirement of the executable
statement after the label ?

Thanks,
Lynn

[Sam]

There are two options:

1) get rid of the label and the goto. The more goto-s get written, the more
likely is it for Chulhu to appear and bring humanity to an end. Very messy.

2) a single semicolon should be executable enough. I'm too lazy to check. In
any case

if (0)
;

will definitely work.

[Ike Naar]

Put an empty statement after the label:

int aMethod()
{
/* ... */
goto aLabel;
/* ... */
aLabel:
;
}

or use ``return'' instead of ``goto'':

int aMethod()
{
/* ... */
return;
/* ... */
}

[Bo Persson]

Not right now, but it will be allowed in C++23. :-)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2324r2.pdf

[Elephant]

On 8/30/22 07:50, Ike Naar wrote:

> or use ``return'' instead of ``goto'':
>
> int aMethod()
> {
> /* ... */
> return;
> /* ... */
> }

Preferebly with a value, since the signature says the function returns
an int :)

Seriously, the fact that the question was asked on a non void-returning
function is an additional code-smell over the goto in itself.

[Anton Shepelev]

Sam:

> The more goto-s get written, the more likely is it for
> Chulhu to appear and bring humanity to an end.

I disagree. Structured use of GOTO's (the topic of a Knuch
article!), especially when they jump down and nest stack-
like can greately simplify certain code structures. They
help to avoid returns from mid-function, and let the
programmer execute common deinitialisation code. My standard
pattern of error-handling is based on GOTO's:

https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[Juha Nieminen]

In comp.lang.c++ Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> The more goto-s get written, the more likely is it for
>> Chulhu to appear and bring humanity to an end.
>
> I disagree. Structured use of GOTO's (the topic of a Knuch
> article!), especially when they jump down and nest stack-
> like can greately simplify certain code structures. They
> help to avoid returns from mid-function, and let the
> programmer execute common deinitialisation code.

That may be true in C, but C++ throws a spanner in the works because
of one fun feature: Exceptions.

If running the deinitialization code is crucial (or else for example
resources will be leaked, such as file handles left open), it won't
be run no matter how many gotos you use if anything along the line
throws an exception and it's not caught.

This is one of the main reasons to use RAII instead of gotos: Object
destructors will always be run no matter how the function is exited,
be it an early return, be it an exception.

As a bonus, if you implement it properly, the code will actually become
cleaner.

[Scott Lurndal]

Your function is missing a return statement.

[Kenny McCormack]

In article <99oPK.21145$6Il8...@fx14.iad>,

Or they misspelled "void" as "int".

P.S. Why is this also posted to a Fortran group?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

[Opus]

Le 30/08/2022 à 11:46, Anton Shepelev a écrit :
> Sam:
>
>> The more goto-s get written, the more likely is it for
>> Chulhu to appear and bring humanity to an end.
>
> I disagree. Structured use of GOTO's (the topic of a Knuch
> article!), especially when they jump down and nest stack-
> like can greately simplify certain code structures. They
> help to avoid returns from mid-function, and let the
> programmer execute common deinitialisation code. My standard
> pattern of error-handling is based on GOTO's:
>
> https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

This is a relatively common pattern in C, and I also use it occasionally
(meaning, not in all cases.)

I find it quirky though, and it works for lack of better flow control in
C. Something that is sometimes implemented as "defer" in other languages.

[Lynn McGuire]

On 8/30/2022 9:44 AM, Kenny McCormack wrote:
> In article <99oPK.21145$6Il8...@fx14.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
>> Lynn McGuire <lynnmc...@gmail.com> writes:
>>> I just found out that a label at the end of a c/c++ function must have
>>> an executable statement after it.
>>>
>>> int aMethod ()
>>> {
>>> int aFakeVar = 0;
>>>
>>> goto aLabel;
>>>
>>> aLabel:
>>>
>>> aFakeVar++;
>>> }
>>>
>>> Is there any way to get around the requirement of the executable
>>> statement after the label ?
>>
>> Your function is missing a return statement.
>
> Or they misspelled "void" as "int".
>
> P.S. Why is this also posted to a Fortran group?

Because I typed comp.lang.c into Thunderbird and Thunderbird graciously
also put comp.lang.fortran in there for me which I did not notice.

Lynn

[Anton Shepelev]

Lynn McGuire to Kenny McCormack:

> > P.S. Why is this also posted to a Fortran group?
>
> Because I typed comp.lang.c into Thunderbird and
> Thunderbird graciously also put comp.lang.fortran in there
> for me which I did not notice.

Amazing grace. Did you mean `gratuitiously'?

[Lynn McGuire]

Thanks to all ! I now understand a little bit better. I've been
programming in Fortran for 47 years, C for 35 years, and C++ for 20
years. I always like learning a little bit more about each.

Lynn