220 8797 article Path: news.gmane.org!not-for-mail From: euloanty@live.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: I think many methods could be written by compilers, not users. Date: Fri, 24 Jan 2014 18:22:07 -0800 (PST) Lines: 98 Approved: news@gmane.org Message-ID: References: <32b93ed2-1852-453a-872e-accba451fed6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1008_11787581.1390616527971" X-Trace: ger.gmane.org 1390616526 31672 80.91.229.3 (25 Jan 2014 02:22:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 02:22:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDPYX6PYRQNBBUN7RSLQKGQE5GTCD5A@isocpp.org Sat Jan 25 03:22:14 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W6sst-0005rb-8X for gclcip-std-proposals@m.gmane.org; Sat, 25 Jan 2014 03:22:11 +0100 Original-Received: by mail-qc0-f199.google.com with SMTP id m20sf6706003qcx.10 for ; Fri, 24 Jan 2014 18:22:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=ODkGmA/8M/QMiMCkbJ62fSJud69sMiu2cS+GZV2GHZw=; b=k3u/XTXLm19rzgX1Ib5AWa/ngpIGye9VizKwEknWCX84gxBAVDKJA5z6XBfRRhGHH/ VmLsAYGCtPxQszCVn9TtEkgM3q2JUBsZRY8BYx5gnIq92LBExDjBdn3XdtkOwmjNvvIe nxbHPyyFlLlONd/Gp4Z9uLT/ChzmUaN4SX/dtEsN49c4Dj9rawkKYf99DKzewakIE+jg k4WpJt0X1MH5ivo+gZik2psrFlbkkluPRbQTGLknEBKHxPpoMdICfXMfwi2coyXbcpOr 86vqpehWvzttImWC1pEfxDhRcKttS78lplzEwEhybIenerGAVv0ihqgOoRjrwUrYMsHq 0ufA== X-Gm-Message-State: ALoCoQl9y5ou2l7XUPGU8bEFtV0M7myN4ud7Ljrj2UCxGJdIrdwa4TcWtt64W/No5qgSs4S0uyLd X-Received: by 10.236.82.110 with SMTP id n74mr25760yhe.57.1390616530075; Fri, 24 Jan 2014 18:22:10 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.20.136 with SMTP id n8ls1200741ige.35.gmail; Fri, 24 Jan 2014 18:22:09 -0800 (PST) X-Received: by 10.50.67.68 with SMTP id l4mr130805igt.1.1390616529388; Fri, 24 Jan 2014 18:22:09 -0800 (PST) In-Reply-To: X-Original-Sender: euloanty@live.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8797 Archived-At: ------=_Part_1008_11787581.1390616527971 Content-Type: text/plain; charset=UTF-8 "This can be, and is, already done. The standard already has something like "auto-moved": is_trivially_move_constructible and is_trivially_move_assignable. However, your above type does *not* qualify, because the move operation can't simply use memcpy and memmove -- they must also zero out the original pointer, and (for the move assignment) release the destination pointer before clobbering it." I don't think "they must also zero out the original pointer". If this type is moved by yourself, you need zero them. But if it's in containers, you needn't zero and deconstruct. If you write a vector-like specific-type data-structure. You won't zero and do deconstructor.You will just do destroy. Right? when you write f(f&& bmv) noexcept =auto; f& operator=(f&&) noexcept =auto; Containers will know that your type has concept "standard-moving-operations of types" by concept-check. template void push_back() { // optimized version } template void push_back() { // can't be optimized version } Then they can directly do memcpy / memmove, for it's no wrong. For your zero-memory is needless now. For after you zero-memory, your type will be deconstruct. It's not truly move!! You just move your resources to new places, and deconstructor is only need to call once but you call more than once. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1008_11787581.1390616527971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"This can be, and is, already done. The standard alre= ady has something like "auto-moved": is_trivially_move_constructible a= nd is_trivially_move_assignable. However, your above type does *not* qualif= y, because the move operation can't simply use memcpy and memmove -- they m= ust also zero out the original pointer, and (for the move assignment) relea= se the destination pointer before clobbering it."

=
I don't think "they must also zero out the original pointer"= ..
If this type is moved by yourself, you need zero them.

But if it's in containers, you needn't zero and decon= struct.

If you write a vector-like specific-type d= ata-structure. You won't zero and do deconstructor.You will just do de= stroy. Right?

when you write
 f(f&a= mp;& bmv) noexcept =3Dauto;
 f& operator=3D(f&&) no= except =3Dauto;

Containers will know that your typ= e has concept "standard-moving-operations of types" by concept-check.
=

template<std::stdandard_move T>
void pu= sh_back()
{
// optimized version
}
=
template<typename T>
void push_back()
{
// can't be optimized version
}
Then they can directly do memcpy / memmove, for it's no wrong.=
For your zero-memory is needless now. For after you zero-me= mory, your type will be deconstruct. It's not truly move!!
<= div>You just move your resources to new places, and deconstructor is only n= eed to call once but you call more than once.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1008_11787581.1390616527971-- .