Ron Natalie <ron@sensor.com> escribi    en el mensaje de noticias
39E471DE.3FABD146@sensor.com...
>
>
> Fernando Cacciola wrote:
> >
> > Two questions:
> >
> > First,
> > I figured that if you have a container which holds pointers to objects,
and
> > if this container isn't responsible for the lifetimes of the contained
> > objects
>
> The container is responsible for the lifetimes of the objects stored in
it.
> Note that in your vector<myclass*> only pointers are stroed in the
container.
> The vector cares not what they point to.
Of course.
I meant that the container is responsible for the lifetimes of the pointers
but not of the 'objects' of type myclass that the user creates and then
collects.

> No.  First, applying const to pointers doesn't affect their lifetime.
> Second, the objects in standard containers must be ASSIGNABLE.  A
> type which is const is not, and you can't make any comments about what
happens
> next.
>
> You've probably hosed something internally, but I'm not sure what.  const
has
> NO bearing on whether you can delete something (if you're compiler is
correct).

Yes, I see it now.

I got confused because of the error I got when trying to declare the above
vector:

    void deallocate(pointer p, size_type)


      ::operator delete(p); // Error: Could not find a match for 'operator
delete (myclass* const*)'
    }

This made me believe that you couldn't delete a const pointer, which is
untrue (and couldn't be true as I realise now).

 This snippet shows the strange behaviour of Builder C++ 5.0 (update patch
1):

      int main()
     {
         int* const* p1 = 0 ;
        delete p1 ;
        ::operator delete(p1);  // same error here
     }

> (And the allocator is NOT deleting MyVector* it's playing with the place
MyVector*
> is stored, essentially MyVector*[].

Yes, I should have looked deeper at the error code: it says that it cannot
delete a 'myclass * const*', not a 'myclass * const'

Thank you for taking me out of this confusion!

>
> Ignoring the behavior of the container, can you please explain just what
it is
> again that you are trying to achieve.  I think you're getting down a
rathole
> expecting const to do something it isn't designed to do.
Yes.
I was indeed expecting 'const' to do something it isnt't designed to do.

Here's a brief history about how I ended up playing with vector<some*
const>:

I was getting a hand on a class I've downloaded which has the following form
(schematically):

class thing ; // whatever
class manager
{
   public:

      manager() ;
     ~manager();

      void add_thing( thing* );

  private:

    std::vector<thing*> think_list ;
} ;

At first glance I was unsure about how was I supposed to 'delete' things.
Will ~manager() delete them, or was it my responsbility?
I had to look at the implementation to discover that it DID delete things.

Then I wondered if the declaration of think_list could have made this
'ownership issue' more explicit; that is, how can I declare a container
which holds 'pointers' to objects and make clear at the same time if the
class owning the container will also 'own' the objects collected in it,
being that the container 'values' are actually just pointers.

In my own code I use reference counting or other smart pointers. But in a
general case?

Then I somehow believed that could at least design an interface in which you
can make explicit that objects handled through pointers are not owned by
just adding 'const'. But as you pointed me out this is not the way.

BTW, I assumed that the concepts of: "take this object through this pointer
but don't delete the object' ; or "take this object through this pointer and
delete it when you no longer need it' were well defined, but I'm not sure
now.
Reference counting can help, but I was considering other cases. auto_ptr
isn't enough though.

Thanks,





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Two questions:

First,
I figured that if you have a container which holds pointers to objects, and
if this container isn't responsible for the lifetimes of the contained
objects (and that you can ensure that the objects will remain alive during
the lifetime of the container itself, so you don't need reference counting
or anything special), then you could declare something of the form:

vector<myclass* const>

would this make any sense?

Second,

Unfortunately, the above declaration fails to compile under Builder5 because
allocator<> defines deallocate(), which in turn deletes the pointer. (which
isn't possible and I deliberately intended to prevent this). Now, the vector
destructor doesn't really deletes the pointers so why is deallocate
instantiated and syntax-checked?

Is this behaviour consistent with the definitions of allocator and the
containers using it, or is it a bug on my compiler?

Thanks,

Fernando Cacciola
Sierra s.r.l.
fcacciola@fibertel.com.ar
www.gosierra.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Fernando Cacciola wrote:
>
> Two questions:
>
> First,
> I figured that if you have a container which holds pointers to objects, and
> if this container isn't responsible for the lifetimes of the contained
> objects

The container is responsible for the lifetimes of the objects stored in it.
Note that in your vector<myclass*> only pointers are stroed in the container.
The vector cares not what they point to.

> (and that you can ensure that the objects will remain alive during
> the lifetime of the container itself, so you don't need reference counting
> or anything special), then you could declare something of the form:
>
> vector<myclass* const>
>
> would this make any sense?

No.  First, applying const to pointers doesn't affect their lifetime.
Second, the objects in standard containers must be ASSIGNABLE.  A
type which is const is not, and you can't make any comments about what happens
next.

> Unfortunately, the above declaration fails to compile under Builder5 because
> allocator<> defines deallocate(), which in turn deletes the pointer.

You've probably hosed something internally, but I'm not sure what.  const has
NO bearing on whether you can delete something (if you're compiler is correct).
(And the allocator is NOT deleting MyVector* it's playing with the place MyVector*
is stored, essentially MyVector*[].



Ignoring the behavior of the container, can you please explain just what it is
again that you are trying to achieve.  I think you're getting down a rathole
expecting const to do something it isn't designed to do.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]