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,196864e6c216ca4f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-30 13:25:27 PST Path: archiver1.google.com!news2.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread3.news.pas.earthlink.net.POSTED!not-for-mail From: Jeffrey Carter Organization: jrcarter commercial-at acm [period | full stop] org User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to Emulate C++ Macro with Static Local Variable? References: <3F73107A.1060502@attbi.com> <04Hcb.577973$Ho3.106182@sccrnsc03> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 30 Sep 2003 20:25:24 GMT NNTP-Posting-Host: 63.184.17.34 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.pas.earthlink.net 1064953524 63.184.17.34 (Tue, 30 Sep 2003 13:25:24 PDT) NNTP-Posting-Date: Tue, 30 Sep 2003 13:25:24 PDT Xref: archiver1.google.com comp.lang.ada:33 Date: 2003-09-30T20:25:24+00:00 List-Id: taashlo@sandia.gov wrote: > I went up one order of magnitude, you went up four. You appear to play > the game much better than I. :-) There's no profit in thinking small :) > If the ID is simply an index into an array of caches, it doesn't require > you to "modify the code that interprets the ID". So it's down to "add > new IDs" and "insert the new call". > >>With an instantiation you add the new instantiation and >>the new call. > > Same as above. Please give more detail on the "significant > differences". And if the ID is NOT simply an index into an array? Generics handle that case exactly the same way. IDs do not; in the general case, you have some processing to deal with the IDs. > But don't forget to delete the associated generic instantiation, too. You probably want to delete the instantiation, but you don't have to. A good compiler will eliminate the resulting code; in the worst case, you have unused code. > I don't know of a manual process that can prevent me from being human > and therefore making mistakes. And the penalty for making a mistake of > accidentally re-using an instantiation name is that the location that > gets called first will determine the contents of the cache for both > locations. In a dynamic system where the one that gets called first > changes from execution to execution, this could result in a *very* > difficult bug to find. Yes, but this is the argument against using C/++ and for using Ada. It's very easy to make simple mistakes that compile and run and are very difficult to find. If that's acceptable to you in C/++ it should be acceptable in Ada. > I'm attempting to port a C++ library that supports implementing > hierarchical state machines (think UML statecharts) directly in a > programming language (as opposed to using a tool to generate the code). > The function in question performs a state transition. You pass in the > target state and it discovers the path from the current state to the > target state. It then caches this information so that subsequent calls > from the same location don't need to perform the same "discovery" > process. > > Yes, the transition path could (possibly) be cached by the state > transition function based on the starting state and the target state. > (In Ada, is it possible to somehow use the *value* of subprogram access > parameters? In this system, a state is defined as a subprogram access > type.) You can use dynamic allocation. Or you can reserve enough space > so that you can cache all state transitions. Or you can can have some > combination of both so that when the reserved space is filled, more will > be allocated. Or you can come up with more options that I haven't > thought of yet. And if I was just developing an application, a large > number of choices is great. But for porting a library whose utility > ranges from GUI applications running on workstations to small embedded > systems, having to make a choice will certainly narrow this range. And > it won't win me any converts from C++ because the C++ implementation > didn't require you to know ahead of time how many state transitions > there are, or suffer the overhead of dynamic allocation, or have to come > up with a unique name for each cache. This is much clearer. Yes, access-to-subprogram values are no different than any other access values. You can store them and compare them. So a solution based on the 2 states sounds like a good approach to use. > One solution would be to come up with a way to automatically pre-cache > the state transitions during initialization. This way, you could > statically reserve cache space and if you didn't have enough cache space > reserved, you would find out during start-up. I'll look into this. Could you do a "2-pass" process? The 1st pass would tell you how big your cache needs to be; then you could statically allocate enough space (Ada allows you to statically allocate space based on values not known until run time) and fill it during the 2nd pass. As a compromise, starting with a default amount of space that's usually big enough, and doubling it if you run out of space, is usually acceptable, even for some embedded systems. -- Jeff Carter "All citizens will be required to change their underwear every half hour. Underwear will be worn on the outside, so we can check." Bananas 29