«

Eric Sosman <> writes:

> On 10/21/2012 10:28 PM, Steve Thompson wrote:
>> On Mon, Oct 22, 2012 at 02:27:01AM +0100, Ben Bacarisse wrote:
>>>
>>> There's a terminology confusion here. Your flexible array member is
>>> just that, it's not a VLA. Variable length arrays are not permitted in
>>> structs and flexible array members can only appear, unsurprisingly, in a
>>> struct.
>>
>> I suppose so. Simply stated, anytime I use "something foo[]", it will
>> usually be at the end of a struct. Good enough?
>
> No, not unless you delete "usually."

That's overly restrictive, isn't it? something foo[] can legally appear
in places other than at the end of a struct.

He should, perhaps, have said "Simply stated, anytime I use 'something
foo[]' in a struct, it will be at the end" but what he said is fine by
me.

>> Really, you ought to have read what I meant, rather than reading what I
>> wrote.
>
> If only the compiler would do so ...

--
Ben.

Ben Bacarisse <> writes:

> Eric Sosman <> writes:
>
>> On 10/21/2012 10:28 PM, Steve Thompson wrote:
<snip>
>>> [...] Simply stated, anytime I use "something foo[]", it will
>>> usually be at the end of a struct. Good enough?
>>
>> No, not unless you delete "usually."
>
> That's overly restrictive, isn't it? something foo[] can legally appear
> in places other than at the end of a struct.

That's point's been made. I should have read to the end of the thread.
Sorry for the noise...

<snip>
--
Ben.

Steve Thompson <> 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".

Whatever you meant, the fact it that `a` *isn't* a pointer; it's
the name of an object of type `struct point`, and the name `a`
certainly can be used in an expression: as the LHS or RHS of an
assignment, as a function argument, as an argument to `sizeof` or
`&`, as the left operand of `.`, and probably in other ways that
I haven't thought of. Of course `&a` is a pointer (not a pointer
object, but an expression of pointer type).

> 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.

--
Keith Thompson (The_Other_Keith) kst- <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"

Steve Thompson <> writes:

> On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
>> Steve Thompson <> 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.

I am not surprised. I would have found it totally baffling when I was
learning C. I find it baffling even now, having learnt C!

Whatever goes on under the hood (and I'd dispute that 'a' is "really a
pointer") it's much easier to learn a language in its own terms, at
least as far as that's possible.

In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
expression, just as if it had been declared to be an int. trying to
reconcile this with some model that says it's a pointer (when it isn't
one) is bound to be confusing.

<snip>
--
Ben.

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.

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;

"Steve Thompson" <> wrote in message
news:...

> 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

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

BartC wrote:
> "Steve Thompson" <> wrote in message
> news:...
>
>> 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

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?