This one is a real doozy.

Here is the background. My collaborator is on Linux using GCC G++ as his compiler with C++11. I'm on OS X with Xcode 5, so my compiler is LLVM (which I understand to be clang++).

I have a vector of smart pointers to an object called GenericEnemy:

vector<unique_ptr<GenericEnemy> > enemies_;

Then during a game logic tick I iterate through each GenericEnemy, send a tick to it which checks if changeDirectionTimer_ has ticked. If so, select a new, random direction for the enemy:

SO, this all works fine and dandy on his computer. On mine, the timer ticks once as it should (a few seconds), and then suddenly it ticks every logic tick, as if e.type == ALLEGRO_EVENT_TIMER is ALWAYS true. I've even tried flushing the queue after every movingDirection_ update.

HERE is the really weird part. If I remove the use of smart pointers and do this:

vector<GenericEnemy*> enemies_;

Then everything works as it should on both OS's. Does anyone have ANY clue what could be causing this? We would realllllllly like to use smart pointers in this project.

The pointer would only be deleted if I removed it from it's vector, right? I'm checking, and GenericEnemy::~GenericEnemy() is never called.

Update - now it's happening on Linux, too. We didn't even change any code...

Sorry for confusion. We're both new to smart pointers. Here is the interaction with the unique_ptr's

So the vector only resizes if any enemy is hit. The GenericEnemy::~GenericEnemy() is definitely called when it's hit and we get:

i = enemies_.erase(i); //vector resize causes the unique_ptr to delete.

Do you see anything in this bit of code that would create issues?

He isn't using the wrong pointer type.
It's completely legal to have a raw pointer point to the same address as a unique_ptr, an unique_ptr implies unique ownership; raw pointers are still useful as weak references. unique_ptr is also very much compatible with the STL as opposed to auto_ptr, which is one of the biggest reasons auto_ptr sucks.

If you're creating unique_ptrs and then inserting them into a vector, I'm pretty sure you must use the emplace_back method to avoid copies, if you're inserting raw pointers make sure they point to unique addresses on the heap.
I personally just push_back raw pointers.

Also, the auto keyword makes your life easier.

vector<unique_ptr<GenericEnemy> >::iterator i = enemies_.begin();  
// Can be rewritten as
auto i = enemies_.begin();

As to why your program has this weird behaviour, I have no idea.

Going with the manual for al_get_next_event, I'd say you're getting unspecified behaviour.

And most prolly (haven't checked impelmentation) the referenced returning event is left unchanged if there si no event.

Indeed, looking at event.c, it turns out that al_get_next_event will leave the data in the event struct unchanged if there is no next event. Which explains exactly why the irratic bhaviour was seen, as the struct was no initialiazed to anuthing really. Morale of the story: always check the return values!

Well said.