<purr\Paws>
[Issues] ELLIOTTCABLE comment on issue #17: The most obvious problem with this change, from where I'm standing, is that it, well, “breaks Executions.” The famous old move-foward Execution semantics upon which huge swaths of Paws' semantics depend make little or no sense here: an Execution can only ‘move forward’ to next node of a Script, if that Script is strictly linear (thus providing such a “next node” *to* move to.) With no
<alexgordon>
joelteon: I always use -fno-exceptions so I might not be the best person to ask :P
<alexgordon>
but I'll try
<joelteon>
well this library likes exceptions
<alexgordon>
joelteon: I think I see the problem
<joelteon>
oh good
<alexgordon>
lol
<purr>
lol
<alexgordon>
well I'm not sure, like I say I never use exceptions
<alexgordon>
but you need to make them const references
<alexgordon>
joelteon: a special feature in C++ is that if you pass a temporary object to a "const T&" then your code won't break
<alexgordon>
because the temporary will be promoted to a variable with a lifetime exceeding that of the reference
<joelteon>
okay, just so you know, this works as expected with g++ but not with clang++
<joelteon>
and i'm using clang
<joelteon>
okay, THAT didn't help either
<alexgordon>
joelteon: whereas for T& (no const) there is no such guarantee, and the temporary may be destroyed before it ever gets to the reference
<joelteon>
if I do a strcmp on typeid(e).name() and then cast it if strcmp succeeds, I get expected behavior :/
<joelteon>
wtf is going on
<alexgordon>
joelteon: std::exception has a virtual destructor
<alexgordon>
that means it's not designed to be stack allocated
<joelteon>
oh, i see
<alexgordon>
or rather, it can be stack allocated, but...
<joelteon>
it shouldn't be
<joelteon>
it's not a good idea
<alexgordon>
well possibly not with this interaction with exceptions
<alexgordon>
I dunno
<alexgordon>
I never use exceptions! :P
<joelteon>
tell you what, clang fucking sucks
<joelteon>
it doesn't accept nearly as much broken code as g++ does
<alexgordon>
joelteon: but just try `throw new nix::Exit(0);`
<alexgordon>
joelteon: LOL
<purr>
LOL
<joelteon>
like, last week i spent about 3 days debugging an error that came from this same guy that wrote this same library passing a stale stack pointer to something
<alexgordon>
joelteon: you don't actually have to inherit from std::exception at all
<alexgordon>
man C++ exception handling is broken as shit
<alexgordon>
I tell you, -fno-exceptions is your god
<joelteon>
and clang is like "ok, that's a temp variable, we'll just optimize it away" and g++ says "naw dude"
<joelteon>
so then you get an execve() call half of whose arguments are null pointers
<alexgordon>
heh
<joelteon>
also, clang isn't called "gcc", and some libraries really hate that
<alexgordon>
it makes it easy to spot the bad ones!
<joelteon>
if only people would standardize an environment variable for which C compiler the user wants to use