«

"santosh" <> wrote in message
news:fq3i89$9rg$...
> Bartc wrote:

>> Maybe the standard should have gone a bit further and defined
>> lengthof() to return the bound of an array. Using sizeof for this is
>> rather clumsy.
>
> Could have. But it's easy enough to compute with sizeof.
>
> int arr[4];
>
> size_t size_of_arr = sizeof arr / sizeof arr[0];

Clumsy like I said -- sizeof appears twice, you also have the array name
twice (imagine a much longer name, especially one only slightly different
from another), plus you have "/" and "[0]" thrown in for good measure. A
recipe for errors.

You don't need more than - the array name, and the operator.

>> I suppose my real quibble is the use of the macro system in C, which
>> I'm sure must have dogged its development; if anyone comes up with a
>> real enhancement, someone else is bound to come up with an ugly macro
>> hack which does 90% of it - badly.
>>
>> And the macro system which I'm guessing was put there for the benefit
>> and edification of the users, instead has been used by the standard as
>> a cheap way of extending the language.
>
> Can you propose a better way?

That's a dangerous thing to ask an amateur language designer!

--
Bart

Bartc wrote:

>
> "santosh" <> wrote in message
> news:fq3i89$9rg$...
>> Bartc wrote:
>
>>> Maybe the standard should have gone a bit further and defined
>>> lengthof() to return the bound of an array. Using sizeof for this is
>>> rather clumsy.
>>
>> Could have. But it's easy enough to compute with sizeof.
>>
>> int arr[4];
>>
>> size_t size_of_arr = sizeof arr / sizeof arr[0];
>
> Clumsy like I said -- sizeof appears twice, you also have the array
> name twice (imagine a much longer name, especially one only slightly
> different from another), plus you have "/" and "[0]" thrown in for
> good measure. A recipe for errors.
>
> You don't need more than - the array name, and the operator.

Another good solution (keeping in mind that the context is C) is to
simply make sure that you store the array's length (which you'll have
to supply during it's declaration) somewhere convenient.

#define MY_ARR_SIZE SOME_VALUE
/* ... */
const size_t my_arr_length = MY_ARR_SIZE;
int my_arr[MY_ARR_SIZE];

Of course, you could dispense with the size_t variable and use
MY_ARR_SIZE too, though type safety is lost. Unfortunately C doesn't
permit static array size to be specified by const qualified variables,
since they cannot be assumed to be present at compile time (Except for
VLAs, which is a different matter).

C probably isn't a good choice if you want a feature-rich or elegant
language (for some definitions of elegant and feature-rich).

>>> I suppose my real quibble is the use of the macro system in C, which
>>> I'm sure must have dogged its development; if anyone comes up with a
>>> real enhancement, someone else is bound to come up with an ugly
>>> macro hack which does 90% of it - badly.
>>>
>>> And the macro system which I'm guessing was put there for the
>>> benefit and edification of the users, instead has been used by the
>>> standard as a cheap way of extending the language.
>>
>> Can you propose a better way?
>
> That's a dangerous thing to ask an amateur language designer!

The purpose, I believe, was to introduce these features without breaking
existing code that might legitimately be using identifiers
like "and", "bitor" etc. That was probably the chief reason why they
are added as macros and furthermore, only defined in <iso646.h>, a
header that only programs that needed it's facilities would include.
Making them keywords would have (I suppose) broken existing code.

There are more complicated alternatives one can think off, but this was
probably the simplest acceptable solution that the committee could come
up with, given their stated mandate to be as "silent" as possible with
changes to the language.

William Pursell <> writes:

