Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!nx01.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 18:47:08 -0500 From: Steve Thompson Newsgroups: comp.lang.c Subject: Re: Compatibility question Date: Mon, 22 Oct 2012 23:27:41 +0000 Organization: Friends of the Galactic Collective Message-ID: <9vtC6c.NDd.KogKS@gmail.com> References: <0.a87a1c8a472d870b0466.20121022022701BST.87y5izxpne.fsf@bsb.me.uk> <0.d779297035d2edccd1b4.20121022173052BST.87ehkqbhab.fsf@bsb.me.uk> <2nYjPo.Krd.2aRbe@gmail.com> <90b3a525-f709-4638-b566-25480c865799@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: NN 6.4.3 Lines: 67 X-Trace: sv3-RjFoz+7/jWcRxsMhiZpbXZ8gSCgeLPGndCjUYvzx4uBmIWbD+LNuco6ZSdAZsahLG6mCL+LaZXv+nvs!1f1u/kvK2e9yzpYkyEtaKxQ6vD8VPdO5+9oVCUfzcJAfwtTzBc9y9CQubolRVA== 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: 4434 Xref: csiph.com comp.lang.c:27550 On Mon, Oct 22, 2012 at 02:23:59PM -0700, Öö Tiib wrote: > On Monday, 22 October 2012 20:29:11 UTC+3, Steve Thompson wrote: > > When I was > > less experienced with C, I was confused by the fact that variables > > defined as structures were not pointers: > > > > struct point { > > int x, y, z; > > }; > > > > struct point a; > > > > > > One cannot reference 'a' (as such) in an expression even though it is > > a pointer in the implementation because C allows one to use structures > > as arguments to a function. > > One can use 'a' as such in several expressions like '(void)a', '&a', 'sizeof(a)' and 'a.x'. > > > I'd never do that in my own code, but > > some people may like the fact that they can pass complex data > > structures around as if they were simple variables. > > Anything that contains less than 32 bytes of information is very small amount > of data in modern PC and so is usually optimal to use it by value as whole > instead of making dynamic memory allocations for it. Passing by value > makes it impossible for callee to modify the data of caller so it is safer. > That is especially important in situations of concurrency. It is safer > to pass data between different threads copied, then each has his own copy > and there can not be any race conditions. There's lots of room for argument in that . All that can be said is that it depends. It depends on the kind of data being passed around, and what's being done with it. In terms of concurrency, I suggest it would be rare to see the same data making the rounds in a bunch of different threads, but of course YMMV. In the case where you have small data objects, making copies of them is no big deal unless you have millions or billions of them. A properly written program will modify only the data it is supposed to change; anything else is a bug. I can use four of the 32 bytes that you'd copy and instantiate a lightweight r/w lock that would absolutely guarantee consistency for that object. > > I think it wastes resources, but of course that is less of an issue today > > than it was when C was first developed. > > Dynamic memory management is what wastes most of resources these days. OOP > languages like Java and C++ rely sometimes too heavily on dynamic allocations > of little objects and that makes them inefficient when the whole amount of > such data grows into very large. For example: just 1000 cycles within 1000 > cycles and little allocations/deallocations done in that inner cycle. That > takes about 5 seconds. 1000 by 1000 is very little however these days. > Everybody have gigabytes of memory, terabyte of hard drive and millions of pixels on screen. I'm taking some pains to make allocations very speedy, but the problem you are describing likely results from all those small objects being copied as a consequence of the implementation of those languages. Regards, Steve Thompson -- GOTO's are like guns. Safety is entirely contingent on the user.