468,490 Members | 2,606 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,490 developers. It's quick & easy.

Converting unsigned long to string in C

Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?
In C++ there is a function _ultoa so wanted a similar one in C .
Regards,
Shivaraj
Feb 24 '08 #1
107 24171
bm********@gmail.com writes:
Could any one tell me how to convert a unsigned long value into string
(char *) ?
You want to look at snprintf with a format of "%lu". If you are not
lucky enough to have snprintf use sprintf with a large enough buffer.

--
Ben.
Feb 24 '08 #2
bm********@gmail.com wrote:
Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?
In C++ there is a function _ultoa so wanted a similar one in C .
Regards,
Shivaraj
sprintf and snprintf will do what you want.

<OT>

You probably want to use string streams in C++, rather than a primitive
like _ultoa.

</OT>

Feb 24 '08 #3
bm********@gmail.com said:
Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?
A char * isn't a string. It's just a way of pointing to one.
In C++ there is a function _ultoa so wanted a similar one in C .
C++ has no such function. It is almost certainly an extension provided by
your implementation.

First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

#include <limits.h>
#include <stdio.h>

int main(void)
{
unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
sprintf(s, "%lu", n);
printf("The string value is [%s]\n", s);
return 0;
}

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 24 '08 #4
Richard Heathfield <rj*@see.sig.invalidwrites:
bm********@gmail.com said:
>Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?

A char * isn't a string. It's just a way of pointing to one.
>In C++ there is a function _ultoa so wanted a similar one in C .

C++ has no such function. It is almost certainly an extension provided by
your implementation.

First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

#include <limits.h>
#include <stdio.h>

int main(void)
{
unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
sprintf(s, "%lu", n);
printf("The string value is [%s]\n", s);
return 0;
}
I hate this "fad" of using "sizeof n". It reads horribly.
Feb 24 '08 #5

"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:9Z******************************@bt.com...
bm********@gmail.com said:
First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

I would do two things different. First its not immediately obvious where the
buffer size calculation comes from so I'd put that in a macro.
Second, if n becomes signed in the future you need one more space if n
becomes negative. The code gets a little easier to maintain then

Feb 24 '08 #6
In article <fp**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:
>I hate this "fad" of using "sizeof n". It reads horribly.
I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

-- Richard

--
:wq
Feb 24 '08 #7
bm********@gmail.com wrote:
Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?
sprintf and snprintf do that job quite nicely.
In C++ there is a function _ultoa so wanted a similar one in C .
You have been misled. There is no C++ function named _ultoa. Your
implementation may provide a non-standard, non-portable function with
that name, and if it does so for C++, it may do so for C. There are,
with less than a handful of exceptions, no standard functions in C or
C++ with names beginning with an underscore. If you see such an
identifier, be alert to the possibility that you are looking at a
completely non-standard, non-portable identifier, and even the next
edition of your implementation might not support it
Feb 24 '08 #8
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <fp**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:
>>I hate this "fad" of using "sizeof n". It reads horribly.

I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.
I disagree. Since sizeof really is an operator, it makse sense to
treat it as one. Making it look like a function call is misleading.

Do you use extra parentheses on return statements?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 24 '08 #9
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.
>I disagree. Since sizeof really is an operator,
What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
>Making it look like a function call is misleading.
Making it look like an operator is "misleading" too; if it was an
operator you ought to be able to write "sizeof int". But anyway, what
do you mean, misleading? Who could it mislead?
>Do you use extra parentheses on return statements?
"return" is a statement; it can't be used in an expression. There
isn't anything for it to be consistent with, and there aren't two
different syntaxes depending on its operand.

-- Richard

--
:wq
Feb 24 '08 #10
Richard Tobin wrote:
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
[...]
>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator." For
example,

6.5.3.4 The sizeof operator
Constraints
1) The sizeof operator shall not be applied to [...]
Semantics
2) The sizeof operator yields the size [...]

--
Eric Sosman
es*****@ieee-dot-org.invalid
Feb 24 '08 #11
Richard wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:

