Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #27400 > unrolled thread
| Started by | Steve Thompson <stevet810@gmail.com> |
|---|---|
| First post | 2012-10-20 03:08 +0000 |
| Last post | 2012-10-21 19:27 -0700 |
| Articles | 19 on this page of 79 — 13 participants |
Back to article view | Back to comp.lang.c
Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 03:08 +0000
Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-20 16:20 +1300
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 11:50 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-20 11:41 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:04 +0000
Re: Compatibility question Barry Schwarz <schwarzb@dqel.com> - 2012-10-21 20:27 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 04:01 +0000
Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:26 +1300
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 22:54 +0000
Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-22 12:29 +1300
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:50 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 02:27 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 02:28 +0000
Re: Compatibility question Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 11:18 -0400
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 16:19 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:37 +0100
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:40 +0100
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:30 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 17:23 +0000
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 10:52 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 18:42 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 21:06 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 22:52 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 03:33 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:28 +0000
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 16:45 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 17:53 +0000
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:41 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 21:28 +0100
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 20:57 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:26 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 20:39 +0000
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 15:53 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 00:57 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 20:06 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 11:18 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 12:04 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 23:10 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:58 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-25 01:46 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 19:40 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-24 20:20 +0000
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 14:38 -0700
Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-24 17:55 -0400
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:29 -0700
Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-24 15:21 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-26 03:30 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 13:02 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-27 00:04 +0000
Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 20:15 +0100
Re: Compatibility question Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-10-27 16:36 -0600
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:36 +0000
Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 22:42 +0300
Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-27 14:30 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-27 22:57 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:04 -0700
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:14 -0700
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 18:04 -0700
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:46 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-25 01:18 +0000
Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 21:08 +0300
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:38 +0000
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:38 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 16:50 -0700
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:33 +0000
Re: Compatibility question Öö Tiib <ootiib@hot.ee> - 2012-10-22 14:23 -0700
Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 17:26 -0400
Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 10:55 +1300
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:27 +0000
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-22 22:44 +0100
Re: Compatibility question Les Cargill <lcargill99@comcast.com> - 2012-10-22 17:15 -0500
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:13 +0100
Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 18:35 -0400
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:14 +0100
Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:42 +0000
Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 13:35 +1300
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 17:01 -0700
Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 01:47 +0100
Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-21 19:27 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2012-10-27 21:08 +0300 |
| Message-ID | <87625vzt2f.fsf@bazspaz.fatphil.org> |
| In reply to | #27606 |
Steve Thompson <stevet810@gmail.com> writes: > No, a char ** object is a pointer to a char ** object. And I thought Bill was the most woo-woo person on the froup... Give up C. Please. If you want to use C in the future, run into a wall at high speed. Forget everything you know. Relearn from scratch. Correctly this time. Phil -- Regarding TSA regulations: How are four small bottles of liquid different from one large bottle? Because four bottles can hold the components of a binary liquid explosive, whereas one big bottle can't. -- camperdave responding to MacAndrew on /.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2012-10-28 17:38 +0000 |
| Message-ID | <EQtycA.yYe.suEw0@gmail.com> |
| In reply to | #27769 |
On Sat, Oct 27, 2012 at 09:08:24PM +0300, Phil Carmody wrote: > Steve Thompson <stevet810@gmail.com> writes: > > No, a char ** object is a pointer to a char ** object. > > And I thought Bill was the most woo-woo person on the froup... > > Give up C. Please. > > If you want to use C in the future, run into a wall at high speed. Forget > everything you know. Relearn from scratch. Correctly this time. I would have more change of success if I used a hammer; plus it feels so good when you stop. Regards, Steve Thompson -- GOTO's are like guns. Safety is entirely contingent on the user.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-23 00:38 +0100 |
| Message-ID | <k64ler$48l$1@dont-email.me> |
| In reply to | #27530 |
"Steve Thompson" <stevet810@gmail.com> wrote in message
news:qRFu8I.lcH.7XEwQ@gmail.com...
> On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
>> I'm not sure what you mean when you say `a` "is a pointer in
>> the implementation", especially after you mention "the fact that
>> variables defined as structures were not pointers".
>
> Meaning that under the hood in the C compiler, 'a' is really a
> pointer.
Not really. &a is a pointer, but a is just a value (of the struct).
I suppose if the struct was huge, a compiler might see if it could get away
with using a pointer to the struct instead. But for smaller structs it's not
a problem to manipulate them by value. (And it's anyway up to the programmer
if he wanted large structs handled by value or not.)
Also consider a function like this:
struct point add(struct point a,struct point b) {
struct point c={a.x+b.x,a.y+b.y};
return c;
}
and calling it like this:
struct point p,q,r,s,t;
p=add(q,add(r,add(s,t)));
how much work do you think it's going to be to manage all those behind the
scenes pointers, which might even require memory allocations to keep track
of? It's easier to keep intermediate values on the call stack.
> True enough, but the difference is that a structure cannot be used for
> arithmetic operations of any kind in C. That makes it fundamentally
> different from simple type variables. It may be meaningful to say that
> structures passed to functions as values is a hack in the C language.
> It fills a use-case scenario that will be found (or should be found)
> only in trivial programs, IMHO.
See above example..
>> > These days I'm thinking more and more about cache-line usage, so I am
>> > concerned with preserving the 'hotness' of my data. Copying
>> > structures around a whole lot is hostile to this paradigm, so that is
>> > one language feature I am happy to avoid.
>>
>> If a structure is smaller than a pointer, or not much bigger, it makes
>> perfect sense to pass it around by value.
>
> Most structures are considerably larger than a pointer in practice.
> My personal opinion is that it is a waste to pass them around by
> value in most cases.
It depends. If there are 100 fields and you only access 1 or 2, then it
probably is wasteful. If you have to access most of the fields anyway, then
it's not so bad (and you can avoid a level of indirection.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-10-22 16:50 -0700 |
| Message-ID | <lnbofuf4mn.fsf@nuthaus.mib.org> |
| In reply to | #27530 |
Steve Thompson <stevet810@gmail.com> writes:
> On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> [...]
>> > No annoyance taken, although now that I think of it it does show an
>> > instance of overloaded semantics, which can be confusing. 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. 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. I think it wastes
>> > resources, but of course that is less of an issue today than it was
>> > when C was first developed.
>>
>> I'm not sure what you mean when you say `a` "is a pointer in
>> the implementation", especially after you mention "the fact that
>> variables defined as structures were not pointers".
>
> Meaning that under the hood in the C compiler, 'a' is really a
> pointer. The logic of the compiler causes it to use the structure
> data as specified in the standard, but conceptually 'a' is still a
> pointer to the data in the specific structure identified by 'a'. I
> found it very confusing when I was learning C.
Frankly, I think you're still confused.
`a` is not in any sense a pointer. It's one of several things,
depending on what level of abstraction you're looking at:
- An identifier that's the name of an object of type `struct point`;
- An object of type `struct point`;
- An lvalue expression that designates an object of type `struct point`;
- A non-lvalue expression that evaluates to the value of an object of
type `struct point`, a value that consists of the values of the
members.
If you want a pointer to `a`, you can construct one easily enough
by writing `&a`. A compiler *might* use pointers internally to
handle some operations on `a`, but there's no reason at all to
assume that it has to. For example, here's the code generated by
gcc for an assignment `b = a;`, where `b` and `a` are both of type
`struct point`:
movl 56(%esp), %eax
movl %eax, 68(%esp)
movl 60(%esp), %eax
movl %eax, 72(%esp)
movl 64(%esp), %eax
movl %eax, 76(%esp)
And here's the code generated for an assignment `y = x;`, where `y` and
`x` are of type `long double`:
movl 16(%esp), %eax
movl 20(%esp), %edx
movl 24(%esp), %ecx
movl %eax, 32(%esp)
movl %edx, 36(%esp)
movl %ecx, 40(%esp)
Looks pretty similar to me. Is a long double object "really" a pointer?
[...]
> True enough, but the difference is that a structure cannot be used for
> arithmetic operations of any kind in C. That makes it fundamentally
> different from simple type variables. It may be meaningful to say that
> structures passed to functions as values is a hack in the C language.
> It fills a use-case scenario that will be found (or should be found)
> only in trivial programs, IMHO.
Ok, you can't do arithmetic on structures. You can't use "%" on
floating-point types. You *can* assign structures and pass them as
function arguments, with exactly the same syntax and semantics as the
corresponding operations on scalar types.
[...]
There's a close relationship between arrays and pointers (though it's
important to remember that *arrays are not pointers*; see section 6 of
the comp.lang.c FAQ <http://www.c-faq.com>). There is no such special
relationship at the language or compiler level between structures and
pointers.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2012-10-23 12:33 +0000 |
| Message-ID | <aHs6Ek.mkn.YUJP6@gmail.com> |
| In reply to | #27552 |
On Mon, Oct 22, 2012 at 04:50:40PM -0700, Keith Thompson wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> > On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> [...]
> >> > No annoyance taken, although now that I think of it it does show an
> >> > instance of overloaded semantics, which can be confusing. 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. 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. I think it wastes
> >> > resources, but of course that is less of an issue today than it was
> >> > when C was first developed.
> >>
> >> I'm not sure what you mean when you say `a` "is a pointer in
> >> the implementation", especially after you mention "the fact that
> >> variables defined as structures were not pointers".
> >
> > Meaning that under the hood in the C compiler, 'a' is really a
> > pointer. The logic of the compiler causes it to use the structure
> > data as specified in the standard, but conceptually 'a' is still a
> > pointer to the data in the specific structure identified by 'a'. I
> > found it very confusing when I was learning C.
>
> Frankly, I think you're still confused.
>
> `a` is not in any sense a pointer. It's one of several things,
> depending on what level of abstraction you're looking at:
>
> - An identifier that's the name of an object of type `struct point`;
> - An object of type `struct point`;
> - An lvalue expression that designates an object of type `struct point`;
> - A non-lvalue expression that evaluates to the value of an object of
> type `struct point`, a value that consists of the values of the
> members.
>
> If you want a pointer to `a`, you can construct one easily enough
> by writing `&a`. A compiler *might* use pointers internally to
> handle some operations on `a`, but there's no reason at all to
> assume that it has to. For example, here's the code generated by
> gcc for an assignment `b = a;`, where `b` and `a` are both of type
> `struct point`:
>
> movl 56(%esp), %eax
> movl %eax, 68(%esp)
> movl 60(%esp), %eax
> movl %eax, 72(%esp)
> movl 64(%esp), %eax
> movl %eax, 76(%esp)
>
> And here's the code generated for an assignment `y = x;`, where `y` and
> `x` are of type `long double`:
>
> movl 16(%esp), %eax
> movl 20(%esp), %edx
> movl 24(%esp), %ecx
> movl %eax, 32(%esp)
> movl %edx, 36(%esp)
> movl %ecx, 40(%esp)
>
> Looks pretty similar to me. Is a long double object "really" a pointer?
Similar, although I don't know which one is faster. No, it's not a
pointer in the sense of the C language definition of a pointer, but
the compiler sort of treats it as a pointer in the process of
implementing the language.
> [...]
>
> > True enough, but the difference is that a structure cannot be used for
> > arithmetic operations of any kind in C. That makes it fundamentally
> > different from simple type variables. It may be meaningful to say that
> > structures passed to functions as values is a hack in the C language.
> > It fills a use-case scenario that will be found (or should be found)
> > only in trivial programs, IMHO.
>
> Ok, you can't do arithmetic on structures. You can't use "%" on
> floating-point types. You *can* assign structures and pass them as
> function arguments, with exactly the same syntax and semantics as the
> corresponding operations on scalar types.
>
> [...]
>
> There's a close relationship between arrays and pointers (though it's
> important to remember that *arrays are not pointers*; see section 6 of
> the comp.lang.c FAQ <http://www.c-faq.com>). There is no such special
> relationship at the language or compiler level between structures and
> pointers.
I think the confusion is arising from the way I envision the
compiler's internal representation of variables, structures, and
pointers, as distinct from the definitions in the standard relating to
their semantics.
Regards,
Steve Thompson
--
GOTO's are like guns. Safety is entirely contingent on the user.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-10-22 14:23 -0700 |
| Message-ID | <90b3a525-f709-4638-b566-25480c865799@googlegroups.com> |
| In reply to | #27520 |
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.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-22 17:26 -0400 |
| Message-ID | <5085BA1D.6040902@verizon.net> |
| In reply to | #27538 |
On 10/22/2012 05:23 PM, Öö 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'.
Also, given
struct point b;
'a' can be used in expressions like:
a = b;
b = a;
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-23 10:55 +1300 |
| Message-ID | <aeltm5FfnodU1@mid.individual.net> |
| In reply to | #27538 |
On 10/23/12 10:23, Öö Tiib wrote: > On Monday, 22 October 2012 20:29:11 UTC+3, Steve Thompson wrote: > >> 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. That is true, but you have to be careful what you are copying. Plain old data is fine, but if your struct contains pointers or something that shouldn't be copied such as a mutex, nasty things can happen. >> 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. Java more than C++. Dynamic allocations can be avoided in C++, but not Java. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2012-10-22 23:27 +0000 |
| Message-ID | <9vtC6c.NDd.KogKS@gmail.com> |
| In reply to | #27538 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-22 22:44 +0100 |
| Message-ID | <k64enk$eqt$1@dont-email.me> |
| In reply to | #27520 |
"Steve Thompson" <stevet810@gmail.com> wrote in message
news:2nYjPo.Krd.2aRbe@gmail.com...
> 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. 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. I think it wastes
> resources, but of course that is less of an issue today than it was
> when C was first developed.
What about this struct:
struct {
char r,g,b,a;
} c;
It would be less efficient to pass a pointer to this value, than to pass the
value itself (especially when the pointer could well be wider). Returning
such a struct as a value from a function is also far simpler.
In any case C gives you the choice of pass-by-value or pass-by-reference -
for structs.
(What confuses *me* in some languages (it seems most of them these days) is
stuff like this:
a=[10,20,30]
b=a
a[0]=9999 # modify a
print a
print b
You modify a, and find that b has also changed! Yet if a and b were numbers,
you could 'modify' a after b=a, and b is not affected!)
This is pass-by-reference taken to extremes.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-22 17:15 -0500 |
| Message-ID | <k64gjh$ptl$1@dont-email.me> |
| In reply to | #27540 |
BartC wrote:
> "Steve Thompson" <stevet810@gmail.com> wrote in message
> news:2nYjPo.Krd.2aRbe@gmail.com...
>
>> 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. 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. I think it wastes
>> resources, but of course that is less of an issue today than it was
>> when C was first developed.
>
> What about this struct:
>
> struct {
> char r,g,b,a;
> } c;
>
> It would be less efficient to pass a pointer to this value, than to pass
> the
> value itself (especially when the pointer could well be wider). Returning
> such a struct as a value from a function is also far simpler.
>
> In any case C gives you the choice of pass-by-value or pass-by-reference -
> for structs.
>
> (What confuses *me* in some languages (it seems most of them these days)
> is stuff like this:
>
> a=[10,20,30]
> b=a
>
> a[0]=9999 # modify a
>
> print a
> print b
>
> You modify a, and find that b has also changed! Yet if a and b were
> numbers,
> you could 'modify' a after b=a, and b is not affected!)
>
> This is pass-by-reference taken to extremes.
>
That's not too different from:
short a[] = {10, 20, 30};
short *b = a;
...
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-23 00:13 +0100 |
| Message-ID | <k64k14$qp9$1@dont-email.me> |
| In reply to | #27542 |
"Les Cargill" <lcargill99@comcast.com> wrote in message
news:k64gjh$ptl$1@dont-email.me...
> BartC wrote:
>> You modify a, and find that b has also changed! Yet if a and b were
>> numbers,
>> you could 'modify' a after b=a, and b is not affected!)
>>
>> This is pass-by-reference taken to extremes.
>>
>
>
> That's not too different from:
>
> short a[] = {10, 20, 30};
> short *b = a;
But you've explicitly said that b is a pointer, so subsequent behaviour is
not unexpected.
(Although, because C doesn't need an explicit dereference for b, it can
cause a bit of confusion when the types of a and b are not immediately
visible to the reader. That's just another quirk of the language that has
both pros and cons.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-22 18:35 -0400 |
| Message-ID | <5085CA36.4020802@verizon.net> |
| In reply to | #27540 |
On 10/22/2012 05:44 PM, BartC wrote: ... > (What confuses *me* in some languages (it seems most of them these days) is > stuff like this: > > a=[10,20,30] > b=a > > a[0]=9999 # modify a > > print a > print b > > You modify a, and find that b has also changed! Yet if a and b were numbers, > you could 'modify' a after b=a, and b is not affected!) > > This is pass-by-reference taken to extremes. I agree, but it's a viable choice, so long as the language also provides some mechanism for creating a copy of 'a' rather than a reference to 'a'. Do each of the languages you're thinking of have some such mechanism?
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-23 00:14 +0100 |
| Message-ID | <k64k15$qp9$2@dont-email.me> |
| In reply to | #27544 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5085CA36.4020802@verizon.net... > On 10/22/2012 05:44 PM, BartC wrote: > ... >> (What confuses *me* in some languages (it seems most of them these days) >> is >> stuff like this: >> >> a=[10,20,30] >> b=a >> >> a[0]=9999 # modify a >> >> print a >> print b >> >> You modify a, and find that b has also changed! Yet if a and b were >> numbers, >> you could 'modify' a after b=a, and b is not affected!) >> >> This is pass-by-reference taken to extremes. > > I agree, but it's a viable choice, so long as the language also provides > some mechanism for creating a copy of 'a' rather than a reference to > 'a'. Do each of the languages you're thinking of have some such mechanism? > Probably. But you have to look it up. (Googling suggests it might be something like b=copy.deepcopy(a) for my Python example, but each language is different.) (It gets worse too: try adding the line c=[a]*100 to this example. After a is modified, c now has 100 'copies' of the new a. Now do this: c[0][0]=45 You'll find that all the other 99 elements of c have changed too, and is the point where you start tearing your hair out! I can see where they're coming from: if a and b were file handles for example, then clearly b=a only makes a copy of the handle, not of the file! But that's an explicit use of handles and references; it's not implicit and depending also on what exactly a and b might be, as it it in these languages. When I implement this stuff, I always do deep copies - of data that is managed by the language - but then I also allow everything to be mutable.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2012-10-22 23:42 +0000 |
| Message-ID | <VWb607.moi.LHtZ5@gmail.com> |
| In reply to | #27540 |
On Mon, Oct 22, 2012 at 10:44:11PM +0100, BartC wrote:
> "Steve Thompson" <stevet810@gmail.com> wrote in message
> news:2nYjPo.Krd.2aRbe@gmail.com...
>
> >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. 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. I think it wastes
> >resources, but of course that is less of an issue today than it was
> >when C was first developed.
>
> What about this struct:
>
> struct {
> char r,g,b,a;
> } c;
>
> It would be less efficient to pass a pointer to this value, than to pass the
> value itself (especially when the pointer could well be wider). Returning
> such a struct as a value from a function is also far simpler.
I have my doubts about that, at least on anything like a contemporary
x86 machine.
> In any case C gives you the choice of pass-by-value or pass-by-reference -
> for structs.
>
> (What confuses *me* in some languages (it seems most of them these days) is
> stuff like this:
>
> a=[10,20,30]
> b=a
>
> a[0]=9999 # modify a
>
> print a
> print b
>
> You modify a, and find that b has also changed! Yet if a and b were numbers,
> you could 'modify' a after b=a, and b is not affected!)
>
> This is pass-by-reference taken to extremes.
That's gross. Who would ever do such a thing and in what language?
Regards,
Steve Thompson
--
GOTO's are like guns. Safety is entirely contingent on the user.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-23 13:35 +1300 |
| Message-ID | <aem728FfnodU2@mid.individual.net> |
| In reply to | #27551 |
On 10/23/12 12:42, Steve Thompson wrote:
> On Mon, Oct 22, 2012 at 10:44:11PM +0100, BartC wrote:
>> "Steve Thompson"<stevet810@gmail.com> wrote in message
>> news:2nYjPo.Krd.2aRbe@gmail.com...
>>
>>> 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. 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. I think it wastes
>>> resources, but of course that is less of an issue today than it was
>>> when C was first developed.
>>
>> What about this struct:
>>
>> struct {
>> char r,g,b,a;
>> } c;
>>
>> It would be less efficient to pass a pointer to this value, than to pass the
>> value itself (especially when the pointer could well be wider). Returning
>> such a struct as a value from a function is also far simpler.
>
> I have my doubts about that, at least on anything like a contemporary
> x86 machine.
Try it, you may be surprised.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-10-22 17:01 -0700 |
| Message-ID | <ln7gqif44e.fsf@nuthaus.mib.org> |
| In reply to | #27540 |
"BartC" <bc@freeuk.com> writes:
[...]
> What about this struct:
>
> struct {
> char r,g,b,a;
> } c;
(unsigned char would probably make more sense.)
> It would be less efficient to pass a pointer to this value, than to pass the
> value itself (especially when the pointer could well be wider). Returning
> such a struct as a value from a function is also far simpler.
>
> In any case C gives you the choice of pass-by-value or pass-by-reference -
> for structs.
I presume what you mean by that is that you can define a function that
takes a pointer to a struct, like this:
struct rgba {
unsigned char r, g, b, a;
};
void func(struct rgba *arg);
struct rgba obj;
func(&obj);
If the parameter is declared to be of type "struct rgba", it's
*always* passed by value.
I presume you know that, but other readers might mistakenly infer
that you can tell the compiler to pass arguments by reference
(which is possible in some other languages).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-23 01:47 +0100 |
| Message-ID | <k64pfo$o06$1@dont-email.me> |
| In reply to | #27553 |
"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln7gqif44e.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> In any case C gives you the choice of pass-by-value or
>> pass-by-reference -
>> for structs.
>
> I presume what you mean by that is that you can define a function that
> takes a pointer to a struct, like this:
>
> struct rgba {
> unsigned char r, g, b, a;
> };
>
> void func(struct rgba *arg);
>
> struct rgba obj;
> func(&obj);
>
> If the parameter is declared to be of type "struct rgba", it's
> *always* passed by value.
>
> I presume you know that, but other readers might mistakenly infer
> that you can tell the compiler to pass arguments by reference
> (which is possible in some other languages).
Yes, pass-by-reference is emulated by using a pointer to the data. C
*thinks* it's pass-by-value (the value of the pointer).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-10-21 19:27 -0700 |
| Message-ID | <ln1ugrgs0g.fsf@nuthaus.mib.org> |
| In reply to | #27480 |
Steve Thompson <stevet810@gmail.com> writes:
[...]
>From the GCC info pages:
>
> In ISO C99, you would use a "flexible array member", which is slightly
> different in syntax and semantics:
>
> * Flexible array members are written as `contents[]' without the `0'.
>
> * Flexible array members have incomplete type, and so the `sizeof'
> operator may not be applied. As a quirk of the original
> implementation of zero-length arrays, `sizeof' evaluates to zero.
>
> * Flexible array members may only appear as the last member of a
> `struct' that is otherwise non-empty.
>
> * A structure containing a flexible array member, or a union
> containing such a structure (possibly recursively), may not be a
> member of a structure or an element of an array. (However, these
> uses are permitted by GCC as extensions.)
>
> So I'm free and clear. My VLAs will be in structures which are not
> encapsulated in other structures.
VLAs and flexible array members are two different things. A VLA
is an array with a non-constant size; a flexible array member is
a member of array type defined with "[]".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web