220 4344 <106c52d4-54c3-4ea6-aa45-0f955f4ebd24@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas 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:37:58 -0700 (PDT) Lines: 247 Approved: news@gmane.org Message-ID: <106c52d4-54c3-4ea6-aa45-0f955f4ebd24@isocpp.org> 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_4650_32123335.1368099478125" X-Trace: ger.gmane.org 1368099483 2521 80.91.229.3 (9 May 2013 11:38:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 11:38:03 +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, unituniverse.1@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBGEVV2GAKGQEHRWO3BQ@isocpp.org Thu May 09 13:38:03 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ia0-f197.google.com ([209.85.210.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UaPAg-0003g7-0b for gclcip-std-proposals@m.gmane.org; Thu, 09 May 2013 13:38:02 +0200 Original-Received: by mail-ia0-f197.google.com with SMTP id i20sf7334950ian.4 for ; Thu, 09 May 2013 04:38:01 -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=7Nq8PC764WKlKcs+7ecni2tDqqodj/EGH+TOxLWSJ/M=; b=xQR9Ys6AH85fFvp8oueNaSjeAqT2Z6y78hlCgg6Wtsq/9l2uCvqVnbyBENFfZe7XLb JCNzZvC204uKkpS2xvtsdNpyovi88K0/c1eCI8vwG54Yyq+K/w1T8yUVVn583ujrwLGh IStir3tMKNPo+sMXnHkBE38qMmsYTBxPWEHT/iEudtu+XLAJuBOAyVokUgv/3EpoNFjv PuUbns0nZgs9+xoO2K35PUotoIKxTfFogbZdkw8sH7WXhAq+XtlLROosR5Sk+vPqu1Qs 6s1rNJ1BOV2SIr8BZ2lzEsuvFTnPIuqEZvsMiv7cZ7+mG7KcvYF0c3HtuhpOwTdVnPI+ BK/g== X-Received: by 10.50.183.164 with SMTP id en4mr21684333igc.2.1368099480882; Thu, 09 May 2013 04:38:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.157.170 with SMTP id wn10ls1846100igb.31.gmail; Thu, 09 May 2013 04:37:59 -0700 (PDT) X-Received: by 10.50.176.234 with SMTP id cl10mr1685019igc.6.1368099479609; Thu, 09 May 2013 04:37:59 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:4344 Archived-At: ------=_Part_4650_32123335.1368099478125 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, May 9, 2013 4:02:06 AM UTC-7, unituni...@gmail.com wrote: > > What your point, obviously is, that anything 'worst' is something you are > limited or prevented? > Preventing the user from doing things that the class is not intended to do is fine. Preventing a class from being copied is fine. Preventing a class from being default constructed is fine. And so forth. Getting a pointer to an object is the *right* of every C++ programmer. It is a basic language feature, regardless of the object's type. For you to deny a programmer that *right* is a violation of the contract between class designer and class user. I'm not the only C++ programmer who thought it was a mistake to allow users to overload the unary `operator&` on classes. And I have no love for code that would deny me that right. I don't really understand what the point of forbidding "explicit" conversion of references is. Particularly when such explicit conversions don't make sense and aren't protected by the rules of C++ anyway. It's forbidding something that people don't do. 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'. > So... what's the point? Why are you making normal usage of your class (like heap allocation) *inconvenient*? People do not write C++ this way. And we should not add features to the language that only a select few people who use this coding style will use. 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? > .... I don't understand what you're saying. Your use of language is becoming an issue. I would consider the "normal C++ way" to be what you see in real, live C++ programs. What you see in actual C++ libraries. I don't see a lot of objects that you can't call `new` or `delete` on in Boost. I don't see a lot of objects you can't get pointers to with `operator&` in Microsoft or Google's C++ code. The standard library did not forbid reference casting of `std::thread`. That is what is "normal". Your code is not following established C++ coding practices. And we shouldn't add features to the *language* if it would only ever be useful to people who are doing things that just don't make sense. 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. > I explained those reasons: it standardized existing practice. Also, it's sometimes very useful to be layout-compatible with C types, while still availing one's self of certain C++ features. The difference between that and this is that I could explain how standard layout is important just by referencing an existing C API. I want to interface with that via a class, and I want that class to have member functions, constructors, destructors, and the like. The only thing it can't have are base classes that have members, and I don't *need* that to interface with a C API. Your attempts to explain why you need the functionality you outline all involve writing terrible code. *Needlessly* terrible code. They're artificial problems that arise because you keep wanting to derive classes from things or to stop people from using `operator&`, or other things that have nothing to do with low-level coding. Everything you have posted can be achieved another way, and in most cases with only minor inconvenience. And those that can't are things you have no business doing to begin with (like reference casting). They have nothing to do with interfacing with C APIs or other low-level binary tasks. 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. > Again, I don't really understand what you're trying to say here. -- --- 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_4650_32123335.1368099478125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thursday, May 9, 2013 4:02:06 AM UTC-7, unituni...@gmail.com wrote:
What your point, obviously is,= that anything 'worst' is something you are limited or prevented?

