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

 
 
Default User
Guest
Posts: n/a
 
      02-27-2008
John Bode wrote:

> On Feb 27, 1:43 pm, "Default User" <(E-Mail Removed)> wrote:


> > Richard is troll, which is why I killfiled him long ago. He'll
> > "rant" about anything that he thinks will cause trouble on the
> > newsgroup. It's best to ignore him if at all possible.


> I don't see him as a troll like Twink and McCormack; he strikes me as
> someone who could contribute meaningfully to the group if he just got
> over himself.


That's irrelevant. In fact, what he does is post messages designed to
cause trouble. He's a troll, pure and simple.





Brian
 
Reply With Quote
 
 
 
 
Richard Harter
Guest
Posts: n/a
 
      02-27-2008
On Mon, 25 Feb 2008 16:37:49 -0500, Eric Sosman
<(E-Mail Removed)> wrote:

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


You're right about it only being true of a subset - that's why I
used the word "ordinary". Still, your point is well taken; C
does have operators that don't take values. The term "operator"
is a bit misleading. This is not to say that it doesn't have a
well defined meaning in the C standard; merely that the usage in
the C standard is idiosyncratic. If we use function in the
broader context of computer science and mathematics rather than
the specific meaning of a C source function I would classify

-> and . as term formation symbols,
casts as ordinary functions, and
=, +=, etc as ordinary functions.

Assignment forms can be treated as functions with a caveat, the
issue being the C sequence point business. Pre and post
decrement and increment operators go even further into that murky
territory.




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
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      02-27-2008
Ben Bacarisse wrote:
> Richard <(E-Mail Removed)> writes:
>

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


I simply use "y + sizeof x" to avoid reading problems. Similarly I
use "N * sizeof *p".

--
[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
 
Doug Miller
Guest
Posts: n/a
 
      02-28-2008
In article <(E-Mail Removed)>, (E-Mail Removed) (Richard Harter) wrote:
>On Wed, 27 Feb 2008 15:25:06 GMT, (E-Mail Removed) (Doug
>Miller) wrote:
>
>>In article <fq3psc$dm3$(E-Mail Removed)>, Richard <(E-Mail Removed)>

> 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)) ?
>>

> I dunno, I would expect that for most people it is not "just as
>obvious". That * binds more closely than + is customary usage in
>basic algebra. C (and most other computer languages) uses the
>same precedence rules as ordinary usage. "sizeof" is an operator
>peculiar to C; its precedence is necessarily idiosyncratic.


I disagree with respect to the degree of "obviousness" -- even if sizeof and +
were at the *same* level of precedence, left-to-right evaluation would still
guarantee that "sizeof x + y" would mean "(sizeof x) + y". It takes (IMHO) a
deliberately obtuse interpretation to suppose that it could mean "sizeof (x +
y)" instead.

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.
 
Reply With Quote
 
Jean-Marc Bourguet
Guest
Posts: n/a
 
      02-28-2008
Richard <(E-Mail Removed)> writes:

> Would you like to see
>
> printf "hello%s" "world";
>
> or something equally as contrived for example?


I suggest that your learn about some other programming languages. For
example Haskell or one of the ML familly.

Yours,

--
Jean-Marc
 
Reply With Quote
 
Jean-Marc Bourguet
Guest
Posts: n/a
 
      02-28-2008
(E-Mail Removed) (Doug Miller) writes:

> In article <(E-Mail Removed)>, (E-Mail Removed) (Richard Harter) wrote:
> >On Wed, 27 Feb 2008 15:25:06 GMT, (E-Mail Removed) (Doug
> >Miller) wrote:
> >
> >>In article <fq3psc$dm3$(E-Mail Removed)>, Richard <(E-Mail Removed)>

> > 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)) ?
> >>

> > I dunno, I would expect that for most people it is not "just as
> >obvious". That * binds more closely than + is customary usage in
> >basic algebra. C (and most other computer languages) uses the
> >same precedence rules as ordinary usage. "sizeof" is an operator
> >peculiar to C; its precedence is necessarily idiosyncratic.

>
> I disagree with respect to the degree of "obviousness" -- even if sizeof and +
> were at the *same* level of precedence, left-to-right evaluation would still
> guarantee that "sizeof x + y" would mean "(sizeof x) + y". It takes (IMHO) a
> deliberately obtuse interpretation to suppose that it could mean "sizeof (x +
> y)" instead.


If the grammar was changed in the obvious way so that sizeof x + y meant
sizeof(x+y), sizeof(x) + y would also be interpreted as sizeof((x)+y). BTW
sizeof(x)->field currently mean sizeof((x)->field).

Yours,

--
Jean-Marc
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      03-01-2008
In article <fpuqg1$cq2$(E-Mail Removed)>,
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.


Richard - face it. For the in-crowd, using parens with sizeof is like
mixing primaries during daylight hours. Not done.

(We'll see if anyone catches the reference. Free peppermint candy to
anyone who does)

 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      03-10-2008
On Wed, 27 Feb 2008 21:32:24 GMT, (E-Mail Removed) (Richard Harter) wrote:

> On Mon, 25 Feb 2008 16:37:49 -0500, Eric Sosman
> <(E-Mail Removed)> wrote:
>
> >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 ().

>

Where that () is funccall not grouping. Plus && || .

> You're right about it only being true of a subset - that's why I
> used the word "ordinary". Still, your point is well taken; C


I usually use 'computational' for this distinction.

> does have operators that don't take values. The term "operator"
> is a bit misleading. This is not to say that it doesn't have a
> well defined meaning in the C standard; merely that the usage in
> the C standard is idiosyncratic. If we use function in the
> broader context of computer science and mathematics rather than
> the specific meaning of a C source function I would classify
>
> -> and . as term formation symbols,


See below.

> casts as ordinary functions, and


You can treat a particular cast as a monadic value->value function,
but then you have an unboundedly extensible set of operators. To treat
cast syntax as a single operator you need a typevalued operand.

> =, +=, etc as ordinary functions.
>
> Assignment forms can be treated as functions with a caveat, the


As math function only if you include lvalues in values, which
'ordinary'<G> math i.e. arithmetic doesn't*; and as C function only if
you convert to pointers (or use C++ references). C's rough peers
(Fortran, PL/I, COBOL) do not allow assignment as a subexpression, and
F90 allows assignment to be overloaded for a userdefined (struct-like)
type as a (nonvalued and visibly nonpure) SUBROUTINE, not a valued
FUNCTION. (* Math in its full glory can manipulate almost anything the
mind can conceive, but with terminology far more bizarre and confusing
than the C standard. For example, part of modern computer cryptography
uses 'elliptic curves' which are neither elliptic nor curves.)

Those peers treat function call (where available), field selection,
and subscripting as (forms of) primaries rather than (sub)expressions
using an operator. PL/I has sort of the opposite problem: it used
named syntax for some things that 'ought' to be operators, partly
because of the 48-char BCDIC/card charset it had to support. For
example ABS(-3) is a 'built-in function' and so is SUBSTR(str,1,2)
_when used in an rvalue context_ but when the latter is used in an
lvalue context it is a 'pseudovariable'.

> issue being the C sequence point business. Pre and post
> decrement and increment operators go even further into that murky
> territory.


AFAICS inc/dec don't cause any 'further' problem than += et al,
they're just (much) more frequent in common/idiomatic C.

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
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