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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ab1d177a5a26577d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: What's wrong with C++? Date: Thu, 17 Feb 2011 21:51:37 +0100 Organization: A noiseless patient Spider Message-ID: <87pqqqz8o6.fsf@ludovic-brenta.org> References: <1ee1a434-4048-48f6-9f5e-d8126bebb808@r19g2000prm.googlegroups.com> <4D5C1824.3020509@obry.net> <21443638-5ec6-49d4-aafe-6fbc1e59daba@r19g2000prm.googlegroups.com> <87d2371e-af91-4d6a-8d5b-3ddb972d84fd@k17g2000pre.googlegroups.com> <87zkpuze5e.fsf@ludovic-brenta.org> <4d5d791f$0$17330$882e7ee2@usenet-news.net> <87vd0izba1.fsf@ludovic-brenta.org> <4d5d8112$0$17330$882e7ee2@usenet-news.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="h3lW1vp1zj3M9XETvzOiKw"; logging-data="7923"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+nSq8OxQK5O80j+B0tsdIN" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:LgUXyRhs5jDyC54jhXH1adO/AS8= sha1:pjfVJdoosW8mbSLQag6HmNhJ/m8= Xref: g2news2.google.com comp.lang.ada:18337 Date: 2011-02-17T21:51:37+01:00 List-Id: Hyman Rosen writes: > On 2/17/2011 2:55 PM, Ludovic Brenta wrote: >> Hyman Rosen writes: >>> And what does it mean for something to be >>> "really an integer"? >> >> Simple: integers have arithmetic, enumeration values don't. > > C and C++ enumerations don't have arithmetic. > They do convert automatically to integers, but > they don't automatically convert back. Actually they do in the example you provided: struct DamageType { enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 }; }; DamageType::E what_my_dragon_can_do = DamageType::E( DamageType::Acid | DamageType::Poison ); In this example, the two enumeration values are automatically promoted to integer (which has arithmetic) ORed, then the result is automatically converted back to the type DamageType::E. Except that the value of what_my_dragon_can_do is not one of the values defined in the type. >>> Ada 'Pos and 'Val attributes certainly give the illusion that Ada >>> enumerators are integers too! >> >> If you mean to say that Ada provides features for unsafe programming, > > Not at all, merely that it's easy within the language to convert back > and forth between enumerations and integers. Nothing unsafe about it. Actually, there is something unsafe about it. Ada programmers have both integers and enumerations; they choose enumerations when arithmetic does not make sense. Converting enumerations to integers provides arithmetic, which is unsafe for these types. Actually, the only really dangerous part is converting back to the enumeration type using 'Val. >> Now try this and see your "illusion" shattered by reality: >> type E is (A, B, C); >> B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error > > What illusion? I certainly know that Ada checks and C doesn't! I meant the intentional illusion that you can treat enumerated values like integers; you can't. > Oh, and don't Ada implementers go insane because enumerations are > supposed to provide the illusion of being consecutive even in the face > of representation clauses which give them arbitrary underlying values? The consecutiveness is embedded in the operations 'Pred and 'Succ, not by 'Pos and 'Val. It is true that validity checking is much more difficult when the set of valid values is disjoint. But it is a good thing that compilers provide this functionality, instead of programmers having to re-implement it each time. > Also, I don't know if you did this intentionally or not, but you > redefine the name B as a variable when it is already an enumeration > literal. Do I recall correctly that this works because enumeration > literals are "really" functions returning their value, and functions > can be overloaded? That was not intentional; my code doesn't compile. Thanks for pointing that out. -- Ludovic Brenta.