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: 
 border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 13 Jul 2014 12:24:24 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: why Ada type casting is different from other languages?
 newType(value) vs. (newType)value
References: <lpsoun$5b0$1@speranza.aioe.org>
 <c2f070Ffne5U1@mid.individual.net>
 <1cqb2iccfzox2$.f74qor2zqcub.dlg@40tude.net>
In-Reply-To: <1cqb2iccfzox2$.f74qor2zqcub.dlg@40tude.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <53c25e58$0$6665$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 13 Jul 2014 12:24:24 CEST
NNTP-Posting-Host: 5644f1ab.newsspool3.arcor-online.net
X-Trace: DXC==JbcK9lM3?4LNKYb?b>076McF=Q^Z^V384Fo<]lROoR18kF<OcfhCO;
 gWaom=?WBl2PCY\c7>ejV8QQfIKUEA2Z7FTdGljDJdJ6
X-Complaints-To: usenet-abuse@arcor.de
Xref: number.nntp.dca.giganews.com comp.lang.ada:187560
Date: 2014-07-13T12:24:24+02:00
List-Id: <comp.lang.ada>

On 13.07.14 11:08, Dmitry A. Kazakov wrote:
> On Sun, 13 Jul 2014 12:01:26 +0300, Niklas Holsti wrote:
>
>> Ranting aside, the C form has the clear disadvantage that one must
>> remember precedence rules to understand what is being converted:
>>
>>    is (float)i the same as (float)i + j,
>>    or is it the same as (float)(i + j) ?
>>
>> In the Ada form, type(value), the parentheses nicely enclose the value
>> to be converted. Much better IMO.
>
> BTW, in Ada one need not remember precedence rules because all expressions
> where unary operation might be ambiguous are illegal:
>
>     not X and Y -- Illegal, brackets required
>     X and not Y -- That's OK


The bit about ambiguity is not meant to be a statement of a general truth?
Before the fact, is the following text unambiguous for a human reader?

    X : constant := 16#7F_FF#;

begin

    if not X in Unsigned_16'Range then  -- legal, brackets suggested
       raise Program_Error;
    end if;

(Yes, there are better ways to write this, but since you must know
them, the latter requirement wipes out some of the alleged advantage of Ada
in this regard, I think.)

I have read plausible justifications for the choice of type conversion syntax
of both Ada and C. But conceptually, I think that C++ has found a better
solution. It is more Ada like, perhaps, whenever C++ suggests to explicitly
state the intent:

    static_cast<float>(i + j)

seems pretty clear (even when it might be unnecessary). Ada's and C's
overloading of round brackets for several different things might be
tempting at first, but the temptation ceases once ease of understanding
the differences is considered more important. Of course, that's the time
when the phrase "every competent programmer ..." will be heard from all
camps, and then the ones about < and > !