Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and runtime checks Date: Wed, 8 May 2019 10:31:25 +0200 Organization: A noiseless patient Spider Lines: 102 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-064@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-046@comp.compilers> <19-05-052@comp.compilers> <19-05-059@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="55918"; mail-complaints-to="abuse@iecc.com" Keywords: C, standards Posted-Date: 08 May 2019 12:43:29 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2299 On 08/05/2019 02:27, Hans-Peter Diettrich wrote: > Am 07.05.2019 um 16:29 schrieb David Brown: >> On 29/04/2019 22:36, Hans-Peter Diettrich wrote: >>> Am 28.04.2019 um 23:49 schrieb David Brown: > >>>> This is exactly the same as mathematics.  The "square root" function, >>>> for real numbers, is defined for non-negative numbers.  If someone asks >>>> you for "sqrt(-4)", then the question is meaningless.  Any answer given >>>> can be considered incorrect - equally, any answer given can be >>>> considered correct. >>> >>> That's a cheap excuse for poor language design, aimed at sloppy compiler >>> implementation. >>> >> >> You are saying that mathematics is a poor language design? > > No, I criticize the lack of restricted (non-negative...) types for such > purposes. OK. Again, I'd note that different languages have different design requirements and different uses. (Although I agree that such specific ranged types are nice, and are a feature of Pascal that I miss in C.) > > >> Different languages have different purposes and trade-offs.  This is >> important to accept when discussing them. > > No doubt :-) > > So I wonder why the topic (optimization...) drifted into a discussion of > almost only the C language. > C is a language that many people know, one for which optimisations are very important, and where certain kinds of optimisations can be controversial - and therefore lead to discussions. If everyone is happy with a language's definitions, behaviours, and typical optimisations, there'd be no arguments and few posts! But by all means, add more about Pascal or any other language you like to this thread - it could be interesting for many of us. > I also wonder where runtime efficiency nowadays is really so important, > that safety and security breaches are considered acceptable? > This depends on the use of the code. I have many times noted that C is often a poor choice of language. There was a time when it was the best, or only, language suitable for a wide range of uses. This is no longer the case. I personally use it for small-systems embedded programming, and the runtime efficiency /is/ important. But for PC programming, I use mostly Python (I used to use Delphi more). Pick a language that makes sense for the job, and gives the trade-offs that suit your needs. And often there is no way to handle run-time errors sensibly anyway. You don't want your car brakes to give you a message "Your braking system has encountered an integer overflow. Please report this error to your car dealer". You want the brake software developers to be /absolutely/ sure that overflows can't happen - and then there is no point in run-time checks. C is not going away. But it would be good to see less C code used, but more care used with the C code that is written. That includes testing with tools that do run-time checks, but not having them included in the final product. It is the run-time efficiency of the underlying C code in libraries, VMs, etc., that makes the speed of most checked languages acceptable. > >> Every language has its oddities, and there are always things that some >> people thing are terrible design.  For example, it is truly weird that >> "const x : int = 10;" is one of Delphi's way of making "x" a variable >> with an initialised value.  (In older Delphi, it was the only way!) > > This makes the different evolution visible: > Pascal started as a tutorial language, C as a production language. > Evolution added features of great demand - in the case of Pascal many > features had to be added to Wirth's academic language(s) before it > became usable outside education. > Yes. I realise that this oddity is "for historical reasons". The same applies to a great many oddities in C. > I definitely prefer a safe language, which can be tuned later for > efficieny. Lowering requirements and checks in specific parts of a > program is doable and acceptable easier than introducing requirements > that were not anticipated in the basic language design. > > DoDi > [These days I write just about everything in python.  Occasionally > I'll rewrite something in C if python can't do it but that's pretty > rare.  The python implementation everyone uses is written in C but it > does a pretty good job of managing storage and arithmetic. -John] That's the way to do it.