...
> char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long time.
Feb 24 '08 #12
Richard Tobin wrote:
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
>>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.
>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"?
Presumably in the sense that it is an operator.
It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
It's an operator, just like any other operator except for an extension
which allows it to operate on parenthesized type names.
... if it was an
operator you ought to be able to write "sizeof int".
Why? To be consistent with 'a *= int' and '47 + int'? As far as I
recall, sizeof is the only operator which can operate on type names.
There's a rule that type names have to be in parenthesis when being
operated on. I expect that if any other operator gets added which can
operate on type names, the same rule will apply.
...
Feb 24 '08 #13
In article <oJ******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:
>>I disagree. Since sizeof really is an operator,
>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."
Which is not relevant to whether it's more or less confusing to write
it without parentheses.

-- Richard
--
:wq
Feb 24 '08 #14
Richard Tobin wrote:
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
>>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.
>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"?
In the sense that it actually is an operator, as defined by the standard

Feb 25 '08 #15
Richard Tobin wrote:
In article <oJ******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:
>>>I disagree. Since sizeof really is an operator,
>>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
> The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."

Which is not relevant to whether it's more or less confusing to write
it without parentheses.
So what?
Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Feb 25 '08 #16
Richard Heathfield wrote:
unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
Where are you getting "+ 2" from?

--
pete
Feb 25 '08 #17
pete <pf*****@mindspring.comwrites:
Richard Heathfield wrote:
> unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

Where are you getting "+ 2" from?
I image it is habit from the general case.

Here is low-down in case anyone is interested. It would be nice if
n_bits/3 were enough for the decimal representation of an unsigned
integer n_bits wide, but it is not. Interestingly is *is* enough for
C's unsigned long, since the longest integers for which this
expression fails to be large enough is 20 bits -- and C guarantees
more than 20 bits for unsigned long.

There are three bit sizes at which the more generous (n_bits + 1)/3 is
not enough: 1, 4, 7 and 10. The minimum range guaranteed for C's
unsigned int means that (CHAR_BIT * sizeof n + 1)/3 is enough for that
type, but not for unsigned char if CHAR_BIT is 10.

The upshot is that if the type not constrained, you need to add 2 and
divide by three and I imagine many people just remember this as rule
of thumb (I did until a few minutes ago!).

Obviously, add one for a sign bit and one for null as required.

--
Ben.
Feb 25 '08 #18
pete wrote:
Richard Heathfield wrote:
> unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

Where are you getting "+ 2" from?
3 - 1

;-)

Familiar trick: To divide integers M / N and get the
ceiling ("round up") instead of floor ("truncate"), divide
(M + N - 1) / N instead. Work it out for yourself; choose
a value like N==3 and go through the possibilities.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Feb 25 '08 #19
Serve Laurijssen said:
>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:9Z******************************@bt.com...
<snip>
> char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];


I would do two things different. First its not immediately obvious where
the buffer size calculation comes from so I'd put that in a macro.
Second, if n becomes signed in the future you need one more space if n
becomes negative. The code gets a little easier to maintain then
The second point is trivially true (but it's still a point worth making).
The first point is more a matter of opinion but, as a matter of fact, I
agree with you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 25 '08 #20
In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>>>I disagree. Since sizeof really is an operator,
>>>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.
>> The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."
>Which is not relevant to whether it's more or less confusing to write
it without parentheses.
>So what?
Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.
Look up "context" in a dictionary.

-- Richard
--
:wq
Feb 25 '08 #21
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
>Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)
I have no objection to operators that are words, but C doesn't have
any apart from sizeof. That makes it look out of place and
distracting in an expression. In a language where such things
were common, it wouldn't.

It is of course just a matter of taste.

-- Richard
--
:wq
Feb 25 '08 #22
Richard Tobin said:
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
>>Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)

I have no objection to operators that are words, but C doesn't have
any apart from sizeof.
....except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 25 '08 #23
In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>I have no objection to operators that are words, but C doesn't have
any apart from sizeof.
>...except for:

* and
[...]
10/10 for pedantry.

-- Richard
--
:wq
Feb 25 '08 #24
Richard Tobin said:
In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>I have no objection to operators that are words, but C doesn't have
any apart from sizeof.
>>...except for:

* and
[...]

