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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Instantiations of a generic with often encountered arguments
Date: Mon, 27 Nov 2017 09:41:52 +0100
Organization: Aioe.org NNTP Server
Message-ID: <ovgj4h$iqs$1@gioia.aioe.org>
References: <ovd0dt$hmi$1@gioia.aioe.org> <ovdvck$2r4$1@gioia.aioe.org>
 <ovfrna$1hkd$1@gioia.aioe.org>
NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.8.2
Xref: reader02.eternal-september.org comp.lang.ada:49174
Date: 2017-11-27T09:41:52+01:00
List-Id: <comp.lang.ada>

On 27/11/2017 03:02, Victor Porton wrote:

> I received what seems two opposite opinions on my question.

Opinions meant to be different...

> Please state the reasons.
> 
> I am now in analysis-paralysis of whether to define instantiations for often
> encountered types in advance (globally) or immediately before use.

The latter is C++ policy which is acceptable because in C++ there is no 
lingering effects of an act of instantiation. Therefore C++ can deploy 
automatic instantiation and need not to care how frequently you do so. 
In Ada instantiation has consequences. Consider:

generic
    ...
package Printer is
    procedure Print (Text : String);
private
    task Monitor is
       entry Do_Print (Text : String);
    end Monitor;
end Printer;

Each instance produces a new task.

"Don't multiply entities beyond necessity"

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de