Steffen Daode Nurpmeso <sdao...@googlemail.com> added the comment:
On Sat, 7 May 2011 14:20:51 +0200, Charles-François Natali wrote:
> I really can't see a good reason for using it here (and
> anywhere, see http://c-faq.com/decl/auto.html).
You're right.
> Why are you using the "auto" storage class specifier? I know
> that "explicit is better than implicit"
Yup. I'm doing what is happening for real in (x86) assembler.
Thus "auto" means (at a glance!) that this one will need space on
the stack.
(Conversely i'm not using "register" because who knows if that is
really true? ;))
> Do you really need to use goto for such a simple code?
Yup. Ok, this is more complicated. The reason is that my funs
have exactly one entry point and exactly one place where they're
left. This is because we here do manual instrumentalisation as in
ret
fun(args)
{
locals
s_NYD_ENTER;
assertions
...
jleave:
s_NYD_LEAVE;
return;
[maybe only, if large: possibly "predict-false" code blocks]
[possible error jumps here
goto jleave;]
}
We're prowd of that. N(ot)Y(et)D(ead) is actually pretty cool,
i've used debuggers exactly 5 times in the past about ten years!
I don't even know exactly *how to use debuggers*. 8---} (NYD can
do backtracing, or, with NDEBUG and optional, profiling.)
A really good optimizing compiler will produce the very same code!
And i love nasm, but it's pretty non-portable.
But C is also nice.
But of course i can change this (in C) to simply use return, this
is easy here, no resources to be freed.
Thanks for looking at this, by the way. :)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
