Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Converting unsigned long to string in C

Reply
Thread Tools

Converting unsigned long to string in C

 
 
Antoninus Twink
Guest
Posts: n/a
 
      02-25-2008
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.

 
Reply With Quote
 
 
 
 
William Pursell
Guest
Posts: n/a
 
      02-25-2008
On Feb 25, 4:30 pm, Richard <(E-Mail Removed)> wrote:
> "J. J. Farrell" <(E-Mail Removed)> writes:
>
> > Richard wrote:
> >> Richard Heathfield <(E-Mail Removed)> writes:

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


 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      02-25-2008
William Pursell wrote:

> On Feb 25, 4:30 pm, Richard <(E-Mail Removed)> wrote:
>> "J. J. Farrell" <(E-Mail Removed)> writes:
>>
>> > Richard wrote:
>> >> Richard Heathfield <(E-Mail Removed)> writes:

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

 
Reply With Quote
 
Richard Harter
Guest
Posts: n/a
 
      02-25-2008
On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<(E-Mail Removed)> wrote:

>Eric Sosman <(E-Mail Removed)> writes:
>> 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.


That's open to question. The problem is that sizeof is a hack;
it is not an operator in the same way that operators such as + et
al are operators. (The fact that the standard calls sizeof an
operator is beside the point - the issue is not what the thing is
called but rather its intrinsic propertires.)

In effect, ordinary C operators are functions in disguise, i.e.
functions with special syntax. Their arguments are the values of
expressions; they "return" values within the C type system. C
does not have type valued variables; nonetheless sizeof has a
type as an "argument", either explicitly as in sizeof(int) or
implicitly as in sizeof(x). The fact that in some instances the
parentheses are not needed and in others it is required is a
hack.

Since sizeof (or $ if you want to call it that) requires
parentheses in some circumstance IMHO it would have made more
sense to call it a function (in the C sense of functions of
course) rather than an operator and always require parentheses.

Be that as it may, always using parentheses seems to me to be the
better policy because it is simple and consistent.

>(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) <(E-Mail Removed)>
>Nokia
>"We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"


Richard Harter, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
 
Reply With Quote
 
Serve Laurijssen
Guest
Posts: n/a
 
      02-25-2008

"Richard" <(E-Mail Removed)> schreef in bericht
news:fpuqm1$cq2$(E-Mail Removed)...
> Mark McIntyre <(E-Mail Removed)> writes:
>
>> Richard Tobin wrote:
>>> In article <tunwj.1754$(E-Mail Removed)2.easynews.com>,
>>> Mark McIntyre <(E-Mail Removed)> wrote:
>>>

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


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-25-2008
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 ().

--
(E-Mail Removed)
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-25-2008
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

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      02-25-2008
In article <(E-Mail Removed)>,
Richard Harter <(E-Mail Removed)> wrote:

>On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
><(E-Mail Removed)> 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.

>Since sizeof (or $ if you want to call it that) requires
>parentheses in some circumstance IMHO it would have made more
>sense to call it a function (in the C sense of functions of
>course) rather than an operator and always require parentheses.


A way to make the current situation seem slightly more consistent in
the grammar would be to add a production:

type-expression:
( type-name )

and change some other productions:

cast-expression:
unary-expression
type-expression cast-expression

unary-expression
[...]
sizeof unary-expression
sizeof type-expression

and in C99:

postfix-expression:
[...]
type-expression { initializer-list }
type-expression { initializer-list , }

Whenever type names are used in expressions they are parenthesized,
but that's not apparent without looking closely at the grammar.

Of course, all this would be simpler if keywords were in a different
font from identifiers, as in Algol 68.

-- Richard
--
:wq
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-25-2008
Richard Heathfield wrote:
> Richard Tobin said:
>> Keith Thompson <(E-Mail Removed)> wrote:
>>
>>> 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.h> and 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

 
Reply With Quote
 
J. J. Farrell
Guest
Posts: n/a
 
      02-25-2008
Richard wrote:
> "J. J. Farrell" <(E-Mail Removed)> writes:
>
>> Richard wrote:
>>> Richard Heathfield <(E-Mail Removed)> writes:
>>>
>>> ...
>>>> 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.


What on earth are you on about? What "reads horribly" about it? What
"practical reasons"? I can only assume you haven't seen much production
code.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
Question on converting unsigned long to std::string Ramesh C++ 2 10-10-2008 07:58 AM
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments