code portability

[Philip Potter]

Re: code portability

<websnarf@gmail .comwrote in message
news:1154758023 .486934.32470@i 42g2000cwa.goog legroups.com...

*something in which the content was lost in a swathe of personal attacks*

Calm down. You do not make your points any clearer by insulting others and
ignoring their arguments. While I think that *what* you were saying has some
validity [1], the way you said it was completely OTT.

You have become my first *plonk*

Philip

[1] Not that Keith Thompson has any less validity.

[Richard]

Re: code portability

Chris Torek <nospam@torek.n etwrites:

>>In article <eb2eak$2mr$1@c anopus.cc.umani toba.ca>
>>roberson@ibd. nrc-cnrc.gc.ca (Walter Roberson) writes:

>>Caution: on most 2s complement machines ... there
>>is no "additive inverse" for INT_MIN -- no element in the set
>>such that INT_MIN plus the element is 0.

>
In article <J3JwvM.LAn@cwi .nl>, Dik T. Winter <Dik.Winter@cwi .nlwrote:

>>Yes, there is. It is INT_MIN. Provided that overflow does not bother
>>the processor (which we assume, otherwise it would not be closed under
>>either addition or multiplication) .

>
Indeed, the problem is that overflow is not defined in C. It seems
to me odd for anyone to argue that 10414516 * 50120 "should" be
-2010468192 in ordinary (signed integer) arithmetic; it seems to
me more likely that it should be "caught runtime error: integer
overflow" with the default behavior being to terminate the process
(on a Unix-like system anyway). It would be better if the behavior
*were* defined as "caught at runtime" (among other things, perhaps
Yahoo finance would not show NYSE stock trading volume as a negative
number when 2147483600 + 100 becomes -2147483596 -- apparently
someone forgot to use unsigned there too). But, as we see over
and over again in computing, it tends to be more important to get
the wrong answer as fast as possible... :-)

I would be surprised and irritated to have a language like C do any
runtime checks. Its why ADA was invented :)

Failing that there are loads of libraries out there which deal with
large ints, financial rounding and so forth.

[Richard]

Re: code portability

"Philip Potter" <philip.potter@ xilinx.comwrite s:

<websnarf@gmail .comwrote in message
news:1154758023 .486934.32470@i 42g2000cwa.goog legroups.com...

>*something in which the content was lost in a swathe of personal attacks*

>
Calm down. You do not make your points any clearer by insulting others and
ignoring their arguments. While I think that *what* you were saying has some
validity [1], the way you said it was completely OTT.
>
You have become my first *plonk*

He wasnt overly rude : just somewhat miffed, as a lot of posters get,
when dealing with the typically overtly imperious tone taken by a
certain poster.

[ena8t8si@yahoo.com]

Re: code portability


Frederick Gotham wrote:

Ian Collins posted:
>

Keith Thompson wrote:

>
My objection to C's integer type system is that the names are
arbitrary: "char", "short", "int", "long", "long long", "ginormous
long". I'd like to see a system where the type names follow a regular
pattern, and if you want to have a dozen distinct types the names are
clear and obvious. I have a few ideas, but since this will never
happen in any language called "C" I won't go into any more detail.
>

Isn't that why we now have (u)int32_t and friends? I tend to use int or
unsigned if I don't care about the size and one of the exact size type
if I do.

>
>
I use "int unsigned" when I want to store a positive integer.

I use "int unsigned" when I want to store an integer nonnegative.

If, on the other hand, I want to store nonnegative integers, I
use "unsigned int" or just "unsigned".

[ena8t8si@yahoo.com]

Re: code portability


Dik T. Winter wrote:

In article <eb2eak$2mr$1@c anopus.cc.umani toba.caroberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <1154742138.310 186.94530@h48g2 000cwc.googlegr oups.com>,
<websnarf@gmail .comwrote:
>

And if you need a correctly functioning ring modulo 2**n? If you can
assume 2s complement then you've *got one*. Otherwise, you get to
construct one somehow (not sure how hard this is, I have never ever
been exposed to a system that didn't *ONLY* support 2s complement).

>
Caution: on most 2s complement machines, the *signed* integers do
not form a ring. In cases where INT_MIN is (-INT_MAX - 1)
(e.g., INT_MIN is -32768 for an INT_MAX of 32767) then there
is no "additive inverse" for INT_MIN -- no element in the set
such that INT_MIN plus the element is 0.

>
Yes, there is. It is INT_MIN. Provided that overflow does not bother
the processor (which we assume, otherwise it would not be closed under
either addition or multiplication) . That INT_MIN is its own additive
inverse is in itself not a problem. And I think it is indeed a ring.
Just as I think that signed 1's complement numbers form a ring (again,
provided that overflow is ignored).

