Re: Can a temporary be assigned to itself?
On Sunday, March 24, 2013 3:33:40 PM UTC, =D6=F6 Tiib wrote:
On Sunday, 24 March 2013 16:45:58 UTC+2, James Kanze wrote:
On Saturday, March 23, 2013 11:24:51 AM UTC, =D6=F6 Tiib wrote:
On Friday, 22 March 2013 22:24:59 UTC+2, Balog Pal wrote:
On 3/22/2013 8:52 PM, =D6=F6 Tiib wrote:
Object should remain in sane state if anything throws exceptions
during assignment. Sole imaginable sane state is "like it was bef=
ore".
That is strong XG, can be done too at about the same amount of code=
but
some increased resource cost at runtime. I don't agree that strong =
XG is
the only sane way but that is up to opinion in general -- and detai=
led
design at a particular instance, so we should not debate it. :)
I did not want to debate it.
There's no reason to debate. It depends on the application.
I've worked a lot on large servers; in this case, there are two
categories of objects: those which have been created in the
context of the request, and "permanent" obejcts, which will be
accessible in future requests. For the first, the only
guarantee which is necessary is that they can be destructed.
The second require the strong guarantee.
Interesting concept. How do you make difference between classes that may
be used for temporary objects during transaction and classes that have
used for more permanent objects? Do you have some special trait?
You design your application. Classes are designed to fulfill a
specific role in the application. That pretty much determines
the use they will have.
(Although one
possibility, which I often use, is to make copies of these
objects, and modify them, swapping them in in the commit phase.)
Yes, such system-wide idiom lets to enwiden usefulness of weak quarantee.
The problem is that ... some stuff possibly affected ... is rather
expensive to clone (just for case).
Such system-wide idioms are part of the requirements
specification, at least in servers. You *must* implement
rollback somehow. To my knowledge, there are only two
possibilities: cloning the object, or providing some sort of
"undo" facility. An undo facility is significantly more
complex. And realistically, for a large server, only a small
percentage of the objects will be involved in any single
transaction, so the impact on memory usage can't really be
significant. (There are probably exceptions, but I've not seen
them in practice.)
[...]
Since '=' is so innocent in code I feel it should be
robust. Common case ... some GUI designer made it too permissive
and user can do illegal copy or move. Throwing is fine since it is
defect of GUI ... however being broken afterwards is out of question.=
For most objects where it is important, the obvious solution is
to not support assignment. In my experience (which does *not*
include all application domains), all that is needed for objects
which support assignment is that the results can be destructed
(the weakest acceptable guarantee). But in my experience, there
is a large category of objects which don't support assignment.
I meant case where user can copy-paste or cut-paste. It is so
common that everybody know the accelerators
(ctrl-x,ctrl-c,ctrl-v) and mouse gestures (drag-drop,
ctrl-drag-drop) to those. I often use far more sophisticated
features (like serializing-unserialising) at that spot but on
lot of cases it is in essence copy or move exposed in GUI.
I'm not sure I follow you. Most applications aren't connected
to a terminal or a GUI window. And things like copy/paste are
purely GUI---how they map to application data depends on the
application. You could use assignment, but you're certainly not
obliged to. (For small scall copy/paste, classes like
`std::string` definitely should use assignment. For
copy/pasting larger entities: GUI objects generally need to know
their parent, and are usually polymorphic, so value assignment
doesn't work anyway.)
--
James