220 30489 <9df8fc29-d366-4168-9c65-0cae9ffd76d0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: enum_cast proposal Date: Wed, 11 Jan 2017 12:21:41 -0800 (PST) Lines: 139 Approved: news@gmane.org Message-ID: <9df8fc29-d366-4168-9c65-0cae9ffd76d0@isocpp.org> References: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> <58750288.5080004@gmail.com> <587512E1.1050708@gmail.com> <216fe26f-2155-42b4-9350-cb4c7f4e9f4a@isocpp.org> <615ad4bb-f321-4ace-8dd1-335e97b6c7a0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6864_1207080978.1484166101641" X-Trace: blaine.gmane.org 1484166133 5075 195.159.176.226 (11 Jan 2017 20:22:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jan 2017 20:22:13 +0000 (UTC) Cc: mwoehlke.floss@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBV5H3LBQKGQEEHICFWI@isocpp.org Wed Jan 11 21:22:08 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRPOt-0006sK-7Q for gclcip-std-proposals@m.gmane.org; Wed, 11 Jan 2017 21:21:39 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id 127sf799402286pfg.5 for ; Wed, 11 Jan 2017 12:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ynFtlC6EQsZCF9sEm/60MxZu8zAqfO3qWXB+YFqIkfo=; b=sdHV/0I06TyD832mzSPlN5+2NFXiJYi/dHvVKRFVvPTz/qnjztY+3HCpodD2EyDNuP xyn4LJsoO0jNiEl4WqhOiHWCshjPnlWdQHW4/03GzRCaocTlNPKEI7Ls1kAhQ6374A4D sAI6DhjWE9WDQHpWpIJzO0Xpd2fz9eykiSg1lzHOmHA8XILbIJDMUfYx50x12DwkgVQN gmFu88mZzNEApWOkpHLvKA07uDhp029QNhodc/Ysy83WJT7j9kzYZMhG/S/gxn4V0eV+ 4nozoZIAu0qmLKjiM2fmeFqtpWEgM+aE8WCWbmU27E3j+YHvKbEB4cuPHZW/jyiImhZ3 6E9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ynFtlC6EQsZCF9sEm/60MxZu8zAqfO3qWXB+YFqIkfo=; b=pb/GvXn2Kx4EYx1f8+ophSw6/lb4cLTmCRP3CsHrcypY/0jE4QE+xqHpeZNOdPkd7S dSDIwUe1VJ5fKezt88pkM2zbDmE6uPK7v5o+iOScT9yXXHu8Zp8ebhSCKmvPJaH/+3G1 +BTPkCbzlxUfilt65I4HPjKkadiuDSX4ynH8vAZto72H4jI2OD8wpw1T0HzRonR/DGR0 wK7GXNW/xH2ptOG5rkMtnsXzhJ1YSvUwYC6INSUip7tnkbxY/A97cXCtcl0hpcSoFwMg 9CWgoD/M76XNhlcdj8o4V4zKXgc+H3g0gIpoiAH463dyApdyUtT8t2KOhFfE5Lj8zj0R 8OBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=ynFtlC6EQsZCF9sEm/60MxZu8zAqfO3qWXB+YFqIkfo=; b=ekrCF5ZnL5fqYz+gM/daZn/toH9StgNbVXeiKHAThAODYlOl67bAMnjK9PgP4rK2eD tD2t2iA21RHPVn9JmdVdgl0EXyWEF7VgNgEpfM6iKuVxXJ+R285JPsqFsihnHhSTBEFz 4TVjrsldf+/W5tUsxSYccNrD2zKHp1ZbaKPL6qJdqjkVA88d4xUvWJDeYktgQgWbRV0s 6nI1vxPMDuKY2wcV7iPdpiOPzuG0pmC6WCYTBo7QIc7PfV22pYknr9shId1+bOfdE/w+ 4TEAJh6Rp73M8D4RhNVzi6nqBIQgyV9ZYun0BjE2rO4K1ns106G5e6cGa8Q15E4JdeDT cNbg== X-Gm-Message-State: AIkVDXJ0Zb/4oOCyICD+IAWS1RfjiYld2DDxQhi1WuTOUKh0XZ7BwQmTmKkj5asKHM0KaQ== X-Received: by 10.99.113.75 with SMTP id b11mr3793934pgn.162.1484166103537; Wed, 11 Jan 2017 12:21:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.3.235 with SMTP id f98ls4765016otf.16.gmail; Wed, 11 Jan 2017 12:21:42 -0800 (PST) X-Received: by 10.157.12.165 with SMTP id b34mr1099762otb.2.1484166102908; Wed, 11 Jan 2017 12:21:42 -0800 (PST) In-Reply-To: <615ad4bb-f321-4ace-8dd1-335e97b6c7a0@isocpp.org> X-Original-Sender: gmisocpp@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:30489 Archived-At: ------=_Part_6864_1207080978.1484166101641 Content-Type: multipart/alternative; boundary="----=_Part_6865_383276369.1484166101642" ------=_Part_6865_383276369.1484166101642 Content-Type: text/plain; charset=UTF-8 > > It would then create a string of the info an give you an exception object >> back that you could then throw or do whatever with. >> so given namespace my { enum class traffic_light { stop, careful, go }; } >> } >> make_enum(3) would produce an exception where what() would >> return an array with >> '3 is not a valid value for my:;traffic_light'. >> >> I think this is desirable to just having either an >> std::bad_optional_access with what string exactly in? >> > > Sure, but... I'm not arguing against what you suggested. Indeed, I was > specifically arguing against the idea that generic exceptions (whether > `bad_optional_access` or ` bad_expected_access`) were a good idea. > > Are you sure you intend to be replying to me? > Yes I intended to reply to you, but you are right it would have been better to reply to someone in less agreement for what I want to know. > > std::range_error was ok with me as that could be constructed with a string >> and the type more reflected the problem. >> >> What's wrong with this in your opinion? >> > > I see no reason to use a generic exception when an exception type specific > to enumeration casting could be employed instead. It's ultimately more > descriptive and obvious what's going on. > > A bad_enum class would have allowed an internal char buffer of fixed size >> to be used because we know what length string worst case we are storing >> here if that was the problem. >> > > How? An enumeration can be a member of any number of namespaces and/or > classes. Thus its name can be quite long. While any particular > implementation could use its internal compiler limits to give it a maximum > length, that length would be pretty huge, tens if not hundreds of kilobytes > long. > > Better to dynamically allocate it than to throw such a gargantuan object > around. > If it had to bet truncated it wouldn't be the end of the world (one hopes!), I was thinking about avoiding dynamic allocation, but you are probably right that's a bad idea anyway. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9df8fc29-d366-4168-9c65-0cae9ffd76d0%40isocpp.org. ------=_Part_6865_383276369.1484166101642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
It would then create a string of the info an give you= an exception object back that you could then throw or do whatever with.
so given namespace my { enum class traffic_light { stop, careful, g= o };=C2=A0} }
make_enum<traffic_light>(3) would produce an = exception where what() would return an array with
'3 is not a= valid value for my:;traffic_light'.

