In article <3um0o6$7qb@indy-backup.indy.net> bflorman@indy.net (Bruce
A. Florman) writes:

|> I've just started playing with the ObjectSpace implementation of STL using
|> IBM C Set++ on OS/2.  I had a class with rather strict identity semantics
|> that had neither a default constructor nor a copy constructor, and I found
|> that it was quite difficult to create an STL list with it.  The list
|> operations (at least in the ObjectSpace implementation, and I suspect
|> everywhere else too) pretty much require a copy-ctor.  So my first question
|> is: does anyone know a good work-around for such classes?

|> My first attempted work-around was to make the list a list of pointers, but
|> I immediately found my code leaking memory because I would forget to delete
|> the pointer before erasing it from the list.  "This is a job for auto_ptr!"
|> I thought, and so I rolled my own quick-and-dirty implementation of the
|> auto_ptr template and tried to declare a list of auto_ptrs.  Unfortunately
|> this failed because auto_ptr's copy-ctor and assignment operator take non-
|> const arguments but the STL list template tries to pass consts to them.
|> So my next question is: Is this problem specific to the ObjectSpace
|> implementation of STL, or is it intrinsic to the nature of STL and auto_ptr?
|> If it's intrinsic, is there anything that can be done to make auto_ptr and
|> STL work better together, or is this an unreasonable thing to want?

I've been wondering about this too.  I recently implemented a clone of
auto_ptr, and started using it in place of my own RefCntPtr where
appropriate.  As my compiler (at least, the one I used on this
project) is very lax in enforcing const-correctness, I only noticed
the problem after having written a significant amount of code:  I
regularly have functions which return an auto_ptr, thus:

 auto_ptr< X > f() ;
 auto_ptr< X > p = f() ;

With the current definition, this is, of course, illegal.

Probably the biggest single use of my RefCntPtr class was along these
lines.  A function created an object (generally, with a type depending
on its parameters or some other external criteria) and returned a
pointer to it.  The pointer then ended up in some container class, who
was deemed to own it.

It sounded like a perfect application for auto_ptr:

 -  My RefCntPtr class is invasive; the object pointed to must inherit
    from RefCntObj.  Until now, this has not been a big problem,
    but...

 -  Non-invasive forms of reference counting have very significant
    overhead (see Barton and Nackman for an example).  I'd prefer
    avoiding this overhead if possible (and since there is, in the
    end, never more than one real owner, it *should* be possible).

But the standard `auto_ptr' doesn't work for the reasons cited:-).  Of
course, I could always create my own, declaring the actual pointer
member as mutable, or casting away const in the copy constructor.  But
I really get the feeling that there is something simple here that I am
missing.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3um0o6$7qb@indy-backup.indy.net>,
Bruce A. Florman <bflorman@indy.net> wrote:
>I've just started playing with the ObjectSpace implementation of STL using
>IBM C Set++ on OS/2.  I had a class with rather strict identity semantics
>that had neither a default constructor nor a copy constructor, and I found
>that it was quite difficult to create an STL list with it.  The list
>operations (at least in the ObjectSpace implementation, and I suspect
>everywhere else too) pretty much require a copy-ctor.  So my first question
>is: does anyone know a good work-around for such classes?

 Try using a smart (reference counted) pointer.
Auto_ptr is NOT a such a device. There's no standard smart pointer,
but you can surely roll your own or borrow one.

 If your identity semamtics are stricter than that,
invent your own class. You may have to declare a copy constructor,
you shouldn't have to implement it. [Problem is probably due to
compilers instantiating unused member functions which they aren't
supposed to do]


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

I've just started playing with the ObjectSpace implementation of STL using
IBM C Set++ on OS/2.  I had a class with rather strict identity semantics
that had neither a default constructor nor a copy constructor, and I found
that it was quite difficult to create an STL list with it.  The list
operations (at least in the ObjectSpace implementation, and I suspect
everywhere else too) pretty much require a copy-ctor.  So my first question
is: does anyone know a good work-around for such classes?

My first attempted work-around was to make the list a list of pointers, but
I immediately found my code leaking memory because I would forget to delete
the pointer before erasing it from the list.  "This is a job for auto_ptr!"
I thought, and so I rolled my own quick-and-dirty implementation of the
auto_ptr template and tried to declare a list of auto_ptrs.  Unfortunately
this failed because auto_ptr's copy-ctor and assignment operator take non-
const arguments but the STL list template tries to pass consts to them.
So my next question is: Is this problem specific to the ObjectSpace
implementation of STL, or is it intrinsic to the nature of STL and auto_ptr?
If it's intrinsic, is there anything that can be done to make auto_ptr and
STL work better together, or is this an unreasonable thing to want?

--Bruce

In article <3um0o6$7qb@indy-backup.indy.net>, bflorman@indy.net (Bruce A. Florman) writes:
> I've just started playing with the ObjectSpace implementation of STL using
> IBM C Set++ on OS/2.  I had a class with rather strict identity semantics
> that had neither a default constructor nor a copy constructor, and I found
> that it was quite difficult to create an STL list with it.  The list
> operations (at least in the ObjectSpace implementation, and I suspect
> everywhere else too) pretty much require a copy-ctor.  So my first question
> is: does anyone know a good work-around for such classes?
>
> My first attempted work-around was to make the list a list of pointers, but
> I immediately found my code leaking memory because I would forget to delete
> the pointer before erasing it from the list.  "This is a job for auto_ptr!"
> I thought, and so I rolled my own quick-and-dirty implementation of the
> auto_ptr template and tried to declare a list of auto_ptrs.  Unfortunately
> this failed because auto_ptr's copy-ctor and assignment operator take non-
> const arguments but the STL list template tries to pass consts to them.
> So my next question is: Is this problem specific to the ObjectSpace
> implementation of STL, or is it intrinsic to the nature of STL and auto_ptr?
> If it's intrinsic, is there anything that can be done to make auto_ptr and
> STL work better together, or is this an unreasonable thing to want?
>
   auto_ptr is another instance of a holder class (see above posting).
You can implement auto_ptr something like:

template <class T> Null
{
 operator()(T  p){}; // do nothing on accepting hold
};
template <class T> Release
{
 operator()(T p){ delete p; }; // delete on release
};
template <class T> auto_ptr : public holder<T,Null<T>,Release<T> >;

 list< auto_ptr<YOUR_CLASS*> > your_list;

 hope this is helpful!

jon borden
jabr technology corporation
component medical software

jon@synapse.nsur.nemc.org
617-636-5858