Xref: utzoo comp.lang.c:26784 comp.lang.misc:4401 Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.c,comp.lang.misc Subject: Re: problems/risks ... Message-ID: <871@enea.se> Date: 11 Mar 90 12:32:35 GMT References: <2596@gmu90x.gmu.edu> <300@isgtec.UUCP> Organization: Enea Data AB, Sweden Lines: 25 Robert Osborne (robert@isgtec.UUCP) writes: >I'm tired of people blithly saying that "such and such is dangerous, >and hence should be removed from the language" when I need such >things to get interactive performance. How many people posting to >this group(s) are actually using C in a production environment? Well, not me. I work in a production environment, but I fear of the consequences of having the product I work with written in C. We use VAX-Pascal, and that's bad enough. We have severe performance problems in the system I involved with, but I can tell you it's not because Pascal doesn't provide fall- throughs on the CASE statement or have expensive function calls. Those are simply not an issue. (This is a database application, so our problems are connected with the disk I/O and locking.) Working in a production does not only mean ultimate performance, but also acceptable reliability and correctness. With a small application you can maybe afford to have those traps around to be able to gain some small percentage in execution time. (Which not always is worth the bucks it costs your employer to pay you doing it.) But when the size increases it becomes more and more important to keep those traps out. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se