From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: 'Size hack for enumerated types
Date: Tue, 8 Jul 2014 15:56:25 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <lphltp$so0$1@loke.gir.dk>
References: <lp9nc6$no3$1@speranza.aioe.org> <lyk37rcwah.fsf@pushface.org>
 <lp9t79$5pj$1@speranza.aioe.org> <lp9tj0$6ii$1@speranza.aioe.org>
 <ly38eefbkf.fsf@pushface.org> <lpckgk$6a8$1@speranza.aioe.org>
 <lpcm62$nug$1@dont-email.me> <lpeg5s$f6r$1@speranza.aioe.org>
 <ly7g3pdreg.fsf@pushface.org> <lpevj6$nai$1@speranza.aioe.org>
 <lytx6scowp.fsf@pushface.org>
 <d2272863-c1e4-4130-a767-eb6fdd61e14b@googlegroups.com>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1404852986 29440 69.95.181.76 (8 Jul 2014 20:56:26 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 8 Jul 2014 20:56:26 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:20813
Date: 2014-07-08T15:56:25-05:00
List-Id: <comp.lang.ada>

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:d2272863-c1e4-4130-a767-eb6fdd61e14b@googlegroups.com...

<Various interesting stuff elided>

...
>Conversely, ISO 9899 C2011 does not allow this new language feature, as
>shown in section 6.4.4.3 on page 67 of 
>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf.
>So perhaps ARG needs to seriously consider adding Convention => C_Plus_Plus 
>or
>whatever its syntax would be to handle the increasing divergence between 
>C++ and
>C standards.

We've previously argued about a convention C_Plus_Plus or the like. We 
decided not to go there for two reasons:
(1) C_Plus_Plus is unspeakable ugly; C++ is bad syntax. We could get no 
agreement on the name here.
(2) We don't want to support convention C_Plus_Plus (or whatever it ends up 
being called) on tagged types. Doing so insists that all tagged types are 
represented as C++ does. That might be OK for GNAT (where the C++ compiler 
is maintained in tandem), but it wouldn't work very well for any target 
where the C++ compiler is from a separate organization. (I'm not interested 
in chasing Microsoft on this, thank you.) In addition other information is 
needed which tends to vary between C++ implementations. We didn't think that 
we could come up with a mechanism that was sufficiently abstract to allow 
portability between implementations.

The ultimate decision was that we wouldn't define a C++ convention.

Implementations are supposed to have a dedicated convention for every 
compiler they support. So if the C++ compiler does something different than 
the C compiler, then the *implementation* should have a separate convention 
for the C++ compiler. The language need not get involved, as portability 
between implementations can't be guaranteed anyway.

I'm sure we'll revisit this someday, but I'm not sure that any other 
conclusion is possible.

                                     Randy.