It's in principle possible to add a Java-style GC to Nim but precise stack root
traversal is in practice just not feasible when you produce C(++) code. While
it can be done, it cannot be done efficiently. You don't have to be precise in
the stack root traversal but when you don't, add about 5 ye
In order to buy](https://seokot.com/services'>buy) SEO
services from SEKOT, you can always get in touch with our professionals
through e-mail or by ringing us. Our experts will reach out to you as soon as
possible.
If all you're doing is reraising, you don't need the exception variable.
except SomeError:
when not staticVarOn:
raise
else:
discard
Run
Worst case you can `discard e`.
In a proc, with static variables, I have somewhere:
except SomeError as e:
when not staticVarOn:
raise e
else:
discard
Run
This obviously leads to 2 different versions of the _proc_ : one (when
staticVarOn is true) re-raising SomeEr
[full proc](https://github.com/AS400JPLPC/nim_termkey)
Well, I kind of agree with you that it shouldn't have compiled. But since it's
quite early code and was left there as-is, I can assure you it was compiling
just fine.
But yes, the culprit is there I guess.
* * *
P.S. I have - obviously - come up with a workaround to all this, but involved
cha
First thought, before reading deeper: `const NoValues = @[]` has no type and
shouldn't compile. `template NoValues = @[]` might work
I'm trying to create a totally-minimal example of the above in order to
reproduce the error.
I haven't managed to reproduce it exactly, but I've still managed to make
another one appear (I guess there is some bug with static vars and procs).
For example, this works fine:
type
> Calling =destroy twice without wasMoved results in segmentation fault.
> Calling wasMoved without =destroy results in memory leak.
While true, you're not supposed to call them yourself. Unless you are making a
destructor-based object from raw pointers.
