It is seldom needed, and I don't use them particularly often, but goto statements can occasionally improve both efficiency and clarity. Once in a rare while they are the best solution; when this is the case, it is nothing short of stupid to religiously avoid them. Whatever the best tool for the job is, use it.

use break instead of goto and put it inside two loops, outer one loops until it has reached the end of the container.

Something like this (grossly simplified to make things clearer):

Code not tested but in theory it should work. There are about a million other ways of doing the same thing.

[edit]
Of course if the container is big then some kind of system should be used that would prevent the inner for loop to start over every time something gets deleted.

Ugh, learn the STL

for(multiset<CObject*, SSortObjects>::iterator it = CObjectList::o().begin();it != CObjectList::o().end();) // loop through STL-multiset (could be any other container as well)
      if ((*it)->get_x() + (*it)->get_w() < CCamera::o().get_x()) // check, if some statement about the object is true and delete it
      {
        it = CObjectList::o().erase(it); // delete one object from the container
      }
      else
        it++;

Your docs are probably outdated.

Didn't read through carefully, didn't notice that we're talking about multisets here. Sorry Audric, you're right about that.

To clarify, multisets are AssociativeContainers, and those have a void erase() (they don't need the return value anyway). The iterator erase() is part of Sequence (which is a list, vector, deque etc.). My comment about outdated docs stemmed from the fact that in the past, even Sequences had a void erase() in some compilers.

IIRC, erase() returns void on associative containers UNLESS you're using microsofts implementation and/or documentation : )

All destructors on objects will be called with exit. They will not with abort, though.

I never use exit. Errors that force program shutdown usually appear while setting up the program. I just create a function for initialization that returns some value. If it is an error it returns an error value (duh!). When I see that an error occured I simply call the function that is responsible for cleaning up and return from main afterwards.

for example.

kosmitek: both Matthew and Jonatan are correct: you would use some sort of loop (while, for, etc.) until you specify that you should break out of it (or, you can specify that you will only run it once UNLESS some condition is met).

This is making my head hurt!

But it really is a loop—it's not a one time jump. I prefer the do/while construct because of that. Ideally there would be a slimmer syntax like:

do {
  // ...
  if (foo) continue;
  // ...
}

Either way, the use of goto (or a similar loop construct) usually indicates that you should consider rethinking your approach altogether. I think the biggest problem with relying on goto for anything is that you might end up relying on it elsewhere out of laziness.

Most of Allegro's goto usage is for error handling. Given C's lack of exceptions, there's not always a good alternative.