> On Feb 27, 3:44 am, Richard <de...@gmail.com> wrote:
>> Michael Mair <Michael.M...@invalid.invalid> writes:
>> > Richard wrote:
>
>> >> I have NEVER known an
>> >> industry C programmer use that horrible style. Really.
>>
>> > You mean face to face, I guess. Via usenet, you know several if you
>> > read comp.lang.c carefully.
>>
>> Of course I mean face to face. On big projects with code rules and
>> guidelines for consistent look and feel to all code.
>
> I think Richard is accurate about the percentage usage
> of "sizeof x". Most programmers don't use it. Most
> don't know it is valid syntax. Most production code
> doesn't use it. Unfortunately it is also the case
> that most programmers are ignorant and have no sense
> of aesthetics. Richard obviously has a strong aesthetic
> sense, which in this case is in disagreement with the
> sensibility of many others in this thread. When I
> first saw "sizeof x", I was annoyed that I hadn't seen
> it long before, and thought it was amazing that I had
> not. How did such an aesthetically appealing usage
> avoid my eyes for so long? Because I was reading code
> written by incompetent boobs with no aesthetic sense
> who were probably following some absurd coding standard
> written by persons who may or may not have
> known that sizeof could be applied to an object and
> mandated that it only be used in the form "sizeof(T)".
> (Well, really, it's probably because I wasn't coding
> very much at all, and what code I was reading was
> obfuscated Perl, but that's a different story which
> is clearly OT. Here on CLC, we must pretend that
> C is the only language.)
>
> In short, it is not because sizeof is an operator
> that I use "sizeof x". It is because I find it
> more aesthetically appealing. Richard's sense of
> aesthetics is different.

How do you find it more pleasing? In what way? Are you sure its not
becauase you know it to be an operator?

Would you like to see

printf "hello%s" "world";

or something equally as contrived for example?

Keith Thompson <kst-> writes:

> Richard <devr_@gmail.com> writes:
>> Keith Thompson <kst-> writes:
> [...]
>>>>>> Richard wrote:
>>>>>>> it makes no sense to me whatsoever and I dont give a monkeys uncle about
>>>>>>> whats in the standard
> [...]
>
>>> I'm not missing your point; I'm simply disagreeing with you.
>>>
>>> You find "sizeof n" ugly and difficult to read. That's fine;
>>> I don't expect, or even particularly want, you to change your mind.
>>>
>>> I find the "sizeof n" form cleaner and easier to read than the
>>> "sizeof(n)" form. For me, *because* "sizeof" is an operator,
>>
>> Exactly. But you do NOT have to think of it as one.
>
> So what? I do think of "sizeof" as an operator. You're saying
> there's something wrong with that. That's absurd.
>
> [...]
>
>> I DO care about whats in the standard.
>
> Glad to hear it. Note that that directly contradicts what you wrote
> upthread.

Only if you want to be an anal retentive fool. I was referring before to
it being called an "operator" in the standard. This does not dictate how
I USE it.

Ben Bacarisse <> writes:

> Richard <devr_@gmail.com> writes:
>
>> I simply do not believe that in the context of other C code that this
>>
>> x= y + sizeof z + a;
>>
>> is easier to read than:
>>
>> x= y + sizeof(z) + a;
>>
>> for anyone.
>
> I find it amazing that you can't believe this. I can see how you may
> have moved in a programming circle where this looks odd and so, if you
> ask, the people around you agree. But how can you make the leap to
> not believing it of anyone? y + sizeof z + a has only one plausible
> meaning in C and only one plausible meaning even if you don't know C.
>
> To anyone exposed to languages with many word-like operators, or to
> those where juxtaposition implies a tight binding, it will be
> obvious. For it to have any meaning but the right one, the syntax
> would have to be absurd.

For starters theres the

"is it sizeof(x)+y" or "sizeof(x+y)" double take. For seconds, well, I
give up.

I do not believe you don't get my point here. sizeof is a one off in C as
far as I can see. And you reckoning this "one off" is easy and as clear as
"sizeof(y)"?

I cant see it myself.

My experience is that almost nowhere other than here have I seen "sizeof
x + y" used in preference to "sizeof(x)+y";

santosh <> writes:

> Ben Bacarisse wrote:
>
>> Richard <devr_@gmail.com> writes:
>>
>>> I simply do not believe that in the context of other C code that this
>>>
>>> x= y + sizeof z + a;
>>>
>>> is easier to read than:
>>>
>>> x= y + sizeof(z) + a;
>>>
>>> for anyone.
>>
>> I find it amazing that you can't believe this. I can see how you may
>> have moved in a programming circle where this looks odd and so, if you
>> ask, the people around you agree. But how can you make the leap to
>> not believing it of anyone? [...]
>
> Richard has unfortunately gradually developed a "Spinoza" like complex,
> wherein he is compelled to suspect as posturing anything that a poster
> whom he considers as a part of the hypothetical "clique" says.

No he hasn't. He knows that the clique are very proud of their ability
to use standards C and the ability to use something as fundamentally
"silly" as this alternative syntax is, frankly, rather amusing. I would
hazard a guess that his alternative usage is in less than 1% of code
worldwide. Only in CLC is it "equally as clear".

