Hallo!

Actually I think, that maybe throwing an exception would be a cleaner way here and in other places, where something tries to access non-existing Elements (like the other "Element &get()" methods. However then all uses of get() will need to catch possible exceptions.

Yep, I also though about this yesterday. The problem is/was, that i decided at the begin to not use exceptions (but this was a bad decision). I think I will rework the code a bit and use exceptions (not only in the get methods), because there were some more situations where I thought I should use them.

outlet gets a bang in the catch block, if an exception occurs, but that's just for illustration and should be removed, as the list is not empty in fact, when the exception is thrown. Or maybe it should not be removed? It depends on what the right outlet should indicate: an empty list or the "end" iterator of a container. Thinking of how [textfile] and [qlist] use the right outlet, banging it at "EOF" would also be sensible, IMO.

Thats a good question. The concept of the right outlet isn't really clear (because all the containers are different...).

My idea was, that if get doesn't output an element (so the list is empty or the iterator is at a position where's no element) there should be a bang at the right outlet, so that you can react in PD. The same e.g. with the map: if the requested key (with get) isn't stored in it, there's a bang at the right outlet.

Now I just saw that there's a problem with the vector and deque: I didn't write it into the help-patches, but you can give a vector or a deque a second init-arg: the size (i thought then it's similar to the array). Then all the elements are initialized with Elements of length 0 and the bang at the outlet is handled a bit different (see attached patch)! But maybe this with an init-size isn't a good idea ? And the bang should also be if theres an invalid index (see attached patch) !?

Thanks for your advices, LG Georg