220 12677 article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Usability extensions to offsetof Date: Thu, 4 Sep 2014 12:19:38 -0700 (PDT) Lines: 322 Approved: news@gmane.org Message-ID: References: <507AB10F-66B5-4E72-AF78-98B4AECBE6B3@gmail.com> <1790122.GP859xiMW3@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3810_1726609344.1409858378802" X-Trace: ger.gmane.org 1409858392 10461 80.91.229.3 (4 Sep 2014 19:19:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 19:19:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRBTPWUKQAKGQEIK3QELQ@isocpp.org Thu Sep 04 21:19:45 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPcZL-0001jN-BF for gclcip-std-proposals@m.gmane.org; Thu, 04 Sep 2014 21:19:43 +0200 Original-Received: by mail-ig0-f198.google.com with SMTP id h18sf50564122igc.5 for ; Thu, 04 Sep 2014 12:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=V++WcqVkPHva1Sz6RIMJvEbZZit6nQyO3Ca4i3prMUA=; b=IYCs/DjBUsFs0FWx6G5mAiAjAyRJY2hsS8HyvC9shYB0tEVXeI2J5oBUsUXxA6jwsB Pb5Az5mp0CYqkumKACOP8HZcDcu8AuIwuFGATmDl8YOFy2YQ2pBtrfnCP6WcoCyJ7e7L LaveFJgy8WjaF+/DjrvePNAbFhHArQt2fhB9Gs9thiAuFXfhBGvkrBC9Pe6PcXAett9x v/p9m6fPzLWpxspOH452EmS5g5suFdXWeyl5B53IPzQyZtU/ZEnulhsXGwvh3MLjy3yW iBD+Gb9h4gMFbXuZQYWf8QDrYsgJ5K1sCvQjYb/q7MlBBsLExp56pQYzwjOu9ldg+Gfo 87Xw== 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=V++WcqVkPHva1Sz6RIMJvEbZZit6nQyO3Ca4i3prMUA=; b=ixcJkWolZPccxZUiXVLhp6zU5rDcCT7LyrTTqg6JxArEImuUawjKr1SO/77kudBEmr nCXYoXXEmC6QRFiOaIh8JsRhaWHMFWGzJNDM1aEjXdVt395XooGTkxWllAquDYJrARfM 9Za3VJ9phx1UvLzNWlSiZ2gA0rvTVPGR3AY37ge57dnyPv0TcNk7gqyyJmB/+nY/SKZi Y1Cot0QFLve7JYU1la89Vgzj21TUakQdoXfKiHWmK7ul1yS6ivQbqNENTencNOBI6b/6 jPLWJZpX9V97MgSPyJ5jQHJTyU6yQb3Tb/lWSEsE3xqIL3lnoYVPt4U8IF+QaT7D8GGd ru9g== X-Gm-Message-State: ALoCoQnxRNVU9NK584KezIedH8+8MPbeZlJiVUh+LgBrZNsii2MhpRGgdREehyRCI7rmEMhiceKW X-Received: by 10.50.33.18 with SMTP id n18mr3731178igi.8.1409858382379; Thu, 04 Sep 2014 12:19:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.143.76 with SMTP id sc12ls765059igb.3.gmail; Thu, 04 Sep 2014 12:19:41 -0700 (PDT) X-Received: by 10.50.41.103 with SMTP id e7mr128405igl.8.1409858381628; Thu, 04 Sep 2014 12:19:41 -0700 (PDT) In-Reply-To: <1790122.GP859xiMW3@tjmaciei-mobl4> X-Original-Sender: myriachan@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:12677 Archived-At: ------=_Part_3810_1726609344.1409858378802 Content-Type: text/plain; charset=UTF-8 On Wednesday, September 3, 2014 9:03:07 AM UTC-7, Thiago Macieira wrote: > > On Wednesday 03 September 2014 12:46:39 David Krauss wrote: > > Where would you prefer to use offsetof, instead of a pointer-to-member? > > In the calculation of the reverse: from member to top-of-object. > This has been my experience as well: most of the time, the reason I want such functionality is because I want to return to the beginning of the object, to "undo" a member pointer. In other words, Microsoft's CONTAINING_RECORD macro, but with member pointers. It actually wasn't what prompted the idea *this* time, though. template Source *containing_instance(Member *member, Member Source::*member_pointer) { static_assert(is_object::value, "source class must be of object type"); typedef typename conditional::value, const char, char >::type c_char; typedef typename conditional::value, volatile c_char , c_char>::type cv_char; ptrdiff_t offset = reinterpret_cast(&(reinterpret_cast(1)->*member_pointer)) - reinterpret_cast(1); // I don't see how to do this without breaking aliasing rules... return reinterpret_cast(reinterpret_cast(member) - offset); } There isn't a Standard way of determining whether a class has virtual inheritance, however. is_offsetof_compatible would help with this, and would be useful in more cases than merely standard-layout. Although, actually, *are* there cases in which virtual inheritance breaks offsetof? Member pointers also have a limitation in that you can't use them without a known base type. If you have highly-generic code that can't be templated on the type, you'd need to have a base class in order to use member pointers. Adding a base class means that you can no longer use aggregate-initialization of arrays of that class. I ran into this exact problem last week at work, and it forcing me to use offsetof and lose all type safety prompted me to make this proposal. (Conversion to an offset loses type safety, of course, but prior to that conversion, you have type safety. Some is better than none, I figure.) On Tuesday, September 2, 2014 9:46:44 PM UTC-7, David Krauss wrote: > > offsetof is a vestige of C compatibility, and standard layout is > specifically tailored to C ABI compatibility. So the restriction is > probably exactly what its designers intended. > > Standard-layout exists for compatibility with other languages' in-memory structures, yes, but offsetof is useful under looser requirements. Standard-layout guarantees things like that the in-memory order matches the order of members, and that the offset of the first element is zero. These need not be true to make use of offsetof in many cases. However, even in the worst case, with virtual functions and virtual inheritance, it's always true that a class C's instance C *c occupies a "fixed" location starting at a char *p = reinterpret_cast(c) and ends right before p + sizeof(C). Applied recursively, this means that for each data member M C::m there exists an offset o such that &c->m == reinterpret_cast(p + o). Where would you prefer to use offsetof, instead of a pointer-to-member? > > Whenever a template won't work or is inconvenient - whenever you need to access a member of a class using a char *. It can avoid code bloat, too, by avoiding a zillion copies of assembly code with tiny changes. The purpose of such a feature would primarily be for libraries. Users of such a library would specify an element using a member pointer, then the library itself would internally use offsets. (Such a library could not exist as a DLL, because it is not possible in current C++ to use a member pointer with void *. Instead, you have to use callback functions.) Melissa -- --- 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_3810_1726609344.1409858378802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, September 3, 2014 9:03:07 AM UTC-7, Thiago M= acieira wrote:
On Wednesday 03 = September 2014 12:46:39 David Krauss wrote:
> Where would you prefer to use offsetof, instead of a pointer-to-me= mber?

