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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: operation can be dispatching in only one type
Date: Mon, 23 Nov 2015 15:59:29 +0100
Organization: A noiseless patient Spider
Message-ID: <n2v9g3$ifi$1@dont-email.me>
References: <b4aee46c-7dbb-4906-99c5-f4f8e9876fc6@googlegroups.com>
 <1e4hyjazuvi88.159qsn7u0y067$.dlg@40tude.net>
 <817c092d-4c49-4b09-a116-6d27d4d20291@googlegroups.com>
 <127g5diox4xef$.1bc0ja7q2xobo.dlg@40tude.net>
 <26b461b8-3a2e-4fee-906f-673c7ff22543@googlegroups.com>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 23 Nov 2015 14:57:07 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="18930"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19iTkwHCb0Gz9FlTvDYLJPoiSpqOWHA+wQ="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <26b461b8-3a2e-4fee-906f-673c7ff22543@googlegroups.com>
Cancel-Lock: sha1:AndGFV0CEzoo9zsZeKInFjPrtyY=
Xref: news.eternal-september.org comp.lang.ada:28507
Date: 2015-11-23T15:59:29+01:00
List-Id: <comp.lang.ada>

On 23.11.15 15:16, Serge Robyns wrote:
> I do feel very frustrated with regards to the Ada idiosyncrasies

To me, 'Class means openly stating the intent:  C++ does many things
"automatically" when possible. Which is why you can show excellence
when you can tell how. (In case of interpreting compiler diagnostics,
say.)

An example is when different types inheriting from t_balance
are placed in a container

   map<..., t_balance>

If class t_balance_A : public t_balance, then the compiler may
let you place an object declared of type t_balance_A in the map
- you'd think. But it turns out to silently have become a t_balance.
Trying a fix

   map<..., t_balance&>

or similar, chances are that after this, a long list of errors
will appear, about operators, value initialization, type differences
etc.

If Ada does fewer things "automatically", thus requesting that you
specify type T'Class when you mean things class-wide, this reduced
malleability of the meaning of names may become an advantage.
A consequence is less effort at understanding what a name is
referring to, and an increase of  errors-related productivity,
as no automatic choice needs to be unfolded in the diagnostic messages.

    T'Class   means   for all types with T a progenitor
    T         means   T, only.

The 'Class thing marks the place where there could be a variation
in run-time dispatching at all.

Of course, any competent C++ programmer will always do the right
thing, which is not using T where a T* or T& is in order.