220 4340 <97b8bfb8-53e8-46a5-81b1-64d68b2ca54b@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: Wed, 8 May 2013 19:01:42 -0700 (PDT) Lines: 465 Approved: news@gmane.org Message-ID: <97b8bfb8-53e8-46a5-81b1-64d68b2ca54b@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4353_29143114.1368064902805" X-Trace: ger.gmane.org 1368064912 2199 80.91.229.3 (9 May 2013 02:01:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 02:01:52 +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+bncBCEKFTV6ZUMBBCUHVSGAKGQENFZPTKY@isocpp.org Thu May 09 04:01:50 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UaGB1-0002SB-TR for gclcip-std-proposals@m.gmane.org; Thu, 09 May 2013 04:01:48 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id 10sf8778382ied.7 for ; Wed, 08 May 2013 19:01:47 -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=1YXxtyZsSdzNHMmhqkcYjbp2KRHjuu24dVSDCKwxzeY=; b=v5dnzILjRl9E02MgfgCREK4OPaRLSJcGLdnWGJ7dbMtv29WxCANw/6Lp+9L6uXgHdP IfvYk7urlXmFrZYEXNrCoeQxpbxMxB3jWa5XHezcfhe+OSHCnHo4+T571RuxeyOjYJKp IimbAFcSIMcDvzHvPISquhyBzeJemVKcD/MGBL1qVXf8fJL2/F/GuMKHUFJA2k/cUE56 V6SgckBS2kP74hq9TNh/9BiXHxRx6WjYLLrcstAwmWgswixTyudBqKel7oPn/xf+M/S1 ylZvcR/nCUF17+j8+AYD7z21Ahilmhas+p1uPTg/hkC3qZJSzLs8PDAjHMT/qdBBmEXy hKyg== X-Received: by 10.43.155.200 with SMTP id lj8mr6698328icc.23.1368064906992; Wed, 08 May 2013 19:01:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.112.71 with SMTP id io7ls1736561igb.3.gmail; Wed, 08 May 2013 19:01:45 -0700 (PDT) X-Received: by 10.50.109.228 with SMTP id hv4mr1535758igb.2.1368064905256; Wed, 08 May 2013 19:01:45 -0700 (PDT) In-Reply-To: <85781912-423b-4ee3-9710-79e69370924b@isocpp.org> 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:4340 Archived-At: ------=_Part_4353_29143114.1368064902805 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, May 8, 2013 10:04:04 AM UTC-7, unituni...@gmail.com wrote: > > Because it can be used at many places to enhance both the performance and > readability. > > 1.Assuming we have a class C1: > class C1 > { > private: > int a; > > public: > C1(void); > C1(int var1, float var2); > > private: > C1(const C1 &); // disabled copy-construct. > C1 & operator = (const C1 &); // disabled copy-assignment. > static void * operator new (size_t); > static void operator delete (void *);// deleting C1 with pointer of > C1 or the inheritance is not allowed. > static void * operator new [] (size_t); > static void operator delete [] (void *);// deleting C1 with pointer > of C1 or the inheritance is not allowed. > template < typename _ty > > operator _ty & (void) const; // disabled generic (means without > using 'reinterpret_case') convertions. > C1 * operator & (void) const; // Get the address of C1 object is not > allowed. > }; > This is some of the worst C++ code I've ever seen. That's an impressive feat, since it's just a class declaration. I could imagine that there's a reason why you need to forbid heap allocation for some type. I can't think of one off the top of my head, but I'm sure there's a reason. But there is *absolutely no reason* to forbid implicit conversions. Unless you specify a specific implicit conversion... you can't do any implicit conversions. They're already forbidden; *double*forbidding them is just silly. And there is *absolutely no reason* to forbid getting the address of the object. If I want to get the address of a type, that's my business, not yours. Not to mention, I can undo all of this effort just by using `std::address_of`. It seems to me that your problem is not with C++. It's that you're writing garbage C++ code and want it to work. > Now we need a class to let it begin handled by a container and, however, > the container only allowed to provided at most one, at least none argument > to initialize the object. Finally let the object can be work in this way: > > > struct Packer // It should have been a template, for explanation i used a > non-template class instead. > { > C1 mydata; > > Packer(void) {}; // Calling the default-constuctor of object mydata. > > Packer(ArgLists args) // The container support at most one > argument. So we use ArgLists. > : mydata(args.get<0>(), args.get<1>()) > {}; > }; > > Here is the request: The Packer will be put as a inner class of that > container, which requires that the start address of it equals to the start > address of the mydata, as a result many things can be written in pithy > style. > That doesn't explain why the container needs to have `mydata` and `Packer` be at the same address. Indeed, I don't understand why the container *cares at all* about the binary layout of this object. But even if it did, you said it yourself: `Packer` is an inner class of the container. It's an implementation detail of the container. So it knows good and well what it contains. If you have some "Allocated_C1_ptr" and you want a pointer to `mydata`, you should use the obvious: C1 *ptr_mydata = &Allocated_C1_ptr->mydata; Oh right, you expressly forbid getting a pointer to the object in the *normal C++ way*. So: C1 *ptr_mydata = std::address_of(Allocated_C1_ptr->mydata); Wasn't forbidding the use of `operator&` so useful? It kept me from getting an address for *the entire second* that it took me to type `std::address_of`. That was time well spent. My point is that your pointer fiddling here seems to serve no purpose. Your example is exceedingly contrived. It relies on pointlessly forbidding me from getting a pointer to an object. It also falls apart the moment someone remembers that `std::address_of` exists. Please find an example that looks like reasonable C++ code. Without the standarized supporting it can still be applied but also > complicated with unnecessary performance losts, Something like: > ptr_Packer = (Packer *)((byte *)Allocated_C1_ptr - offsetof(Packer, > mydata)); > realy?? no, there is strong reason that the offsetof(Packer, mydata) be > zero. and much worse, once a compiler decided to use the hidden extended > bytes betweens the entry of Packer and address of mydata to do something, > that formal won't work correctly. But since the Packer itself is not a > polymorphism class: no base, no virtual function, and a class' > local-resources (not including static and global res.) shall never expand > outside of itself (or the sizeof operator would yield a ill result), It > seems no reason to do that by any compiler(the hidden bytes for alignment > both between two data members and after the last data member is still > allowed)? Or you can tell me more about if there is ... > > Another sample: > > class C2 > { > private: > SomeClass data; > > public: > C2(void); > > operator ExpandedInterf & (void); > operator const ExpandedInterf & (void) const; > > // ... // some extended functions to handle data at here. > > private: > C2(const C2 &); // disabled copy-construct. > C2 & operator = (const C2 &); // disabled copy-assignment. > static void * operator new (size_t); > static void operator delete (void *);// deleting C1 with pointer of > C1 or the inheritance is not allowed. > static void * operator new [] (size_t); > static void operator delete [] (void *);// deleting C1 with pointer > of C1 or the inheritance is not allowed. > template < typename _ty > > operator _ty & (void) const; // disabled generic (means without > using 'reinterpret_case') convertions. > C2 * operator & (void) const; // Get the address of C1 object is not > allowed. > }; > > Here is the 'ExpandedInterf' looks like: > > class ExpandedInterf > { > private: > SomeClass mappeddata; > > public: > // ... // Constructors & destructors & some extended functions to > handle mappeddata at here. > }; > > You may tell 'you can use the pointer/pointer class in ExpandedInterf > ...'. First, it's slower than direct-mapping; Second, using those kind of > way will lead the lifetime of the ExpandedInterf and C2 being different. > It's also not pithy enough. > It's not clear at all what the relationship between these two classes are, besides the fact that you have this incredibly dubious notion of returning a *reference* from a conversion operator rather than a value. What exactly are these conversion operators doing? And how does it make sense to return a reference rather than a value? Are you trying to do some nonsense like this: operator ExpandedInterf & (void) { return *reinterpret_cast(std::address_of(this->data)); } Because that's seriously horrible code. If you want `ExpandedInterf` to share ownership of `SomeClass`, you use a *pointer*, not a horrible `reinterpret_cast`. At least there, the ownership semantics and relationships are explicit rather than implicit (and terribly broken, mind you). Give me an example of using this functionality that *isn't* laden with `reinterpret_cast` usage. Remember: `reinterpret_cast` is something you, generally, speaking, *shouldn't be using*. Indeed, it seems to me that everything you want this for are things you shouldn't be doing in the first place. Low-level, horrible, and fundamentally bad ideas. Also, this is the second time you've used the word "pithy". I don't know what you mean by this, and Google isn't helping. -- --- 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_4353_29143114.1368064902805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, May 8, 2013 10:04:04 AM UTC-7, unituni...@gmail.com wrote:
Because it can be used at ma= ny places to enhance both the performance and readability.

