Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!216.196.98.142.MISMATCH!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 22 Oct 2012 10:13:10 -0500 From: Steve Thompson Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: C/C++ question about dynamic "static struct" Date: Mon, 22 Oct 2012 15:08:11 +0000 Organization: Friends of the Galactic Collective Message-ID: <55nV5E.95v.TjMTe@gmail.com> References: <8q66l9-lkm.ln1@wilbur.25thandClement.com> <5081D9DA.6020103@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: NN 6.4.3 Lines: 80 X-Trace: sv3-CoWKZ8BE2Q3UhUiqh8HORwl7ijIf59W82edADMst2zCmgrd1Yif97iqk2MY1obn4u232lwTowI1mk6w!HKRvXgd9HeyGncJR2UD4gvYvEmub2aFNAYpNp1QmJgs/2E4N5qR76g9k8uQCbg== X-Complaints-To: www.supernews.com/docs/abuse.html X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5360 X-Received-Bytes: 5568 Xref: csiph.com comp.lang.c++:19199 comp.lang.c:27509 On Mon, Oct 22, 2012 at 08:13:31AM +0000, Juha Nieminen wrote: > In comp.lang.c++ James Kuyper wrote: > > In any event, your summary of my argument dropped the key point - that > > the greater complexity of C++ provides more temptations for incompetent > > programmers to generate overly complex code than C does. > > My experience makes me disagree with the the last part. I would say that > the limiting "simplicity" of C causes many incompetent programmers to > create horrible code (much of which is caused *because* C is so archaic.) C maps relatively cleanly to the architecture of the stored program computer, at least for a non-SMP design. The language doesn't try to do a whole lot behind the scenes in making the language primitives work, except in cases where native types are too small for the language types, and then the math has to be simulated with those narrower instructions. In this sense it is conceptually minimalistic. > Many C advocates argue that the "simplicity" of the language somehow > induces people to make straightforward, clear, simple and efficient > implementations. That's not what I see at all. Instead, what I see > quite often is really complicated code with tons of implied coding > conventions (that exist solely to address things like memory management > issues), and which is quite frankly horribly designed. Just take almost > any C project out there and study its source code. You'll easily find > 400+ LOC functions (with little to no comments), that use lots of > repetition and/or are really obfuscated, oftentimes riddled with gotos, I like gotos. They make the recovery from an error conditions much easier to handle. Some of the code I have written would suck utterly if it were translated to a C that lacks the goto construct. I was once caught up in the "GOTO Considered Harmful" theology, and my code suffered accordingly. Judicious use of the statement is entirely reasonable in C. > and so on and so forth. They often also suffer from inefficiency because > the programmer did a "straightforward" job at implementing the task at > hand. Coding is not a science and nor is it a serious engineering discipline for the vast majority of programmers. Most of the time, a programmer of average skill will write something that works well enough for the problem at hand. Adding functionality or capabilities to such code later may be difficult or a practical impossibility, but it may be that the original writer was not given enough time, or expertise was not available in the design phase, to build something extensible. Part of the problem is the tool set. C comes with a standard library that encourages a certain style of coding. If you want an event- driven architecture, a different language is probably going to be a better choice. The language provides tools to make calculations with numbers, control-flow constructs to make decisions based on the value of the numbers, constructs to encourage a modular program design, and an interface to the operating system for input/output, etc. Everything else is up to the programmer. > I'm not saying that *every* C program out there is like that. I'm saying > that quite a significant portion of them are. There's nothing in C that > would somehow induce or encourage people to make good code. It's not the job of the language to "induce" good code. What is "good code" anyhow? Is good code easy to read and understand? Is good code merely correct? Is good code elegant and pretty? At any rate, good is a subjective quality. What may be good to a five-year old will be different from what an adult will consider as good. You seem to be saying that you know what good is when you see it, but I doubt you can define what you mean in terms that everyone will understand. Regards, Steve Thompson -- GOTO's are like guns. Safety is entirely contingent on the user.