On Aug 23, 2013, at 9:36 PM, Gabriel Dos Reis <g...@integrable-solutions.net>
wrote:
> You made a statement. It was not clear whether it was what you want
> or whether it is what the standards mandate.
Both.
>>> (2) what you believe the standards mandate, with appropriate quote; and
>>
>> The life of the original object does not end. See below for the quote.
>
> Your assertion or a quote from the standards?
A quote. You can tell it is a quote, because the wording comes from the
standard.
>> And yet memcpy is exactly defined and all interactions with the entire rest
>> of the standard are as specified. Those semantics that are defined and
>> required, are, by definition. You can't make them go away by claiming they
>> are undefined.
>
> I have no idea what exactly you are talking about.
You said memcpy was undefined. You've not quoted the standard that said it was
undefined. I've quoted the definition from the standard.
> If you have a rule in that standards that say that mempcy is assignment,
> please share it with us.
I have. Please read the thread once more.
>> int i = 1, j = 2;
>> {
>> memcpy (&i, &j)
>> // here i exists and is 2.
>> }
>>
>> 3.7.1 Static storage duration [basic.stc.static]
>>
>> 1 All objects which neither have dynamic storage duration nor are local
>> have static storage duration. The storage for these objects shall
>> last for the duration of the program (_basic.start.init_,
>> _basic.start.term_).
>>
>> This covers why i exists.
>
> The storage duration of an object is not necessarily the same
> as its lifetime.
Is this relevant in this case? If so, please quote the standard. It is not.
> Yes, but what is the relevance?
If you don't understand the relevance of the standard that mandates the
behavior of the code in question, I can't help you.
>> Right, because it doesn't define taking the bytes of one object and
>> assigning another object to have those bytes. The definition of memcpy does
>> that.
>
> Chapter and verse, please.
Again, I've already quoted it. You need to be able to read and understand
quotes from the standard, why they apply and how the requirements drive the
semantics.
>> char c1, c2;
>>
>> c1 = c2;
>>
>> This is defined to take the bytes that comprise c2 (1 byte, by definition),
>> and slam them into c1. After this runs, c1 will have the value of c2.
>> This, is, by definition. We can plainly see the assignment operator. This
>> is assignment, the hint is the spelling of the operator. It is spelled =.
>> This is what the C standard means, when they say copies. copies is defined
>> to mean, =.
>
> so? What is the relevance exactly?
See above.
>>> Which was the point I was making.
>>
>> Sure it does. Directly, please read the statement again:
>>
>> The memcpy function copies n characters from the object
>> pointed to by s2 into the object pointed to by s1.
>
> Yes, but why is that assignment not copy construction as in
>
> new (p) T (v);
>
> ?
> That is the question.
I can cover that; but, it would be a waste of mine time if you are unable to
see such simple things like memcpy is defined and that memcpy does an
assignment. The case for this is harder to follow. Essentially, the short
version, placement creates an object. The address of the data of that object
is identical to the backing store. Therefore, the two are indistinguishable.
Since the access type is the same, the original object refers to the object
from the new expression; therefore, it exists. There is no end of it's
lifetime[1], so it continues to exist, post the block the new was in. The
value of that object must compare == to the new object, since the address and
the type are the same and the storage isn't volatile. QED. Trivial enough to
dig out all the quotes to make that happen from the standard. If you don't buy
that, feel free to quote the standard that mandates the semantics are other
than the above.
1 - One can equally view the lifetime of the old object ending and the lifetime
of a new object beginning, since the required semantics in both cases are
identical. Since the difference can't be seen, there is none. Since there is
none, it is irrelevant what words we actually use to describe it in this case.
>> I said what the words mean. I'd said copy means the = operator.
>
> Copy in C++ does not necessarily mean assignment.
Sorry, can't help you then. It does, that's just the way it is. If it meant
increment, you'd be able to quote a definition of copy that said it meant
increment. You can't, because it doesn't. Also, in this case, there is no
difference in semantics, even if you assume copy meant copy construction. So,
doesn't matter in the least which particular copy you want to claim it is.
>> Here is the text for =:
>>
>> [#3] An assignment operator stores a value in the object
>> designated by the left operand.
>
> This does not say that storying a value in an object is assignment.
Sure it does:
5.17 Assignment operators [expr.ass]
I think you are trying really hard to not read and understand the words of the
standard. See the first word of this section heading? It says assignment. It
says this because = is the C assignment operator. Curious enough, in C++ it
also happens to be the assignment operator. Why? Because 5.17 defines the
assignment operators, with = being called the `simple assignment operator'.
>> This is the very definition of the word copy, trust me. This is how the
>> standard was meant to be read.
>
> See above.
See above. You seem overly resistant to the words of the standard. Why is
that?
>>>>>> I think the most logical line of reasoning is that when the requirements
>>>>>> of [basic.lval] are met, the, this is a change of value of an object,
>>>>>> not a modification to it's lifetime.
>>>>>
>>>>> Why?
>>>>
>>>> Because if you end the lifetime of the original int, you destroy the
>>>> semantic that everyone knows for C. This cannot be done.
>>>
>>> But:
>>> (1) we are not talking about C
>>
>> Sure we are.
>
> No, we are not. Please look back at my original message that you replied to.
Look at the text you quote. I said, "knows for C." I was talking about C, the
hint is, I said "for C". I am terribly sorry you didn't follow. But, don't
worry, it would equally destroy C++. Again, it doesn't matter if we talk about
C or C++, as both have the exact same mandates.
>> The semantics of memcpy and its behavior come from C, and are identical to
>> it. Since this is true, I can freely quote the required semantics of the C
>> standard, they are identical.
>>
>>> (2) C does not have a notion of lifetime -- at least not in the sense of
>>> C++.
>>
>> It absolutely does: Let me quote:
>>
>> [#1] An object has a storage duration that determines its
>> lifetime.
>
> Please give the definition of 'lifetime'.
You'd have to read and understand the quoted text. if you are unable, well,
please explain to us what you failed to understand, and I can explain it to
you. I can try:
http://www.thefreedictionary.com/lifetime
life·time (lftm)
n.
1. The period of time during which an individual is alive.
2. The period of time during which property, an object, a process, or a
phenomenon exists or functions.
but I fear you won't understand this and how it applies.
I've already quoted the definition of lifetime, just above, but you completely
missed it. I can try again, the lifetime is the storage duration.
> But this is not the lifetime in the C++ sense.
It is. I'm sorry you missed it. I've now pointed it out to you, and yet, you
still missed it. The rules of lifetime in C++ are virtually identical. For
the case at hand, I can't think of any differences.
>> I'll note that C++ merely sought to explain and formalize the rules of C.
>
> Strongly disagree with that note.
I don't recall you in the room when we set the rules for C++. I'm merely
explaining what we did, I'm sorry you don't understand what we did, I don't
think we were sworn to secrecy and I don't think we tried to hide what we in
fact did. Anyway, you'll notice an almost perfect copy of the C object model
and semantics of C, in C++; this was by design, not accident. This is what we
did, this is what was done, and the evidence for it, is the standard itself.
Of course, a better understanding of what we did, would be to actually ask
someone that was in the room when we did it. If someone was in the room that
disagrees with me, who is it? Feel free to name names.
> The object model may have been based on C, but it went way beyond C in say
> that
> C++ object model is expressible in C any more -- think empty base
> optimization.
C doesn't have bases… :-) Apparently, that isn't a difference.
> This isn't just a few bits.
Oh, you didn't think that I meant that C++ didn't have anything new in it did
you? Certainly I didn't mean to imply that.
>> I can't begin to fathom how you could have possibly missed the notion of
>> lifetime in C.
>
> Most likely because I didn't miss it.
You did. You said you didn't see it. Which is it? Do see the lifetime for
objects in C or not?
>> It right there, an just about exactly matches C++.
>
> Not at all. We tried to make certain constructs have similar byte-level
> interpretation, but the conceptual models are completely different.
And yet, it is virtually identical by design. :-) lol I should just say
identical, but, if you're skilled enough, you might be able to find an
inconsequential difference or two. We had fun with corresponding members, in
end, we even included that, kinda didn't want to however.
> Yep, and C++ makes a distinction between copy and assignment.
If you knew the requirements of each, you'd know they are identical. So, no
matter which you think it might be, the required semantics are the same.
> Trying to connect what the standards say and your assertions.
Oh, then just read and understand the standard; it was meant to be accessible.
Sorry if we failed for you.
