- labels at the end of a function - 12 Updates
- Virtual pure function call without constructor - 2 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 29 08:35PM -0500 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 <sam@email-scan.com>: Aug 29 10:42PM -0400 Lynn McGuire writes: > } > Is there any way to get around the requirement of the executable statement > after the label ? 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 <ike@sdf.org>: Aug 30 05:50AM > } > Is there any way to get around the requirement of the executable > statement after the label ? Put an empty statement after the label: int aMethod() { /* ... */ goto aLabel; /* ... */ aLabel: ; } or use ``return'' instead of ``goto'': int aMethod() { /* ... */ return; /* ... */ } |
| Bo Persson <bo@bo-persson.se>: Aug 30 09:14AM +0200 On 2022-08-30 at 03:35, Lynn McGuire wrote: > } > Is there any way to get around the requirement of the executable > statement after the label ? 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 <diespammer@yahoo.it>: Aug 30 10:14AM +0200 On 8/30/22 07:50, Ike Naar wrote: > 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 <anton.txt@g{oogle}mail.com>: Aug 30 12:46PM +0300 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 <nospam@thanks.invalid>: Aug 30 11:20AM > 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@slp53.sl.home (Scott Lurndal): Aug 30 01:21PM >} >Is there any way to get around the requirement of the executable >statement after the label ? Your function is missing a return statement. |
| gazelle@shell.xmission.com (Kenny McCormack): Aug 30 02:44PM In article <99oPK.21145$6Il8.5192@fx14.iad>, >>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? -- 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 <ifonly@youknew.org>: Aug 30 08:15PM +0200 Le 30/08/2022 à 11:46, Anton Shepelev a écrit : > 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 <lynnmcguire5@gmail.com>: Aug 30 04:08PM -0500 On 8/30/2022 9:44 AM, Kenny McCormack wrote: >> 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 <anton.txt@gmail.com>: Aug 31 01:04AM +0300 Lynn McGuire to Kenny McCormack: > 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'? |
| Manfred <noname@add.invalid>: Aug 30 02:28AM +0200 On 8/29/2022 3:56 PM, Marcel Mueller wrote: > The latter was likely the problem. The automatically generated move or > copy constructor probably somehow generated a dangling reference. > Marcel If you have virtual functions, then it's not a POD. |
| Richard Damon <Richard@Damon-Family.org>: Aug 30 07:49AM -0400 On 8/29/22 9:44 AM, Marcel Mueller wrote: >> I can see it happening with threads (the constructor/destructor is in >> a different Thread). > That's UB. Anything can happen. Yep, and the error mentioned is one of them. > The compiler should prevent that kind of slicing because no variable of > an abstract type can exist. > Marcel That's why I said "Not Sure". I wasn't going to say definitively that it wasn't possible. The comment about accessing the distructed object was one way to get such a sliced object (but again, invoking Undefined Behavior). |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment