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

Re: collection container

Expand Messages
  • Bohdan
    Matthias Kronenberger wrote in message news:000501c238ec$cdd152c0$5ab2f683@koe5isewcagsnh... ... ok. What if your class hasn t copy
    Message 1 of 6 , Aug 1, 2002
      "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 2 of 6 , Aug 1, 2002
        ----- 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 3 of 6 , Aug 1, 2002
          > 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 4 of 6 , Aug 1, 2002
            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.