220 4343 article Path: news.gmane.org!not-for-mail From: unituniverse.1@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Please implement more rules about memory layout of the non-virtual classes. Date: Thu, 9 May 2013 04:02:06 -0700 (PDT) Lines: 135 Approved: news@gmane.org Message-ID: References: <53cf1f05-734a-4cfa-86f0-f7e112f69d14@isocpp.org> <10ea67e2-61cb-4e14-8d22-111c1321dac0@isocpp.org> <0037922f-5a94-4865-9599-61b49fd4e60a@isocpp.org> <6335d08d-3ae5-41dc-b128-6b2c49b3d51b@isocpp.org> <85781912-423b-4ee3-9710-79e69370924b@isocpp.org> <97b8bfb8-53e8-46a5-81b1-64d68b2ca54b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_29773192.1368097326037" X-Trace: ger.gmane.org 1368097332 11442 80.91.229.3 (9 May 2013 11:02:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 11:02:12 +0000 (UTC) Cc: unituniverse.1@gmail.com, unituniverse.1@gmail.com, unituniverse.1@gmail.com, unituniverse.1@gmail.com, unituniverse.1@gmail.com, unituniverse.1@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBYPZVK7MJRBMEEV2GAKGQEOZN7RMA@isocpp.org Thu May 09 13:02:11 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UaOby-0006ON-N1 for gclcip-std-proposals@m.gmane.org; Thu, 09 May 2013 13:02:11 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id tb18sf10096480obb.1 for ; Thu, 09 May 2013 04:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:cc:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=X90NGSHU6kdhOUBUsH4dbsK0m/aS3d8f0PfUol2a3ug=; b=zJLRhPwQbPlXw4zwvG8Og8SaBQRrfiuSCnjkOm9XkeKp3Ty/jBJAaoVnkmQvOuPpE+ 1hm7V0SnTkgYvBcHTHK3H8UeBdDxWcnOK7QawPp3dpuZrRM47WC6H4ctBYM3fFzDpbIJ zSTkWHq1HD00mF4tjGfRVw3BEbWIPBs5teR3m15jJCsYWza1wE9Cw9/dNGI9NfEg/t/I hRs7iwKQVwGh3IAqNJrW29ZlppK+x31hGAHbtrMkJleF1OO/kZdYB9A+PD2QQwxG8Wfk KYpCXj+9rzK3lH8Ew36KVo4QOMeC7NnHqq1gl23w/dUpd+hbcf3r5WHp71F/SJUxqdZQ 9kLg== X-Received: by 10.50.111.162 with SMTP id ij2mr9337735igb.5.1368097329487; Thu, 09 May 2013 04:02:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.73.161 with SMTP id m1ls17915igv.0.canary; Thu, 09 May 2013 04:02:07 -0700 (PDT) X-Received: by 10.50.12.4 with SMTP id u4mr1676177igb.5.1368097327926; Thu, 09 May 2013 04:02:07 -0700 (PDT) In-Reply-To: <97b8bfb8-53e8-46a5-81b1-64d68b2ca54b@isocpp.org> X-Original-Sender: unituniverse1@gmail.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:4343 Archived-At: ------=_Part_1_29773192.1368097326037 Content-Type: text/plain; charset=ISO-8859-1 What your point, obviously is, that anything 'worst' is something you are limited or prevented? The code i put before is a sort of locker(or just a kind of warning signs to tell the clients something they'd better not to do) to special access ways. using the reinterpret_cast and addressof(which internally use reinterpret_cast) is just like a way to broken the door, which doesn't mean to be bad or lack of the locker itself. The conversion operator overloading in the C1 is not for forbiding implicit conversions but explicit ones(except any reinterpret_cast<>). The implicit conversions have been disabled before the conversion operator overloading has been placed. The private declaration(or another formal which with '= delete;') of new and delete operators is not for disabling the heap allocating what you talked about. It's just for disabling the allocating requests in direct allocating way, as i said before, with the pointer to C1 or the inherited class from C1. You can still do allocating with other formal, like class Placement { C1 val; }; with 'new Placement'. It seems that the 'normal C++ way' you said meaning 'Use C++ just for making the code Looked Like the Coding and running In C++ way, but not compling in C++ way'? Or it must and will be garbage hur? I feel you are being so angry about my code Not because the crap it was so but just something making you feeling restricted, then anything on your way should have been killed and why don't just get the hell out of the front of you -- is that what you mean? You don't want to solve anything. You don't want to think. You don't even care. All you did were just or even prefer to stand on where you are and tell others 'No'. There must be a reason that the C++11 implement more rules for POD/trivil/Standard-Layout. As your understand, they are all useless and even shouldn't be exist if there was no such rules yet. The allocator the stl internally used manage objects as binary way, but with the type of object-pointer. finally the most of such codes they introduced work like the following formal: data_type * pBinary = (data_type *)new byte [number * sizeof(data_type)];//Pseudo code. which is as the formal of 'alloc.allocate(size_type)' generally. for(size_type i(); i < number; ++i) { new(pBinary + i) data_type(init_arg); //Pseudo code. which is as the formal of alloc.construct(pBinary + i, init_arg); generally. } // ... // Save the pointer and length here. Anything have a reason. The 'normal C++ way' still have nothing to do to stop the realy bad formal code. In most of cases it won't be necessary to ask standard to change for that not because the client should take this job but the interfaces maker should handle that verification in code but not language standard. The 'normal way' is too crude and even worse. The decision that reject to implement a rule shouldn't rely on whether it 'has to' but it 'shall not'. There is a view that a good C++ code should do as possible as it could to let the verification be done at the compiling time rather than runtime unless it's realy hard or logically not fit for. The 'normal C++ way' is not good for that. -- --- 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/?hl=en. ------=_Part_1_29773192.1368097326037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What your point, obviously is, that anything 'worst' is something you = are limited or prevented? The code i put before is a sort of locker(or just= a kind of warning signs to tell the clients something they'd better not to= do) to special access ways. using the reinterpret_cast and addressof(which= internally use reinterpret_cast<char&>) is just like a way to br= oken the door, which doesn't mean to be bad or lack of the locker itself.
The conversion operator overloading in the C1 is not for forbiding= implicit conversions but explicit ones(except any reinterpret_cast<>= ). The implicit conversions have been disabled before the conversion operat= or overloading has been placed.
The private declaration(or anothe= r formal which with '=3D delete;') of new and delete operators is not for d= isabling the heap allocating what you talked about. It's just for disabling= the allocating requests in direct allocating way, as i said before, with t= he pointer to C1 or the inherited class from C1. You can still do allocatin= g with other formal, like class Placement { C1 val; }; with 'new Placement'= ..
It seems that the 'normal C++ way' you said meaning 'Use C++ ju= st for making the code Looked Like the Coding and running In C++ way, but n= ot compling in C++ way'? Or it must and will be garbage hur? I feel you are= being so angry about my code Not because the crap it was so but just somet= hing making you feeling restricted, then anything on your way should have b= een killed and why don't just get the hell out of the front of you -- is th= at what you mean?
You don't want to solve anything. You don't wan= t to think. You don't even care. All you did were just or even prefer to st= and on where you are and tell others 'No'. There must be a reason that the = C++11 implement more rules for POD/trivil/Standard-Layout. As your understa= nd, they are all useless and even shouldn't be exist if there was no such r= ules yet. The allocator the stl internally used manage objects as binary wa= y, but with the type of object-pointer. finally the most of such codes they= introduced work like the following formal:

data_t= ype * pBinary =3D (data_type *)new byte [number * sizeof(data_type)];//Pseu= do code. which is as the formal of 'alloc.allocate(size_type)' generally.
for(size_type i(); i < number; ++i)
{
 = ;   new(pBinary + i) data_type(init_arg); //Pseudo code. which is as t= he formal of alloc.construct(pBinary + i, init_arg); generally.
}=
// ... // Save the pointer and length here.

=
Anything have a reason. The 'normal C++ way' still have nothing to do = to stop the realy bad formal code. In most of cases it won't be necessary t= o ask standard to change for that not because the client should take this j= ob but the interfaces maker should handle that verification in code but not= language standard. The 'normal way' is too crude and even worse. The decis= ion that reject to implement a rule shouldn't rely on whether it 'has to' but it 'shall not'. There is a view that a good C++ code should do as possible as it coul= d to let the verification be done at the compiling time rather than runtime= unless it's realy hard or logically not fit for. The 'normal C++ way' is n= ot good for that.

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_1_29773192.1368097326037-- .