|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
digitalmars.D - DMD 0.148 - scope guard
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
↑ ↓ ← → Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Neat!
↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 13:06:36 +1100, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Wow! I know of one other language that (almost) implements this.
Does 'scope' mean any type scope, and not just function scope? For
example, can it include module scope? ... if/while/for/foreach scope? ...
block scope?
And I assume 'statement' can be a block of statements ...
on_exit_scope { stmt1; stmt2; ... stmtn;}
--
Derek Parnell
Melbourne, Australia
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Wow! I know of one other language that (almost) implements this.
Which one?
Does 'scope' mean any type scope, and not just function scope? For
example, can it include module scope? ... if/while/for/foreach scope? ...
block scope?
Yes.
And I assume 'statement' can be a block of statements ...
on_exit_scope { stmt1; stmt2; ... stmtn;}
Yup. (The C++ macro version is limited to a single function call with
argument.)
↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 14:51:45 +1100, Walter Bright
<newshound digitalmars.com> wrote:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Wow! I know of one other language that (almost) implements this.
Which one?
Progess. Its a Database 4GL. It handles the on_exit, on_failure situations
but not to the extent that D now does with the 'statement' flexibility. A
very neat solution.
--
Derek Parnell
Melbourne, Australia
↑ ↓ ← → Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Does 'scope' mean any type scope, and not just function scope? For
example, can it include module scope? ... if/while/for/foreach scope? ...
block scope?
Yes.
On module scope? No, it doesn't actually work on module scope, right?
Wouldn't make sense, as a module scope is a declaration scope, and not a
instruction scope/block.
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message
news:dtvcoj$225e$1 digitaldaemon.com...
Walter Bright wrote:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Does 'scope' mean any type scope, and not just function scope? For
example, can it include module scope? ... if/while/for/foreach scope?
... block scope?
Yes.
On module scope? No, it doesn't actually work on module scope, right?
Wouldn't make sense, as a module scope is a declaration scope, and not a
instruction scope/block.
That's right. You can't have statements in module scope, so there's no way
to apply it to module scope. Or class scope. Or any other place where
statements are not allowed.
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dtr8kl$4lm$1 digitaldaemon.com...
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Wow! I know of one other language that (almost) implements this.
Which one?
If I understand this correctly Ruby has something similar
http://www.rubycentral.com/book/tut_exceptions.html
But this is the same try-catch-finally I guess
as these on_scope_*** too, btw.
Andrew.
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:dtvkhr$2cf4$1 digitaldaemon.com...
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dtr8kl$4lm$1 digitaldaemon.com...
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
Wow! I know of one other language that (almost) implements this.
Which one?
If I understand this correctly Ruby has something similar
http://www.rubycentral.com/book/tut_exceptions.html
But this is the same try-catch-finally I guess
as these on_scope_*** too, btw.
Ruby's rescue thing looks like try-catch. on_scope is much more than
try-catch, or I wouldn't have implemented it <g>.
↑ ↓ ← → Mike Capp <mike.capp gmail.com> writes:
In article <du0slm$lj0$2 digitaldaemon.com>, Walter Bright says...
Ruby's rescue thing looks like try-catch. on_scope is much more than
try-catch, or I wouldn't have implemented it <g>.
on_scope is quite cute, and certainly cleaner than the C++ implementation of
ScopeGuard. Compared to ctor/dtor RAII, though, it still has the same problem as
try-catch{-finally} - a naive use of a resource is wrong by default, and the
programmer has to do something extra to make it right.
When I first saw Andrei's paper it struck me that what made things painful in
C++ was the lack of usable closures. Since D is pretty good in this regard,
could the same effect have been achieved with a less sugary but more regular
approach reusing RAII-auto syntax, e.g.
# import std.scopeguard;
# auto Guard onOk = new OnScopeSuccessGuard(&mySuccessFunc);
# auto Guard onFail = new OnScopeFailureGuard(function { /* ad hoc code */ });
with something like C++'s std::uncaught_exception in the Guard subclass
destructor implementations to discriminate exit conditions?
cheers
Mike
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message
news:du1ire$1h1s$1 digitaldaemon.com...
When I first saw Andrei's paper it struck me that what made things painful
in
C++ was the lack of usable closures. Since D is pretty good in this
regard,
could the same effect have been achieved with a less sugary but more
regular
approach reusing RAII-auto syntax, e.g.
# import std.scopeguard;
# auto Guard onOk = new OnScopeSuccessGuard(&mySuccessFunc);
# auto Guard onFail = new OnScopeFailureGuard(function { /* ad hoc code
*/ });
with something like C++'s std::uncaught_exception in the Guard subclass
destructor implementations to discriminate exit conditions?
I don't know a way to make that work as cleanly.
↑ ↓ ← → Tom <Tom_member pathlink.com> writes:
In article <dtr2fg$2vqr$4 digitaldaemon.com>, Walter Bright says...
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Again the release is very nice!
A question: I seemed to miss the scope guard discussion (whatever). Can you
enlighten me with an example (or guide me with a link) to illustrate the
usefulness of this feature?
Thanks,
P.S.: In the new docs for the scope guard stuff there is a TYPO at "[snip] close
of the scope, they also are interleaved with the OnScopeStatements in the
reverse *lexeical* order in which they appear."
Tom;
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Tom" <Tom_member pathlink.com> wrote in message
news:dtrakc$6lo$1 digitaldaemon.com...
A question: I seemed to miss the scope guard discussion (whatever). Can
you
enlighten me with an example (or guide me with a link) to illustrate the
usefulness of this feature?
This article has some good examples:
www.digitalmars.com/d/exception-safe.html
Also, do a google groups search on "Alexandrescu on_scope_exit" for a good
thread on it.
Thanks,
P.S.: In the new docs for the scope guard stuff there is a TYPO at "[snip]
close
of the scope, they also are interleaved with the OnScopeStatements in the
reverse *lexeical* order in which they appear."
Thanks, I'll fix it.
↑ ↓ ← → John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty. Nonetheless the scope
guard looks like something I should read up on.
Thanks for another good release.
-JJR
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message
news:dtrg0e$c9k$1 digitaldaemon.com...
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty.
I think it's ugly, too, but I just couldn't come up with anything
significantly better.
Nonetheless the scope guard looks like something I should read up on.
Thanks for another good release.
You're welcome.
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
"John Reimer" <terminal.node gmail.com> wrote in message
news:dtrg0e$c9k$1 digitaldaemon.com...
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty.
I think it's ugly, too, but I just couldn't come up with anything
significantly better.
Nonetheless the scope guard looks like something I should read up on.
Thanks for another good release.
You're welcome.
Why not just reuse "finally"?
void func()
{
init_some_reource();
foo(); // foo throws an exception
//func doesn't catch the exception
//but it has a finally clause
finally //aka on scope exit, whether success or fail
{
release_the_resource();
}
}
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:dtsfm5$1h2i$1 digitaldaemon.com...
Why not just reuse "finally"?
void func()
{
init_some_reource();
foo(); // foo throws an exception
//func doesn't catch the exception
//but it has a finally clause
finally //aka on scope exit, whether success or fail
{
release_the_resource();
}
}
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
↑ ↓ ← → Miles <_______ _______.____> writes:
Walter Bright wrote:
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
on_scope_exit -> finally { ... }
on_scope_success -> finally(true) { ... }
on_scope_failure -> finally(false) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally(success) { ... }
on_scope_failure -> finally(failure) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally("success") { ... }
on_scope_failure -> finally("failure") { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally return { ... }
on_scope_failure -> finally throw { ... }
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Miles" <_______ _______.____> wrote in message
news:dtu8ic$i0t$1 digitaldaemon.com...
Walter Bright wrote:
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
on_scope_exit -> finally { ... }
on_scope_success -> finally(true) { ... }
on_scope_failure -> finally(false) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally(success) { ... }
on_scope_failure -> finally(failure) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally("success") { ... }
on_scope_failure -> finally("failure") { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally return { ... }
on_scope_failure -> finally throw { ... }
I don't think those are much better :-(
↑ ↓ ← → Wang Zhen <nehzgnaw gmail.com> writes:
Walter Bright wrote:
"Miles" <_______ _______.____> wrote in message
news:dtu8ic$i0t$1 digitaldaemon.com...
Walter Bright wrote:
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
on_scope_exit -> finally { ... }
on_scope_success -> finally(true) { ... }
on_scope_failure -> finally(false) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally(success) { ... }
on_scope_failure -> finally(failure) { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally("success") { ... }
on_scope_failure -> finally("failure") { ... }
on_scope_exit -> finally { ... }
on_scope_success -> finally return { ... }
on_scope_failure -> finally throw { ... }
I don't think those are much better :-(
How about
on_scope_exit -> scope exit
on_scope_success -> scope success
on_scope_failure -> scope failure
?
on_prefixed_underscore_separated_keywords just look obtrusive in D code.
↑ ↓ ← → "Lionello Lunesu" <lio remove.lunesu.com> writes:
How about
on_scope_exit -> scope exit
on_scope_success -> scope success
on_scope_failure -> scope failure
?
on_prefixed_underscore_separated_keywords just look obtrusive in D code.
I don't like the _ either (mostly because D doesn't have any other _s in the
language, I know of), but I think reserving "exit", "failure" and "success"
would be even worse. I'd rather have the _s.
L.
↑ ↓ ← → "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dtsr1i$1u4v$4 digitaldaemon.com...
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:dtsfm5$1h2i$1 digitaldaemon.com...
Why not just reuse "finally"?
void func()
{
init_some_reource();
foo(); // foo throws an exception
//func doesn't catch the exception
//but it has a finally clause
finally //aka on scope exit, whether success or fail
{
release_the_resource();
}
}
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
Similar to allowing multiple "finally" statements, even without "try", you
could allow multiple "catch", also without "try":
finally writefln("done");
dofoo();
catch dofoo_undo();
dobar();
where the catch would also rethrow the exception being caught.
Now we just need something sensible for on_scope_success and we're done ; )
L.
↑ ↓ ← → "Lionello Lunesu" <lio remove.lunesu.com> writes:
Now we just need something sensible for on_scope_success and we're done
; )
"leave" seems like a good enough word, but since on_scope_failure and
on_scope_success are mutually exclusive, we could use ~catch, or !catch.
Pretty ugly too, but no new keywords.
on_scope_exit => finally
on_scope_failure => catch
on_scope_success => ~catch
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:dtsfm5$1h2i$1 digitaldaemon.com...
Why not just reuse "finally"?
void func()
{
init_some_reource();
foo(); // foo throws an exception
//func doesn't catch the exception
//but it has a finally clause
finally //aka on scope exit, whether success or fail
{
release_the_resource();
}
}
finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.
Why do we need to handle "on failure" and "on success" any differently
than a regular scope exit?
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Hasan Aljudy wrote:
Why do we need to handle "on failure" and "on success" any differently
than a regular scope exit?
See the "transaction processing" examples here:
http://www.digitalmars.com/d/exception-safe.html
Sean
↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:
Honestly, as ugly as the syntax is, I must admit I like the grouping of
the start and end conditions together.
That's one thing I've always thought strange about programming; people
talk about functions and classes and all the different aesthetic and
linear/non-linear relationships between them, but in the end it is all
completely and totally linear, when for many cases that doesn't make sense.
-[Unknown]
Walter Bright wrote:
"John Reimer" <terminal.node gmail.com> wrote in message
news:dtrg0e$c9k$1 digitaldaemon.com...
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty.
I think it's ugly, too, but I just couldn't come up with anything
significantly better.
Nonetheless the scope guard looks like something I should read up on.
Thanks for another good release.
You're welcome.
Why not just reuse "finally"?
void func()
{
init_some_reource();
foo(); // foo throws an exception
//func doesn't catch the exception
//but it has a finally clause
finally //aka on scope exit, whether success or fail
{
release_the_resource();
}
}
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:dtstki$20os$1 digitaldaemon.com...
Honestly, as ugly as the syntax is, I must admit I like the grouping of
the start and end conditions together.
That's one thing I've always thought strange about programming; people
talk about functions and classes and all the different aesthetic and
linear/non-linear relationships between them, but in the end it is all
completely and totally linear, when for many cases that doesn't make
sense.
Consider the for loop:
for (expr; expr; expr)
The 3rd expression is executed at the *end* of the loop, yet it is placed at
the beginning. So there is precedent for the utility of putting code where
it conceptually belongs rather than where it is executed.
↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'm not at all disagreeing; but aside from language constructs like
looping, which seem to be (in my experience) the easiest thing to get a
good grasp on for newcomers, there aren't many ways in which (general)
programming is non-linear.
I am saying this is strange; tasks, in many cases, are not linear.
Obviously it must map well to something the computer understands, but
that can often be handled by the compiler (as in this case.)
For example, academic programming typically teaches that multiple
returns in a function are evil. This is because it is mixing non linear
programming (not returning always at the very end) with linear programming.
Scope exit and such cases are a good example of a clean way to resolve
this problem without saying that "returns and continues are evil." What
more, they are logical.
-[Unknown]
Consider the for loop:
for (expr; expr; expr)
The 3rd expression is executed at the *end* of the loop, yet it is placed at
the beginning. So there is precedent for the utility of putting code where
it conceptually belongs rather than where it is executed.
↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:
John Reimer wrote:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty. Nonetheless the scope
guard looks like something I should read up on.
Thanks for another good release.
-JJR
I thought the same, perhaps the "scope" portion is understood? So that the
keywords become: onsuccess, onfailure, ...?
↑ ↓ ← → Nick <Nick_member pathlink.com> writes:
In article <dtri4j$ejs$1 digitaldaemon.com>, Kyle Furlong says...
I thought the same, perhaps the "scope" portion is understood? So that the
keywords become: onsuccess, onfailure, ...?
Personally I think it's better not to overuse simple words and phrases as
keywords. onsuccess/onSuccess etc. are a bit too likely to be chosen as a
function name, especially since these are not common keywords in other
languages.
Nick
↑ ↓ ← → John Reimer <terminal.node gmail.com> writes:
Nick wrote:
In article <dtri4j$ejs$1 digitaldaemon.com>, Kyle Furlong says...
I thought the same, perhaps the "scope" portion is understood? So that the
keywords become: onsuccess, onfailure, ...?
Personally I think it's better not to overuse simple words and phrases as
keywords. onsuccess/onSuccess etc. are a bit too likely to be chosen as a
function name, especially since these are not common keywords in other
languages.
Nick
I have to agree with this. The "scope" prefix, however unsightly,
serves its purpose here. Yet I wonder if there is a way to improve upon
that syntax.
-JJR
↑ ↓ ← → Cris <central_p hotmail.com> writes:
Yes I agree with Kyle but not to overuse simple keywords, what about
something like "onSuccess:", "onFailure:", etc...
To me all "_" look ugly. Perhaps the author could ask the community for
suggestions when naming new features?
Or perhaps just "onScopeSuccess", "onScopeFailure"...
Kyle Furlong wrote:
John Reimer wrote:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Nice feature, but rather ugly to look at; although, I'm not sure how
something like that could be made to look pretty. Nonetheless the
scope guard looks like something I should read up on.
Thanks for another good release.
-JJR
I thought the same, perhaps the "scope" portion is understood? So that
the keywords become: onsuccess, onfailure, ...?
↑ ↓ ← → Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Cris wrote:
Yes I agree with Kyle but not to overuse simple keywords, what about
something like "onSuccess:", "onFailure:", etc...
Then it would look like an ordinary label, wouldn't it ? That's a
different thing.
To me all "_" look ugly. Perhaps the author could ask the community for
suggestions when naming new features?
Or perhaps just "onScopeSuccess", "onScopeFailure"...
And these don't stand out enough IMO
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------
Tomasz Stachowiak /+ a.k.a. h3r3tic +/
↑ ↓ ← → Cris <central_p hotmail.com> writes:
Tom S wrote:
Cris wrote:
Yes I agree with Kyle but not to overuse simple keywords, what about
something like "onSuccess:", "onFailure:", etc...
Then it would look like an ordinary label, wouldn't it ? That's a
different thing.
Are there labels in D?
To me all "_" look ugly. Perhaps the author could ask the community
for suggestions when naming new features?
Or perhaps just "onScopeSuccess", "onScopeFailure"...
And these don't stand out enough IMO
I don't say my suggestions are the best :) you can always suggest
something better.
↑ ↓ ← → Chris Sauls <ibisbasenji gmail.com> writes:
Cris wrote:
Tom S wrote:
Cris wrote:
Yes I agree with Kyle but not to overuse simple keywords, what about
something like "onSuccess:", "onFailure:", etc...
different thing.
Yup. As free labels and as block statement labels.
# import std.stdio;
# void main () {
# goto L_bar;
#
# L_foo:
# writefln("foo"c);
# goto L_exit;
#
# L_bar:
# writefln("bar"c);
# goto L_foo;
#
# L_exit:
# }
-- Chris Nicholson-Sauls
↑ ↓ ← → =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Sat, 25 Feb 2006 18:06:36 -0800, Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Thanks Walter very cool.
I like kyle's suggestion on using.
onExit, onFailure, onSuccess so that it looks a little like javascript.
Walter have you considered like publishing new releases on
http://freshmeat.net ??
Like GDC and DStress do ??
Freshmeat is the slashdot equivalent for software.
Knud
↑ ↓ ← → bobef <bobef lessequal.com> writes:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:
On Sun, 26 Feb 2006 19:41:14 +1100, bobef <bobef lessequal.com> wrote:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
It's the equvalent of FreshMeat for I.T. related news and gosip.
--
Derek Parnell
Melbourne, Australia
↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:
Derek Parnell wrote:
On Sun, 26 Feb 2006 19:41:14 +1100, bobef <bobef lessequal.com> wrote:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
It's the equvalent of FreshMeat for I.T. related news and gosip.
That's a nice, circular definition. =P
What's a square?
Well, it's like a rectangle but with even sides.
What's a rectangle?
Well, it's like a square but only opposite side pairs need to be the
same length.
--
Regards,
James Dunne
↑ ↓ ← → Charles <noone nowhere.com> writes:
LOL
Derek Parnell wrote:
On Sun, 26 Feb 2006 19:41:14 +1100, bobef <bobef lessequal.com> wrote:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
It's the equvalent of FreshMeat for I.T. related news and gosip.
↑ ↓ ← → =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Sun, 26 Feb 2006 10:41:14 +0200, bobef wrote:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
↑ ↓ ← → Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
bobef schrieb am 2006-02-26:
Knud Sørensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
http://slashdot.org
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
ThkzHvadOtJAdWlCXR6c6zc=
=sWOz
-----END PGP SIGNATURE-----
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Thomas Kuehne wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
bobef schrieb am 2006-02-26:
Knud S�rensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
http://slashdot.org
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
ThkzHvadOtJAdWlCXR6c6zc=
=sWOz
-----END PGP SIGNATURE-----
Still, what is it? I've been there before .. didn't quite get it. Why is
it so popular?!
↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:
In article <dtsgcf$1i3q$1 digitaldaemon.com>, Hasan Aljudy says...
Thomas Kuehne wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
bobef schrieb am 2006-02-26:
Knud S�rensen wrote:
Freshmeat is the slashdot equivalent for software.
Forgive my ignorance, but what is slashdot?
http://slashdot.org
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
ThkzHvadOtJAdWlCXR6c6zc=
=sWOz
-----END PGP SIGNATURE-----
Still, what is it? I've been there before .. didn't quite get it. Why is
it so popular?!
It's technology and scientific news and covers a lot of 'nerd' interest stuff;
it's highly configurable if you have an account.
Every article has free-form user comments and discussion, which means you not
only see the news article, but can pick up dozens of links to related info, get
opinions on both sides, etc. (Many of the participants are highly uninformed,
but that is hard to avoid on the web...)
It's news, discussion, conversation, and a sort of "commonwealth" community, and
each discussion is anchored off of a "real" news article, book review, or
writeup, usually somewhere else. In this way its like a mixture of newsgroup
discussions, journalism, and wiki-like community authoring.
Like almost all human communities, the appeal is determined mostly by the types
of people that exist there (i.e. prisons versus country clubs versus rock
concerts). So its probably very grating if you don't like techie/trekkie/IT
types.
[But it's starting to look commonplace now because everyone copied them. Every
revolution is unthinkable beforehand and obvious afterwards...]
Kevin
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Concept is really promising. Syntax ... well ... :D
I try to come with some other syntaxs.
ORYGINAL:
void LongFunction()
{
State save = UIElement.GetState();
on_scope_success UIElement.SetState(save);
on_scope_failure UIElement.SetState(Failed(save));
...lots of code...
}
Why not:
VERSION A:
void LongFunction()
{
State save = UIElement.GetState();
on (success) {
UIElement.SetState(save)
}
on (failure) {
UIElement.SetState(Failed(save))
}
...lots of code...
}
(not that success and failure could be recognized only as "on" keyword's
argument.)
VERSION B:
void LongFunction()
{
State save = UIElement.GetState();
scope (success) {
UIElement.SetState(save);
}
scope (failure) {
UIElement.SetState(Failed(save));
}
...lots of code...
}
VERSION C:
void LongFunction()
{
State save = UIElement.GetState();
scope_success UIElement.SetState(save);
scope_failure UIElement.SetState(Failed(save));
...lots of code...
}
What do you think? Maybe later we'll come with better ideas.
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION D:
void LongFunction()
{
  State save = UIElement.GetState();
  onscope (success) UIElement.SetState(save);
  onscope (failure) UIElement.SetState(Failed(save));
  ...lots of code...
}
VERSION E:
void LongFunction()
{
  State save = UIElement.GetState();
  onscope {
case success: UIElement.SetState(save);
}
  onscope {
case failure: UIElement.SetState(Failed(save));
}
  ...lots of code...
}
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:
VERSION E:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save);
}
onscope {
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
Just came to my mind:
This version is especially neat because it may be simplified to:
void LongFunction()
{
  State save = UIElement.GetState();
  onscope {
    case success: UIElement.SetState(save); break;
    case failure: UIElement.SetState(Failed(save));
  }
  ...lots of code...
}
↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
VERSION E:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save);
}
onscope {
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
Just came to my mind:
This version is especially neat because it may be simplified to:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save); break;
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
I really like this idea, cons anyone?
↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:
Kyle Furlong wrote:
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
VERSION E:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save);
}
onscope {
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
Just came to my mind:
This version is especially neat because it may be simplified to:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save); break;
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
I really like this idea, cons anyone?
I don't like the words 'success' and 'failure' used all over the place.
The meaning of the function's success isn't based on only if no
exceptions were thrown. Similarly, the function doesn't have to 'fail'
if an exception were thrown.
I think they should be renamed to represent what they actually do. That
is, 'no exception thrown'/'pass', 'exception thrown'/'catch', 'scope
exited'/'exit'. Also, I think it would be more pleasing to the eye (and
the maintainer) if the effect of the scope guard were more obvious in
the code. Something like:
void LongFunction()
{
scope (State save = UIElement.GetState())
catch {
UIElement.SetState(Failed(save));
}
pass {
UIElement.SetState(save);
}
body {
... lots of code ...
}
}
This way, it looks like a function contract, except it applies to any
scope. The catch block is reused but only for purposes of noting that
there was an exception caught. The pass block is quite simply the
'else' to the catch block, and should happen only if no exceptions were
caught. Furthermore, there could be a general 'exit' block.
One could add as many of these blocks as necessary, and the compiler
will guarantee to call them in order of definition, much like the
original solution but not requiring one to think backwards.
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
So, if an exception were thrown in '... lots of code ...', you'd see
'03' and the function would return false. However, if no exception were
thrown you'd see '123' and the function would return true. This
demonstrates the order of execution across multiple blocks. In this
example, the order of the 'exit' block relative to the 'catch' and
'pass' blocks is important.
Consequently, I don't think the order of the 'body' block should matter
at all, relative to the other blocks; and it should be fixed to only
allow one instance of it. Then, it is a matter of personal/project
style where the 'body' block would fall.
Thoughts on this?
One last thought I had was to remove the parenthesized expression form
of scope (expr) ... and use another block name to represent the
initialization stage, just to be consistent.
--
Regards,
James Dunne
↑ ↓ ← → =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
James Dunne wrote:
Kyle Furlong wrote:
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
This is the best I've seen but:
- Why two "pass" blocks?.
- About "exit" would be better before the "body" block and maybe replace
it with "finally" to save one more keyword.
I'm also assuming that we could also do one liners without the braces:
bool LongFunction()
{
bool passed = false;
scope State save = UIElement.GetState();
catch UIElement.SetState(Failed(save));
pass UIElement.SetState(save);
finally writef('3');
body {
... lots of code ...
}
return passed;
}
↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:
Julio César Carrascal Urquijo wrote:
James Dunne wrote:
Kyle Furlong wrote:
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
This is the best I've seen but:
- Why two "pass" blocks?.
Just to demonstrate that the ordering of the blocks matters, and that
multiple blocks can be defined.
- About "exit" would be better before the "body" block and maybe replace
it with "finally" to save one more keyword.
I noted this was a matter of personal style where the body block goes,
as it does not depend on the order of the other blocks. Personally, I
like seeing the exit block after the body, as it should flow naturally.
I'm also assuming that we could also do one liners without the braces:
bool LongFunction()
{
bool passed = false;
scope State save = UIElement.GetState();
catch UIElement.SetState(Failed(save));
pass UIElement.SetState(save);
finally writef('3');
body {
... lots of code ...
}
return passed;
}
Sure, why not?
--
Regards,
James Dunne
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
James Dunne wrote:
I don't like the words 'success' and 'failure' used all over the place.
Yes. I have to agree they are little missused. Changing them to "pass" as
success, "fail"/"catch" as "failure" and "default" as exit is good idea.
void LongFunction()
{
scope (State save = UIElement.GetState())
catch {
UIElement.SetState(Failed(save));
}
pass {
UIElement.SetState(save);
}
body {
... lots of code ...
}
}
This way, it looks like a function contract, except it applies to any
scope. The catch block is reused but only for purposes of noting that
there was an exception caught. The pass block is quite simply the
'else' to the catch block, and should happen only if no exceptions were
caught. Furthermore, there could be a general 'exit' block.
One could add as many of these blocks as necessary, and the compiler
will guarantee to call them in order of definition, much like the
original solution but not requiring one to think backwards.
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
IMHO now it looks overcomplicated. You are explicitly declaring new scope
using body {} . This is for what whole idea was invented - to prevent it.
Using "catch" keyword is missleading. Keyword scope (expr.) works now as try
{ expr. } . And I have to say that I needed to read this code few times to
understand it. It looks for me as reinventing try { } catch { } finally {}
way of handling exceptions. Sorry, but I don't like it.
↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:
Dawid Ciężarkiewicz wrote:
James Dunne wrote:
I don't like the words 'success' and 'failure' used all over the place.
Yes. I have to agree they are little missused. Changing them to "pass" as
success, "fail"/"catch" as "failure" and "default" as exit is good idea.
Yeah, after posting I realized this was the best idea out of my post.
Really, there's no *nice* way of fixing the syntax problem. You have a
fixed statement keyword - nobody will like what you name it; or you have
the curly-brace blocks nesting - which looks busy.
void LongFunction()
{
scope (State save = UIElement.GetState())
catch {
UIElement.SetState(Failed(save));
}
pass {
UIElement.SetState(save);
}
body {
... lots of code ...
}
}
This way, it looks like a function contract, except it applies to any
scope. The catch block is reused but only for purposes of noting that
there was an exception caught. The pass block is quite simply the
'else' to the catch block, and should happen only if no exceptions were
caught. Furthermore, there could be a general 'exit' block.
One could add as many of these blocks as necessary, and the compiler
will guarantee to call them in order of definition, much like the
original solution but not requiring one to think backwards.
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
IMHO now it looks overcomplicated. You are explicitly declaring new scope
using body {} . This is for what whole idea was invented - to prevent it.
Using "catch" keyword is missleading. Keyword scope (expr.) works now as try
{ expr. } . And I have to say that I needed to read this code few times to
understand it. It looks for me as reinventing try { } catch { } finally {}
way of handling exceptions. Sorry, but I don't like it.
Reusing the catch keyword was not intended to be misleading, but instead
to keep other whining about introducing new keywords. Though,
technically there's no reason for any keyword to actually be a reserved
word in the first place... ;)
Yes, it does somewhat analogue try/catch/finally, but it is more
explicit in its meaning.
Thanks for your opinion.
--
Regards,
James Dunne
↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:
James Dunne wrote:
Kyle Furlong wrote:
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
VERSION E:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save);
}
onscope {
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
Just came to my mind:
This version is especially neat because it may be simplified to:
void LongFunction()
{
State save = UIElement.GetState();
onscope {
case success: UIElement.SetState(save); break;
case failure: UIElement.SetState(Failed(save));
}
...lots of code...
}
I really like this idea, cons anyone?
I don't like the words 'success' and 'failure' used all over the place.
The meaning of the function's success isn't based on only if no
exceptions were thrown. Similarly, the function doesn't have to 'fail'
if an exception were thrown.
I think they should be renamed to represent what they actually do. That
is, 'no exception thrown'/'pass', 'exception thrown'/'catch', 'scope
exited'/'exit'. Also, I think it would be more pleasing to the eye (and
the maintainer) if the effect of the scope guard were more obvious in
the code. Something like:
void LongFunction()
{
scope (State save = UIElement.GetState())
catch {
UIElement.SetState(Failed(save));
}
pass {
UIElement.SetState(save);
}
body {
... lots of code ...
}
}
This way, it looks like a function contract, except it applies to any
scope. The catch block is reused but only for purposes of noting that
there was an exception caught. The pass block is quite simply the
'else' to the catch block, and should happen only if no exceptions were
caught. Furthermore, there could be a general 'exit' block.
One could add as many of these blocks as necessary, and the compiler
will guarantee to call them in order of definition, much like the
original solution but not requiring one to think backwards.
bool LongFunction()
{
bool passed = false;
scope (State save = UIElement.GetState())
catch { UIElement.SetState(Failed(save)); writef('0'); }
pass { UIElement.SetState(save); writef('1'); }
pass { passed = true; writef('2'); }
body {
... lots of code ...
}
exit { writef('3'); }
return passed;
}
So, if an exception were thrown in '... lots of code ...', you'd see
'03' and the function would return false. However, if no exception were
thrown you'd see '123' and the function would return true. This
demonstrates the order of execution across multiple blocks. In this
example, the order of the 'exit' block relative to the 'catch' and
'pass' blocks is important.
Consequently, I don't think the order of the 'body' block should matter
at all, relative to the other blocks; and it should be fixed to only
allow one instance of it. Then, it is a matter of personal/project
style where the 'body' block would fall.
Thoughts on this?
One last thought I had was to remove the parenthesized expression form
of scope (expr) ... and use another block name to represent the
initialization stage, just to be consistent.
for any scope:
in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}
Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Kyle Furlong wrote:
for any scope:
in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}
Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax
I'm sorry to say but IMO this miss the whole point.
Current keywords: in, out, body are place-insensitive . They are just blocks
that may be moved relatively for themselves and this will not change
anything. The whole point in "scope guarding" is that expression you type
_registers_ some piece of code (to be called in some conditions) in place
where it appears.
You gain nothing with such syntax. If you want to deal with whole scope then
you can use finally and catch blocks.
Examples:
Current syntax:
void LongFunction()
{
foo1();
on_scope_failure clean_what_foo1_did();
foo2();
on_scope_failure clean_what_foo2_did();
foo3();
on_scope_failure clean_what_foo3_did();
foo4();
}
What I understand from your proposal:
void LongFunction()
{
foo1();
failure {
on_scope_failure clean_what_foo1_did();
}
body {
foo2();
failure {
on_scope_failure clean_what_foo2_did();
}
body {
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
body {
foo4();
}
}
}
}
If you think about:
void LongFunction()
{
foo1();
failure{
clean_what_foo1_did();
}
foo2();
failure {
clean_what_foo2_did();
}
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
foo4();
}
Then concept is OK, but you can no longer say this "will fit and expand
current syntax", because it's used totally diffrent from body {} in {} out
{} blocks.
↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:
Dawid Ciężarkiewicz wrote:
Kyle Furlong wrote:
for any scope:
in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}
Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax
I'm sorry to say but IMO this miss the whole point.
Current keywords: in, out, body are place-insensitive . They are just blocks
that may be moved relatively for themselves and this will not change
anything. The whole point in "scope guarding" is that expression you type
_registers_ some piece of code (to be called in some conditions) in place
where it appears.
You gain nothing with such syntax. If you want to deal with whole scope then
you can use finally and catch blocks.
Examples:
Current syntax:
void LongFunction()
{
foo1();
on_scope_failure clean_what_foo1_did();
foo2();
on_scope_failure clean_what_foo2_did();
foo3();
on_scope_failure clean_what_foo3_did();
foo4();
}
What I understand from your proposal:
void LongFunction()
{
foo1();
failure {
on_scope_failure clean_what_foo1_did();
}
body {
foo2();
failure {
on_scope_failure clean_what_foo2_did();
}
body {
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
body {
foo4();
}
}
}
}
If you think about:
void LongFunction()
{
foo1();
failure{
clean_what_foo1_did();
}
foo2();
failure {
clean_what_foo2_did();
}
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
foo4();
}
Then concept is OK, but you can no longer say this "will fit and expand
current syntax", because it's used totally diffrent from body {} in {} out
{} blocks.
That is definitely *NOT* what I was saying *AT ALL*. Obviously that is a
terrible syntax.
Here's what it would look like:
Current syntax:
void LongFunction()
{
foo1();
on_scope_failure clean_what_foo1_did();
foo2();
on_scope_failure clean_what_foo2_did();
foo3();
on_scope_failure clean_what_foo3_did();
foo4();
}
What I understand from your proposal: (how it should have been)
void LongFunction()
failure
{
clean_what_foo1_did();
clean_what_foo2_did();
clean_what_foo3_did();
clean_what_foo4_did();
}
body
{
foo1();
foo2();
foo3();
foo4();
}
I think you missed the point that each function call does not introduce a new
scope. Now, its true that if you wanted the
operations foox() to each be in its own scope, then it would look like this:
void LongFunction()
{
failure
{
clean_what_foo1_did();
}
body
{
foo1();
}
failure
{
clean_what_foo2_did();
}
body
{
foo2();
}
failure
{
clean_what_foo3_did();
}
body
{
foo3();
}
failure
{
clean_what_foo4_did();
}
body
{
foo4();
}
}
↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:
Kyle Furlong wrote:
Dawid Ciężarkiewicz wrote:
Kyle Furlong wrote:
for any scope:
in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}
Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax
I'm sorry to say but IMO this miss the whole point.
Current keywords: in, out, body are place-insensitive . They are just
blocks
that may be moved relatively for themselves and this will not change
anything. The whole point in "scope guarding" is that expression you type
_registers_ some piece of code (to be called in some conditions) in place
where it appears.
You gain nothing with such syntax. If you want to deal with whole
scope then
you can use finally and catch blocks.
Examples:
Current syntax:
void LongFunction()
{
foo1();
on_scope_failure clean_what_foo1_did();
foo2();
on_scope_failure clean_what_foo2_did();
foo3();
on_scope_failure clean_what_foo3_did();
foo4();
}
What I understand from your proposal:
void LongFunction()
{
foo1();
failure {
on_scope_failure clean_what_foo1_did();
}
body {
foo2();
failure {
on_scope_failure clean_what_foo2_did();
}
body {
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
body {
foo4();
}
}
}
}
If you think about:
void LongFunction()
{
foo1();
failure{
clean_what_foo1_did();
}
foo2();
failure {
clean_what_foo2_did();
}
foo3();
failure {
on_scope_failure clean_what_foo3_did();
}
foo4();
}
Then concept is OK, but you can no longer say this "will fit and expand
current syntax", because it's used totally diffrent from body {} in
{} out
{} blocks.
That is definitely *NOT* what I was saying *AT ALL*. Obviously that is a
terrible syntax.
Here's what it would look like:
Current syntax:
void LongFunction()
{
foo1();
on_scope_failure clean_what_foo1_did();
foo2();
on_scope_failure clean_what_foo2_did();
foo3();
on_scope_failure clean_what_foo3_did();
foo4();
}
What I understand from your proposal: (how it should have been)
void LongFunction()
failure
{
clean_what_foo1_did();
clean_what_foo2_did();
clean_what_foo3_did();
clean_what_foo4_did();
}
body
{
foo1();
foo2();
foo3();
foo4();
}
I think you missed the point that each function call does not introduce
a new scope. Now, its true that if you wanted the operations foox() to
each be in its own scope, then it would look like this:
void LongFunction()
{
failure
{
clean_what_foo1_did();
}
body
{
foo1();
}
failure
{
clean_what_foo2_did();
}
body
{
foo2();
}
failure
{
clean_what_foo3_did();
}
body
{
foo3();
}
failure
{
clean_what_foo4_did();
}
body
{
foo4();
}
}
David has brought some things to my attention on IRC that invalidate this
syntax, sorry for the clutter.
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 26 Feb 2006 12:20:58 -0800, Kyle Furlong <kylefurlong gmail.com>
wrote:
What I understand from your proposal: (how it should have been)
void LongFunction()
failure
{
clean_what_foo1_did();
clean_what_foo2_did();
clean_what_foo3_did();
clean_what_foo4_did();
}
body
{
foo1();
foo2();
foo3();
foo4();
}
In the above:
- is clean_what_foo1_did only called if foo1() has returned successfully
and foo2,foo3,or foo4 failed?
- is clean_what_foo2_did only called if foo2() has returned successfully
and foo3,or foo4 failed?
- is clean_what_foo3_did only called if foo3() has returned successfully
and foo4 failed?
(there is actually no point to clean_what_foo4_did)
Because, this is an important part of the scope guard feature, each
on_scope_failure statement registers something which is then called on
failure of the scope in which it is registered. The order in which they
are registered WRT the other code is important.
Regan
↑ ↓ ← → John Reimer <terminal.node gmail.com> writes:
Dawid Ciężarkiewicz wrote:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Concept is really promising. Syntax ... well ... :D
<snip>
VERSION B:
void LongFunction()
{
State save = UIElement.GetState();
scope (success) {
UIElement.SetState(save);
}
scope (failure) {
UIElement.SetState(Failed(save));
}
...lots of code...
}
<snip>
I like something similar to the "scope" keywords. That looks quite
promising.
VERSION B +1
-JJR
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION F:
void LongFunction()
{
State save = UIElement.GetState();
register (scopepass) UIElement.SetState(save);
register (scopefail) UIElement.SetState(Failed(save));
...lots of code...
}
VERSION G:
void LongFunction()
{
  State save = UIElement.GetState();
  register (scope) {
case pass: UIElement.SetState(save); break;
  case fail: UIElement.SetState(Failed(save));
}
  ...lots of code...
}
VERSION H:
void LongFunction()
{
State save = UIElement.GetState();
register {
case scopepass: UIElement.SetState(save); break;
case scopefail: UIElement.SetState(Failed(save));
}
...lots of code...
}
P.S.
If I get more ideas I will throw them all (with those already posted) in one
new thread.
↑ ↓ ← → Cris <central_p hotmail.com> writes:
Why do you need "case" at all?
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION F:
void LongFunction()
{
State save = UIElement.GetState();
register (scopepass) UIElement.SetState(save);
register (scopefail) UIElement.SetState(Failed(save));
...lots of code...
}
VERSION G:
void LongFunction()
{
State save = UIElement.GetState();
register (scope) {
case pass: UIElement.SetState(save); break;
case fail: UIElement.SetState(Failed(save));
}
...lots of code...
}
VERSION H:
void LongFunction()
{
State save = UIElement.GetState();
register {
case scopepass: UIElement.SetState(save); break;
case scopefail: UIElement.SetState(Failed(save));
}
...lots of code...
}
P.S.
If I get more ideas I will throw them all (with those already posted) in one
new thread.
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Cris wrote:
Why do you need "case" at all?
Good point. Intention was to make it similar to switch (smth.) block.
void LongFunction()
{
State save = UIElement.GetState();
register (scope) {
pass: UIElement.SetState(save); break;
fail: UIElement.SetState(Failed(save));
}
...lots of code...
}
This looks better. I think about "(scope)" part. It's redundant _but_ very
informative and leaves open doors for expanding.
Currently I like this syntax best. IMO it naturally fits, "register" keyword
is old (but rarely used) old C-keyword and it realy means: "register this
piece of code to be called when something with scope happens".
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION I: (yeah, I know ...)
h3r3tic on #D channel said that VERSION H is too long and too switch-like.
This is hybrid of two concepts - verbose and informative "register" keyword
and short usage without switch-like syntax.
void LongFunction()
{
State save = UIElement.GetState();
register (scopepass) UIElement.SetState(save);
register (scopefail) UIElement.SetState(Failed(save));
...lots of code...
}
↑ ↓ ← → Cris <central_p hotmail.com> writes:
Now you have just to persuade Walter Bright or to write your own
compiler/language :)
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION I: (yeah, I know ...)
h3r3tic on #D channel said that VERSION H is too long and too switch-like.
This is hybrid of two concepts - verbose and informative "register" keyword
and short usage without switch-like syntax.
void LongFunction()
{
State save = UIElement.GetState();
register (scopepass) UIElement.SetState(save);
register (scopefail) UIElement.SetState(Failed(save));
...lots of code...
}
↑ ↓ ← → John Reimer <John_member pathlink.com> writes:
In article <dtueau$pdo$1 digitaldaemon.com>, Cris says...
Now you have just to persuade Walter Bright or to write your own
compiler/language :)
Dawid Ciężarkiewicz wrote:
Dawid Ciężarkiewicz wrote:
What do you think? Maybe later we'll come with better ideas.
VERSION I: (yeah, I know ...)
h3r3tic on #D channel said that VERSION H is too long and too switch-like.
This is hybrid of two concepts - verbose and informative "register" keyword
and short usage without switch-like syntax.
void LongFunction()
{
State save = UIElement.GetState();
register (scopepass) UIElement.SetState(save);
register (scopefail) UIElement.SetState(Failed(save));
...lots of code...
}
Hmm... we have "static if"; why not adopt a "scope if"?
Here's a sample using Walter's Mailer example from
http://www.digitalmars.com/d/exception-safe.html:
# class Mailer
# {
# void Send( Message msg )
# {
# {
# char[] origTitle = msg.Title();
#
# scope if (exit)
# msg.SetTitle( origTitle );
#
# msg.SetTitle("[Sending] " ~ origTitle);
# Copy(msg, "Sent");
# }
# scope if(success)
# SetTitle(msg.ID(), "Sent", msg.Title);
# scope if (failure)
# Remove(msg.ID(), "Sent");
# SmtpSend(msg); // do the least reliable part last
# }
# }
Simple, clear, and parallel to other D constructs, no? We've certainly come to
enjoy the "static if" syntax.
-JJR
↑ ↓ ← → h3 <h3 foo.bar> writes:
John Reimer wrote:
> Hmm... we have "static if"; why not adopt a "scope if"?
Here's a sample using Walter's Mailer example from
http://www.digitalmars.com/d/exception-safe.html:
# class Mailer
# {
# void Send( Message msg )
# {
# {
# char[] origTitle = msg.Title();
#
# scope if (exit)
# msg.SetTitle( origTitle );
#
# msg.SetTitle("[Sending] " ~ origTitle);
# Copy(msg, "Sent");
# }
# scope if(success)
# SetTitle(msg.ID(), "Sent", msg.Title);
# scope if (failure)
# Remove(msg.ID(), "Sent");
# SmtpSend(msg); // do the least reliable part last
# }
# }
Simple, clear, and parallel to other D constructs, no? We've certainly come to
enjoy the "static if" syntax.
Looks the best so far, but it implies making 'scope', 'success' and
'failure' keywords. Not that I recall ever using them as identifiers...
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Cris wrote:
Now you have just to persuade Walter Bright or to write your own
compiler/language :)
I only hope Walter will take a look how much possibilities he have. I just
don't like operators_with_underscore and everybody seems to agree that they
don't fit well with beauty of D.
↑ ↓ ← → Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
I like the idea, but I don't like the names. Can something else be used instead?
--
Carlos Santander Bernal
↑ ↓ ← → Charles <noone nowhere.com> writes:
I don't see how this is marginally better than try - catch - finnaly.
Thanks to garbage collection , exception safety is dramatically less
complicated in D then in C++ ( in fact other than the mutex lock -- can
anyone think of examples for exception safety in D ? ). I think the
problem here is exceptions, not exception safety -- and I think that
point is illustrated with all the many work arounds for 'exception safety'.
I love that D is "thinking outside the box" , but I have to vote against
this one. Instead of improving exception safety, we should be improving
exceptions.
Charlie
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Awesome :-) I've been wondering when this would make it into D. It
certainly beats the heck out of the RAII approach.
Sean
↑ ↓ ← → "Jim H" <jhewesNOSPAM ix.netcom.com> writes:
This looks like a great new D feature. Curse you. It makes it all that much
worse that I still have to do my day-job programming in C++. Why did you
ever have to invent D anyway? Why couldn't you just let me go on thinking
C++ was a good thing? I thought I was happy then. :-)
Seriously, I read the Alexandrescu's article and downloaded the C++
Scopeguard code. I may end up using it. It's not as nice as D scopeguards
though because you need to remember to call Dismiss at the end of functions.
Plus, you probably want to avoid returning successfully in the middle of
functions.
Jim
↑ ↓ ← → "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dtr2fg$2vqr$4 digitaldaemon.com...
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Note GCC has pretty much the same thing with the "cleanup" attribute
extension on variables:
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:dtv8f5$1svn$1 digitaldaemon.com...
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dtr2fg$2vqr$4 digitaldaemon.com...
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
Note GCC has pretty much the same thing with the "cleanup" attribute
extension on variables:
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
cleanup only corresponds with on_scope_exit, not the other two. It also only
runs a function with a local variable as a parameter - i.e. it is the same
thing as RAII. It doesn't allow arbitrary code to be executed, nor manage
things like state of a class member, etc.
↑ ↓ ← → Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
There is probably room to improve the syntax a bit more (although I too
don't yet see how), but it is already a fine feature.
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
↑ ↓ ← → "Chris Miller" <chris dprogramming.com> writes:
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope` keyword,
name in () doesn't need to be a keyword but is still treated special, and
doesn't look bad.
↑ ↓ ← → Lars Ivar Igesund <larsivar igesund.net> writes:
Chris Miller wrote:
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope` keyword,
name in () doesn't need to be a keyword but is still treated special, and
doesn't look bad.
Me votes for this too.
↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:
On Tue, 28 Feb 2006 04:40:56 +1100, Chris Miller <chris dprogramming.com>
wrote:
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope`
keyword, name in () doesn't need to be a keyword but is still treated
special, and doesn't look bad.
Nice and consistent.
--
Derek Parnell
Melbourne, Australia
↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Chris Miller wrote:
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
Yeap. It's nice. Maybe s/success/pass/ s/failure/fail/ would even improve it
a little.
↑ ↓ ← → "Chris Miller" <chris dprogramming.com> writes:
On Mon, 27 Feb 2006 17:16:38 -0500, Dawid Ciężarkiewicz
<dawid.ciezarkiewicz gmail.com> wrote:
Chris Miller wrote:
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
Yeap. It's nice. Maybe s/success/pass/ s/failure/fail/ would even
improve it
a little.
Good one.
↑ ↓ ← → Georg Wrede <georg.wrede nospam.org> writes:
Chris Miller wrote:
On Mon, 27 Feb 2006 17:16:38 -0500, Dawid Ciężarkiewicz
<dawid.ciezarkiewicz gmail.com> wrote:
Chris Miller wrote:
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
This gets my vote too.
And then it would look natural, if you ever need more than one function run:
scope(failure) foo();
scope(success) { bar(); haveAParty(); writeHome(); }
scope(exit) yawn();
Yeap. It's nice. Maybe s/success/pass/ s/failure/fail/ would even
improve it
a little.
Good one.
That's kind of neat, too. Having all three alternatives with same number
of characters, makes it tidy:
scope(exit) foo();
scope(pass) bar();
scope(fail) baz();
Except of course, that "pass" might look like "skip" to somebody new to D.
↑ ↓ ← → Wang Zhen <nehzgnaw gmail.com> writes:
Dawid Ciężarkiewicz wrote:
Chris Miller wrote:
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
Yeap. It's nice. Maybe s/success/pass/ s/failure/fail/ would even improve it
a little.
The proposed syntax feels like D. Count my vote.
↑ ↓ ← → Lucas Goss <lgoss007 gmail.com> writes:
Chris Miller wrote:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
While I don't really like the _'s in on_scope_exit, etc, I don't like
this proposed syntax any more, in fact I think I don't like it as much.
With this proposed syntax it seems like an expression such as an
if/while/for/etc, however, in all of those the condition is user
defined. So this proposed syntax would appear inconsistent.
<rant>
And if there's one thing I dislike in languages and libraries, it's
inconsistencies, right up with it is non descriptive or inconsistent
functions. Don't even get me started on those, I'm looking at you Phobos :)
writefln ... what? write file name? write first line? write f language?
isxdigit ... is x a digit? of course not! why do I need this function?
pardir ... parrot directory? not everyone has the parrot vm.
altsep ... Alt key seperator? does this get the Alt key?
ifind ... integer find? iFind? iWork? is this for Mac only?
First, I don't see why all of the above aren't readable. And second, why
don't they follow the D guidelines of camelCase? (I prefer the
PascalCase myself, but I could live with camelCase if it was
consistent). For example:
writeLine(string), writeLine(string, format)
isHexDigit
parentDirectory
windowsAlternateSeperator
FindFirst
The only reason I can see is "it will make it easier for C/C++
programmers." or, it's shorter. The first has little merit, as
templates, operator overloading, streams, reals etc. are all different
(for good reason of course), and C/C++ programmers will have to learn D
no matter what. As for shorter, you may gain a few seconds (after a
couple hundred lines), but I'd much rather be able to tell what I was
doing at a glance...
(notice: Yes I know, the functions come from C... it's good we hold on
to our history just like C++ did :) )
</rant>
I'd much rather prefer something like:
scopeexit
scopesuccess
scopefailure
Or some derivative:
scopeabort, scopefault, scopedone, scopefinish, scope?
ps. I like the looks of this new feature and find it very elegant. I
prefer this to try/catch/finally.
↑ ↓ ← → Lars Ivar Igesund <larsivar igesund.net> writes:
Lucas Goss wrote:
Chris Miller wrote:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
While I don't really like the _'s in on_scope_exit, etc, I don't like
this proposed syntax any more, in fact I think I don't like it as much.
With this proposed syntax it seems like an expression such as an
if/while/for/etc, however, in all of those the condition is user
defined. So this proposed syntax would appear inconsistent.
<rant>
And if there's one thing I dislike in languages and libraries, it's
inconsistencies, right up with it is non descriptive or inconsistent
functions. Don't even get me started on those, I'm looking at you Phobos
:)
writefln ... what? write file name? write first line? write f language?
isxdigit ... is x a digit? of course not! why do I need this function?
pardir ... parrot directory? not everyone has the parrot vm.
altsep ... Alt key seperator? does this get the Alt key?
ifind ... integer find? iFind? iWork? is this for Mac only?
First, I don't see why all of the above aren't readable. And second, why
don't they follow the D guidelines of camelCase? (I prefer the
PascalCase myself, but I could live with camelCase if it was
consistent). For example:
writeLine(string), writeLine(string, format)
isHexDigit
parentDirectory
windowsAlternateSeperator
FindFirst
The only reason I can see is "it will make it easier for C/C++
programmers." or, it's shorter. The first has little merit, as
templates, operator overloading, streams, reals etc. are all different
(for good reason of course), and C/C++ programmers will have to learn D
no matter what. As for shorter, you may gain a few seconds (after a
couple hundred lines), but I'd much rather be able to tell what I was
doing at a glance...
(notice: Yes I know, the functions come from C... it's good we hold on
to our history just like C++ did :) )
</rant>
I'd much rather prefer something like:
scopeexit
scopesuccess
scopefailure
Or some derivative:
scopeabort, scopefault, scopedone, scopefinish, scope?
ps. I like the looks of this new feature and find it very elegant. I
prefer this to try/catch/finally.
Sorry, but I find the proposed statements very consistent with D's existing
version, debug, etc statements.
↑ ↓ ← → Charles <noone nowhere.com> writes:
Aye gets my vote too.
Chris Miller wrote:
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope`
keyword, name in () doesn't need to be a keyword but is still treated
special, and doesn't look bad.
↑ ↓ ← → Yves Jacoby <kloune gmail.com> writes:
On Mon, 27 Feb 2006 12:40:56 -0500, Chris Miller wrote:
I find this one better too.
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope` keyword,
name in () doesn't need to be a keyword but is still treated special, and
doesn't look bad.
↑ ↓ ← → Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Chris Miller wrote:
On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
<newshound digitalmars.com> wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This format looks good to me:
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope`
keyword, name in () doesn't need to be a keyword but is still treated
special, and doesn't look bad.
Here's some more experimental ideas:
scope.onExit fooexpr;
scope.onSuccess barexpr;
scope.onFailure bazexpr;
Now a more clean/pure version, but that doesn't allow block statements:
scope.onExit(fooexpr);
scope.onSuccess(barexpr);
scope.onFailure(bazexpr);
Don't really 100% like them, but I'll present them anyway, maybe it will
inspire someone for a better idea. (The problem with this one is that is
makes scope seem like a workable proper object, while it's not)
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:
Chris Miller wrote:
<snip>
scope(exit) foo();
scope(success) bar();
scope(failure) baz();
similar to extern(name), pragma(name), etc, requires one `scope`
keyword, name in () doesn't need to be a keyword but is still treated
special, and doesn't look bad.
The scope(exit) notation gets me thinking, considering that all three of
them are on exit from the scope. Not that I can think of anything
better....
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
I am with Charles here...
I don't understand why
on_scope_failure & co. are significantly better than
try catch finally?
What is wrong with them?
Semantically try-catch-finally are well known and
widely recognizable constructions.
BTW: Am I right in my assumption that
proposed on_scope_exit / on_scope_success / on_scope_failure
is a direct equivalent of the following:
try
{
[scope code]
my_on_scope_success().
}
catch(...)
{
my_on_scope_failure().
}
finally {
my_on_scope_exit().
}
If yes then again what it wrong with them in principle?
Andrew.
http://terrainformatica.com
↑ ↓ ← → xs0 <xs0 xs0.com> writes:
Andrew Fedoniouk wrote:
I am with Charles here...
I don't understand why
on_scope_failure & co. are significantly better than
try catch finally?
imho, they're not better in all cases, just in some :)
What is wrong with them?
nothing
Semantically try-catch-finally are well known and
widely recognizable constructions.
agreed
BTW: Am I right in my assumption that
proposed on_scope_exit / on_scope_success / on_scope_failure
is a direct equivalent of the following:
try
{
[scope code]
my_on_scope_success().
}
catch(...)
{
my_on_scope_failure().
}
finally {
my_on_scope_exit().
}
If yes then again what it wrong with them in principle?
Well, nothing in principle, but like it was said already:
- init and cleanup can be close together (which is good in itself)
- as a consequence, it's harder to forget cleanup
- it's prettier - code that is about linear looks like it's about linear
(see example 2)
- you can reorder them as you see fit (see example 1)
- less typing :)
Example 1:
=======================
on_scope_exit foo();
on_scope_failure bar();
on_scope_exit baz();
// code
=======================
Versus
=======================
try {
try {
try {
// code
} finally {
baz();
}
} catch (Object e) {
bar();
throw e;
}
} finally {
foo();
}
=======================
Example 2:
==================================
// notice how creation and cleanup are together
Logger log = getLogger();
on_scope_exit log.close();
on_scope_failure log.logFailure("...");
File outf = getOutputFile();
on_scope_exit outf.close();
File inf = getInputFile();
on_scope_exit inf.close();
File tmpf = createTempFile();
on_scope_exit tmpf.delete();
on_scope_exit tmpf.close();
// lots of code
==================================
Versus
==================================
Logger log = getLogger();
try {
File outf = getOutputFile();
try {
File inf = getInputFile();
try {
File tmpf = createTempFile();
try {
// lots of code
} finally {
tmpf.close();
tmpf.delete();
}
} finally {
inf.close();
}
} finally {
outf.close();
}
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
log.close();
}
==================================
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
==================================
Logger log = getLogger();
try {
File outf = getOutputFile();
try {
File inf = getInputFile();
try {
File tmpf = createTempFile();
try {
// lots of code
} finally {
tmpf.close();
tmpf.delete();
}
} finally {
inf.close();
}
} finally {
outf.close();
}
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
log.close();
}
==================================
This is real life example:
Logger log = getLogger();
try {
File outf = getOutputFile(); // state managed outside
File inf = getInputFile(); // state managed outside
File tmpf = createTempFile();
// lots of code
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
delete tmpf;
}
log.close();
----------------------------------
Andrew.
↑ ↓ ← → Carlos Santander <csantander619 gmail.com> writes:
Andrew Fedoniouk escribió:
This is real life example:
Logger log = getLogger();
try {
File outf = getOutputFile(); // state managed outside
File inf = getInputFile(); // state managed outside
File tmpf = createTempFile();
// lots of code
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
delete tmpf;
}
log.close();
----------------------------------
Andrew.
This is not rhetorical, but honest: in the cases where you said "state managed
outside", how do you do that? i.e., how do you know for sure that the files will
be closed, provided that destructors are not guaranteed to be run and you can't
return auto references?
--
Carlos Santander Bernal
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, Carlos
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:dtvtgt$2mvh$1 digitaldaemon.com...
Andrew Fedoniouk escribió:
This is real life example:
Logger log = getLogger();
try {
File outf = getOutputFile(); // state managed outside
File inf = getInputFile(); // state managed outside
File tmpf = createTempFile();
// lots of code
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
delete tmpf;
}
log.close();
----------------------------------
Andrew.
This is not rhetorical, but honest: in the cases where you said "state
managed
outside", how do you do that? i.e., how do you know for sure that the
files will
be closed, provided that destructors are not guaranteed to be run and you
can't return auto references?
"get" in getOutputFile implies that file exists somewhere and opened by
someone else
so code here cannot delete it.
In contrary "create" in createTempFile says that it creates new instance
so we are owning it - must delete.
If getOutputFile creates new instance then
finally {
delete tmpf;
delete outf;
delete inf;
}
will be enough.
In any case it shall be something one: either
try-catch-finally or on_scope_xxx() - two similar
and probably conflicting mechanisms is a bad design.
( This is why I like Java - with some minor exceptions
its grammar just perfect for the the domain it serves.
Ascetic but clean and simple. )
Andrew Fedoniouk.
http://terrainformatica.com
↑ ↓ ← → Carlos Santander <csantander619 gmail.com> writes:
Andrew Fedoniouk escribió:
Hi, Carlos
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:dtvtgt$2mvh$1 digitaldaemon.com...
Andrew Fedoniouk escribió:
This is real life example:
Logger log = getLogger();
try {
File outf = getOutputFile(); // state managed outside
File inf = getInputFile(); // state managed outside
File tmpf = createTempFile();
// lots of code
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
delete tmpf;
}
log.close();
----------------------------------
Andrew.
managed
outside", how do you do that? i.e., how do you know for sure that the
files will
be closed, provided that destructors are not guaranteed to be run and you
can't return auto references?
"get" in getOutputFile implies that file exists somewhere and opened by
someone else
so code here cannot delete it.
If I understand correctly, then that someone else who opened the file would
have
to close it (or delete it, as you put it). How does the opener know when to
close it?
In contrary "create" in createTempFile says that it creates new instance
so we are owning it - must delete.
If getOutputFile creates new instance then
finally {
delete tmpf;
delete outf;
delete inf;
}
will be enough.
See Walter's reply.
In any case it shall be something one: either
try-catch-finally or on_scope_xxx() - two similar
and probably conflicting mechanisms is a bad design.
Not necessarily. RAII and finally could be seen as "similar mechanisms", but I
don't think having both is a bad design. How about for and foreach? do and
while? function and delegate?
( This is why I like Java - with some minor exceptions
its grammar just perfect for the the domain it serves.
Ascetic but clean and simple. )
Andrew Fedoniouk.
http://terrainformatica.com
--
Carlos Santander Bernal
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:dtvl91$2dds$1 digitaldaemon.com...
This is real life example:
Logger log = getLogger();
try {
File outf = getOutputFile(); // state managed outside
File inf = getInputFile(); // state managed outside
File tmpf = createTempFile();
// lots of code
} catch (Object e) {
log.logFailure("...");
throw e;
} finally {
delete tmpf;
}
log.close();
I don't see how it could be real life, since tmpf is not in scope in the
finally statement, so it won't compile. Furthermore, even if tmpf was in
scope, if getOutputFile() throws, then tmpf wouldn't have even been created
when the finally statement attempts to delete it. The log.close() also does
not reliably happen, as the throw e; statement would cause it to be skipped.
These kinds of issues are what on_scope_xxx are for. Let's rewrite it:
Logger log = getLogger();
on_scope_exit log.close();
on_scope_failure log.logFailure("...");
File outf = getOutputFile();
File inf = getInputFile();
File tmpf = createTempFile();
on_scope_exit delete tmpf;
...lots of code...
We don't have any more resource leaks.
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 27 Feb 2006 10:42:10 -0800, Andrew Fedoniouk
<news terrainformatica.com> wrote:
I am with Charles here...
I don't understand why
on_scope_failure & co. are significantly better than
try catch finally?
What is wrong with them?
Semantically try-catch-finally are well known and
widely recognizable constructions.
BTW: Am I right in my assumption that
proposed on_scope_exit / on_scope_success / on_scope_failure
is a direct equivalent of the following:
try
{
[scope code]
my_on_scope_success().
}
catch(...)
{
my_on_scope_failure().
}
finally {
my_on_scope_exit().
}
If yes then again what it wrong with them in principle?
For a simple example it is very similar, for a more complex one it's not.
Have you read this:
http://www.digitalmars.com/d/exception-safe.html
Here is my attempt at "explaination by example", a more complex example
and it's equivalent using try/catch/finally.
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
on_scope_failure dofoo_unwind(f);
b = dobar();
on_scope_failure dobar_unwind(b);
d = dodef();
return Transaction(f, b, d);
}
as try/catch/finally:
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
try {
b = dobar();
try {
d = dodef();
return Transaction(f, b, d);
}
catch(Object o) {
dobar_unwind(b);
throw o;
}
}
catch(Object o) {
dofoo_unwind(f);
throw o;
}
}
Note, the order of the unwind calls is important:
http://www.digitalmars.com/d/statement.html#scope
"If there are multiple OnScopeStatements in a scope, they are executed
in the reverse lexical order in which they appear."
There are many benefits of on_scope over try/catch, they are:
1. less verbose, with less clutter it's easier to see the purpose of the
code. on scope scales well to handle many 'transactions' which require
cleanup, like the example above, try/catch/finally does not, it gets
horribly nested and confusing.
2. groups the cleanup code with code that requires it, less seperation
between the thing that is done, and the thing that cleans up after it.
try/catch/finally has the cleanup code in a seperate 'catch' or 'finally'
scope often a long way from the code that creates the need for that
cleanup.
Regan
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:ops5nhbgii23k2f5 nrage.netwin.co.nz...
On Mon, 27 Feb 2006 10:42:10 -0800, Andrew Fedoniouk
<news terrainformatica.com> wrote:
I am with Charles here...
I don't understand why
on_scope_failure & co. are significantly better than
try catch finally?
What is wrong with them?
Semantically try-catch-finally are well known and
widely recognizable constructions.
BTW: Am I right in my assumption that
proposed on_scope_exit / on_scope_success / on_scope_failure
is a direct equivalent of the following:
try
{
[scope code]
my_on_scope_success().
}
catch(...)
{
my_on_scope_failure().
}
finally {
my_on_scope_exit().
}
If yes then again what it wrong with them in principle?
For a simple example it is very similar, for a more complex one it's not.
Have you read this:
http://www.digitalmars.com/d/exception-safe.html
Here is my attempt at "explaination by example", a more complex example
and it's equivalent using try/catch/finally.
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
on_scope_failure dofoo_unwind(f);
b = dobar();
on_scope_failure dobar_unwind(b);
d = dodef();
return Transaction(f, b, d);
}
as try/catch/finally:
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo(); try {
b = dobar();
try {
d = dodef();
return Transaction(f, b, d);
}
catch(Object o) {
dobar_unwind(b);
throw o;
}
}
catch(Object o) {
dofoo_unwind(f);
throw o;
} }
Note, the order of the unwind calls is important:
http://www.digitalmars.com/d/statement.html#scope
"If there are multiple OnScopeStatements in a scope, they are executed
in the reverse lexical order in which they appear."
There are many benefits of on_scope over try/catch, they are:
1. less verbose, with less clutter it's easier to see the purpose of the
code. on scope scales well to handle many 'transactions' which require
cleanup, like the example above, try/catch/finally does not, it gets
horribly nested and confusing.
2. groups the cleanup code with code that requires it, less seperation
between the thing that is done, and the thing that cleans up after it.
try/catch/finally has the cleanup code in a seperate 'catch' or 'finally'
scope often a long way from the code that creates the need for that
cleanup.
Regan
Seems like I realy don't understand something here...
Why you think that your example is aesthetically
better (technically they are the same) than this?
Transaction abc()
{
Foo f; Bar b; Def d;
try
{
f = dofoo();
b = dobar();
d = dodef();
return Transaction(f, b, d);
}
finally {
delete f; delete b; delete d;
}
}
I can easily accept on_scope_failure if
it would solve something in principle.
But so far it is a reformulation of VBs onerror/resume as
far as I can see.
Andrew Fedoniouk.
http://terrainformatica.com
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 27 Feb 2006 19:54:23 -0800, Andrew Fedoniouk
<news terrainformatica.com> wrote:
Seems like I realy don't understand something here...
Why you think that your example is aesthetically
better (technically they are the same) than this?
Wait, your example below is not technically the same as mine because:
1. My example (actually taken from the docs on digitalmars.com) used
on_scope_failure, not on_scope_exit. on_scope_exit has the same effect as
"finally" except...
2. The important feature of all of these statements is that they allow you
to add items to the list of things to do _as you go_ and to then execute
them in reverse lexical order at the appropriate time i.e. on_scope_exit
or on_scope_failure etc.
The same cannot be achieved with catch or finally without nesting several
of them. That is what the example I gave was designed to show I believe.
Transaction abc()
{
Foo f; Bar b; Def d;
try
{
f = dofoo();
b = dobar();
d = dodef();
return Transaction(f, b, d);
}
finally {
delete f; delete b; delete d;
}
}
For the fun of it, lets re-write your example to use on_scope_exit:
Transaction abc()
{
Foo f; Bar b; Def d;
f = dofoo();
on_scope_exit delete f;
b = dobar();
on_scope_exit delete b;
d = dodef();
on_scope_exit delete d;
return Transaction(f, b, d);
}
I believe this is better that your try/finally example because:
1- delete is not called on an unitialized class reference as in your
example. (thankfully D initialises them to null)
2- the init and delete of each object is in the same place (the larger
the block of code this is used in, the better it gets).
3- the resulting code is linear, which is easier to follow than some
branching, indented, or nested try/catch/finally block.
Regan
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:ops5n25std23k2f5 nrage.netwin.co.nz...
On Mon, 27 Feb 2006 19:54:23 -0800, Andrew Fedoniouk
<news terrainformatica.com> wrote:
Seems like I realy don't understand something here...
Why you think that your example is aesthetically
better (technically they are the same) than this?
Wait, your example below is not technically the same as mine because:
1. My example (actually taken from the docs on digitalmars.com) used
on_scope_failure, not on_scope_exit. on_scope_exit has the same effect as
"finally" except...
2. The important feature of all of these statements is that they allow you
to add items to the list of things to do _as you go_ and to then execute
them in reverse lexical order at the appropriate time i.e. on_scope_exit
or on_scope_failure etc.
BTW:
Walter is using "reverse lexical order" incorectly in the doc I beleive.
"lexical order" is something from different opera.
Andrew
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:du0hhf$a0u$1 digitaldaemon.com...
Why you think that your example is aesthetically
better (technically they are the same) than this?
Transaction abc()
{
Foo f; Bar b; Def d;
try
{
f = dofoo();
b = dobar();
d = dodef();
return Transaction(f, b, d);
}
finally {
delete f; delete b; delete d;
}
}
Technically, they are not the same. The above version *always* deletes f, b
and d, but it's not supposed to if the function succeeds. Only if dofoo(),
dobar(), or dodef() throws are f, b and d supposed to be deleted.
This is the whole problem with try-finally. It works great with trivial
problems, and all the tutorials and example code unsurprisingly only show
trivial problems. Try scaling it up for things like multi-step transactions,
and it gets very complicated very fast, and it gets very hard to get right.
Here's the on_scope version:
Transaction abc()
{
Foo f = dofoo();
on_scope_failure delete f;
Bar b = dobar();
on_scope_failure delete b;
Def d = dodef();
on_scope_failure delete d;
return Transaction(f, b, d);
}
Scaling it up is as easy as linearly adding more on_scope statements, and
easy to get it right.
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
Technically, they are not the same. The above version *always* deletes f,
b and d, but it's not supposed to if the function succeeds. Only if
dofoo(), dobar(), or dodef() throws are f, b and d supposed to be deleted.
Ok, mea culpa.
This is the whole problem with try-finally. It works great with trivial
problems, and all the tutorials and example code unsurprisingly only show
trivial problems. Try scaling it up for things like multi-step
transactions, and it gets very complicated very fast, and it gets very
hard to get right.
Well, I spent year programming on PocketPC in eVC where are no such
things as exceptions. In principle. Not implemented in C++ compiler.
Still alive :)
Here's the on_scope version:
Transaction abc()
{
Foo f = dofoo();
on_scope_failure delete f;
Bar b = dobar();
on_scope_failure delete b;
Def d = dodef();
on_scope_failure delete d;
return Transaction(f, b, d);
}
Scaling it up is as easy as linearly adding more on_scope statements, and
easy to get it right.
True.
But
Transaction abc()
{
try {
Foo f = dofoo();
Bar b = dobar();
Def d = dodef();
return Transaction(f, b, d);
} catch(object er) {
delete f; delete b; delete d;
}
}
is not worse to be honest.
I would think rather about extending mixins to allow to add
on_scope_exit as a custom template conrstructions.
Like mixins taking block {} as a parameter:
template on_scope_exit(B) auto Auto t = new Auto(B);
... and in Galaxy far far away:
mixin on_scope_exit{ delete foo; }
So anyone can implement needed policy for himself.
I mean on_scope_exit is only one particular way of dealing
with the problem. There are and will be others.
Huh?
Andrew.
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:du106f$ptt$1 digitaldaemon.com...
Well, I spent year programming on PocketPC in eVC where are no such
things as exceptions. In principle. Not implemented in C++ compiler.
Still alive :)
It's true that if code doesn't generate exceptions, then one doesn't need
exception safety.
But
Transaction abc()
{
try {
Foo f = dofoo();
Bar b = dobar();
Def d = dodef();
return Transaction(f, b, d);
} catch(object er) {
delete f; delete b; delete d;
}
}
is not worse to be honest.
It is worse because it won't even compile. f, b, and d are not in scope in
the catch statement. Even if they were, there's still a serious bug - if
dofoo() throws an exception, then the catch statement will attempt to delete
b and d, which are not even initialized yet.
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:du106f$ptt$1 digitaldaemon.com...
Well, I spent year programming on PocketPC in eVC where are no such
things as exceptions. In principle. Not implemented in C++ compiler.
Still alive :)
It's true that if code doesn't generate exceptions, then one doesn't need
exception safety.
It's worth mentioning that an allocation failure will cause an exception
to be thrown, in addition to divide by zero and other errors on Windows.
So code doesn't need to explicitly throw to generate exceptions.
The PocketPC really doesn't have exceptions? And they still call it
C++? :-)
But
Transaction abc()
{
try {
Foo f = dofoo();
Bar b = dobar();
Def d = dodef();
return Transaction(f, b, d);
} catch(object er) {
delete f; delete b; delete d;
}
}
is not worse to be honest.
It is worse because it won't even compile. f, b, and d are not in scope in
the catch statement. Even if they were, there's still a serious bug - if
dofoo() throws an exception, then the catch statement will attempt to delete
b and d, which are not even initialized yet.
Is it really a bug to call delete on a null reference? This is
well-defined behavior in C++.
Sean
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:du225a$2549$1 digitaldaemon.com...
But
Transaction abc()
{
try {
Foo f = dofoo();
Bar b = dobar();
Def d = dodef();
return Transaction(f, b, d);
} catch(object er) {
delete f; delete b; delete d;
}
}
is not worse to be honest.
It is worse because it won't even compile. f, b, and d are not in scope
in the catch statement. Even if they were, there's still a serious bug -
if dofoo() throws an exception, then the catch statement will attempt to
delete b and d, which are not even initialized yet.
Is it really a bug to call delete on a null reference? This is
well-defined behavior in C++.
It's not even a null reference.
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
"Sean Kelly" <sean f4.ca> wrote in message
news:du225a$2549$1 digitaldaemon.com...
But
Transaction abc()
{
try {
Foo f = dofoo();
Bar b = dobar();
Def d = dodef();
return Transaction(f, b, d);
} catch(object er) {
delete f; delete b; delete d;
}
}
is not worse to be honest.
in the catch statement. Even if they were, there's still a serious bug -
if dofoo() throws an exception, then the catch statement will attempt to
delete b and d, which are not even initialized yet.
well-defined behavior in C++.
It's not even a null reference.
Not in the above example, but then the above example doesn't even
compile. I assumed you were talking about something like this:
Foo f;
Bar b;
try {
f = dofoo();
b = dobar();
} catch( Object o ) {
delete f; delete b;
}
It's quite possible for f and b to both be uninitialized, yet I would
expect the delete calls to be well-defined anyway.
Sean
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:du25eb$288m$3 digitaldaemon.com...
Not in the above example, but then the above example doesn't even compile.
I assumed you were talking about something like this:
Foo f;
Bar b;
try {
f = dofoo();
b = dobar();
} catch( Object o ) {
delete f; delete b;
}
It's quite possible for f and b to both be uninitialized, yet I would
expect the delete calls to be well-defined anyway.
delete is well defined, and works properly with null. For more complex
unwinding, you'll need to add state variables to keep track of what has been
set and what hasn't.
The new bug in the above code is that the catch block fails to rethrow o.
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the on_scope
correct. This leads me to believe that try-catch-finally is just
conceptually wrong, as it does not match up with how we think despite being
in common use for over a decade.
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
"Sean Kelly" <sean f4.ca> wrote in message
news:du25eb$288m$3 digitaldaemon.com...
Not in the above example, but then the above example doesn't even compile.
I assumed you were talking about something like this:
Foo f;
Bar b;
try {
f = dofoo();
b = dobar();
} catch( Object o ) {
delete f; delete b;
}
It's quite possible for f and b to both be uninitialized, yet I would
expect the delete calls to be well-defined anyway.
delete is well defined, and works properly with null. For more complex
unwinding, you'll need to add state variables to keep track of what has been
set and what hasn't.
That's all I was asking. I wondered at the implications of:
"there's still a serious bug - if dofoo() throws an exception, then the
catch statement will attempt to delete b and d, which are not even
initialized yet"
The new bug in the above code is that the catch block fails to rethrow o.
Arguably not a bug, as this could be intended behavior. However, I
would think it's clear that the above code was merely intended to
clarify a previous statement. I wouldn't suggest that it is correct or
well-written :-)
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the on_scope
correct. This leads me to believe that try-catch-finally is just
conceptually wrong, as it does not match up with how we think despite being
in common use for over a decade.
I've been sold on Andrei's method since he first introduced it, so no
issue there. It's certainly far simpler and more meaningful than the
backflips often required by RAII. And while the proposed C++ shared_ptr
syntax makes some progress for this purpose, it's still a far cry from
on_scope_*, particularly when paired with inner functions.
Sean
↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:
On Wed, 01 Mar 2006 06:19:35 +1100, Walter Bright
<newshound digitalmars.com> wrote:
...
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the on_scope
correct. This leads me to believe that try-catch-finally is just
conceptually wrong, as it does not match up with how we think despite
being in common use for over a decade.
Execellent point, Walter. The concept of scope guards in D is very
exciting and a real winner in my opinion. I'm looking forward to the
syntax improving and stabilizing so I can use it in real applications.
And may I be so bold as to paraphase you ...
: I hope that these buggy examples show just how hard it is to get
: C-style booleans to be correct, and how easy it is to get the
semantically
: boolean correct. This leads me to believe that the C-style boolean is
just
: conceptually wrong, as it does not match up with how we think despite
: being in common use for many decades.
<G><G><G>
--
Derek Parnell
Melbourne, Australia
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s5pd12y86b8z09 ginger.vic.bigpond.net.au...
<G><G><G>
Nice try :-)
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:du2925$2cvj$1 digitaldaemon.com...
"Sean Kelly" <sean f4.ca> wrote in message
news:du25eb$288m$3 digitaldaemon.com...
Not in the above example, but then the above example doesn't even
compile. I assumed you were talking about something like this:
Foo f;
Bar b;
try {
f = dofoo();
b = dobar();
} catch( Object o ) {
delete f; delete b;
}
It's quite possible for f and b to both be uninitialized, yet I would
expect the delete calls to be well-defined anyway.
delete is well defined, and works properly with null. For more complex
unwinding, you'll need to add state variables to keep track of what has
been set and what hasn't.
The new bug in the above code is that the catch block fails to rethrow o.
Let's say it was an intention. Pretty common by the way.
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the on_scope
correct. This leads me to believe that try-catch-finally is just
conceptually wrong, as it does not match up with how we think despite
being in common use for over a decade.
Well try first to explain what will happen on
on_scope_success { delete baz; throw foo; }
on_scope_exit { delete baz; throw foo; }
What "lexical order" will be used here? What scope guards will be invoked
and so on.
Having on_scope_*** spread all other the "... lots of code ..." will create
code maintainance nightmare as to trace visually what will happen and when
will not
be a task for human anymore.
And as far as I understand main idea of on_scope_exit is a sort of poor man
struct destructor...
I suspect that you are thinking about how to remove 'auto'/RAII, right?
Andrew.
http://terrainformatica.com
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:du2q1c$4tv$1 digitaldaemon.com...
"Walter Bright" <newshound digitalmars.com> wrote in message
The new bug in the above code is that the catch block fails to rethrow o.
Perhaps, but the stated point of the example was to show equivalent
try-catch code to the on_scope example. It isn't equivalent.
Well try first to explain what will happen on
on_scope_success { delete baz; throw foo; }
on_scope_exit { delete baz; throw foo; }
What "lexical order" will be used here? What scope guards will be invoked
and so on.
Throwing from inside an on_scope statement is as bad an idea as throwing
inside a destructor or inside a finally block. Doing it in an on_scope_exit
or on_scope_failure will result in a double-fault exception. Doing it in an
on_scope_success will be like throwing at the } of a scope.
Having on_scope_*** spread all other the "... lots of code ..." will
create
code maintainance nightmare as to trace visually what will happen and when
will not be a task for human anymore.
I submit that based on what's been posted in this thread, it's easier to get
on_scope *correct* than try-finally, because most of the try-finally
examples posted here do not work as intended by the author. Not only that,
the try-finally examples fail in ways that are difficult to write test cases
for, so the errors are likely to go unnoticed.
And as far as I understand main idea of on_scope_exit is a sort of poor
man struct destructor...
I suspect that you are thinking about how to remove 'auto'/RAII, right?
No. RAII is for managing resources, which is different from managing state
or transactions. try-catch is still needed, as on_scope doesn't catch
exceptions. It's try-finally that becomes redundant, though it is useful to
keep it because so many people are used to it.
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:du2q1c$4tv$1 digitaldaemon.com...
"Walter Bright" <newshound digitalmars.com> wrote in message
The new bug in the above code is that the catch block fails to rethrow o.
Perhaps, but the stated point of the example was to show equivalent
try-catch code to the on_scope example. It isn't equivalent.
That may have been the point of the original example, but it wasn't the
point of mine. But it's water under the bridge, as you answered my
question either way :-)
Having on_scope_*** spread all other the "... lots of code ..." will
create
code maintainance nightmare as to trace visually what will happen and when
will not be a task for human anymore.
I submit that based on what's been posted in this thread, it's easier to get
on_scope *correct* than try-finally, because most of the try-finally
examples posted here do not work as intended by the author. Not only that,
the try-finally examples fail in ways that are difficult to write test cases
for, so the errors are likely to go unnoticed.
The only complaint I've heard about on_scope that I consider valid is
that program flow may be a tad confusing in excessively long functions.
But traditional RAII is no better, and try-finally introduces
maintenance and readability problems by breaking the logical connection
between unwinding code and the code block it's associated with. It's
also helpful that throwing an exception while another is in-flight in D
does not result in program termination, even if doing so is not advisable.
And as far as I understand main idea of on_scope_exit is a sort of poor
man struct destructor...
I suspect that you are thinking about how to remove 'auto'/RAII, right?
No. RAII is for managing resources, which is different from managing state
or transactions. try-catch is still needed, as on_scope doesn't catch
exceptions. It's try-finally that becomes redundant, though it is useful to
keep it because so many people are used to it.
That may have been the original intent, but RAII has since become almost
indispensable for writing exception-safe code, be it with resources,
transactions, or something else. Personally, I've never liked
try-finally, but I attribute that to my C++ background. If I were a
Java person it may be a different story.
Sean
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:du4mfe$18k5$1 digitaldaemon.com...
Walter Bright wrote:
RAII is for managing resources, which is different from managing state or
transactions. try-catch is still needed, as on_scope doesn't catch
exceptions. It's try-finally that becomes redundant, though it is useful
to keep it because so many people are used to it.
That may have been the original intent, but RAII has since become almost
indispensable for writing exception-safe code, be it with resources,
transactions, or something else.
RAII is used for those other things in C++ because there is *no other
choice*. Nevertheless, the reality of using destructors to manage
transaction processing is:
1) it's so hard to do that most programmers simply ignore the problem,
trusting to luck that exceptions won't happen
2) those that do try it, most of the time get it wrong
3) it's pretty hard to visually inspect the code and determine that it is
exception safe
This suggests to me that RAII and try-finally are the wrong paradigms for
doing transaction programming. I've attended Scott Meyer's insightful
lecture on doing transaction programming in C++. There is no hope for it to
be reliably done by anyone but experts.
Personally, I've never liked try-finally, but I attribute that to my C++
background. If I were a Java person it may be a different story.
Try-finally and RAII are like goto's. They work, but aren't using whiles,
fors, switches, etc., much more natural?
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
This suggests to me that RAII and try-finally are the wrong paradigms for
doing transaction programming. I've attended Scott Meyer's insightful
lecture on doing transaction programming in C++. There is no hope for it to
be reliably done by anyone but experts.
This is actually my concern about C++ in general. The language is
becoming so complicated--including the recommended solutions to common
problems--that I wonder if any but experts will be able to reliably
write correct code. And in my personal experience, C++ experts are few
and far between.
Sean
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:du51tu$1lvh$1 digitaldaemon.com...
Walter Bright wrote:
This suggests to me that RAII and try-finally are the wrong paradigms for
doing transaction programming. I've attended Scott Meyer's insightful
lecture on doing transaction programming in C++. There is no hope for it
to be reliably done by anyone but experts.
This is actually my concern about C++ in general. The language is
becoming so complicated--including the recommended solutions to common
problems--that I wonder if any but experts will be able to reliably write
correct code. And in my personal experience, C++ experts are few and far
between.
True. I run into a lot of C++ programmers, but few who really enjoy it. They
usually use C++ because they need the performance, not because they like it.
The leading edge of C++ thought is to use increasingly complex templates for
everything. The new C++0x proposed features are aimed at more complex
template support.
By doing this, C++ has opened the door wide for Java, Ruby, C#, etc. C++ is
never going to go away, but it will increasingly marginalize itself as the
C++ experts leave the average programmer further and further behind.
↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:
In article <du5cao$237b$1 digitaldaemon.com>, Walter Bright says...
"Sean Kelly" <sean f4.ca> wrote in message
news:du51tu$1lvh$1 digitaldaemon.com...
Walter Bright wrote:
This suggests to me that RAII and try-finally are the wrong paradigms for
doing transaction programming. I've attended Scott Meyer's insightful
lecture on doing transaction programming in C++. There is no hope for it
to be reliably done by anyone but experts.
This is actually my concern about C++ in general. The language is
becoming so complicated--including the recommended solutions to common
problems--that I wonder if any but experts will be able to reliably write
correct code. And in my personal experience, C++ experts are few and far
between.
True. I run into a lot of C++ programmers, but few who really enjoy it. They
usually use C++ because they need the performance, not because they like it.
The leading edge of C++ thought is to use increasingly complex templates for
everything. The new C++0x proposed features are aimed at more complex
template support.
I think this is C language history repeating itself. A book called Principia
Mathematica was once written, an attempt to build a minimal set of mathematical
axioms from which all others could be proven. It kept getting bigger and
bigger, but never had enough axioms. They wanted all necessary axioms, but none
that were provable from the others. Godel later proved that its impossible to
build such a list. But its a very magnetic idea for mathematicians.
C and C++ both strive to provide a sort of Principia for programming, a set of
language features from which all possible other features could be derived via
syntax, using macros, functions, and in C++, templates. They never want to add
anything that can already be defined with syntax.
The C language was kept simple, so if you wanted magic (as in, anything outside
the 'physics' of the language), you used the macro system. Like all magic, this
was 50% style and 50% fakery... If you poke at it, the illusion breaks down.
There were many "better" languages but nothing "better and committed in a big
way to high-performance code", until C++.
In C++, the language designers still feel pressured to keep things simple - e.g.
they try hard to avoid introducing keywords, and things like foreach are always
done in the STL not in the language. But they have a tendency to introduce
features and concepts that multiply the complexity of using the language. These
can't be done with macros, so they belong in the set of axioms. As they add
these multipliers, the knowledge needed to use it gets worse geometrically.
So the C++ team adds hard-to-implement/use stuff to the language, and rarely
adds easy-to-implement/use stuff, because the easy-to-implement stuff is doable
with macros/template magic. Macro/template language is much more powerful than
macro-only magic. But the illusion still breaks down ... everyone has an
ITERATE macro that doesnt quite work seamlessly.
By doing this, C++ has opened the door wide for Java, Ruby, C#, etc. C++ is
never going to go away, but it will increasingly marginalize itself as the
C++ experts leave the average programmer further and further behind.
The plethora of similar languages creates division, which causes tension. The
performance and low level abilities of C and C++ is not available in Ruby, C#,
or Java. I know the gap you mention creates tension on the programming teams
I've been on. The C++ wonks want the others to just do the right think (use all
the advanced methods all the time). The others just want the compiler to stop
bugging them and get out of their way.
I think the crown might pass to any language that could fix C++ performance and
syntax... once it declared for the throne. D does very well syntactically and
performance wise, but I think it still has the "not ready yet" label stuck on
the front of the box, because of the sub-1.0 version and lack of ... (insert
wishlist items). (Question: What was the "trigger" that made people start
adopting Java for projects?)
Kevin
↑ ↓ ← → ianc <ianc_member pathlink.com> writes:
(Question: What was the "trigger" that made people start
adopting Java for projects?)
Kevin
About 1996 the web and serverside programming took off. The options were:
- c++ - complicated and not fast enough turn around time for average users.
- visual basic - big problems with vb runtime on the server and windows only.
- scripting languages
- perl - complex for prog in the large
- php - too simple for prog in the large
- others - not mature enough
- delphi - excellent but owned by borland
- java - originally for applets at which it proved to be fairly useless - found
a niche on the server by default. The prog model was simple and the package and
jar features enabled prog in the large.
The things i like a about D are:
- makes the same trades offs as delphi
- fast compiled language without pointers being so "in your face".
- stucts on the stack, objects on the heap
- parameter passing to functions does not require pointers
- has a standards based scripting language - DMDScript/ECMAScript - which is
written in D.
- generic/templates
Pity it was not available a few years ago.
↑ ↓ ← → pragma <pragma_member pathlink.com> writes:
In article <du68r5$7fa$1 digitaldaemon.com>, ianc says...
(Question: What was the "trigger" that made people start
adopting Java for projects?)
Kevin
About 1996 the web and serverside programming took off. The options were:
- c++ - complicated and not fast enough turn around time for average users.
- visual basic - big problems with vb runtime on the server and windows only.
- scripting languages
- perl - complex for prog in the large
- php - too simple for prog in the large
- others - not mature enough
- delphi - excellent but owned by borland
- java - originally for applets at which it proved to be fairly useless - found
a niche on the server by default. The prog model was simple and the package and
jar features enabled prog in the large.
The things i like a about D are:
- makes the same trades offs as delphi
- fast compiled language without pointers being so "in your face".
- stucts on the stack, objects on the heap
- parameter passing to functions does not require pointers
- has a standards based scripting language - DMDScript/ECMAScript - which is
written in D.
- generic/templates
Pity it was not available a few years ago.
/me hands Ianc a cigar :)
- EricAnderton at yahoo
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
A lot of excellent comments. Some more from me embedded:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:du5hbu$2bag$1 digitaldaemon.com...
So the C++ team adds hard-to-implement/use stuff to the language, and
rarely
adds easy-to-implement/use stuff, because the easy-to-implement stuff is
doable
with macros/template magic. Macro/template language is much more powerful
than
macro-only magic. But the illusion still breaks down ... everyone has an
ITERATE macro that doesnt quite work seamlessly.
Yes, my thoughts exactly.
I think the crown might pass to any language that could fix C++
performance and
syntax... once it declared for the throne. D does very well syntactically
and
performance wise, but I think it still has the "not ready yet" label stuck
on
the front of the box, because of the sub-1.0 version and lack of ...
(insert
wishlist items).
The wishlist thing is an ever-growing thing. It's a problem, mostly my
fault.
(Question: What was the "trigger" that made people start
adopting Java for projects?)
The initial trigger was the idea you could embed Java applets into a web
page, coupled with the idea that it was a C++ like language that was, in
contrast, easilly mastered.
↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:
In article <du7fo5$1uqo$1 digitaldaemon.com>, Walter Bright says...
A lot of excellent comments. Some more from me embedded:
Thanks.
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:du5hbu$2bag$1 digitaldaemon.com...
So the C++ team adds hard-to-implement/use stuff to the language, and
rarely
adds easy-to-implement/use stuff, because the easy-to-implement stuff is
doable
with macros/template magic. Macro/template language is much more powerful
than
macro-only magic. But the illusion still breaks down ... everyone has an
ITERATE macro that doesnt quite work seamlessly.
Yes, my thoughts exactly.
I think the crown might pass to any language that could fix C++
performance and
syntax... once it declared for the throne. D does very well syntactically
and
performance wise, but I think it still has the "not ready yet" label stuck
on
the front of the box, because of the sub-1.0 version and lack of ...
(insert
wishlist items).
The wishlist thing is an ever-growing thing. It's a problem, mostly my
fault.
For some reason I always want to write "the only thing on the wishlist I really
care about is...", but then I think of 10 things right away. When I write here
I tend to write a lot of stuff off the cuff, in a sort of "noone's ever done X,
I wonder if it would be useful..." style.
But:
(Question: What was the "trigger" that made people start
adopting Java for projects?)
The initial trigger was the idea you could embed Java applets into a web
page, coupled with the idea that it was a C++ like language that was, in
contrast, easilly mastered.
You and Ianc wrote about this side of it, and it makes sense now - I have been
thinking of Java strictly in terms of language design.
Now I realize something..
Business people, and for that matter, most other people, tend to explain their
own logic (and history itself) via "narratives". Everyone used X, but then
problem Y happened. Language Z came along and solved this. Political movement
X was replaced by movement Y when World War Z occurred. Cause->Effect.
But the original rationale rarely stays put. C was for systems programming (but
took over everything). Java was designed for the web, but now is used for
desktop applications, etc. Computers originally were marketed for the home on
the rationale that they can manage recipes for dishes.
So... from this kind of marketing point of view, what problems are just over the
horizon that D can get ahead of the curve on? It's very good at what C, C++,
and Java already can do, better than those languages, IMHO.
But I'm coming around to the idea that to "win the election", D needs to look
like a solution to a crisis, or at least some phenomena that Bill Manager can
claim was a new problem that needed a new solution. Little problems won't cut
it, even if your project is dying of thousands of little papercuts.
(As an illustration, I changed the title of this post - snappier, right? The
following may seem a bit cynical, but I'm just trying to be practical.)
People who pick (or at least sign off on) programming languages will drag their
heels to adopt unless there is a motivation they can "feel". Reduces pointer
errors by 35% and code length by 20% is not good enough, even if it would save
the software industry. I once described D to a colleage as a language that
"improves hundreds of little things that taken together are revolutionary". But
I couldn't think of a "killer app" story for D.
This is not a criticism of business, its just that to take a big risk, managers
need to know (1) what problem they are solving, (2) how to measure whether the
solution is working. Otherwise they feel they could easily get conned by silver
bullet salesmen -- it's happened before, right? If you ask a big-name CEO what
problem he is solving with a new initiative, its a "moment of truth" question
for him. He won't argue incremental improvements, he'll strike at the core of
something he thinks is close to your heart and explain how his company can help.
Let me propose some general hype; these will look a little like hyperbole, but
most of them are more or less true (or could be without *too* much pain):
1. D unites scripting style and C/C++ performance.
2. D is like C++ after the lessons learned from Java, Python, and Perl.
3. D is a high performance Java.
4. D can do Perl or Python-style rapid development, but is safe enough and fast
enough for "BIG" problems.
5. D is like Java, but for systems programming tasks.
6. D has all the power of C++ with the safety of Java.
[ Noone knows exactly what the previous means, but it leverages Java's claims.
Since much of Java's safety claims were on the basis of pointer elimination, D
can legitimately claim much of the same benefit. ]
5. D is compile anywhere, run anywhere.
This is not true yet; would be immense to accomplish unless the D compiler was
distributed with GCC. This is unfortunate, since the DMD compiler is so fast
and focused, but I think lack of platform portability is a killer for a compiler
(but not so much for an interpreter for some reason.)
I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
The high compile speed makes it perfect for scripting and rapid development on
the platforms it does support, and GCC's D compiler makes sure the rest of the
platforms don't have to go begging. Everyone gets fast development and every
platform can build binaries. But GCC would need to support D out of the box.
FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
there is one "blessed" compiler, but it still gets installed by everyone. All
of these seem to be scripting languages (why is that??). The only way this can
happen (I think) is if D supports every platform (very very much work, I
think...) or can at least produce and run some kind of bytecode.
[ D in bytecode sounds tricky, but I don't know enough to know how many genuine
obstacles there are. I would think the "Java subset" of D could be done this
way, but... ]
Compiled languages generally don't seem to take off until there is a compiler
available for every big platform. (Am I wrong about this?)
And to top it off, a "customer anecdote":
I work at a government job, writing public services and C++ libraries for
biotech apps. I imagine walking into a meeting and saying that there is this
cool new language, D, "but it only works on 32 bit amd/intel". This would be
enough to reject D (all our servers are 64 bit amd/intel already, and we also
provide Solaris, IRIX, OSX, and Windows binaries).
Which is too bad, because we are a high-performance project (we worry about
cache lines and register pressure all the time), that suffers from C language
pointer-related mishaps and C++ syntax related burn out. In many ways, D is
perfect for the niche we are in.
But on the other hand, our project has spent the last 3-5 years shifting from C
to a rewritten-in-C++ version. So it's probably a no-fly zone for new language
adoption in any case, for the next few years.
Kevin
↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kevin Bealer wrote:
5. D is compile anywhere, run anywhere.
This is not true yet; would be immense to accomplish unless the D compiler was
distributed with GCC. This is unfortunate, since the DMD compiler is so fast
and focused, but I think lack of platform portability is a killer for a
compiler
(but not so much for an interpreter for some reason.)
I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
The high compile speed makes it perfect for scripting and rapid development on
the platforms it does support, and GCC's D compiler makes sure the rest of the
platforms don't have to go begging. Everyone gets fast development and every
platform can build binaries. But GCC would need to support D out of the box.
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
Yes, I know that the main GCC distribution also contains frontends for
Objective C, Fortran, Java, and Ada. But those are more "different"... ?
As it is now, most GCC-using systems support C and C++ "out of the box",
and if you want an "odd" language like Pascal or D - you go download it:
http://www.gnu-pascal.de/ (GNU Pascal Compiler, gpc)
http://home.earthlink.net/~dvdfrdmn/d/ (GNU D Compiler, gdc)
We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
(putting it on the TODO list for next GDC release, along with new site)
But then again most people don't want GDC, but want DMD on all platforms
and only want a Digital-Mars-supported graphical interface such as DWT ?
And there isn't much anyone but Walter himself can do about those, IMHO.
(I don't have time for both, so I'll worry about the GNU / wx versions)
FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
there is one "blessed" compiler, but it still gets installed by everyone. All
of these seem to be scripting languages (why is that??). The only way this can
happen (I think) is if D supports every platform (very very much work, I
think...) or can at least produce and run some kind of bytecode.
[ D in bytecode sounds tricky, but I don't know enough to know how many genuine
obstacles there are. I would think the "Java subset" of D could be done this
way, but... ]
Color me sceptic, but I'm not too sure about "D the scripting language".
It just doesn't seem to be in the nature of the language, to do that...
I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
But DMDScript is probably more likely to fill the DM scripting needs ?
--anders
↑ ↓ ← → ianc <ianc_member pathlink.com> writes:
In article <du91ou$1rd4$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kevin Bealer wrote:
5. D is compile anywhere, run anywhere.
This is not true yet; would be immense to accomplish unless the D compiler was
distributed with GCC. This is unfortunate, since the DMD compiler is so fast
and focused, but I think lack of platform portability is a killer for a
compiler
(but not so much for an interpreter for some reason.)
I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
The high compile speed makes it perfect for scripting and rapid development on
the platforms it does support, and GCC's D compiler makes sure the rest of the
platforms don't have to go begging. Everyone gets fast development and every
platform can build binaries. But GCC would need to support D out of the box.
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
Yes, I know that the main GCC distribution also contains frontends for
Objective C, Fortran, Java, and Ada. But those are more "different"... ?
As it is now, most GCC-using systems support C and C++ "out of the box",
and if you want an "odd" language like Pascal or D - you go download it:
http://www.gnu-pascal.de/ (GNU Pascal Compiler, gpc)
http://home.earthlink.net/~dvdfrdmn/d/ (GNU D Compiler, gdc)
We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
(putting it on the TODO list for next GDC release, along with new site)
But then again most people don't want GDC, but want DMD on all platforms
and only want a Digital-Mars-supported graphical interface such as DWT ?
And there isn't much anyone but Walter himself can do about those, IMHO.
(I don't have time for both, so I'll worry about the GNU / wx versions)
FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
there is one "blessed" compiler, but it still gets installed by everyone. All
of these seem to be scripting languages (why is that??). The only way this can
happen (I think) is if D supports every platform (very very much work, I
think...) or can at least produce and run some kind of bytecode.
[ D in bytecode sounds tricky, but I don't know enough to know how many genuine
obstacles there are. I would think the "Java subset" of D could be done this
way, but... ]
Color me sceptic, but I'm not too sure about "D the scripting language".
It just doesn't seem to be in the nature of the language, to do that...
I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
But DMDScript is probably more likely to fill the DM scripting needs ?
--anders
Anders, despite my inital thoughts D does not probably need to be part of gcc
install. The desktop has settled on x86 and dmd is strong there. Any idea what
Digital Mars biz model is for D when version 1 is released?
↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
ianc wrote:
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
install. The desktop has settled on x86 and dmd is strong there.
We probably do agree that packaging GDC up neatly is a Good Thing ?
And *that* is something I've been pretty much involved in, already.
A GDC-only package is in the 3-4 MB range, while a full GCC/G++/GDC
distribution is more in the 30-40 MB range. Still very downloadable ?
This could be discussed a lot more, but should go in the D.gnu group.
(or contact me privately - by email, if not for public NG discussion)
Any idea what
Digital Mars biz model is for D when version 1 is released?
No idea, but it would be interesting if they (he?) could expand on it...
I *guess* it would be similar to their C/C++ business model, though ?
http://www.digitalmars.com/shop.html
--anders
↑ ↓ ← → Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:
ianc wrote:
Any idea what
Digital Mars biz model is for D when version 1 is released?
No idea, but it would be interesting if they (he?) could expand on it...
I *guess* it would be similar to their C/C++ business model, though ?
http://www.digitalmars.com/shop.html
OEM licencing of DMD derivatives.
↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:
In article <du91ou$1rd4$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kevin Bealer wrote:
5. D is compile anywhere, run anywhere.
This is not true yet; would be immense to accomplish unless the D compiler was
distributed with GCC. This is unfortunate, since the DMD compiler is so fast
and focused, but I think lack of platform portability is a killer for a
compiler
(but not so much for an interpreter for some reason.)
I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
The high compile speed makes it perfect for scripting and rapid development on
the platforms it does support, and GCC's D compiler makes sure the rest of the
platforms don't have to go begging. Everyone gets fast development and every
platform can build binaries. But GCC would need to support D out of the box.
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
Yes, I know that the main GCC distribution also contains frontends for
Objective C, Fortran, Java, and Ada. But those are more "different"... ?
As it is now, most GCC-using systems support C and C++ "out of the box",
and if you want an "odd" language like Pascal or D - you go download it:
http://www.gnu-pascal.de/ (GNU Pascal Compiler, gpc)
http://home.earthlink.net/~dvdfrdmn/d/ (GNU D Compiler, gdc)
We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
(putting it on the TODO list for next GDC release, along with new site)
There is no technical reason. But go to your boss and tell him you want to use
a new language. He'll be sceptical... Now tell him you need to build your own
patched version GCC to get a compiler for it...
But then again most people don't want GDC, but want DMD on all platforms
and only want a Digital-Mars-supported graphical interface such as DWT ?
And there isn't much anyone but Walter himself can do about those, IMHO.
(I don't have time for both, so I'll worry about the GNU / wx versions)
DMD is much better, but since DMD produces machine code directly, it seems
likely that IA64, and even moreso, every non-intel version is going to require a
big chunk of Walter's time. This seems non-scalable right now... maybe the
code for DMD is flexible enough to make this happen quickly, but I don't know
enough.... correct me if I'm wrong, please.
FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
there is one "blessed" compiler, but it still gets installed by everyone. All
of these seem to be scripting languages (why is that??). The only way this can
happen (I think) is if D supports every platform (very very much work, I
think...) or can at least produce and run some kind of bytecode.
[ D in bytecode sounds tricky, but I don't know enough to know how many genuine
obstacles there are. I would think the "Java subset" of D could be done this
way, but... ]
Color me sceptic, but I'm not too sure about "D the scripting language".
It just doesn't seem to be in the nature of the language, to do that...
I think the main feature scripting languages have that make them so great in
their niche is that container classes, regexes, and a fair amount of system call
oriented syntax (i.e. backticks to run commands) are built right in.
D doesn't have all of this yet, but it's far ahead of C and C++ here. I think
it can handle the "scripty" end of the application spectrum better than most
other compiled languages.
It may never have bytecode, but users don't actually care about that if
compile/link is fast -- which seems to be true for dmd but not necessarily gdc.
The dmd compile feels faster than just starting the Java interpreter. I haven't
benchmarked it though.
I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
But DMDScript is probably more likely to fill the DM scripting needs ?
--anders
↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kevin Bealer wrote:
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
There is no technical reason. But go to your boss and tell him you want to use
a new language. He'll be sceptical... Now tell him you need to build your own
patched version GCC to get a compiler for it...
But one can still build binary packages for it (GDC), without it first
being a FSF project ? The only caveat being that if your system compiler
is too far away from what GDC works with, you'll need *another* GCC too.
(which could still be offered as an alternative installation, though...)
I don't necessarily think it's a bad idea. Just wonder why it has to be.
I'd worry more about the language spec not being open, or even finished.
[...]
It may never have bytecode, but users don't actually care about that if
compile/link is fast -- which seems to be true for dmd but not necessarily gdc.
The dmd compile feels faster than just starting the Java interpreter. I
haven't
benchmarked it though.
Part of this speed comes from optlink, I think ? (when it doesn't crash)
At least I've found the GCC linking to be slower, doubly so for C++...
--anders
↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:
In article <dua2qh$ong$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kevin Bealer wrote:
I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?
There is no technical reason. But go to your boss and tell him you want to use
a new language. He'll be sceptical... Now tell him you need to build your own
patched version GCC to get a compiler for it...
But one can still build binary packages for it (GDC), without it first
being a FSF project ? The only caveat being that if your system compiler
is too far away from what GDC works with, you'll need *another* GCC too.
(which could still be offered as an alternative installation, though...)
Like I said .. no *technical* reason, per se -- you could do this. But asking
your boss to approve a toolchain that you patch together yourself, is going to
be like telling him that he doesn't need to *buy* a car, he can just go to the
junkyard and get a nearly complete one running. He could, but he won't.
If your boss does programming or you have a lot of autonomy, you may have a
little flexibility here. But it will never make it in a "Java shop" programming
environment if you have to spend several hours fixing rejected patches to GCC
every time the next revision of GDC or GCC is desired.
It doesn't have to be part of the GCC found on GNU's FTP site, but you need to
at least be able to install the compiler and libphobos from "RPMs" or build them
from one or two tar files.
I don't necessarily think it's a bad idea. Just wonder why it has to be.
I'd worry more about the language spec not being open, or even finished.
[...]
It may never have bytecode, but users don't actually care about that if
compile/link is fast -- which seems to be true for dmd but not necessarily gdc.
The dmd compile feels faster than just starting the Java interpreter. I
haven't
benchmarked it though.
Part of this speed comes from optlink, I think ? (when it doesn't crash)
At least I've found the GCC linking to be slower, doubly so for C++...
--anders
I don't know - I usually work in Linux, and there it looks like dmd uses gcc to
do the link. There is an option that lets you see the commands its running.
Kevin
↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kevin Bealer wrote:
It doesn't have to be part of the GCC found on GNU's FTP site, but you need to
at least be able to install the compiler and libphobos from "RPMs" or build
them
from one or two tar files.
There *are* RPMs for GDC and DMD, though ?
Just haven't had space for the binaries...
But the specs can be found from here:
http://www.algonet.se/~afb/d/gdc.spec
http://www.algonet.se/~afb/d/dmd.spec
Part of this speed comes from optlink, I think ? (when it doesn't crash)
At least I've found the GCC linking to be slower, doubly so for C++...
I don't know - I usually work in Linux, and there it looks like dmd uses gcc to
do the link. There is an option that lets you see the commands its running.
Yes, that is true - it does use gcc on Linux.
--anders
↑ ↓ ← → ianc <ianc_member pathlink.com> writes:
Kevin, I think your analysis is totally correct.
Future 1 and 2 are both possibilitites.
But for anything to happen (as has i think been discussed prev):
- D v1.0 with decent standard libs needs to be reached.
- D frontend standard with gcc install with dmd the optimised commercial option.
A while back on Slashdot there was a discussion about what language the gnome
framework, desktop and apps should be written in. C was felt to be too low, C++
too tricky, python was a scripting language, mono and java were vm based and
tied to ms/sun.
Walter - or someone using his name - suggested D. D would be perfect for this.
Imagine a desktop stack build in D...ahhh. But i can't see it happening.
(Actually, C# on gcc would be good i.e c# as a compiled language. c# syntax and
semantics are pretty good. I think someone may have had a go at this but it
didn't progress).
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Kevin Bealer wrote:
Now I realize something..
Business people, and for that matter, most other people, tend to explain their
own logic (and history itself) via "narratives". Everyone used X, but then
problem Y happened. Language Z came along and solved this. Political movement
X was replaced by movement Y when World War Z occurred. Cause->Effect.
I think this is true of people in general. In fact, Bruce Schneier has
made the same observation with respect to security issues in that most
security initiatives have attempted to address "movie scenarios" rather
than actually improve security in a general sense. There's something
very compelling about a situation we can envision.
Compiled languages generally don't seem to take off until there is a compiler
available for every big platform. (Am I wrong about this?)
If you have Microsoft's marketing strength I think it's quite possible
to push a Windows-only solution. And I suspect people are willing to
take what they can get with niche platforms. But in general I suspect
this is true. Just look at ObjectiveC.
And to top it off, a "customer anecdote":
I work at a government job, writing public services and C++ libraries for
biotech apps. I imagine walking into a meeting and saying that there is this
cool new language, D, "but it only works on 32 bit amd/intel". This would be
enough to reject D (all our servers are 64 bit amd/intel already, and we also
provide Solaris, IRIX, OSX, and Windows binaries).
We're actually heading the opposite direction. Our software was
designed for 64-bit Sparc machines and we've recently ported it to
64-bit AMD. But 32-bit will never happen--memory requirements are
simply too high.
Which is too bad, because we are a high-performance project (we worry about
cache lines and register pressure all the time), that suffers from C language
pointer-related mishaps and C++ syntax related burn out. In many ways, D is
perfect for the niche we are in.
Same here. Though we'd have to make limited use of the GC for memory
size and performance reasons. Still, I think that would fit in nicely
with the way the system is designed.
Sean
↑ ↓ ← → Mike Capp <mike.capp gmail.com> writes:
In article <du8l4c$v6n$1 digitaldaemon.com>, Kevin Bealer says...
[snip]
Let me propose some general hype; these will look a little like hyperbole, but
most of them are more or less true (or could be without *too* much pain):
[snip]
I'd add:
7. D has all (well, most of) the power of C++ but with a grammar that is sane
enough to allow decent tools. The state of C++ tooling is abysmal, because it's
so pathologically awful to parse. Going back to C++ development after working in
a refactoring environment (e.g. VS+ReSharper for C#, or Eclipse/IDEA for Java)
feels like being dragged back to the Stone Age; productivity drops through the
floor.
cheers
Mike
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Kevin Bealer wrote:
> Let me propose some general hype; these will look a little like
hyperbole, but
most of them are more or less true (or could be without *too* much pain):
1. D unites scripting style and C/C++ performance.
2. D is like C++ after the lessons learned from Java, Python, and Perl.
3. D is a high performance Java.
4. D can do Perl or Python-style rapid development, but is safe enough and fast
enough for "BIG" problems.
5. D is like Java, but for systems programming tasks.
6. D has all the power of C++ with the safety of Java.
#3 and #6 is exactly what brought me to D, and I think it can bring many
others!!
↑ ↓ ← → David Medlock <noone nowhere.com> writes:
Kevin Bealer wrote:
In article <du5cao$237b$1 digitaldaemon.com>, Walter Bright says...
I think the crown might pass to any language that could fix C++ performance and
syntax... once it declared for the throne. D does very well syntactically and
performance wise, but I think it still has the "not ready yet" label stuck on
the front of the box, because of the sub-1.0 version and lack of ... (insert
wishlist items). (Question: What was the "trigger" that made people start
adopting Java for projects?)
Kevin
Java launched for 3 reasons(outside of Suns marketing), IMO:
1. Server side web programming was just taking off. This was Java's
killer app. Case in point: Flash does most interactive embedded stuff
today in web pages.
2. No pointers. No memory leaks eliminates large classes of errors. Even
though it existed in other languages, coupled with #1 this made Java a
much better C++.
3. A comprehensive set of tools and a company willing to support them.
In getting business to adopt your tech they need support and Sun
delivers(at least on Solaris and Win32 initially).
-DavidM
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
Java launched for 3 reasons(outside of Suns marketing), IMO:
1. Server side web programming was just taking off. This was Java's killer
app. Case in point: Flash does most interactive embedded stuff today in
web pages.
2. No pointers. No memory leaks eliminates large classes of errors. Even
though it existed in other languages, coupled with #1 this made Java a
much better C++.
3. A comprehensive set of tools and a company willing to support them. In
getting business to adopt your tech they need support and Sun delivers(at
least on Solaris and Win32 initially).
4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
in principle.
5. Extremely simple Java Native Interface mechanism - bridge to native code
for
mission crititcal pieces.
6. Extremely simple bytecode system. I know around 12 working
implementations
of Java VM.
7. ClassLoader as an entity. Killer thing, IMO.
8. Reflection as part of runtime.
------------------
Having said that Java has problems of course. It is good for some set of
tasks.
It is not an universal language.
But it is damned stable. Last 7 years or so it is working as it is.
↑ ↓ ← → David Medlock <noone nowhere.com> writes:
Andrew Fedoniouk wrote:
<snip, some great additions to my list>
Having said that Java has problems of course. It is good for some set of
tasks.
It is not an universal language.
But it is damned stable. Last 7 years or so it is working as it is.
the literal sense and the programming sense).
The generics add nothing useful besides Homogenous collections and
removal of casts, at the expense of loads of complexity.
At the same time Sun *rejected* Design by Contract proposals for the
language...disapointing.
I have a lot more fun with Groovy honestly.
-DavidM
↑ ↓ ← → Juan Jose Comellas <jcomellas gmail.com> writes:
Andrew Fedoniouk wrote:
Java launched for 3 reasons(outside of Suns marketing), IMO:
1. Server side web programming was just taking off. This was Java's
killer
app. Case in point: Flash does most interactive embedded stuff today in
web pages.
2. No pointers. No memory leaks eliminates large classes of errors. Even
though it existed in other languages, coupled with #1 this made Java a
much better C++.
3. A comprehensive set of tools and a company willing to support them. In
getting business to adopt your tech they need support and Sun delivers(at
least on Solaris and Win32 initially).
4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
in principle.
5. Extremely simple Java Native Interface mechanism - bridge to native
code for
mission crititcal pieces.
I beg to differ here. I've worked on several projects on Linux that use JNI
extensively and it's anything but easy to use. It may work for simple
cases, but it has all kinds of quirks and it's unnecessarily verbose. Every
JVM has its JNI functions in different libraries, so there's no hope of
simple portability between them. To top it all, just try to embed the JVM
inside a process that uses threads and Unix signals to see what "all hell
breaks loose" really means.
I think the guy who designed JNI really didn't want it to be used.
↑ ↓ ← → AgentOrange <AgentOrange_member pathlink.com> writes:
In article <du9qmo$9rk$1 digitaldaemon.com>, Juan Jose Comellas says...
Andrew Fedoniouk wrote:
Java launched for 3 reasons(outside of Suns marketing), IMO:
1. Server side web programming was just taking off. This was Java's
killer
app. Case in point: Flash does most interactive embedded stuff today in
web pages.
2. No pointers. No memory leaks eliminates large classes of errors. Even
though it existed in other languages, coupled with #1 this made Java a
much better C++.
3. A comprehensive set of tools and a company willing to support them. In
getting business to adopt your tech they need support and Sun delivers(at
least on Solaris and Win32 initially).
4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
in principle.
5. Extremely simple Java Native Interface mechanism - bridge to native
code for
mission crititcal pieces.
I beg to differ here. I've worked on several projects on Linux that use JNI
extensively and it's anything but easy to use. It may work for simple
cases, but it has all kinds of quirks and it's unnecessarily verbose. Every
JVM has its JNI functions in different libraries, so there's no hope of
simple portability between them. To top it all, just try to embed the JVM
inside a process that uses threads and Unix signals to see what "all hell
breaks loose" really means.
I think the guy who designed JNI really didn't want it to be used.
yeh even ID wanted to use java for gameplay in quake 2 but found the JNI a
jumbled mess - and so different on each platform it was not possible to use a
single codebase. luckally they saw the light of day, threw java away, and wrote
quakec.
coming from a gamedev background, i cant really stand java....
↑ ↓ ← → Matthias Spycher <matthias coware.com> writes:
I completely agree with Andrew's points. Interspersed some comments below:
Andrew Fedoniouk wrote:
4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
in principle.
Concurrency and the memory model should be mentioned. Final, volatile
and object initialization are well defined in a concurrent setting (as
of J2SE 5).
5. Extremely simple Java Native Interface mechanism - bridge to native code
for
mission crititcal pieces.
Minimal exposure, even to JNI programmers, of the VM's internals.
Verbose, ugly? Maybe, but works as intended.
6. Extremely simple bytecode system. I know around 12 working
implementations
of Java VM.
Mobility of state and behavior -- this was one of the original
requirements for the Oak language and runtime when it was first
implemented. It is interesting to note that the platform was initially
designed for PDAs and other mobile gadgets with wireless connectivity.
The internet, browsers and applets came much later; and "accidentally"
turned out to be the most effective vehicle for marketing the system.
Leave out the byte code and we might instead be programming in Dylan or
some other "exotic" language.
7. ClassLoader as an entity. Killer thing, IMO.
across units that are loaded at runtime? For server-side programming,
even D will be challenged on this front.
8. Reflection as part of runtime.
------------------
Having said that Java has problems of course. It is good for some set of
tasks.
It is not an universal language.
But it is damned stable. Last 7 years or so it is working as it is.
Agreed. D is a great step forward for C and C++ programmers, as these
languages compete in the same application domains. Java and C# will
continue to dominate in managed environments. IMHO, Scala is the kind of
language that might challenge Java/C# in the long run.
Matthias
↑ ↓ ← → David Medlock <noone nowhere.com> writes:
Andrew Fedoniouk wrote:
7. ClassLoader as an entity. Killer thing, IMO.
Forgot to mention that this one is not entirely new, it was in Oberon
(circa 1986).
see:
http://www.ics.uci.edu/~franz/SlimBinaries.html
http://www.ics.uci.edu/~franz/pubs-pdf/C09.pdf
http://mini.net/tcl/4400
↑ ↓ ← → Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
RAII is for managing resources, which is different from managing state
or transactions.
This is a fantastic summary statement. I'd like to see it in the docs.
(In fact, error.html should have a link to exception-safe.html. Right
now, error.html is (for a C++ programmer at least) a "motherhood"
statement that doesn't have any D-specific substance).
try-catch is still needed, as on_scope doesn't catch
exceptions.
↑ ↓ ← → Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the on_scope
correct. This leads me to believe that try-catch-finally is just
conceptually wrong, as it does not match up with how we think despite being
in common use for over a decade.
This is very interesting. Seems to me that these on_scope_xxx are kind
of "naked destructors". If you consider them to be the low-level
construct, then putting a destructor into a class means: when the
constructor is called, insert "on_scope_exit ~this()" at the same time.
Is the convoluted nature of the RAII solution simply because
the same destructor is executed regardless of whether the function was
exited normally, or whether an exception occurred? And because there's
no easy way of determining if you are inside an exception handler. So
you only have "finally", without "catch".
I wonder if destructors could be jazzed up, so that they can insert an
"on_scope_failure" as well as "on_scope_exit"?
Maybe called ~catch()?
class Foo
{
~catch() {
unwind_foo();
}
}
class Bar
{
~this() { // destroy bar
}
~catch() {
unwind_bar();
// now we go to ~this(), which behaves like finally.
}
}
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
b = dobar();
d = dodef();
return Transaction(f, b, d);
}
Doesn't have the flexibility of on_scope, where you have access to all
variables -- but on the other hand, it has the RAII benefit that users
of the class don't need to remember to do it.
Just an idea.
↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
<snip>
Is the convoluted nature of the RAII solution simply because
the same destructor is executed regardless of whether the function was
exited normally, or whether an exception occurred? And because there's
no easy way of determining if you are inside an exception handler. So
you only have "finally", without "catch".
I wonder if destructors could be jazzed up, so that they can insert an
"on_scope_failure" as well as "on_scope_exit"?
Maybe called ~catch()?
Can you think of a practical use for this idea? I'm not sure what sense
it would make, considering that the class knows nothing of what the code
that failed was doing at the time.
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
↑ ↓ ← → Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
Walter Bright wrote:
I hope that these buggy examples show just how hard it is to get
try-catch-finally to be correct, and how easy it is to get the
on_scope correct. This leads me to believe that try-catch-finally is
just conceptually wrong, as it does not match up with how we think
despite being in common use for over a decade.
This is very interesting. Seems to me that these on_scope_xxx are kind
of "naked destructors". If you consider them to be the low-level
construct, then putting a destructor into a class means: when the
constructor is called, insert "on_scope_exit ~this()" at the same time.
on_scope does practically eliminate the need for an 'auto' keyword,
assuming auto classes would be allocated on the heap either way.
Is the convoluted nature of the RAII solution simply because
the same destructor is executed regardless of whether the function was
exited normally, or whether an exception occurred? And because there's
no easy way of determining if you are inside an exception handler. So
you only have "finally", without "catch".
I wonder if destructors could be jazzed up, so that they can insert an
"on_scope_failure" as well as "on_scope_exit"?
I've considered adding functionality to Ares to allow a user to
determine if an exception is currently in flight--C++ offers this but
it's little used as it's not terribly reliable. But with on_scope there
seems little need for this.
Maybe called ~catch()?
class Foo
{
~catch() {
unwind_foo();
}
}
class Bar
{
~this() { // destroy bar
}
~catch() {
unwind_bar();
// now we go to ~this(), which behaves like finally.
}
}
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
b = dobar();
d = dodef();
return Transaction(f, b, d);
}
Doesn't have the flexibility of on_scope, where you have access to all
variables -- but on the other hand, it has the RAII benefit that users
of the class don't need to remember to do it.
True. But I would argue that the burden of writing exception-safe code
is on the function writer moreso than the class writer, largely because
the class writer can't predict or address every way that his class may
be used. on_scope also allows a bit more flexibility:
{
Foo f = acquireFoo();
on_scope_exit f.commitAll();
on_scope_failure f.unwindAll();
f.setFirst();
{
f.setSecond();
on_scope_failure f.unwindLast();
}
}
Sean
↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:
Sean Kelly wrote:
<snip>
on_scope does practically eliminate the need for an 'auto' keyword,
assuming auto classes would be allocated on the heap either way.
How would you declare an auto class without the auto keyword?
Moreover, while
auto Qwert yuiop = new Qwert;
appears to be syntactic sugar for
Qwert yuiop = new Qwert;
on_scope_exit delete yuiop;
the former does still (I assume) have the advantage of stopping you from
inadvertently reassigning to yuiop.
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:du4q5j$1ckc$1 digitaldaemon.com...
Moreover, while
auto Qwert yuiop = new Qwert;
appears to be syntactic sugar for
Qwert yuiop = new Qwert;
on_scope_exit delete yuiop;
That's correct. In fact, it's implemented that way <g>.
the former does still (I assume) have the advantage of stopping you from
inadvertently reassigning to yuiop.
Yes, whereas the latter allows state unwinding for things that aren't class
objects. Without on_scope_exit, extra dummy classes would have to be defined
for each, turning a one liner into a dozen lines that appear out of context.
↑ ↓ ← → clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The syntax seems a little kludgey.
↑ ↓ ← → Wang Zhen <nehzgnaw gmail.com> writes:
clayasaurus wrote:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The syntax seems a little kludgey.
The Rubyish style hurts my eyes.
↑ ↓ ← → S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-25 18:06:36 -0800, "Walter Bright" <newshound digitalmars.com> said:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The only thing I see that's amazingly useful about this is the
on_scope_success. Having a block of code that is only executed when an
exception is NOT thrown would be nice. However, the rest of this stuff
seems like rocks under the water. Your example of the new programmer
coming in reads like this to me: "The new programmer may not take the
time to actually read the code he's modifying, so lets stick hidden
stuff in there to take care of things he might have missed." Which
doesn't seem very logical to me, as it may be just as important to
modify those on success/on failure blocks and miss them.
I'd say add another option to try..catch..finally paradigm.
-S.
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 27 Feb 2006 21:05:33 -0800, S. Chancellor
<dnewsgr mephit.kicks-ass.org> wrote:
On 2006-02-25 18:06:36 -0800, "Walter Bright"
<newshound digitalmars.com> said:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The only thing I see that's amazingly useful about this is the
on_scope_success. Having a block of code that is only executed when an
exception is NOT thrown would be nice. However, the rest of this stuff
seems like rocks under the water. Your example of the new programmer
coming in reads like this to me: "The new programmer may not take the
time to actually read the code he's modifying, so lets stick hidden
stuff in there to take care of things he might have missed." Which
doesn't seem very logical to me, as it may be just as important to
modify those on success/on failure blocks and miss them.
I'd say add another option to try..catch..finally paradigm.
You honestly don't think that this:
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
on_scope_failure dofoo_unwind(f);
b = dobar();
on_scope_failure dobar_unwind(b);
d = dodef();
return Transaction(f, b, d);
}
is better than this:
Transaction abc()
{
Foo f;
Bar b;
Def d;
f = dofoo();
try {
b = dobar();
try {
d = dodef();
return Transaction(f, b, d);
}
catch(Object o) {
dobar_unwind(b);
throw o;
}
}
catch(Object o) {
dofoo_unwind(f);
throw o;
}
}
Regan
↑ ↓ ← → Tom Johnson <Tom_member pathlink.com> writes:
I'd say add another option to try..catch..finally paradigm.
-S.
Seconded. For more fun, next we can debate whether the syntax should be:
1. try..pass..catch..finally
2. try..catch..pass...finally
3. try..catch..finally..pass
Tom
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 28 Feb 2006 06:34:00 +0000 (UTC), Tom Johnson
<Tom_member pathlink.com> wrote:
I'd say add another option to try..catch..finally paradigm.
-S.
Seconded. For more fun, next we can debate whether the syntax should be:
1. try..pass..catch..finally
2. try..catch..pass...finally
3. try..catch..finally..pass
No, on_scope gives us more than try/catch/finally. Let me try this another
way.
"catch" from try/catch/finally allows:
- you to execute a static/pre-defined set of code in the event that there
is a failure in the current scope.
"finally" from try/catch/finally allows:
- you to execute a static/pre-defined set of code at the exit of the
current scope in all cases.
Compare that to:
on_scope_failure allows:
- you to add one or more sets of code, at the points at which they become
required, to the list of things to execute in the event of a failure.
on_scope_exit allows:
- you to add one or more sets of code, at the points at which they become
required, to the list of things to execute at the exit of the scope in all
cases.
To achieve the same thing that on_scope gives with try/finally requires
you to store state somewhere to indicate which parts of the finally block
to execute, or, it requires that you define several finally blocks and
nest them. Both of those options are no where near as neat as on_scope.
I'm honestly baffled that people can't see the difference.
Regan
↑ ↓ ← → Tom Johnson <Tom_member pathlink.com> writes:
Regan,
Your last post finally made me get it.
on_scope_* is a different kind of construct. It's kind of like (imperfect
analogy coming) descending down a dynamic ladder. If you have to go up again
on_scope_failure tells you which how to undo each "code rung" so you can go back
up. The on_scope_success adds a last rung from the floor and on_scope_exit adds
codes at both ends of the ladder. The analogy wears a bit thin because you can
do on_scope_exit failure and success multiple times.
I have rtfa and all the previous messages and it still wasn't apparent that all
this was possible.
Thanks,
Tom
In article <ops5n86slk23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Tue, 28 Feb 2006 06:34:00 +0000 (UTC), Tom Johnson
<Tom_member pathlink.com> wrote:
I'd say add another option to try..catch..finally paradigm.
-S.
Seconded. For more fun, next we can debate whether the syntax should be:
1. try..pass..catch..finally
2. try..catch..pass...finally
3. try..catch..finally..pass
No, on_scope gives us more than try/catch/finally. Let me try this another
way.
"catch" from try/catch/finally allows:
- you to execute a static/pre-defined set of code in the event that there
is a failure in the current scope.
"finally" from try/catch/finally allows:
- you to execute a static/pre-defined set of code at the exit of the
current scope in all cases.
Compare that to:
on_scope_failure allows:
- you to add one or more sets of code, at the points at which they become
required, to the list of things to execute in the event of a failure.
on_scope_exit allows:
- you to add one or more sets of code, at the points at which they become
required, to the list of things to execute at the exit of the scope in all
cases.
To achieve the same thing that on_scope gives with try/finally requires
you to store state somewhere to indicate which parts of the finally block
to execute, or, it requires that you define several finally blocks and
nest them. Both of those options are no where near as neat as on_scope.
I'm honestly baffled that people can't see the difference.
Regan
↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:
Regan Heath wrote:
<snip>
To achieve the same thing that on_scope gives with try/finally requires
you to store state somewhere to indicate which parts of the finally
block to execute, or, it requires that you define several finally blocks
and nest them. Both of those options are no where near as neat as on_scope.
I'm honestly baffled that people can't see the difference.
When I started to read it, it did indeed look like syntactic sugar for
try/finally. But then I realised that, as you say, it saves some of the
need to nest try/finally blocks.
on_scope_failure has another advantage still: if you have multiple catch
blocks, it saves having to replicate the recovery code in each.
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
↑ ↓ ← → S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-27 23:17:06 -0800, "Regan Heath" <regan netwin.co.nz> said:
On Tue, 28 Feb 2006 06:34:00 +0000 (UTC), Tom Johnson
<Tom_member pathlink.com> wrote:
I'd say add another option to try..catch..finally paradigm.
-S.
Seconded. For more fun, next we can debate whether the syntax should be:
1. try..pass..catch..finally
2. try..catch..pass...finally
3. try..catch..finally..pass
No, on_scope gives us more than try/catch/finally. Let me try this
another way.
"catch" from try/catch/finally allows:
- you to execute a static/pre-defined set of code in the event that
there is a failure in the current scope.
"finally" from try/catch/finally allows:
- you to execute a static/pre-defined set of code at the exit of the
current scope in all cases.
Compare that to:
on_scope_failure allows:
- you to add one or more sets of code, at the points at which they
become required, to the list of things to execute in the event of a
failure.
on_scope_exit allows:
- you to add one or more sets of code, at the points at which they
become required, to the list of things to execute at the exit of the
scope in all cases.
To achieve the same thing that on_scope gives with try/finally requires
you to store state somewhere to indicate which parts of the finally
block to execute, or, it requires that you define several finally
blocks and nest them. Both of those options are no where near as neat
as on_scope.
I'm honestly baffled that people can't see the difference.
Regan
Ah. I see what you want. I was a bit confused about this before.
This is just syntatic sugar to a relatively easy to write class though.
Maybe it should be part of the standard library?
It essentially acts like a multi-homed delegate which is implicitly
called at the end of the scope.
Something like this would be equivalent?
Transaction abc()
{
Foo f;
Bar b;
Def d;
Auto scoped = new Scoper(); //scoped.exit() can be called by the
destructor. We won't add a finally block.
try {
scoped.failures ~= void delegate () { dofoo_unwind(f); }
f = dofoo();
scoped.failures ~= void delegate () { dobar_unwind(b); }
b = dobar();
scoped.success()
} catch (Exception o) {
scoped.failed()
throw o;
}
return Transaction(f, b, d);
}
It seems to me Walter's class example doesn't exactly do this justice.
I find this fully acceptable for the few places I would use this. The
implicit instantiation of an object like this might be nice though, if
it only added the extra code when it was referenced. Which should be
trivial to do. I'd much rather have an "implicit" scope object than
this, or the current syntax.
-S.
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message
news:du376e$1fbf$2 digitaldaemon.com...
Something like this would be equivalent?
Transaction abc()
{
Foo f;
Bar b;
Def d;
Auto scoped = new Scoper(); //scoped.exit() can be called by the
destructor. We won't add a finally block.
try {
scoped.failures ~= void delegate () { dofoo_unwind(f); }
f = dofoo();
scoped.failures ~= void delegate () { dobar_unwind(b); }
b = dobar();
scoped.success()
} catch (Exception o) {
scoped.failed()
throw o;
}
return Transaction(f, b, d);
}
Should be:
f = dofoo();
scoped.failures ~= void delegate () { dofoo_unwind(f); }
etc. Other than that, it looks like it'll work, but it's a lot more code
than on_scope. You also need to be sure that the delegates don't refer to
any variables declared inside the try block, as those variables no longer
exist in the catch block - and the compiler can't catch that error. This
isn't a problem with on_scope.
↑ ↓ ← → S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-03-01 02:15:35 -0800, "Walter Bright" <newshound digitalmars.com> said:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message
news:du376e$1fbf$2 digitaldaemon.com...
Something like this would be equivalent?
Transaction abc()
{
Foo f;
Bar b;
Def d;
Auto scoped = new Scoper(); //scoped.exit() can be called by the
destructor. We won't add a finally block.
try {
scoped.failures ~= void delegate () { dofoo_unwind(f); }
f = dofoo();
scoped.failures ~= void delegate () { dobar_unwind(b); }
b = dobar();
scoped.success()
} catch (Exception o) {
scoped.failed()
throw o;
}
return Transaction(f, b, d);
}
Should be:
f = dofoo();
scoped.failures ~= void delegate () { dofoo_unwind(f); }
etc. Other than that, it looks like it'll work, but it's a lot more
code than on_scope. You also need to be sure that the delegates don't
refer to any variables declared inside the try block, as those
variables no longer exist in the catch block - and the compiler can't
catch that error. This isn't a problem with on_scope.
Why would that be the case? If dofoo() throws an error, that delegate
would not yet be appended to the failures delegate array. Thus it
wouldn't be able to do it's job in the catch block. I know your and
derek's order was like this originally, but it seemed like a typo so I
fixed it.
-S.
↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 4 Mar 2006 01:09:47 -0800, S. Chancellor
<dnewsgr mephit.kicks-ass.org> wrote:
On 2006-03-01 02:15:35 -0800, "Walter Bright"
<newshound digitalmars.com> said:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message
news:du376e$1fbf$2 digitaldaemon.com...
Something like this would be equivalent?
Transaction abc()
{
Foo f;
Bar b;
Def d;
Auto scoped = new Scoper(); //scoped.exit() can be called by the
destructor. We won't add a finally block.
try {
scoped.failures ~= void delegate () { dofoo_unwind(f); }
f = dofoo();
scoped.failures ~= void delegate () { dobar_unwind(b); }
b = dobar();
scoped.success()
} catch (Exception o) {
scoped.failed()
throw o;
}
return Transaction(f, b, d);
}
f = dofoo();
scoped.failures ~= void delegate () { dofoo_unwind(f); }
etc. Other than that, it looks like it'll work, but it's a lot more
code than on_scope. You also need to be sure that the delegates don't
refer to any variables declared inside the try block, as those
variables no longer exist in the catch block - and the compiler can't
catch that error. This isn't a problem with on_scope.
Why would that be the case? If dofoo() throws an error, that delegate
would not yet be appended to the failures delegate array. Thus it
wouldn't be able to do it's job in the catch block. I know your and
derek's order was like this originally, but it seemed like a typo so I
fixed it.
The idea of dofoo_unwind is to reverse the changes made by dofoo when
dofoo succeeds and a later step fails. If/when dofoo throws it should undo
it's own changes before returning.
Regan
↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message
news:du0lmk$dbg$1 digitaldaemon.com...
On 2006-02-25 18:06:36 -0800, "Walter Bright" <newshound digitalmars.com>
said:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The only thing I see that's amazingly useful about this is the
on_scope_success. Having a block of code that is only executed when an
exception is NOT thrown would be nice. However, the rest of this stuff
seems like rocks under the water. Your example of the new programmer
coming in reads like this to me: "The new programmer may not take the
time to actually read the code he's modifying, so lets stick hidden stuff
in there to take care of things he might have missed." Which doesn't seem
very logical to me, as it may be just as important to modify those on
success/on failure blocks and miss them.
I'd say add another option to try..catch..finally paradigm.
-S.
try {
something horrible here....
//on_scope_success:
... and here is on success part
}
Why do you need separate 'passed' part?
Andrew.
↑ ↓ ← → S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-28 00:08:01 -0800, "Andrew Fedoniouk"
<news terrainformatica.com> said:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message
news:du0lmk$dbg$1 digitaldaemon.com...
On 2006-02-25 18:06:36 -0800, "Walter Bright" <newshound digitalmars.com> said:
Scope guards are a novel feature no other language has. They're based
on Andrei Alexandrescu's scope guard macros, which have led to
considerable interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
The only thing I see that's amazingly useful about this is the
on_scope_success. Having a block of code that is only executed when an
exception is NOT thrown would be nice. However, the rest of this stuff
seems like rocks under the water. Your example of the new programmer
coming in reads like this to me: "The new programmer may not take the
time to actually read the code he's modifying, so lets stick hidden
stuff in there to take care of things he might have missed." Which
doesn't seem very logical to me, as it may be just as important to
modify those on success/on failure blocks and miss them.
I'd say add another option to try..catch..finally paradigm.
-S.
try {
something horrible here....
//on_scope_success:
... and here is on success part
}
Why do you need separate 'passed' part?
Andrew.
You don't. I wasn't thinking clearly. I guess I was confused by the
fact that there was an on_scope_success in this new addition.
-S.
↑ ↓ ← → Ant <duitoolkit yahoo.ca> writes:
Walter Bright wrote:
Scope guards are a novel feature no other language has. They're based on
Andrei Alexandrescu's scope guard macros, which have led to considerable
interest in the idea. Check out the article
www.digitalmars.com/d/exception-safe.html
This is excellent!
is it the first really new thing in D?
thinking hard (for 30 seconds) seems to be the first one.
excellent in any case.
Ant
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next