1.Assuming we have a class C1:
c= lass C1
{
private:
    int a;

public:
    C1(void);
    C1(int var1, float var2);

<= div>private:
    C1(const C1 &); =               //= disabled copy-construct.
    C1 & operator =3D (const C1 &); // disabled copy-assignment.
  &n= bsp; static void * operator new (= size_t);
    static void= operator delete (void *);// deleting C1 with pointer of C1 or the inheritance is not al= lowed.
    static void * operator new [] (size_t);
    static= void operator delete [] (void *);// deleting C1 with pointer of C1 or the inheritance i= s not allowed.
    templ= ate < typename _ty >
    operat= or _ty & (void) const;  // disabled generic (means without using 'reinterpret_case') convert= ions.
    C1 * operator & (void) const; // Get= the address of C1 object is not allowed.
};

This is some of the worst C++ code I've ever seen. That's= an impressive feat, since it's just a class declaration.

I could im= agine that there's a reason why you need to forbid heap allocation for some= type. I can't think of one off the top of my head, but I'm sure there's a = reason. But there is absolutely no reason to forbid implicit convers= ions. Unless you specify a specific implicit conversion... you can't do any= implicit conversions. They're already forbidden; double forbidding = them is just silly.

And there is absolutely no reason to forb= id getting the address of the object. If I want to get the address of a typ= e, that's my business, not yours. Not to mention, I can undo all of this ef= fort just by using `std::address_of`.

