When a TStringList has the OwnsObjectFlag set then it is responsible for freeing the stored objects. So the consumer of a TStringList transfers the responsibility of an object's lifetime to that StringList. In a more abstract way the consuming code is saying "Hey StringList, here's an object. Free it if you don't need it anymore". The StringList takes that responsibility seriously in the methods Clear and Delete as well as in its own destructor.

When a TStringList has the OwnsObjectFlag set then it is responsible for freeing the stored objects. So the consumer of a TStringList transfers the responsibility of an object's lifetime to that StringList. In a more abstract way the consuming code is saying "Hey StringList, here's an object. Free it if you don't need it anymore". The StringList takes that responsibility seriously in the methods Clear and Delete as well as in its own destructor.

Shouldn't it also free the object when
- AddObject is called
- and Duplicates equals dupIgnore
- and the new item would be a duplicate?

I think TStringList should free the object in that case in order to be responsible on the object's lifetime in all cases.

Are you with me? Or would it be a bad idea to implement AddObject that way? I'd like to know your opinion.

Comments

  1. Stefan Glienke Exactly. They key is associated to the object however, so you should not have a different object associated to the same key.

    ReplyDelete
  2. Walter Prins hard to decide out of context....but a bad design anyway :)

    ReplyDelete
  3. Extrapolating Walter Prins example: imagine calling AddObject with different keys but the same object instance. There are multiple ways to screw things up.
    Paul TOTH: I wouldn't call it bad design. It is designed for a specific purpose and not necessarily for everyone's needs. There are plenty of examples where the design is adequate. The example mentioned in this topic seems to ask for a derived class handling especially these requirements.

    ReplyDelete

Post a Comment