220 12643 article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Usability extensions to offsetof Date: Tue, 2 Sep 2014 21:37:53 -0700 (PDT) Lines: 86 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5899_1473812941.1409719073552" X-Trace: ger.gmane.org 1409719084 31119 80.91.229.3 (3 Sep 2014 04:38:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 04:38:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRBI5WTKQAKGQEKLZYUNI@isocpp.org Wed Sep 03 06:37:57 2014 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 1XP2KS-0004yz-Ol for gclcip-std-proposals@m.gmane.org; Wed, 03 Sep 2014 06:37:57 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id wp18sf42842023obc.9 for ; Tue, 02 Sep 2014 21:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=GaAsED2+7mG3HXdWC7H7Pgmyd9LvU9mNLt/o0wCMOY8=; b=V9nEkR18Q4HQDLnpo9xCE/XzA5Y9UK0DqjOr0RnuDFo92uK1eH64B1WKSGeC5gNthF wbQC15m9Jfq/5VTQfOa4fF4TBk4qzq/+OM3yIULQPPF0/K7Fdqts6BllsabljSiz8ehc TePdMTyWz3WqgKT7/OfY1C/yOu1j0tRgiGxkNodOAxwik0X7HjTvYWyV7CFSMyQuijoA CCgQNO3hTQDobQ1GnzF5O2dOV0ILXgljlEJSEfR2g1oG33L0KaYP1uPOWr5UjWDmVvqK grPrwJqise6uMV12B116AWbf2K+LqX64p5ybXWew35LPbEy1sv2tY2IQFqdbv3jcBlG6 nHwA== 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: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=GaAsED2+7mG3HXdWC7H7Pgmyd9LvU9mNLt/o0wCMOY8=; b=QZB8x939ZFk9t7rFk/b0FdhIbkZ+kW7cIChAoJrH8AFnlbwAWLBwoBQxjDMY00ojCE 3xSctr6nzAESsOsziGouaCnaw/DTpPzYkE7LBHcWTTQ8iY0MnzmtjzJ0nC44e2fn3Igb B75OTeq+PbFR3+wkv5Uj3JCw6oWpFk5aDwhdEfBp1ag/jNHwyXCtmD7YXAvuncuXqVaC d1iRgzsg1iv8mndNZOPKE+acW4p9HtpDzL7e86lWGEXVpFox4S7Yp3F0694beIxGdo+r zBUNBz6bnUsEYIX8qZ/kuhxdf/yMMWA7UJ3YV9vZd9xsHXWMrTuGwecAz80irIBlrhJ1 v9Hg== X-Gm-Message-State: ALoCoQkTQa82QQWlaAiA+JU20c3p2WuhfJ+qYaaXMxGCk6mg6AKEWHLinLd35Q49aNzyGvgOF0Ye X-Received: by 10.182.18.8 with SMTP id s8mr20574824obd.21.1409719075770; Tue, 02 Sep 2014 21:37:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.199 with SMTP id qs7ls2982593igb.14.canary; Tue, 02 Sep 2014 21:37:55 -0700 (PDT) X-Received: by 10.50.2.6 with SMTP id 6mr548125igq.10.1409719075053; Tue, 02 Sep 2014 21:37:55 -0700 (PDT) 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:12643 Archived-At: ------=_Part_5899_1473812941.1409719073552 Content-Type: text/plain; charset=UTF-8 As a generalization of std::is_standard_layout, how about an std::is_offsetof_compatible? Requiring standard-layout in order to use offsetof is too restrictive; almost all implementations could support offsetof in more situations than the Standard's "standard-layout" definition allows. Standard-layout makes stricter guarantees than are needed for offsetof itself to work. Given certain caveats, and most implementations, offsetof can work with any class that does not use virtual inheritance. An implementation that isn't compatible wouldn't have to allow it, though standard-layout would be the minimum support. The boundary conditions would be either implementation choices (such as using offsets of a base class on derived classes is defined when the base is the first base class) or entirely undefined (using offsets on virtually-derived classes). Note that merely reordering elements, such as to coalesce all private members together, isn't enough to say that offsetof isn't compatible. Whether element order matches memory order is orthogonal to the ability to reference elements using offsets into a char array. With this, there could also be member_pointer_to_offset and offset_to_member_pointer library functions that work with compatible classes. 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_5899_1473812941.1409719073552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a generalization of std::is_standard_layout, how about an std::is_offsetof_compatible= ?  Requiring standard-layout in order to use offsetof is too restrictive; almost all i= mplementations could support offsetof in more situations than the Standard's "standard-layo= ut" definition allows.

Standard-layout makes stricter guarantees tha= n are needed for offset= of itself to work.  Given certain caveats, and most implementat= ions, offsetof c= an work with any class that does not use virtual inheritance.  An impl= ementation that isn't compatible wouldn't have to allow it, though standard= -layout would be the minimum support.  The boundary conditions would b= e either implementation choices (such as using offsets of a base class on d= erived classes is defined when the base is the first base class) or entirel= y undefined (using offsets on virtually-derived classes).

Note that = merely reordering elements, such as to coalesce all private members togethe= r, isn't enough to say that offsetof isn't compatible.  Whether element order matches = memory order is orthogonal to the ability to reference elements using offse= ts into a char a= rray.

With this, there could also be member_pointer_to_offset and offset_to_member_pointer library f= unctions that work with compatible classes.

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_5899_1473812941.1409719073552-- .