10/10 for pedantry.
Strictly speaking, it should be 11/11. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 25 '08 #25
Richard Tobin wrote:
In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
(RT wrote)
>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.
>Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.

Look up "context" in a dictionary.
Look up "irrelevant". Its an operator in any context. If you don't like
that, raise a DR. If you meant to ask a different question, then say so.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Feb 25 '08 #26
"J. J. Farrell" <jj*@bcs.org.ukwrites:
Richard wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:

...
>> char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

I hate this "fad" of using "sizeof n". It reads horribly.

What ""fad""? sizeof and its usage has been part of C for a long time.
The fad that I have almost never seen it in production code because
..... it reads horribly. Simple. Practical reasons. The clique here use
it all the time because they are the clique.

Feb 25 '08 #27
Mark McIntyre <ma**********@spamcop.netwrites:
Richard Tobin wrote:
>In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
(RT wrote)
>>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.
>>Your question above was "in what sense is it really an
operator?". The answer is that it is defined as such.

Look up "context" in a dictionary.

Look up "irrelevant". Its an operator in any context. If you don't
like that, raise a DR. If you meant to ask a different question, then
say so.
So you dont think it reads horribly?

it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

x = x + sizeof y + 3;

reads like crap in the context of the C programming language.

Operator? Get out of it.

sizeof(y) is obvious to anyone. The above is horrendous. And I dont
believe anyone that says its "as obvious" in the context of other C
code.
Feb 25 '08 #28
Richard wrote:
>
it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard
From the horse's mouth, folks.

--
Er*********@sun.com
Feb 25 '08 #29
Richard <de***@gmail.comwrites:
Operator? Get out of it.
I can write

x = sizeof (ptr+1)->field;

which is valid, but would be meaningless if sizeof was a function returning
an int.

I can't write

x = (sizeof)(ptr);

which would be valid if sizeof was a function.

Luckily, I don't think there is a case where interpreting sizeof as a
function lead to a valid but different parse as using its true definition
excepted variations on the obfuscated contest candidate:

x = sizeof(i)[ptr];
You may want to force additional parenthesis in your coding standard if you
find them more readable. I've no strong opinion about them. But don't let
your cosmetic preference (as cosmetic as prefering the absence of them)
induce you into error, sizeof is not a function and doesn't behave like
one.

A+

--
Jean-Marc
Feb 25 '08 #30
Richard Heathfield <rj*@see.sig.invalidwrites:
Richard Tobin said:
>In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>>I have no objection to operators that are words, but C doesn't have
any apart from sizeof.
>>>...except for:

* and
[...]

10/10 for pedantry.

Strictly speaking, it should be 11/11. :-)
Strictly speaking, 10/10 == 11/11.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 25 '08 #31
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Richard Tobin said:
>>In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
I have no objection to operators that are words, but C doesn't have
any apart from sizeof.

...except for:

* and
[...]

10/10 for pedantry.

Strictly speaking, it should be 11/11. :-)

Strictly speaking, 10/10 == 11/11.
It depends on what you mean by it. In context, 10/10 suggests "10 out of
10", rather as if it were the score on a test, i.e. in the spirit of "10
questions right out of 10 questions asked", rather than "10 divided by
10". Now, "10 right out of 10 asked" is /not/ the same as "11 right out of
11 asked" (the latter being the more difficult achievement), so 10/10
isn't necessarily == 11/11.

(Of course, in a C context they do evaluate to the same result, but we all
knew that we all knew that already, right?)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 25 '08 #32
Eric Sosman <Er*********@sun.comwrites:
Richard wrote:
>it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

From the horse's mouth, folks.
Indeed.