Richard <devr_@gmail.com> writes:

> Ben Bacarisse <> writes:
>
>> Richard <devr_@gmail.com> writes:
>>
>>> I simply do not believe that in the context of other C code that this
>>>
>>> x= y + sizeof z + a;
>>>
>>> is easier to read than:
>>>
>>> x= y + sizeof(z) + a;
>>>
>>> for anyone.
>>
>> I find it amazing that you can't believe this.
<snip>
>> To anyone exposed to languages with many word-like operators, or to
>> those where juxtaposition implies a tight binding, it will be
>> obvious. For it to have any meaning but the right one, the syntax
>> would have to be absurd.
>
> For starters theres the
>
> "is it sizeof(x)+y" or "sizeof(x+y)" double take. For seconds, well, I
> give up.

To *you*? Don't you see. I've spent so many years using languages
that have word-like unary "operators" there is no double take. They
all bind very tightly. The first was SASL in 1978. It looks entirely
normal to me. Please try to accept that. I don't want to persuade
you to do anything you don't like, but I can't see how you can access
my internal parser.

> I do not believe you don't get my point here.

I get it. My problem is that you don't believe me.

> sizeof is a one off in C as
> far as I can see. And you reckoning this "one off" is easy and as clear as
> "sizeof(y)"?

Yes, it is a one-off, but only in C. It one of the parts of C that
looks quite natural -- to me. If C insisted on 'sizeof(expression)',
I'd go with that but it would strike me as odd that this built-in
operator required function syntax. The 'sizeof(type-name)' I can
accept since it is, in effect:

sizeof <applied to> (some cast)

The brackets are there because of the ambiguous syntax of type names,
not because of a function-like call.

> My experience is that almost nowhere other than here have I seen "sizeof
> x + y" used in preference to "sizeof(x)+y";

I don't have much code here to scan, but my Linux kernel source has
more than 1200 instances of this form of sizeof. Much less than the
other form, but my point in not about the frequency of use, but about
your insistence than anyone who thinks differently about is being silly
(that is from another post in this thread).

--
Ben.

In article <fq3psc$dm3$>, Richard <devr_@gmail.com> wrote:

>For starters theres the
>
>"is it sizeof(x)+y" or "sizeof(x+y)" double take.

Don't be ridiculous; the meaning is just as obvious as in
x = y * a + b;

Or do you look at that statement and have trouble deciphering whether the
right side means ((y * a) + b) or (y * (a + b)) ?

In article <fq3pv1$dm3$>,
Richard <devr_@gmail.com> wrote:

>I would
>hazard a guess that his alternative usage is in less than 1% of code
>worldwide. Only in CLC is it "equally as clear".

Not as little as that, but the Google n-gram corpus shows that
2,703,650 of 2,871,816 occurrences of sizeof are followed by an open
parenthesis. Of course we don't know how many of them are followed
by types.

-- Richard
--
:wq

Richard Heathfield wrote:
> CBFalconer said:
>> Richard Tobin wrote:
>>> Richard Harter <> wrote:
>>>> Keith Thompson <kst-> wrote:
>>>>
>>>>> If K&R had chosen to use, say, "$" rather than "sizeof" as the
>>>>> symbol for this operator, we wouldn't be having this discussion.
>>>
>>> It would remove one of my objections, anyway.
>>
>> And they would have been thoroughly criticized. '$' is not
>> available on many keyboards. Think UK, France, Germany, for
>> example. It is not a portable character.
>
> $ is in the ASCII character set (code point 36) and the EBCDIC
> character set (code point 91). It is present on French keyboards
> (between ^ and *), Hungarian keyboards (sharing a key with
> e-acute), Polish keyboards (sharing a key with that funny
> w-sounded L with the line through it) and UK, German, Croatian,
> Slovak, Czech, Italian, Spanish, Latin American, Portuguese, and
> Japanese keyboards (shift-4). It is rather more portable than,
> say, the two square bracket characters [], which caused me one or
> two (minor) portability problems when I was working on mainframes.

I believe you. However, I can definitely remember seeing a
definition where that character was called 'local currency symbol',
or similar. Maybe that preceded general tightening of the ASCII
spec. And you can't deny that many keyboards are missing it.
Especially typewriters (remember them?).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com