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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dff686f95f235879 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-16 12:16:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!syros.belnet.be!news.belnet.be!news.tele.dk!news.tele.dk!small.news.tele.dk!peer1.news.newnet.co.uk!lon1-news.nildram.net!news-peer.gradwell.net!not-for-mail Newsgroups: comp.lang.ada From: porton@ex-code.com (Victor Porton) Date: Fri, 17 Jan 2003 01:09:49 +0500 References: <3e2620ad$0$33930$bed64819@news.gradwell.net> Organization: Extreme Code Software (http://ex-code.com) Subject: Re: Composing sequences (interesting to solve) Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Content-Type: text/plain; charset=us-ascii X-URL: http://www.ex-code.com/ Message-ID: <3e2712ff$0$33929$bed64819@news.gradwell.net> NNTP-Posting-Date: 16 Jan 2003 20:15:59 GMT NNTP-Posting-Host: 195.149.39.13 X-Trace: 1042748159 news.gradwell.net 33929 mail2news/195.149.39.13 X-Complaints-To: news-abuse@gradwell.net Xref: archiver1.google.com comp.lang.ada:33103 Date: 2003-01-16T20:15:59+00:00 List-Id: In article , "Dmitry A. Kazakov" writes: > Victor Porton wrote: > >> See an interesting and yet unsolved by me practical task to solve: >> >> I have "elements" of various kinds (Base_Element'Class): >> >> type Base_Element is null record; >> >> There are many various types of element derived from >> Base_Element. Some of these contain accesses to other >> elements (which I allocate by "new"), so that this forms >> trees. >> >> To eliminate access types conversions I decided to limit >> myself to use only Base_Element_Access (not accesses to >> derived types) (BTW, Is it right design decision?): >> >> type Base_Element_Access is access Base_Element'Class; >> >> One of the types of elements is "sequence" (it is an ordered >> container of elements): >> >> type Sequence is new Base_Element with private; >> >> I wish to produce sequences (allocated dynamically) by such >> the syntax using overloaded function "&": >> >> E1 & E2 & E3 >> >> The question is how to define function "&" so that it would >> give the right result (access to one dynamically allocated >> sequence) independingly on the number of elements? > > I think you should clarify whether A & B creates a new object or just binds > A and B. Why an access type have to be returned? It is a bad style and > error prone. If you really want heap allocated objects [with reference > counting and garbage collection], use handles instead of raw pointers. & > have to be defined on both handles and privately, on the objects. It is a > bit nasty especially if you want to add some operations to derived > elements. If so you have two [bad] alternatives: I don't understand your question, A & B should create (on heap) object of type Sequence which contains accesses to A.all and B.all . A & B & C should create Sequence of three elements etc. Consider: type Pair is new Base_Element with record First, Second: Base_Element_Access; end record; The constructor would be just: function Make_Pair(First, Second: Base_Element_Access) return Base_Element_Access is begin return new Pair'(Base_Element with First=>First, Second=>Second); end; But if I use types themselves, I need: function Make_Pair(First, Second: Base_Element'Class) return Base_Element_Access is begin return new Pair'(Base_Element with First =>new Base_Element'Class'(First), Second=>new Base_Element'Class'(Second)); end; -- Requires two copying of probably big objects First and Second In fact I allocate these elements once at program's (or a subrountine's) lifetime (as these are in fact a part of algorithm, being something like a programming language interpretor, not just a typical data) and then are going to deallocate all of them at once by using scopes, not explicit deallocation. You see that I don't need reference counting and garbage collection. So I see no need for handles. Do you now consider it a good style or have an idea how to make it better? Do you still think that introducing handles would be useful? At least I think that reference counting is a bloating for me. > 1. Compile-time checkable. Derive new handle types and define new operations > on them. > > 2. Run-time checkable. Define new operations on the handle type and leave > checks to casting. The interest case is to make it compile time checkable. (Creating runtime check of 'Tag attrs is trivial.) You haven't given me a solution. (I suspect that it is even impossible in Ada9X.)