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: a07f3367d7,5afd69f1373c41cc
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,CP1252
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!ramfeed-1.ams.xsnews.nl!feed.xsnews.nl!border-3.ams.xsnews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!weretis.net!feeder2.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 02 Jul 2009 17:50:14 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Interfacing with C ; an ununsed fields dilemma
References: 
 <faaa30f7-d69b-4c73-ae70-9b01d3804077@d32g2000yqh.googlegroups.com>
 	<5a416858-4a52-412d-8051-6dadb5eadb2c@t21g2000yqi.googlegroups.com>
 	<d8ed3a51-0762-4e1e-b5a9-13b727dfc76c@l31g2000yqb.googlegroups.com>
 	<4a4ca38d$0$31340$9b4e6d93@newsspool4.arcor-online.net>
 <9d9b5fe7-c990-4c67-9c6e-1dacd484b296@t21g2000yqi.googlegroups.com>
In-Reply-To: 
 <9d9b5fe7-c990-4c67-9c6e-1dacd484b296@t21g2000yqi.googlegroups.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Message-ID: <4a4cd737$0$31877$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 02 Jul 2009 17:50:15 CEST
NNTP-Posting-Host: 6c982ed8.newsspool3.arcor-online.net
X-Trace: 
 DXC=h23<Bm<ma5n016@cHD@m;jMcF=Q^Z^V3h4Fo<]lROoRa^YC2XCjHcbibiGi;SFJC@g;9OJDO8_SKfNSZ1n^B98ijSdLNc:]jPYg
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:6804
Date: 2009-07-02T17:50:15+02:00
List-Id: <comp.lang.ada>

Hibou57 (Yannick Duch�ne) schrieb:
> On 2 juil, 14:09, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> In case you are using current Ada, have you considered
>> making your type limited an use a "construtor function"?http://www.adacore.com/2007/05/28/gem-3/
> 
> But this still allow an automatic instantion without the required
> initialization.

No, if you use (<>) in the public view of the type as explained
in Gem #3 then users will have to initalize explicitly;
the only possibility to declare an object of the type, then,
is together with call a public "constructor function" to do
the initalization in place.



> I oftenly feel the same, and I would probably have choose this design
> if I were to create a specification from the ground up (perhaps I'm
> driven into error by the existing C interface). Reading it in this
> context, make me think that perhaps I should use a more abstract
> specification, thus make these types (there are numerous records of
> the same kind) fully private and define numerous accessors to each of
> these types. I will no more bother to declare these unused fields, as
> this would be now in the private part.

Private or not, "uncontrolled" unused bits may have an impact
on future translations (see the reasons Maciej
has listed).  In the private part of a package, then,

(a) users of its public part will not need to consider
the record's representation,

(b) but you can be specific (open, honest, ...) about the
components not used, and whether or not you want them
to be initialized by default etc.