Loading ...
Sorry, an error occurred while loading the content.

Re: collection container

Expand Messages
  • Matthias Kronenberger
    Hm, what s the point in having such collections? The pointers in a container would refer to data that is stored somewhere. Since we want to minimize side
    Message 1 of 6 , Jul 31, 2002
    • 0 Attachment
      Hm, what's the point in having such collections?
      The pointers in a container would refer to data that is stored somewhere.
      Since we want to minimize side effects, the only valid use of a pointer
      container would be to store a set
      of polymorphic objects.
      Even now, the ownership question is raised. So, one should use a smart
      pointer.

      To adapt the pointers for the standard algorithm of the STL, one could use a
      projection iterator adapter.





      ----- Original Message -----
      From: "Bohdan" <yg-boost-users@...>
      Newsgroups: gmane.comp.lib.boost.user
      Sent: Thursday, August 01, 2002 12:49 AM
      Subject: collection container


      > Has boost any plans on creating container, that holds data by pointer, not
      > by
      > value?
      >
      > Rationale:
      > It is impossible to use normally vector<...> for types that do not have
      > copy constructor. Interface of vector< shared_ptr<...> > doesn't seems to
      be
      > very convenient( for example with std::algorithms ).
      > And most of all it is not good idea to show vector< shared_ptr<...> >
      > interface to
      > user of my lib, that wants to have container::iterator with normal
      behavior.
      >
      > AFAIK majority of existing libraries have/need such container ?
      > As to me it is strange that neither stl nor boost have such class.
      > I'm missing 'something' and there are important reasons for
      > not doing this ?
      >
      >
      >
      >
      >
      >
    • Bohdan
      Matthias Kronenberger wrote in message news:000501c238ec$cdd152c0$5ab2f683@koe5isewcagsnh... ... ok. What if your class hasn t copy
      Message 2 of 6 , Aug 1, 2002
      • 0 Attachment
        "Matthias Kronenberger" <mkronen@...-kl.de> wrote in message
        news:000501c238ec$cdd152c0$5ab2f683@koe5isewcagsnh...
        > Hm, what's the point in having such collections?
        > The pointers in a container would refer to data that is stored somewhere.

        ok. What if your class hasn't copy constructor or you don't want to
        copy your object ... have you other choice ?


        > Since we want to minimize side effects, the only valid use of a pointer
        > container would be to store a set
        > of polymorphic objects.

        Sure, this is another purpose for implementing it.

        > Even now, the ownership question is raised. So, one should use a smart
        > pointer.

        You are right. If you look again on my previous posting you will see
        something about shared_ptr< ... >.

        >
        > To adapt the pointers for the standard algorithm of the STL, one could use
        a
        > projection iterator adapter.

        I know about projection iterator and iterator adaptor library.
        And i didn't tell that it is impossible to use vector< smart_ptr<...> > with
        std::algorithms, i said that it is just uncomfortable.
        Of course you can use iterator adaptor and be happy, but you
        can use such cumbersome code only internally. If you are making
        your own library ( for example GUI lib), you should supply clean
        and simple interface to user! Or you want to explain to user how to
        use iterator adaptor with your strange container ?

        As i can see the only good solution is to make separate container
        or at least some container adaptor.
      • Matthias Kronenberger
        ... From: Bohdan Newsgroups: gmane.comp.lib.boost.user Sent: Thursday, August 01, 2002 11:12 AM Subject: Re: collection
        Message 3 of 6 , Aug 1, 2002
        • 0 Attachment
          ----- Original Message -----
          From: "Bohdan" <yg-boost-users@...>
          Newsgroups: gmane.comp.lib.boost.user
          Sent: Thursday, August 01, 2002 11:12 AM
          Subject: Re: collection container


          >
          > "Matthias Kronenberger" <mkronen@...-kl.de> wrote in message
          > news:000501c238ec$cdd152c0$5ab2f683@koe5isewcagsnh...
          > > Hm, what's the point in having such collections?
          > > The pointers in a container would refer to data that is stored
          somewhere.
          >
          > ok. What if your class hasn't copy constructor or you don't want to
          > copy your object ... have you other choice ?
          >
          >

          Well, the objects need to be stored somewhere. If we don't want to deal with
          reallocation, we need a container
          whose iterators are stable under insert, for example a list or a set.

          You are now able to use the iterator to that container to access the
          objects.

          std::vector <someIterator> v;
          v[123]->functionCall();
          or
          v.front()-> dataMember;
          or
          (*v.begin())-> dataMember;


          Would that help?
        • Bohdan
          ... What is wrong with shared_ptr or intrusive_ptr ? This is user problem, how he wants to allocate his object. Even more he can use different allocation
          Message 4 of 6 , Aug 1, 2002
          • 0 Attachment
            > Well, the objects need to be stored somewhere.

            What is wrong with shared_ptr or intrusive_ptr ?
            This is user problem, how he wants to allocate his object.
            Even more he can use different allocation strategies
            for objects in same collecion.

            > If we don't want to deal with
            > reallocation,

            What realloctation ? Without copy constructor ... ?

            > we need a container
            > whose iterators are stable under insert, for example a list or a set.

            As mentioned in previous postings these containers require
            copy constructor ... so you can forget about using them directly
            for storing objects. It would be better to use some kind of pool,
            if you want, but such container would be very restricted in use,
            because user can not select it's own allocation strategy.
            My opinion is that container should deal with some kind of
            pointers, but not with real data. Imagine you have descendant
            objects of the same base class in one collection ... so which
            allocation strategy you propose in this case ... ?

            > You are now able to use the iterator to that container to access the
            > objects.
            >
            > std::vector <someIterator> v;
            > v[123]->functionCall();
            > or
            > v.front()-> dataMember;
            > or
            > (*v.begin())-> dataMember;
            >
            >
            > Would that help?

            Obviously, not! There is still interface problem:

            std::vector <someIterator>::iterator doesn't behave like normal item
            operator.
            You still should write :
            iterator i = ...;
            iterator last = ...;

            (**i).dataMember; // not a simple i->dataMember;
            (*i)->dataMember; // not a simple (*i).dataMember;

            // and this is obviously is not the case for your library user:
            i = remove_adaptor( find_if( make_adaptor(i), make_adaptor(last),
            condition ) );

            Possibly, i was unclear in my previous postings, but IMHO this is interface
            problem,
            not allocation or implementation.

            Simple questions are :

            1) how to put value in container
            push_back( pointer ); or push_back( reference );
            2) how replace value in container having only iterator:
            iterator i = collection.begin();
            *i.base_iterator() = new_pointer;
            ?
            3) should container have two kinds of iterators :
            base_iterator & adapted_iterator ?

            4) inherit contained object from some collection_item class that
            knows
            something about collection. For example: simple delete ptr can
            delete
            object from collection. // i know this not good idea :-)

            regards,
            bohdan
          • Bohdan
            ... should be std::vector ::iterator doesn t behave like normal iterator.
            Message 5 of 6 , Aug 1, 2002
            • 0 Attachment
              Sorry for mistake:

              > std::vector <someIterator>::iterator doesn't behave like normal item
              > operator.

              should be

              std::vector <someIterator>::iterator doesn't behave like normal iterator.
            Your message has been successfully submitted and would be delivered to recipients shortly.