freenode/#clasp - IRC Chatlog
Search
13:23:04
Bike
you're not supposed to throw exceptions out of C++ destructors because destructors are called while unwinding the stack in the course of exception handling, and if an exception is thrown while another exception is in flight, C++ terminates the entire program because it is a stupid language
13:23:48
Bike
"Because you see, what else could C++ do? There's an ambiguity: which exception out of the two do you want caught now? [...] That's right, terminate(). Solomon-style conflict resolution carried to the end."
13:25:16
Bike
in lisp the roughly equivalent situation would be signaling an error from a handler-bind handler (not handler-case)
13:25:57
Bike
because, and this is perhaps a bit subtle, in lisp we can handle exceptions before unwinding
13:26:38
Bike
so e.g. the second condition can be restarted in such a way that it goes back to the process of signaling the first condition, which ends up in the debugger. a bit convoluted, but no problem
13:27:15
Bike
actually i suppose the better analogy would be signaling an error from an unwind-protect cleanup
13:28:08
Bike
but the solution is the same - higher handlers can handle or restart the new condition, and in the latter case we just go back to the original unwinding process
13:28:51
Bike
in order to do this properly in clasp, every unwind protect catches every C++ exception, so that the cleanup can signal anew without getting recursive
13:29:37
Bike
bla bla bla explanations. i can explain C++ exception stuff more if anyone cares. i try not to be judgmental usually but this is a part of C++ i hate a lot
13:38:44
Bike
memory management gets a little tricky because, as it's used during unwind, the exception object can't be allocated on the stack. usually the C++ runtime has some fixed space for allocating exceptions in and/or just uses malloc
13:39:16
Bike
since you need some unbounded amount of space for exceptions given they can be any object and you can have an unlimited number of recursive (in a different way) exceptions, which again is fine in lisp, not so much in C++
13:39:24
scymtym
karlosz: reconstruct is supposed to find sub-expressions of an input form that a macro splices into a partially freshly consed expansion form. it only works if the spliced sub-expressions are EQ to their counterparts in the input form
13:49:04
beach
Bike: It truly is a crappy language. And it is getting worse every 3 years if I understand things correctly. This morning, I learned that C++ programmers avoid exceptions, probably for some of the reasons you mentioned.
13:52:18
Bike
i can also recommend the C++ FQA for more criticism https://yosefk.com/c++fqa/exceptions.html
13:54:55
beach
I'll put it on my reading list. I am not exposed to C++ on a daily basis, so I am not sure I'll invest that much time up front.
13:55:04
Bike
you can see this basically recommending automatic memory management and restarts instead of what C++ has
14:10:35
Bike
there are other pages on other parts of the language, of course, if you're the kind of person who enjoys this unix-hates handbook kind of thing
14:11:58
beach
I kind of do, in that it's part of my job to have a complete view of features and bugs of programming languages. And it is easier to have someone else point things out to me, than for me to acquire the experience to determine such things myself.
14:13:21
Bike
note that some parts of this are a little old, e.g. he mentions smart pointers being in a language draft, but they're pretty solidly in now
14:23:22
beach
I have said this before, but I'll say it again. If I were in drmeister's situation, I would start a parallel project and systematically rewrite the chemistry code that is now in C++ in Common Lisp. Now that Clasp is up and running, this could be done incrementally.
14:35:23
drmeister
beach: It's a good idea to develop chemistry code in Common Lisp - but we don't have the ability to define and work with packed structures yet. That's going to take a while.
14:37:15
drmeister
I'm currently debugging problems in the non-linear optimization code - it's all C++ double precision math.
14:38:16
drmeister
Lots of double precision parameters in structures and loops doing complex calculations on them.
14:39:53
Bike
at some point i would like to extend defstruct and hopefully defclass to allow "unboxed" slots, and then perhaps as a language extension define specialized arrays for them
14:40:33
beach
You can discuss such an extension with aeth who, if I remember correctly, wants that as well.
14:40:52
drmeister
Yeah - that's what I'm talking about and unboxed math on those slots and then we are talking.
14:41:23
Bike
i think the only actual extension required is saying that if a defstruct as such and such extension option, EQ on those objects is ambiguous, like for fixnums and characters
14:42:52
drmeister
SBCL has structs with unboxed slots - right? I heard from Doug Katzman that these structs posed problems when they ported to MPS. Namely they have maps of what slots are GC managed pointers and they had problems getting that to work with MPS because MPS doesn't let you look at any other GC managed memory when you are fixing one block of GC managed memory.