It seems to me that your probl= em is not with C++. It's that you're writing garbage C++ code and want it t= o work.
 
Now we need a class to let it begin handled by a container and, ho= wever, the container only allowed to provided at most one, at least none ar= gument to initialize the object. Finally let the object can be work in this= way:


struc= t Packer // I= t should have been a template, for explanation i used a non-template class = instead.
{
    C1 mydata;

=     Packer(void) {}; // Call= ing the default-constuctor of object mydata.

    Packer(ArgLists<int,float> args) // The container suppo= rt at most one argument. So we use ArgLists.
   =     : mydata(args.get<0>(), args.get<1>())
    {};
};

Here is the = request: The Packer will be put as a inner class of that container, which r= equires that the start address of it equals to the start address of the myd= ata, as a result many things can be written in pithy style.

That doesn't explain why the container needs to have `mydata` a= nd `Packer` be at the same address. Indeed, I don't understand why the cont= ainer cares at all about the binary layout of this object. But even = if it did, you said it yourself: `Packer` is an inner class of the containe= r. It's an implementation detail of the container. So it knows good and wel= l what it contains.

If you have some "Allocated_C1_ptr" and you want= a pointer to `mydata`, you should use the obvious:

C1 *ptr_mydata =3D &Allocated_C1_ptr->mydata;<= br>

Oh right, you expressly forbid getting a p= ointer to the object in the normal C++ way. So:

<= span style=3D"color: #000;" class=3D"styled-by-prettify">C1 *ptr_mydata =3D std::address_of(Allocated_C1_ptr->mydata);