In the calculation of the reverse: from member to top-of-object.

This has been my experience as well: most of the time,= the reason I want such functionality is because I want to return to the be= ginning of the object, to "undo" a member pointer.  In other words, Mi= crosoft's CONTAINING_RE= CORD macro, but with member pointers.  It actually wasn't what = prompted the idea this time, though.

template <class Source, class= Member>
Source *containing_instance(Member *member<= /span>, Member Source::*member_pointer)
{
    static_assert(is_object<S= ource>:= :value, "source class must be of object = type");

 = ;   t= ypedef typename conditional<is_const<Source>::value, const char, char>::type c_char;
    typedef typename conditional<is_volatile<Source>::value, volatil= e c_char, c_char>::type cv_char;

    ptrdiff_t off= set =3D reinterpret_cast<cv_char *>(&(reinterpret_cast<Source *>(1)->*member_pointer)) -
        reinterpret_cast<cv_char *>(1);

    // I don't see how to do this without breaking aliasing rule= s...
&n= bsp;   return <= /span>reinterpret= _cast<<= /span>Source *>(reinterpret_cast<cv_char *>(member) - offset);
}


There isn't a Standard way of determining whe= ther a class has virtual inheritance, however.  is_offsetof_compatible would help with= this, and would be useful in more cases than merely standard-layout. = Although, actually, are there cases in which virtual inheritance br= eaks offsetof?
Member pointers also have a limitation in that you can't use them=20 without a known base type.  If you have highly-generic code that can't= =20 be templated on the type, you'd need to have a base class in order to=20 use member pointers.  Adding a base class means that you can no longer= =20 use aggregate-initialization of arrays of that class.  I ran into this= =20 exact problem last week at work, and it forcing me to use offsetof and lose all type safety prompted me to make this proposal. =20 (Conversion to an offset loses type safety, of course, but prior to that conversion, you have type safety.  Some is better than none, I figure= ..)


On Tuesday, September 2, 2014 9:46:44 PM UTC-7, David Krauss = wrote:
offsetof is a vestige of C compatibility, and standard layout is specifically=20 tailored to C ABI compatibility. So the restriction is probably exactly=20 what its designers intended.

<= div>
Standard-layout exists for compatibility with other languages' in-m= emory structures, yes, but offsetof is useful under looser requirements.  Standard-lay= out guarantees things like that the in-memory order matches the order of me= mbers, and that the offset of the first element is zero.  These need n= ot be true to make use of offsetof in many cases.

However, even in the worst case, w= ith virtual functions and virtual inheritance, it's always true that a clas= s C's instance <= span style=3D"font-family: courier new,monospace;">C *c occupies a "= fixed" location starting at a char *p =3D reinterpret_cast<char *>(c) and ends right = before p + sizeof(C).  Applied recursively, this means that for each data member M C::m there exists a= n offset o such = that &c->m =3D= =3D reinterpret_cast<M *>(p + o).

Where would you prefer to use offsetof, instead of a pointer-to-member?
 
=
Whenever a template won't work or is inconvenient - whenever you need t= o access a member of a class using a char *.  It can avoid code bloat, too, by avoidin= g a zillion copies of assembly code with tiny changes.  The purpose of= such a feature would primarily be for libraries.  Users of such a lib= rary would specify an element using a member pointer, then the library itse= lf would internally use offsets.  (Such a library could not exist as a= DLL, because it is not possible in current C++ to use a member pointer wit= h void *.  = Instead, you have to use callback functions.)

Melissa

--

---
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-proposa= ls+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_3810_1726609344.1409858378802-- .