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,901038687c38f61c
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!proxad.net!freenix!usenet-fr.net!teaser.fr!noos.fr!proxad.net!proxad.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Idiom for a class and an object in Ada
Date: 20 Oct 2004 06:39:46 +0100
Organization: Pushface
Sender: simon@smaug.pushface.org
Message-ID: <x7v4qkqrlr1.fsf@smaug.pushface.org>
References: <M3Ocd.237$5i5.72@newsread2.news.atl.earthlink.net>
 <mailman.25.1098102395.10401.comp.lang.ada@ada-france.org>
 <FH_cd.575$KJ6.64@newsread1.news.pas.earthlink.net>
 <u4qkrtgn2.fsf@earthlink.net>
 <s78dd.2345$ta5.833@newsread3.news.atl.earthlink.net>
NNTP-Posting-Host: pogner.demon.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.demon.co.uk 1098251170 17103 62.49.19.209 (20 Oct 2004 05:46:10
 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Wed, 20 Oct 2004 05:46:10 +0000 (UTC)
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
Xref: g2news1.google.com comp.lang.ada:5490
Date: 2004-10-20T06:39:46+01:00
List-Id: <comp.lang.ada>

Marin David Condic <nobody@noplace.com> writes:

> What is the preferred Ada idiom for something like this?

I'm not so hung up as Matt about people using the word class (in
conversation; I agree about use in Ada code). But I have to say,
what's wrong with Matt's suggestion? seems to answer all your needs as
stated so far ..

One thing, having "static" (I suppose you mean, created at library
level during elaboration, whatever the words are ..) can cause
elaboration order problems if the things being created are tasks. I
could say that more strongly, "are practically guaranteed to cause
elaboration order problems"! I guess this is unlikely to happen with
hardware interfaces?? Not sure if using dynamic allocation in
elaboration would help? -- probably not, need some sort of Initialize
procedure.

package body ADC is

   task type T is ...
   type T_P is access T;
   Converter_1 : T_P;

begin

   Converter_1 := new T (...);

end ADC;