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,6cbbf1799c1dc6da X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 18 Jan 2006 15:49:37 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <43CCAB76.6050907@mailinator.com> <43CE20CF.4080801@mailinator.com> <43CE65E8.1040307@mailinator.com> Subject: Re: Ada 2005 box (<>) rules in default values Date: Wed, 18 Jan 2006 15:54:18 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-t7GJbLlmXE8fe3MFXqX7d3mg+0BrhP8+FPeSYUf8Wtd5aOGgJVoPDtHqyMNIIiMbY8nm1UO67kpWN7c!7Qp/nY5ovpinMsd2c2EuZkzwawjqqPC23G4q7RhLMhHvyf1gDkhCpM6jaopPExCbBw/jSUMcT2/x X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:2525 Date: 2006-01-18T15:54:18-06:00 List-Id: "Alex R. Mosteo" wrote in message news:43CE65E8.1040307@mailinator.com... > Jean-Pierre Rosen wrote: > >> I'm sorry the example I wrote was made up on the way. Upon reflexion, > >> I think I always saw this problem in relation with Controlled types. > >> Here's an example which fails with my current GPL: > >> > >> with Ada.Text_IO; use Ada.Text_IO; > >> with Ada.Finalization; use Ada.Finalization; > >> > >> procedure Bug2005 is > >> > >> type Thing is new Controlled with record > >> First_Component : Integer; > >> Second_Component : Integer; > >> Third_Component : Integer; > >> end record; > >> > >> procedure Initialize (This : in out Thing) is > >> begin > >> This.Third_Component := 5; > >> end Initialize; > >> > >> type Superthing is record > >> Innerthing : Thing; > >> end record; > >> > >> Blah : Superthing := (others => <>); > >> Bleh : Superthing; > >> Blih : constant Superthing := (others => <>); > >> Bloh : constant Superthing := (Innerthing => <>); > >> Bluh : constant Superthing := (Innerthing => > >> (Controlled with others => <>)); ... > > That's totally different. Third_Component is not default-initialized, it > > is initialized by the Initialize procedure. And Initialize is /not/ > > called on aggregates. > > Yes, I said something about it in the part not quoted. But what about > the other RM paragraphs I've quoted? Am I misinterpreting them? Really > exists the problem I'm suggesting? No, but perhaps there is something wrong with your interpretation of them. As J-P said, Initialize is never called for an aggregate. But it should be called for <>; 7.6(10) was reworded to ensure that happens. (BTW, the wording "initialized by default" is a defined term in Ada 200Y; it means to follow the rules in 3.3.1. We found that the rules for this were duplicated all over the standard, and they were not quite right in many places; clearly these need to be the same everywhere, especially the bizarre stuff about ordering.) So, it's necessary to look at what "others" represents here. As you point out: Blih : Superthing := (others => <>); and Bloh : Superthing := (Innerthing => <>); are the same. Clearly, Initialze should be called in these cases (the aggregate is on Superthing, not Thing). If you had: Blop : Thing := (others => <>); then Initialize would not be called. But that's not the case here. As you pointed out, this certainly ought to work properly when Thing is private; the end user shouldn't need to know or care how the type is implemented. And certainly using <> somewhere shouldn't break abstractions - nothing should be able to break abstractions (presuming the abstractions themselves aren't broken). So I conclude the compiler is wrong; I'd suggest sending a bug report. Randy.