🚀 go-pugleaf

Allan;.

Can't see a way around your problem. Seem to remember the HP STL doing 
similar things. Why worry, anyway? An optimising compiler will reduce the 
cost of the bogus parameter to near zero.


>>  to = from;

What happens to the original T objects that 'to' was tracking?


>>  void deep_copy( Iter fromB, Iter fromE, Iter toB, Iter toE, 
>>    ContainedType* )

The fourth parameter is redundant; the size of the range to be copied is 
already specified by the first 2 parameters.



>> while( (fromB != fromE) && (toB != toE) && *fromB )

Not sure about this. It assumes that 'from' can contain some NULL 
pointers, but that they are guaranteed to be together in a block at the 
upper end of it.



   David Byrden
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <30FCDA77.69CB@trilogy.com>,
D. Allan Drummond <allan.drummond@trilogy.com> wrote:
[an example and discussion about type dereferencing removed]
>I really want to write something like this (the following code is
>nonsensical but should convey the spirit of the idea):
>
>template<class Container>
>void deep_copy( Container& from, Container& to )
>{
>    to = from; // expand to make sure TO is as big as FROM.
>               // should be cheap, if this is really a list of pointers.
>    Container::const_iterator f( from.begin() );
>    Container::iterator t( to.begin );
>
>    while( (f != from.end()) && (t != to.end()) && *f )
>        *t++ = new (*Container::value_type)( **f++ );
>}
>
>It seems as though there's no REAL reason to have to split it into two
>functions, but the "type dereferencing" is crucial.

Well, you can generalize the type deferencing scheme using a partial
specialization:

template <class T> class type_dereferencer
{
};

template <class T>
class type_dereferencer<T*>
{
public:
  typedef T base_type;
};

Of course you would also have to specialize for user-defined
pointer types and STL iterators.

Now you can use
type_dereferencer<Container::value_type>::base_type in place of 
(*Container::value_type) in your example.

And if typedef templates were allowed, you could use a slightly better
syntax:

template <class T>
typedef type_dereferencer<T>::base_type type_dereference;
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.




[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

esap@cs.tut.fi (Pulkkinen Esa) writes:

>template <class T>
>class type_dereferencer<T*>
>{
>public:
>  typedef T base_type;
>};
[...]
>And if typedef templates were allowed, you could use a slightly better
>syntax:
>
>template <class T>
>typedef type_dereferencer<T>::base_type type_dereference;

Can someone please remind me why we decided not to allow typedef templates?
It certainly seems like a bad idea to force everyone to use this silly
obfuscation for what is obviously a common need.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9601281244.8175@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:
> ..
> Can someone please remind me why we decided not to allow typedef templates?
> It certainly seems like a bad idea to force everyone to use this silly
> obfuscation for what is obviously a common need.

D&E says: "The extension is technically trivial, but I'm not sure how
wise it would be to introduce yet another renaming feature."

I have no idea why the committee might have killed typedef templates,
but I doubt that any reasoning used had more than the zero technical
merit of the above.

Doug
----------
Doug Morgan         TEL: (408) 744-3510 Booz-Allen & Hamilton 
doug@ads.com (UNIX) FAX: (408) 744-3565 385 Moffett Park Drive
morgan_doug@bah.com (MS-Mail)           Suite 110             
					Sunnyvale, CA 94089
----------
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]