220 7752 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: 2 Type-Traits Proposals: Standard Transformations and More Array Transformations Date: Thu, 14 Nov 2013 04:48:13 -0800 (PST) Lines: 108 Approved: news@gmane.org Message-ID: References: <49883229-58c3-4c26-bbc8-492ebd7e93dd@isocpp.org> <2CC6D6A0-D78D-4FE7-BBB0-E3CC951E87E4@hsr.ch> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_340_17799915.1384433293218" X-Trace: ger.gmane.org 1384433292 10386 80.91.229.3 (14 Nov 2013 12:48:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Nov 2013 12:48:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBDUNSOKAKGQEJ2KAPMA@isocpp.org Thu Nov 14 13:48:17 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f71.google.com ([209.85.128.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VgwLI-0003XM-85 for gclcip-std-proposals@m.gmane.org; Thu, 14 Nov 2013 13:48:17 +0100 Original-Received: by mail-qe0-f71.google.com with SMTP id 1sf3642291qec.10 for ; Thu, 14 Nov 2013 04:48:15 -0800 (PST) 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=HLlQ+eSwOLcaqK8kuviOrCbDJ1mh5HB+LKMf+Ve6gbY=; b=HNFal7iXfBRgypwChEQheNwENFIHjMV29zt4ZGkycItbd42J6p6o/L8V4esnlSiEdz 7CilJk7WFJCy9w43v5Eyoonm3lgLBNrtrS8MnC2lPk3qeYY1pOjey/Vy+2C3UYlfVKIK /swdExATVgzK+PUiJnilGOrB1P57EITQYbD8GOlggR7vxN1WV7f9sMFvFfE3alhk1LgU k3iclVy2Z/W9dqqRhzMoA9yBper7Lyp20lRvzQuyOyczmpM4M18eeJwW5ytWjmE0D/zY MkDvMq+kUXiwLZhHVLnnU/6d7UWgJYI8W1quql5/yvz+O8E/wzgU97k/6v8RnPXoljEP OfRA== 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=HLlQ+eSwOLcaqK8kuviOrCbDJ1mh5HB+LKMf+Ve6gbY=; b=O7Nq4wdZ8c1bduelbmuNHtOiPFfJYt+jKUdCfTLSRyAQ3QANfpV5F7f0W+4UH5rPiW 7ApPq98kPzujxNoDKWExoQGmyl7FixIgPQasBH05eM3al2mLYA6r0Tc/1TWbiJojUsvP V0yXcJOJ5yCfAVgrgxdNaREtIWkOEYGJtlY4t5NXZHQv/HwS4Cfinhz9G03tfyy37ljC EqEAOTUbn/iShb0vIh3aL58AzdF5DnUDdetI6Nb7FDRHU1cmTGg8sx5RuyKOMFV3doUm ApvpYafgBASzB4U+AeLMwbCH6wTQ100ydG5De/iMl4YmuRD7AlJpQ5GNK94dTE+cTW2U 4MTg== X-Gm-Message-State: ALoCoQk7wj2GEGa5VvuMsfJcnzuPkbIBEEVGocaNXMjpe2Xn0XQSn04hVVp/3qCec7+3zFEH/ZGK X-Received: by 10.236.94.39 with SMTP id m27mr696696yhf.54.1384433295382; Thu, 14 Nov 2013 04:48:15 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.164.200 with SMTP id ys8ls1351060igb.23.gmail; Thu, 14 Nov 2013 04:48:14 -0800 (PST) X-Received: by 10.50.9.33 with SMTP id w1mr32231iga.12.1384433294223; Thu, 14 Nov 2013 04:48:14 -0800 (PST) In-Reply-To: <2CC6D6A0-D78D-4FE7-BBB0-E3CC951E87E4@hsr.ch> X-Original-Sender: andrewtomazos@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:7752 Archived-At: ------=_Part_340_17799915.1384433293218 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, November 14, 2013 1:11:43 PM UTC+1, PeterSommerlad wrote: > > On 14.11.2013, at 12:52, Daryle Walker > > > Should bool be added? (There is no mention if it has to shadow another > integer type.) > I believe bool won't have an underlying type and should not be added. > I agree. bool is quite a special type and should not be considered to have an underlying type. > wrt char > I believe it might be nice to determine if char is signed or unsigned. but > couldn't that already be achieved by is_same_t() ? > No, it could not. char, signed char and unsigned char are distinct fundamental types, so is_same is always false and is_same is also always false. Given the restrictions on the relationships between char, signed char and unsigned char in [basic.fundamental]/1 - it seems reasonable to consider char to have an underlying type of exactly one of signed char or unsigned char, so I would be in favor of extending underlying_type to determine this as Daryl proposes: A char, a signed char, and an > unsigned char occupy the same amount of storage and have the same > alignment requirements (3.11); that is, > they have the same object representation. For character types, all bits of > the object representation participate > in the value representation. For unsigned character types, all possible > bit patterns of the value representation > represent numbers. These requirements do not hold for other types. In any > particular implementation, a > plain char object can take on either the same values as a signed char or > an unsigned char; which one is > implementation-defined. -- --- 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_340_17799915.1384433293218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, November 14, 2013 1:11:43 PM UTC+1, PeterSomm= erlad wrote:
On 14.11.2013, at = 12:52, Daryle Walker <dar...@gmail.com>
> Should bool be added? (There is no mention if it has to shadow ano= ther integer type.)
I believe bool won't have an underlying type and should not be added.

I agree.  bool is quite a special= type and should not be considered to have an underlying type.
&n= bsp;
wrt char
I believe it might be nice to determine if char is signed or unsigned. = but couldn't that already be achieved by is_same_t<char, unsigned char&g= t;() ?

No, it could not.  char, signed char = and unsigned char are distinct fundamental types, so is_same<char, unsig= ned char> is always false and is_same<char, signed char> is also a= lways false.

Given the restrictions on the relatio= nships between char, signed char and unsigned char in [basic.fundamental]/1= - it seems reasonable to consider char to have an underlying type of exact= ly one of signed char or unsigned char, so I would be in favor of extending= underlying_type to determine this as Daryl proposes:

<= blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border= -left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style:= solid; padding-left: 1ex;">A char, a signed char, and an
unsigned char = occupy the same amount of storage and have the same alignment requirements = (3.11); that is,
they have the same object representation. For character= types, all bits of the object representation participate
in the value r= epresentation. For unsigned character types, all possible bit patterns of t= he value representation
represent numbers. These requirements do not hol= d for other types. In any particular implementation, a
plain char object= can take on either the same values as a signed char or an unsigned char; w= hich one is
implementation-defined.

--
 
---
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-proposals/<= /a>.
------=_Part_340_17799915.1384433293218-- .