digitalmars.D.learn - Reverse Lexical Order
- Manfred Nowak (5/5) Jul 15 2013 From the docs:
- Jonathan M Davis (3/9) Jul 15 2013 Under what circumstances would they not be the same thing?
- Manfred Nowak (5/6) Jul 15 2013 http://dlang.org/statement.html#GotoStatement
- Jonathan M Davis (10/16) Jul 15 2013 Well, what that would do would depend on what happens with gotos and try...
- Manfred Nowak (5/7) Jul 15 2013 I did realize this nightmare. Therefore the assurance in the docs
- Jonathan M Davis (6/13) Jul 15 2013 Well, I'd have to study exactly how goto works to say how exactly it wou...
- H. S. Teoh (11/25) Jul 15 2013 [...]
- Jacob Carlborg (6/12) Jul 16 2013 The docs say: "Any intervening finally clauses are executed, along with
- Manfred Nowak (19/20) Jul 16 2013 This does not solve:
- monarch_dodra (20/55) Jul 16 2013 That's wrong. That's "longjmp", which does a raw ASM jump.
From the docs: "If there are multiple ScopeGuardStatements in a scope, they are executed in the reverse lexical order in which they appear." Is lexical or executional order meant? -manfred
Jul 15 2013
On Monday, July 15, 2013 12:20:57 Manfred Nowak wrote:From the docs: "If there are multiple ScopeGuardStatements in a scope, they are executed in the reverse lexical order in which they appear." Is lexical or executional order meant?Under what circumstances would they not be the same thing? - Jonathan M Davis
Jul 15 2013
Jonathan M Davis wrote:Under what circumstances would they not be the same thing?http://dlang.org/statement.html#GotoStatement At least the famous gots can make lexical ordering different to executional ordering. -manfred
Jul 15 2013
On Monday, July 15, 2013 13:02:54 Manfred Nowak wrote:Jonathan M Davis wrote:Well, what that would do would depend on what happens with gotos and try- catch-finally blocks, because scope statements are lowered to try-catch-finally blocks. So, if you know what gotos do with them (and I personally have no idea how gotos affect stuff like destructors being run when you leave the scope, since you're not leaving it normally or properly), then you can figure it out by translating the scope statements to the set of try-catch-finally statements which would have the same semantics. gotos in such a context seem like a bit of a nightmare to me though. - Jonathan M DavisUnder what circumstances would they not be the same thing?http://dlang.org/statement.html#GotoStatement At least the famous gots can make lexical ordering different to executional ordering.
Jul 15 2013
Jonathan M Davis wrote:gotos in such a context seem like a bit of a nightmare to me though.I did realize this nightmare. Therefore the assurance in the docs is probably true only in the absence within the scope of at least gotos to targets within the scope. -manfred
Jul 15 2013
On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote:Jonathan M Davis wrote:Well, I'd have to study exactly how goto works to say how exactly it would interact with stuff like try-catch. I've pretty much only used goto with case statements and loops and haven't spent the time trying to sort out all of its idiosyncracies. I guess that I should add that to be my todo list. - Jonathan M Davisgotos in such a context seem like a bit of a nightmare to me though.I did realize this nightmare. Therefore the assurance in the docs is probably true only in the absence within the scope of at least gotos to targets within the scope.
Jul 15 2013
On Mon, Jul 15, 2013 at 08:59:44PM -0400, Jonathan M Davis wrote:On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote:[...] My understanding is that goto translates directly to a jump in assembly, so jumping in/out of blocks with declarations or stuff that needs cleanups should immediately raise red flags. Of course, the compiler may do something intelligent by inserting implicit stack pointer adjustments and/or cleanup blocks, but I wouldn't count on it unless the language spec explicitly requires so. T -- I am Ohm of Borg. Resistance is voltage over current.Jonathan M Davis wrote:Well, I'd have to study exactly how goto works to say how exactly it would interact with stuff like try-catch. I've pretty much only used goto with case statements and loops and haven't spent the time trying to sort out all of its idiosyncracies. I guess that I should add that to be my todo list.gotos in such a context seem like a bit of a nightmare to me though.I did realize this nightmare. Therefore the assurance in the docs is probably true only in the absence within the scope of at least gotos to targets within the scope.
Jul 15 2013
On 2013-07-16 03:11, H. S. Teoh wrote:My understanding is that goto translates directly to a jump in assembly, so jumping in/out of blocks with declarations or stuff that needs cleanups should immediately raise red flags. Of course, the compiler may do something intelligent by inserting implicit stack pointer adjustments and/or cleanup blocks, but I wouldn't count on it unless the language spec explicitly requires so.The docs say: "Any intervening finally clauses are executed, along with releasing any intervening synchronization mutexes." http://dlang.org/statement.html#GotoStatement -- /Jacob Carlborg
Jul 16 2013
On Tuesday, 16 July 2013 at 07:19:05 UTC, Jacob Carlborg wrote:The docs say: "Any intervening finally clauses are executed,This does not solve: /begin{ code} markA: if( exp1) goto markB; if( exp2) goto markC; ... scope ... ... markB: if( exp3) goto markA; if( exp4) goto markC; ... scope ... ... markC: /end{ code} where all expi are pairwise different. -manfred
Jul 16 2013
On Tuesday, 16 July 2013 at 01:13:15 UTC, H. S. Teoh wrote:On Mon, Jul 15, 2013 at 08:59:44PM -0400, Jonathan M Davis wrote:That's wrong. That's "longjmp", which does a raw ASM jump. C's goto correctly handles stack decrement if the jump would make you leave a scope (destroying a variable), and make a variable disappear. goto's aren't allowed to jump over declarations (unless they "skip" a scope entirelly). Some implementations allow it, but I have no idea how they non-POD type construction :S but stack pointer is always correctly handled. With C++'s destructors, goto has also been "improved" to guarantee that the destructor is called when a goto would make a variable leave a scope. In C++, I don't think it is possible to "leak" a stack variable's destructor, short of doing a longjmp. Long story short, in C, goto always perfectly safe (AFAIK). In C++, it depends on what the compiler will allow you to to do, depending on its "features". If it respects "strict ANSI", though, then you shouldn't be able to go wrong. -------- Related: I use goto fairly often, but I've yet to find a use-case for it outside of loop "improvement", or goto end cleanup. In both these cases, scope blocks should not be a problem.On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote:[...] My understanding is that goto translates directly to a jump in assembly, so jumping in/out of blocks with declarations or stuff that needs cleanups should immediately raise red flags. Of course, the compiler may do something intelligent by inserting implicit stack pointer adjustments and/or cleanup blocks, but I wouldn't count on it unless the language spec explicitly requires so. TJonathan M Davis wrote:Well, I'd have to study exactly how goto works to say how exactly it would interact with stuff like try-catch. I've pretty much only used goto with case statements and loops and haven't spent the time trying to sort out all of its idiosyncracies. I guess that I should add that to be my todo list.gotos in such a context seem like a bit of a nightmare to me though.I did realize this nightmare. Therefore the assurance in the docs is probably true only in the absence within the scope of at least gotos to targets within the scope.
Jul 16 2013