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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: johnb@invision.co.uk (John Birch) Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <369f81a9.31040093@news.demon.co.uk>#1/1 X-Deja-AN: 433070260 X-NNTP-Posting-Host: invision.demon.co.uk:158.152.59.42 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <369F1D39.64A65BC1@sea.ericsson.se> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 916429682 nnrp-12:18625 NO-IDENT invision.demon.co.uk:158.152.59.42 Reply-To: johnb@invision.co.uk Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-15T00:00:00+00:00 List-Id: On Fri, 15 Jan 1999 11:49:29 +0100, Gerhard Menzl wrote: I originally wrote: >> There are many embedded programmers who regard the concept of dynamic >> memory allocation in an embedded system as laughable at best and a >> terminal offence at worst. If you restict C++ in such a way (i.e. >> prevented the use of dynamic memory allocation) you'd pretty much end >> up with C anyway! >You would end up with a better C that gives you stronger type checking, const >correctness etc. It would still be C++, which is a multi-paradigm programming >language. Yes you would certainly gain some features that were not present in C. Whether it made sense to use a crippled C++ in this way is a much more debatable issue. In my experience you should either take it all or leave it. If you start telling developers that "We're using C++ but we don't use X, Y, Z", you are constraining the number of paradigms that they are used to working in. Further you are now creating a non-standard language that looks like C++ but isn't. The possibility would then be open for subsequent maintenance or post design programmers to start using forbidden features out of ignorance. This obviously increases the possibility of errors in the code, especially when the forbidden features are forbidden for 'subtle' reasons. >> Since I do not regard dynamic memory allocation as a _good_ thing for >> most hard embedded systems, I find this claim well founded :-) >That depends entirely on the allocation mechanism, I would say. C++ allows the >programmer to overload operators new and delete to define any form of allocation, >such as distributing chunks of memory from a preallocated pool. There are RTOSes >which have such mechanisms built in. My biggest problem with dynamic memory allocation in embedded systems is the fact that an indeterminate allocation mechanism exists! If dynamic memory allocation is used the resulting program is non-deterministic in the sense that it is impossible to guarantee that there is enough memory resource to complete execution of the program (under all paths for the program). C++ allocates memory for new objects. New objects in C++ can be allocated as temporary objects (i.e. out of the immediate awareness of the code writer). If I do not have a hard disk or operating system in my embedded PC, how can I write a C++ program, (where it is the compiler in cohorts with the OS that allocates memory for objects) and know that my program will execute without exhausting resources. Besides which, the use of dynamic memory allocation seems to insipre a kind of lazy attitude on software developers.I have seen serial port processing routines that just increase their buffer sizes when they fall behind in processing characters (and this in systems where the processing of the characters is the core task!) Granted that a large number of "real time" problems can be solved with fast embedded PCs, but many of them could equally well (or better) be solved with a microprocessor some RAM and an EPROM / FLASH program store. When a programmer is faced with limited RAM, the unnecessary use of dynamic memory allocation is a hinderance. Further, if the use of dynamic memory allocation is prevented, the resulting code must be written in a way such that memory resource requirments can be calculated from examination of the source code and map file. >> Except that a perfectly valid ANSI C program need not compile or >> execute correctly under C++. Consequently, if it's a subset, it's a >> pretty poor one! >C code that does not compile under C++ is either very obscure, or it fails to comply >with the stronger type checking requirements of C++. Neither case can be considered >as essential to embedded systems programming. Or would you claim that embedded >systems code has to be obscure or requires weak type checking? My statement here rests upon the interpretation of 'subset'. I think a perfectly good mathematical definition exists. Using that definition C is not a subset of C++. I grant however that any C program that does not compile under C++ is probably weak ;-) regards John B.