More returning STL Objects

<< split from http://cboard.cprogramming.com/cplus...l-objects.html >>

Hello. I am new to C++, but got some experience in C. I got a question that is similar to the one of this topic. Done some search, and found many diferents results.. If anyone could help me, I apreciate.

I have a vector of a class1 objects. I can make class 1 to not be updated after it is created, if it helps me.

On another vector of class2, I must have atributes that are some members of class1. This vector must be updated, by incerction, removal of members of class2 (will not modify those elements).

Ok, I could keep indexes to track the members of class1 that belong to the members of this atribute on class2.

But I would like to know if the is a more fance way of doing that, by exploring some C++ feature or object oriented technic.

Anyone?

Thank you!

If you use reference or pointers you would not have to maintain the second list, it would maintain itself.

Probably you should post a nice short example in code of what you mean.

If class 1 and class 2 share some attributes, it may be that your design needs to be modified. You can have a class 3 containing shared attributes referenced by class 1 and class 2 objects.

Wow that's some awful spelling there!
After reading "incerction" several times I eventually realised that this was probably meant to be "insertion". I kept reading it as In-Kerk-shun".

Even after realising that, I still cant make heads or tails of this request sorry.

In general I recommend against returning any instances of templated objects and this includes the STL. You will run into problems later if you attempt to do this from a DLL and Visual Studio will give you a warning about it. I recommend you return a pointer to the STL container or you wrap the object using the template instance and then include a pointer to it in another class that acts as a pass through to the actual instance using the container - the PIMPL idom. Alternatively you can use an interface to the class using the instance of the template so long as you do not attempt to export any part of the template.

PIMPL

Code:

---

class TemplateUser
{
  public:
      SomeObject * AddObject(unsigned int ID);
   
  private:
    typedef std::map<unsigned int,SomeObject *> ObjectMap;
    typedef ObjectMap::iterator ObjectMapIter;
    ObjectMap m_objectMap;
};

class TemplateUserPIMPL
{
  public:
    SomeObject * AddObject(unsigned int ID)
    {
        SomeObject *pResult = 0;
        if (m_pTemplateUser)
        {
            pResult = m_pTemplateUser->AddObject(pObject);
        }
        return pResult;
    }     
  private:
    TemplateUser *m_pTemplateUser;
};

---

Interface

Code:

---

#ifdef TEMPLATERUSER_EXPORTS
    #define TEMPLATEUSER_DECL __declspec(dllexport)
#else
    #define TEMPLATEUSER_DECL __declspec(dllimport)
#endif

class TEMPLATEUSER_DECL ITemplateUser
{
    public:
        virtual ~ITemplateUser() { }
        virtual SomeObject * AddObject(unsigned int ID) = 0;
};

---

Code:

---

class TemplateUser : public ITemplateUser
{
  public:
      virtual SomeObject * AddObject(unsigned int ID);
   
  private:
    typedef std::map<unsigned int,SomeObject *> ObjectMap;
    typedef ObjectMap::iterator ObjectMapIter;
    ObjectMap m_objectMap;
};

---

Alternatively you can also choose to export only functions of a class instead of the entire class but you cannot export or return instances of a templated class across a module boundary.

Doesn't having to wrap it or make a pointer to it kind of defeat the purpose of the STL?

Quote:

---

Doesn't having to wrap it or make a pointer to it kind of defeat the purpose of the STL?

---

No it doesn't. You still get the benefit of the container and the code within it that you do not have to maintain. You also get the benefit of being able to use the functions in the <algorithm> header. Just because most of us are more familiar with seeing STL instances on the stack doesn't mean they can't be used just as effectively on the heap.