The simple fact is that sizeof *is* an operator, whether anyone likes
it or not. You (that's a generic "you") can use all the parentheses
you like in your own code, but if you can't cope with "sizeof x", then
you can't cope with valid C.

If K&R had chosen to use, say, "$" rather than "sizeof" as the symbol
for this operator, we wouldn't be having this discussion.

(There are C coding styles that I dislike, but I can deal with them,
and even use them if necessary. I don't question the motivation or
integrity of those whose opinions differ from mine.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 25 '08 #33
On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:
Richard Tobin said:
>I have no objection to operators that are words, but C doesn't have any
apart from sizeof.

...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq
They're operators in C++. They're macros in C.
Feb 25 '08 #34
Harald van D?k wrote:
On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:
>Richard Tobin said:
>>I have no objection to operators that are words, but C doesn't have
any apart from sizeof.

...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq

They're operators in C++. They're macros in C.
Any reason to make them macros instead of keywords, as in C++?

Feb 25 '08 #35
santosh said:
Harald van D?k wrote:
<snip>
>They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?
By making them macros, the Standard attempts to avoid breaking existing
code. After all, these names are in C90 user namespace! So the Standard
stops you from getting access to these operators unless you specifically
request it by #including iso646.h - or at least, that seems to me to be
the most likely rationale.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 25 '08 #36
On Tue, 26 Feb 2008 00:26:45 +0530, santosh wrote:
Harald van D?k wrote:
>On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:
>>Richard Tobin said:
I have no objection to operators that are words, but C doesn't have
any apart from sizeof.

...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq

They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?
To minimise the modifications required for compilers, I believe. It's only
recently that C++ compilers handle the alternate spellings of the
operators correctly (including such things as the required diagnostic for
the syntax error in #ifdef and), when all that complexity is really not
necessary. For correct programs, the only effective difference between a
macro "and" and an operator "and" is how they are stringised, and this
will affect very few programs.
Feb 25 '08 #37
Harald van D?k wrote:
On Tue, 26 Feb 2008 00:26:45 +0530, santosh wrote:
>Harald van D?k wrote:
>>On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:
Richard Tobin said:
I have no objection to operators that are words, but C doesn't
have any apart from sizeof.

...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq

They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?

To minimise the modifications required for compilers, I believe. It's
only recently that C++ compilers handle the alternate spellings of the
operators correctly (including such things as the required diagnostic
for the syntax error in #ifdef and), when all that complexity is
really not necessary. For correct programs, the only effective
difference between a macro "and" and an operator "and" is how they are
stringised, and this will affect very few programs.
Thanks to both Richard and Harald.

Feb 25 '08 #38
On 25 Feb 2008 at 18:01, Richard Heathfield wrote:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Richard Tobin said:
In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>I have no objection to operators that are words, but C doesn't have
>any apart from sizeof.

>...except for:
>
>* and
>[...]

10/10 for pedantry.

Strictly speaking, it should be 11/11. :-)

Strictly speaking, 10/10 == 11/11.

It depends on what you mean by it. In context, 10/10 suggests "10 out of
10", rather as if it were the score on a test, i.e. in the spirit of "10
questions right out of 10 questions asked", rather than "10 divided by
10". Now, "10 right out of 10 asked" is /not/ the same as "11 right out of
11 asked" (the latter being the more difficult achievement), so 10/10
isn't necessarily == 11/11.

(Of course, in a C context they do evaluate to the same result, but we all
knew that we all knew that already, right?)
Another insightful discussion, getting right to the heart of a juicy C
problem...

Feb 25 '08 #39
On 25 Feb 2008 at 17:12, Eric Sosman wrote:
Richard wrote:
>>
it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

From the horse's mouth, folks.
Yes - shock horror, Richard isn't one of the C language fundamentalists
who believe that the ISO Standard was given to us on tablets of gold,
and shouldn't be interpreted in the light of *real world* experience.

Feb 25 '08 #40
On Feb 25, 4:30 pm, Richard <de...@gmail.comwrote:
"J. J. Farrell" <j...@bcs.org.ukwrites:
Richard wrote:
Richard Heathfield <r...@see.sig.invalidwrites:
...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here use
it all the time because they are the clique.
It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];
Feb 25 '08 #41
William Pursell wrote:
On Feb 25, 4:30 pm, Richard <de...@gmail.comwrote:
>"J. J. Farrell" <j...@bcs.org.ukwrites:
Richard wrote:
Richard Heathfield <r...@see.sig.invalidwrites:
>...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
>I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long
time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here
use it all the time because they are the clique.

It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];
Don't you mean?

char s[(CHAR_BIT * sizeof(n) + 2) / 3 + 1];

Feb 25 '08 #42

"Richard" <de***@gmail.comschreef in bericht
news:fp**********@registered.motzarella.org...
Mark McIntyre <ma**********@spamcop.netwrites:
>Richard Tobin wrote:
>>In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
(RT wrote)
>>>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.

Your question above was "in what sense is it really an
operator?". The answer is that it is defined as such.

Look up "context" in a dictionary.

Look up "irrelevant". Its an operator in any context. If you don't
like that, raise a DR. If you meant to ask a different question, then
say so.

So you dont think it reads horribly?
I have entered the 21st century and use syntax highlighting. You can
immediately spot the operator with or without parentheses. Things reading
horribly is only one's opinion
Feb 25 '08 #43
Richard Harter wrote:
>
In effect, ordinary C operators are functions in disguise, i.e.
functions with special syntax. Their arguments are the values of
expressions; [...]
This is true only of a subset of C's operators.
Obvious exceptions are the -and . operators, whose
right-hand operands are not values at all. Also, I
think you'll find it difficult to write functions that
are equivalent to ++ and -- (in either position), to =
and += and their brethren, to (short) and (unsigned char)
and such, to ?:, and to ().

--
Er*********@sun.com
Feb 25 '08 #44
santosh wrote:
William Pursell wrote:
>On Feb 25, 4:30 pm, Richard <de...@gmail.comwrote:
>>"J. J. Farrell" <j...@bcs.org.ukwrites:

Richard wrote:
Richard Heathfield <r...@see.sig.invalidwrites:
...
> char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long
time.
The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here
use it all the time because they are the clique.
It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];