Preventing the user from doing things that the class is n= ot intended to do is fine. Preventing a class from being copied is fine. Pr= eventing a class from being default constructed is fine. And so forth.
<= br>Getting a pointer to an object is the right of every C++ programm= er. It is a basic language feature, regardless of the object's type. For yo= u to deny a programmer that right is a violation of the contract bet= ween class designer and class user. I'm not the only C++ programmer who tho= ught it was a mistake to allow users to overload the unary `operator&` = on classes. And I have no love for code that would deny me that right.
<= br>I don't really understand what the point of forbidding "explicit" conver= sion of references is. Particularly when such explicit conversions don't ma= ke sense and aren't protected by the rules of C++ anyway. It's forbidding s= omething that people don't do.

The private declaration(or another formal which with '= =3D delete;') of new and delete operators is not for disabling the heap all= ocating what you talked about. It's just for disabling the allocating reque= sts in direct allocating way, as i said before, with the pointer to C1 or t= he inherited class from C1. You can still do allocating with other formal, = like class Placement { C1 val; }; with 'new Placement'.
<= div>
So... what's the point? Why are you making normal usage of your cla= ss (like heap allocation) inconvenient? People do not write C++ this= way. And we should not add features to the language that only a select few= people who use this coding style will use.

It seems that the 'normal C++ way' you sai= d meaning 'Use C++ just for making the code Looked Like the Coding and runn= ing In C++ way, but not compling in C++ way'? Or it must and will be garbag= e 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 y= our way should have been killed and why don't just get the hell out of the = front of you -- is that what you mean?

... I don= 't understand what you're saying. Your use of language is becoming an issue= ..

I would consider the "normal C++ way" to be what you see in real, = live C++ programs. What you see in actual C++ libraries.

I don't see= a lot of objects that you can't call `new` or `delete` on in Boost. I don'= t see a lot of objects you can't get pointers to with `operator&` in Mi= crosoft or Google's C++ code. The standard library did not forbid reference= casting of `std::thread`.

That is what is "normal".

Your cod= e is not following established C++ coding practices. And we shouldn't add f= eatures to the language if it would only ever be useful to people wh= o are doing things that just don't make sense.

You don't want to solve anything. You do= n't want to think. You don't even care. All you did were just or even prefe= r to stand on where you are and tell others 'No'. There must be a reason th= at the C++11 implement more rules for POD/trivil/Standard-Layout.

I explained those reasons: it standardized existing pract= ice. Also, it's sometimes very useful to be layout-compatible with C types,= while still availing one's self of certain C++ features.

The differ= ence between that and this is that I could explain how standard layout is i= mportant just by referencing an existing C API. I want to interface with that vi= a a class, and I want that class to have member functions, constructors, de= structors, and the like. The only thing it can't have are base classes that= have members, and I don't need that to interface with a C API.
<= br>Your attempts to explain why you need the functionality you outline all = involve writing terrible code. Needlessly terrible code. They're art= ificial problems that arise because you keep wanting to derive classes from= things or to stop people from using `operator&`, or other things that = have nothing to do with low-level coding.

Everything you have posted= can be achieved another way, and in most cases with only minor inconvenien= ce. And those that can't are things you have no business doing to begin wit= h (like reference casting). They have nothing to do with interfacing with C= APIs or other low-level binary tasks.

As your understand, they are all useless and eve= n 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-p= ointer. finally the most of such codes they introduced work like the follow= ing formal:

data_type * pBinary =3D (data_type *)n= ew byte [number * sizeof(data_type)];//Pseudo code. which is as the formal = of 'alloc.allocate(size_type)' generally.
for(size_type i(); i &l= t; number; ++i)
{
    new(pBinary + i) data_t= ype(init_arg); //Pseudo code. which is as the formal of alloc.construct(pBi= nary + i, init_arg); generally.
}
// ... // Save the po= inter and length here.

Anything have a reason. The= 'normal C++ way' still have nothing to do to stop the realy bad formal cod= e. In most of cases it won't be necessary to ask standard to change for tha= t not because the client should take this job but the interfaces maker shou= ld 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 r= ule shouldn't rely on whether it 'has to' bu= t it 'shall not'. There is a view that a goo= d C++ code should do as possible as it could to let the verification be don= e at the compiling time rather than runtime unless it's realy hard or logic= ally not fit for. The 'normal C++ way' is not good for that.

Again, I don't really understand what you're trying to say her= e.

--
 
---
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_4650_32123335.1368099478125-- .