Wasn't forbidding the use of `oper= ator&` so useful? It kept me from getting an address for the entire = second that it took me to type `std::address_of`. That was time well sp= ent. </sarcasm>

My point is that your pointer fiddling here se= ems to serve no purpose. Your example is exceedingly contrived. It relies o= n pointlessly forbidding me from getting a pointer to an object. It also fa= lls apart the moment someone remembers that `std::address_of` exists.
Please find an example that looks like reasonable C++ code.

=
Without the standarized = supporting it can still be applied but also complicated with unnecessary pe= rformance losts, Something like:
 ptr_Packer =3D (Packer *)(= (byte *)Allocated_C1_ptr - offsetof(Packer, mydata)); 
realy?? no, there is s= trong reason that the offsetof(Packer, mydata) be zero. and much worse, onc= e a compiler decided to use the hidden extended bytes betweens the entry of= Packer and address of mydata to do something, that formal won't work corre= ctly. But since the Packer itself is not a polymorphism class: no base, no = virtual function, and a class' local-resources (not including static and gl= obal res.) shall never expand outside of itself (or the sizeof operator wou= ld yield a ill result), It seems no reason to do that by any compiler(the h= idden bytes for alignment both between two data members and after the last = data member is still allowed)? Or you can tell me more about if there is ..= ..

Another sample:

class C2
{=
private:
    = SomeClass data;

public:
    C2(void);

    operator ExpandedInterf & (void)= ;
    operator const ExpandedInterf & (v= oid) const;

=     // ... // some extended= functions to handle data at here.

private:
    C2(const C2 &);   =             // disabl= ed copy-construct.
    C= 2 & operator =3D (const C2 &); // disabled copy-assignment.
    static void * <= font color=3D"#0000ff">operator new (size_t<= /font>);
    static void operat= or delete (void *);// deleting C1 with pointer of C1 or the inheritance is not allowed.<= /font>
    static void <= font color=3D"#000000">* operator new= [] (size_t);
    static void operator delete [] (void *);// deleting C1 with pointer of= C1 or the inheritance is not allowed.
    template < typename _ty >
    operator _ty & = (void) const;=  // disabled generic (means without using 're= interpret_case') convertions.
    C2 * operator & (void) const; // Get the address of C1 object is not allowed.
};

Here is the 'ExpandedInterf' looks like= :

class ExpandedInterf
{
private:
    SomeClass mappeddata;

public:
    // ... // Constructors & destructors & some extended functions to = handle mappeddata at here.
};

You= may tell 'you can use the pointer/pointer class in ExpandedInterf ...'. Fi= rst, it's slower than direct-mapping; Second, using those kind of way will = lead the lifetime of the ExpandedInterf and C2 being different. It's also n= ot pithy enough.

It's not clear at all what the = relationship between these two classes are, besides the fact that you have = this incredibly dubious notion of returning a reference from a conve= rsion operator rather than a value. What exactly are these conversion opera= tors doing? And how does it make sense to return a reference rather than a = value? Are you trying to do some nonsense like this:

operator ExpandedInterf & (void)
<= /span>{
  return *reinterpret_cast<ExpandedInterf*>(std::address_of(this->d= ata));
}

Because that's seriously horrible code. If you want `ExpandedInterf` = to share ownership of `SomeClass`, you use a pointer, not a horrible= `reinterpret_cast`. At least there, the ownership semantics and relationsh= ips are explicit rather than implicit (and terribly broken, mind you).
<= br>Give me an example of using this functionality that isn't laden w= ith `reinterpret_cast` usage. Remember: `reinterpret_cast` is something you= , generally, speaking, shouldn't be using. Indeed, it seems to me th= at everything you want this for are things you shouldn't be doing in the fi= rst place. Low-level, horrible, and fundamentally bad ideas.

Also, t= his is the second time you've used the word "pithy". I don't know what you = mean by this, and Google isn't helping.

--
 
---
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_4353_29143114.1368064902805-- .