I think t= his is desirable to just having either an std::bad_optional_access with wha= t string exactly in?

Sure, but... I'm = not arguing against what you suggested. Indeed, I was specifically arguing = against the idea that generic exceptions (whether `bad_optional_access` or = ` bad_expected_access<E>`) were a good idea.

Are you sure you = intend to be replying to me?

Yes I=C2=A0intended to reply to you, but you are right it would have been= better to reply to someone in less agreement
for what I want to = know.
=C2=A0
<= div>
std::range_error was ok with me as that could be constructed with a string= and the type more reflected the problem.

What'= ;s wrong with this in your opinion?

I see = no reason to use a generic exception when an exception type specific to enu= meration casting could be employed instead. It's ultimately more descri= ptive and obvious what's going on.

A bad_enum=C2=A0class would have all= owed an internal char=C2=A0buffer of=C2=A0fixed size to be used because we = know what length string worst case we are storing here if that was the prob= lem.

How? An enumeration can be a member of any= number of namespaces and/or classes. Thus its name can be quite long. Whil= e any particular implementation could use its internal compiler limits to g= ive it a maximum length, that length would be pretty huge, tens if not hund= reds of kilobytes long.

Better to dynamically allocate it than to th= row such a gargantuan object around.

<= div>If it had to bet truncated it wouldn't be the end of the world (one= hopes!),
I was thinking about avoiding dynamic allocation,=C2=A0= but=C2=A0you are probably right that's a=C2=A0bad idea anyway.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9df8fc29-d366-4168-9c65-0cae9ffd76d0= %40isocpp.org.
------=_Part_6865_383276369.1484166101642-- ------=_Part_6864_1207080978.1484166101641-- .