www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Reverse Lexical Order

reply "Manfred Nowak" <svv1999 hotmail.com> writes:
 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
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
parent reply "Manfred Nowak" <svv1999 hotmail.com> writes:
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
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, July 15, 2013 13:02:54 Manfred Nowak wrote:
 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.
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 Davis
Jul 15 2013
parent reply "Manfred Nowak" <svv1999 hotmail.com> writes:
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
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote:
 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.
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 Davis
Jul 15 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:
 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.
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.
[...] 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.
Jul 15 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent "Manfred Nowak" <svv1999 hotmail.com> writes:
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
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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:
 On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote:
 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.
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.
[...] 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
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.
Jul 16 2013