91fdf907
In article <98f5459d-c0f9-4d90-8310-47888a1519cf@q13g2000vby.googlegroups.com>,
Mathias Gaunard wrote:
>
>> It is unclear about exactly which constructors etc. container and
>> other operations are allowed to use. In particular, when may they
>> create a temporary copy? That is particularly important when the
>> location of an object is constrained or carries information (e.g.
>> it is commonly used as an equality breaker in sorting).
>>
>> But it is also important when the object includes certain types of
>> data, such as locks and memory-mapped arrays. How much extra
>> complexity does the programmer have to add to defend himself against
>> what the STL code may do?
>
> If the address of the objects are themselves important, clearly you
> want a container of pointers to those objects, not a container of the
> objects themselves.
No, that is NOT true! You may want copying to create a fresh copy,
not an alias. Yes, you can manage such objects by using pointers
and fancy constructors, but that's not relevant to my point - for
heaven's sake, I have been doing this for decades in many languages!
Furthermore, with locks and RDMA and a competently designed program,
you should never be copying such an object when it is active; a
good copy constructor would throw an exception if that occurs.
My point was and is that the standard does not specify when copy
and move constructors etc. may be called, and when a conforming
implementation must provide an operation without calling them.
Without that information, you can't use the STL on such objects,
no matter HOW you implement their copy constructors!
Regards,
Nick Maclaren.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