Don't you mean?

char s[(CHAR_BIT * sizeof(n) + 2) / 3 + 1];
Can't see why he would - that makes even less sense. At least William
Pursell's parenthesis helps readers who aren't confident of operator
precedence; yours does nothing except obfuscate things a little.
Feb 25 '08 #45
On Feb 25, 4:29 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <87y799u5za....@kvetch.smov.org>,
Keith Thompson <ks...@mib.orgwrote:
Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)

I have no objection to operators that are words, but C doesn't have
any apart from sizeof. That makes it look out of place and
distracting in an expression. In a language where such things
were common, it wouldn't.

It is of course just a matter of taste.

-- Richard
--
:wq
Yeah, sizeof is an odd duck, but C is a menagerie of odd ducks, so
it's never really bothered me.
Feb 25 '08 #46
Eric Sosman wrote:
Richard wrote:
>it makes no sense to me whatsoever and I dont give a monkeys
uncle about whats in the standard

From the horse's mouth, folks.
Please don't feed the troll.

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

Feb 25 '08 #47
Richard Heathfield wrote:
Richard Tobin said:
>Keith Thompson <ks***@mib.orgwrote:
>>Note that some languages have a number of operators that use
keywords (For example, Ada has "and", "or", "xor", "not", "mod",
"rem", "abs", "not", even though the fundamental arithmetic
operators use the usual symbols "+", "-", "/", "*".)

I have no objection to operators that are words, but C doesn't
have any apart from sizeof.

...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq
In general, those require #include <iso646.hand are all #defines.

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

Feb 25 '08 #48
Richard Tobin wrote:
In article <47****************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:
>On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<ks***@mib.orgwrote:
>>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.
Of course, the standards committee would've felt compelled to introduce
another trigraph for it. Perhaps ??S ? :)

Or I suppose they could solve the ISO-646 problem by making an
alternative spelling for the same operator.

(Hi y'all)

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 26 '08 #49
Micah Cowan <mi***@cowan.namewrote:
Richard Tobin wrote:
In article <47****************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:
On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<ks***@mib.orgwrote:
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.

Of course, the standards committee would've felt compelled to introduce
another trigraph for it. Perhaps ??S ? :)
None of the other trigraphs have letters in them. Perhaps ??% ?
Or I suppose they could solve the ISO-646 problem by making an
alternative spelling for the same operator.
I don't think that's in EBCDIC... it's certainly not in ASCII, and it's
even missing from some ASCII-based charsets (e.g., ISO-8859-15 and -16).
So you'd dissolve a bit more than just ISO-646.
(Hi y'all)
Hey, look who's back! Where've you been?

Richard
Feb 26 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.