A ones complement representation can form a ring, depending
on how overflow is handled. Which, in terms of the C standard,
makes it no different from twos complement.

But Paul Hsieh is talking about a ring mod 2**n, and in that case the
numbers are inherently unsigned. In that ring -1 == 2**n - 1.
>
Now his question was whether x << 7 would be equal to x * 128.
And indeed, that is the case, as long as there is no overflow,
it is the case, both on 1's complement and on 2's complement machines
(at least all machines I ever did use). For unsigned arithmetic and
for signed arithmetic.

For unsigned, x << 7 is equal to x * 128 whether or not there is
overflow.

And, contrary to Paul Hsieh's experience, in my career I think that
I have used 1's complement machines about as long as I have used
2's complement machines. Both about 25 years, but there is some
overlap when I used both.

Funny, I've read about various ones complement machines
but I don't think I've ever used one. I have used a
sign/magnitude machine though.

[Frederick Gotham]

Re: code portability

Ena8t posted:

>I use "int unsigned" when I want to store a positive integer.

>
I use "int unsigned" when I want to store an integer nonnegative.
>
If, on the other hand, I want to store nonnegative integers, I
use "unsigned int" or just "unsigned".

Congratulations , you've discovered that the word order is at the discretion
of the programmer.

Good luck with that.

Here's some more toys to play with:

int const inline static *const Func() { ...

static inline const int* const Func() { ...

--

Frederick Gotham

[Keith Thompson]

Re: code portability

Frederick Gotham <fgothamNO@SPAM .comwrites:

Ena8t posted:
>

>>I use "int unsigned" when I want to store a positive integer.

>>
>I use "int unsigned" when I want to store an integer nonnegative.
>>
>If, on the other hand, I want to store nonnegative integers, I
>use "unsigned int" or just "unsigned".

>
>
Congratulations , you've discovered that the word order is at the discretion
of the programmer.
>
Good luck with that.
>
Here's some more toys to play with:
>
int const inline static *const Func() { ...
>
static inline const int* const Func() { ...

Yes, it is. And how exactly is that useful? "int unsigned" is legal,
but all it's going to do is confuse the reader. "unsigned int" or
just "unsigned" is far more common, and won't confuse the reader.

Is there some reason you want to confuse your readers?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Frederick Gotham]

Re: code portability

Keith Thompson posted:

Yes, it is. And how exactly is that useful? "int unsigned" is legal,
but all it's going to do is confuse the reader.

People have different coding styles.

"unsigned int" or just "unsigned" is far more common, and won't confuse
the reader.
>
Is there some reason you want to confuse your readers?

When I have a definition (or a declaration), I put things in order of
descending importance. The most important thing comes first.

First and foremost, I specify the type.

Next, I specify things such as "long", "short".

Next, I specify signedness, e.g. "signed", "unsigned".

Next, I specify const, or volatile, or neither.

Next, I specify static, or extern, or neither.

Next, I specify inline, or not.

Next, I specify the name, which may involve asterisks, more const/volatile
qualifiers, or perhaps array bounds.

char unsigned const static inline (*const Func(void))[3]
{
char unsigned const static ch[3] = {'a','b','c'};

return &ch;
}


int main()
{
Func();
}

--

Frederick Gotham

[Ian Collins]

Re: code portability

Frederick Gotham wrote:

Keith Thompson posted:
>
>

>>Yes, it is. And how exactly is that useful? "int unsigned" is legal,
>>but all it's going to do is confuse the reader.

>
>
>
People have different coding styles.
>
>
>

>>"unsigned int" or just "unsigned" is far more common, and won't confuse
>>the reader.
>>
>>Is there some reason you want to confuse your readers?

>
>
>
When I have a definition (or a declaration), I put things in order of
descending importance. The most important thing comes first.
>
First and foremost, I specify the type.
>
Next, I specify things such as "long", "short".
>
Next, I specify signedness, e.g. "signed", "unsigned".
>
Next, I specify const, or volatile, or neither.
>
Next, I specify static, or extern, or neither.
>
Next, I specify inline, or not.
>
Next, I specify the name, which may involve asterisks, more const/volatile
qualifiers, or perhaps array bounds.
>
char unsigned const static inline (*const Func(void))[3]
{
char unsigned const static ch[3] = {'a','b','c'};
>
return &ch;
}
>
>
int main()
{
Func();
}
>

I pity anyone who has to maintain your code.

--
Ian Collins.

[Keith Thompson]

Re: code portability

Frederick Gotham <fgothamNO@SPAM .comwrites:

Keith Thompson posted:

>Yes, it is. And how exactly is that useful? "int unsigned" is legal,
>but all it's going to do is confuse the reader.

>
People have different coding styles.

Yes. That doesn't mean all styles are equally good.

>"unsigned int" or just "unsigned" is far more common, and won't confuse
>the reader.
>>
>Is there some reason you want to confuse your readers?

>
>
When I have a definition (or a declaration), I put things in order of
descending importance. The most important thing comes first.
>
First and foremost, I specify the type.
>
Next, I specify things such as "long", "short".
>
Next, I specify signedness, e.g. "signed", "unsigned".

[..]

Ok, so your style is internally consistent, but it's inconsistent with
perhaps 99.73% of other C programmers (I made up that number).

char unsigned const static inline (*const Func(void))[3]

Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

As Henry Spencer wrote in "The Ten Commandments for C Programmers",
<http://www.lysator.liu .se/c/ten-commandments.ht ml>:

... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Frederick Gotham]

Re: code portability

Ian Collins posted:

I pity anyone who has to maintain your code.

Me too if they can't get their head around word order.

--

Frederick Gotham

[Richard Heathfield]

Re: code portability

Frederick Gotham said:

Ian Collins posted:
>

>I pity anyone who has to maintain your code.

>
Me too if they can't get their head around word order.

If Yoda great Jedi Master is, why English sentences he cannot in the right
order speak?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Re: code portability

Keith Thompson posted:

Ok, so your style is internally consistent, but it's inconsistent with
perhaps 99.73% of other C programmers (I made up that number).

I like my style though.

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

There are flaws in the way most programmers do things; my style tries to
improve on this.

> char unsigned const static inline (*const Func(void))[3]

>
Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

If they're only used to reading their own code, then they could do with the
practise of seeing other people's code. Do they brain-freeze when they see:

int const *p

rather than:

const int *p

As Henry Spencer wrote in "The Ten Commandments for C Programmers",
><http://www.lysator.liu .se/c/ten-commandments.ht ml>:
>
... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

I make up the rules as I go along. I used to like:

const int *p;

, but now I use:

int const *p;

--

Frederick Gotham

[Ian Collins]

Re: code portability

Frederick Gotham wrote:

Ian Collins posted:
>
>

>>I pity anyone who has to maintain your code.

>
>
>
Me too if they can't get their head around word order.
>

They shouldn't have to. The excellent quote at the end of Keith's
comment is very pertinent to your style.

--
Ian Collins.

[Richard]

Re: code portability

Keith Thompson <kst-u@mib.orgwrites :

Frederick Gotham <fgothamNO@SPAM .comwrites:

>Keith Thompson posted:

>>Yes, it is. And how exactly is that useful? "int unsigned" is legal,
>>but all it's going to do is confuse the reader.

>>
>People have different coding styles.

>
Yes. That doesn't mean all styles are equally good.
>

>>"unsigned int" or just "unsigned" is far more common, and won't confuse
>>the reader.
>>>
>>Is there some reason you want to confuse your readers?

>>
>>
>When I have a definition (or a declaration), I put things in order of
>descending importance. The most important thing comes first.
>>
>First and foremost, I specify the type.
>>
>Next, I specify things such as "long", "short".
>>
>Next, I specify signedness, e.g. "signed", "unsigned".

[..]
>
Ok, so your style is internally consistent, but it's inconsistent with
perhaps 99.73% of other C programmers (I made up that number).
>

> char unsigned const static inline (*const Func(void))[3]

>
Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

And aint that the truth. I have a feeling that Fred has recently
mastered a few keywords and is bursting to use them.

>
As Henry Spencer wrote in "The Ten Commandments for C Programmers",
<http://www.lysator.liu .se/c/ten-commandments.ht ml>:
>
... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

Very good. But there is something more important : concistency across
code base and anyone (I often suspect that not many here do) who works
on large, legacy systems knows the importance of good clear basic coding
styles which can be relatively easily understood by anyone with a
reasonable knowledge of the programming language in question.

I remember having one guy express his displeasure at the new edicts
which pretty much banned him from using his programming creativity on a
company code base. He was informed that at home he could program as he
saw fit : but on the huge, maintained system it was the documented way
or the highway.