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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: "Pat Rogers" Subject: Re: Ada vs C++ vs Java Date: 1999/01/16 Message-ID: <77qrg8$k7p$1@remarQ.com>#1/1 X-Deja-AN: 433421600 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: newsabuse@remarQ.com X-Trace: 916517192 Y6JRGRJUHDE78C640C usenet77.supernews.com Organization: Software Arts & Sciences Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.java,comp.realtime,comp.arch.embedded,comp.object Date: 1999-01-16T00:00:00+00:00 List-Id: John Birch wrote in message <77pnqc$cgi$1@newnews.global.net.uk>... >Pat Rogers wrote in message <77ledn$eu7$1@remarQ.com>... >I originally wrote >>>Since I do not regard dynamic memory allocation as a _good_ thing for >>>most hard embedded systems, I find this claim well founded :-) > >You replied; > >>While I certainly agree that the default implementation -- in both Ada >>95 and C++ -- for dynamic allocation is probably not desirable in a >>real-time environment, in both languages once can easily define how >>allocation is done while still using the language's syntax (i.e., >>"new", in both). As a result allocation can be completely >>deterministic, without resorting to user-defined functions. So "don't >>throw the baby out with the bathwater" as the saying goes. > >I feel the issue here is whether you regard any form of run-time memory >allocation a good thing! Whether it is by overriding new is irrelevant. The >very act of designing a program that is not explicitly coded with a known >memory requirement precludes it's use in a system that does not provide a >virtual memory mechanism. It isn't just the overriding of 'new' -- it is how you do it in the context of the system requirements. If we override it such that the block of storage from which it allocates is of a known size, then we have placed an upper bound on the amount of storage available, as in a static allocation, but have also retained the flexibility of linked data structures. We don't magically say that we can do unbounded allocations just by overriding 'new', but that, given a proper overriding, we can say that a) we know the time required per allocation, and b) we know the maximum storage used. Sure, we have to know what the requirements will be beforehand, but we don't lose the flexibility.