I am an idiot.

I have just figured out where I am going wrong. All my variables are stored on the LISP stack, which is a std::vector<Cell> instance, (Cell is the variable type). Some of these Cells themselves contain Standard C++ Library objects (lists use std::list<>, functions are std::vector<Instruction>, strings are std::strings), and references to those objects are stored on the C++ stack during operation.

A few functions deep, when stuff keeps being added to the stack, it eventually will reallocate and… boom, all my iterators and references die a horrible death. Took quite a while to figure out that this was going on, I was preoccupied with assuming there was an issue with the Cell’s implementation of the Rule Of Three. I had already had issues with that, as I mentioned before.

For the moment, a “quick fix” is to manually set the initial stack size quite high. I think with this my current implementation works fine, but I hate such an ugly fix, which is too brittle anyway. I could choose std::list<>, so elements won’t be moved around in memory, but there might be another way.

That took far too long to diagnose…

Advertisements

2 Responses to “I am an idiot.”

  1. fingerprint211b Says:

    Hi. I’ve actually had the same problem a few days ago, it’s a real bastard, especially if you use G++ like I did and get absolutely no information on what’s going on.
    Anyway, since all I needed was iterating through the vector (and calling a specific method), instead of using iterators, I used the good old for loop and random access. Since I know that an object in the vector can only remove itself (not other objects), this is practically bulletproof. Either that or I’m missing something. The vector can reallocate itself all it wants, indexes stay the same.

  2. Thanks for the comment. In my case, it was the references that really killed me. I have a habit of declaring references to make code easier to read, so rather than write (*it)->foo() everywhere I will write “Bar &bar = *it; bar.foo();”. Obviously it depends on the complexity of the code involved.

    I actually haven’t moved away from my fixed stack size yet, partially because I haven’t really updated the project in the last few months and partially because the system stack has an upper limit anyway, and generally only runaway recursion or some heavy stack allocation will ever breach it. I don’t feel quite so bad about my “hack” as I did when I wrote that =)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: