Comment On nice_num, mean_programmer

When Timothy stumbled across a function that had a vague name, no comments, and variables, he took a few minutes to try to break it down in his head. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6Next »

Re: nice_num, mean_programmer

2008-11-28 16:50 • by Will (unregistered)
Unacceptable solution!!!!
How can you name this function "fine"?
It's horrible- no XML configuration, no Web Services interface, can't be accessed via RMI, and, the most terrible thing - all done in one layer, you need a proper render layer(characters rendering), processing layer - math, and data layer, remote server that contains character codes, separator codes, etc.
This should be combined together using Web Services, and this should be designed as scalable system, better to have few processing layers, and load balancing before them.
This will be a real solution

Re: nice_num, mean_programmer

2008-11-28 16:57 • by hexatron (unregistered)
For the "isn't there a function that already does this" crowd:

I just checked the source for Microsoft's C compiler function xtoa, which is the common working part of itoa(), ltoa(), etc.
It is just about identical to the WTF code above, except for the comma stuff. The differences are:
1. The number is given in two arguments--an unsigned value and a sign (absolutely needed for ultoa())
2. The buffer and its size are arguments too.
3. The result is computed backwards (smallest digit at the start of the string), and then the result string is reversed in place.

Imagine that! The 'system function' isn't elfin magic at all. It's the same thing you've been despising.

Re: nice_num, mean_programmer

2008-11-28 16:58 • by Nazca
231474 in reply to 231449
GettinSadda:
Nazca:
GettinSadda:
One improvement that I would probably make is to make the loop infinite with an if(!n) break before adding the comma as this means that you don't have to remove it afterwards.


Which in most numbers is less efficient, since you're doing an extra comparison every loop, instead of a single comparison and increment at the end.
Actually if you look at the original code, the only changes are adding a conditional jump after the division by 10 (which will be very low cost as the test for zero will have probably been calculated by the division) and change the conditional jump at the end of the loop to an unconditional (this conditional is likely to be a more expensive than above as the manipulating of d means that you will now need to re-test the value of n). The upshot is that most systems should be faster doing the test in the middle.


Ah, yes, apologies, I misread what you intended. That'll teach me to skim when tired.

Yes, you are quite correct that that change would nicely.

Re: nice_num, mean_programmer

2008-11-28 17:10 • by Rambaldi (unregistered)
231475 in reply to 231460
emcoffey3:
In terms of code correctness/performance/efficiency, this function seems pretty solid. The only thing I immediately noticed was that he could have saved 3 bytes by using bool instead of int for the "neg" variable, seeing as how it only has 2 possible values. Then again, this function may very well pre-date the bool type.

As for people not understanding the code, I can certainly see why. If you're not familiar with C++ pointers, the pre-increment operator, and "C-strings", then this probably won't make a bit of sense to you. And the vaguely named variables and lack of comments won't help, either.

It isn't pretty, but it's not even close to the worst I've seen. I'm so glad I don't write code in C++ anymore... just looking at this gave me chills.


Standard C doesn't have a bool type.

There has been a lot of discussion about 32/64 bit longs, some architectures have 16 bits longs its all a matter of the register size, and if you are seeing straight C nowadays it will either be for hardware drivers or on an embedded system so you are more likely to encounter these shorter registers.

Re: nice_num, mean_programmer

2008-11-28 17:20 • by John Beaner (unregistered)
makes pretty good sense to me when you think about it.

jess
http://www.online-privacy.cz.tc

Re: nice_num, mean_programmer

2008-11-28 17:25 • by Peter Tax (unregistered)
Maybe I've seen too much bad code in my life, but apart from using a global variable prtbuf instead of passing this as an argument, this function doesn't look that horrible to me.

Re: nice_num, mean_programmer

2008-11-28 17:29 • by emcoffey3
231479 in reply to 231475
Rambaldi:

Standard C doesn't have a bool type.


It was added in C99.

Re: nice_num, mean_programmer

2008-11-28 17:40 • by frustrati (unregistered)
using goofy modulus math

That is just such a stupid comment that it is funny. Let's have it again:
using goofy modulus math

Pure cluelessness.

Re: nice_num, mean_programmer

2008-11-28 17:51 • by lol (unregistered)
fixed n=-n bug:

1.
[ph] [tehbox] [~] ./x 123
2.
pre : -i=123 neg=0
3.

4.
post: i=0 s=1,2,3
5.
[ph] [tehbox] [~] ./x -123
6.
pre : -i=-123 neg=0
7.

8.
post: i=0 s=-1,2,3
9.
[ph] [tehbox] [~] ./x -128
10.
pre : -i=-128 neg=0
11.

12.
post: i=0 s=-1,2,8
13.
[ph] [tehbox] [~] cat x.c
14.
#include <stdio.h>
15.

16.
void main(int c, char **v) {
17.

18.
signed char i = atoi(v[1]);
19.
int neg = 0, d = 1;
20.
char s[10];
21.
char *b = s;
22.

23.
b+=10;
24.
*--b = '\0';
25.

26.
//i < 0 && (neg = 1, i = -i);
27.

28.
printf("pre : -i=%d neg=%d\n", i, neg);
29.

30.
do { *--b = '0' + (int)(i%10<0?i%10*-1:i%10);
31.
i /= 10;
32.
--d == 0&& (*(--b) = ','), d = 1;
33.
if (i<0 && i>-10) neg=1;
34.
} while (i);
35.

36.
*b == ',' && b++;
37.

38.
if(neg) *(--b) ='-';
39.

40.
printf("\npost: i=%d s=%s\n", i, b);
41.

42.
}

Re: nice_num, mean_programmer

2008-11-28 17:55 • by Bobblehead Troll (unregistered)
I hate mandatory invisible default locales. They are a real WTF.

They are the #1 way to make programs that fail more or less inexplicably. For instance there was this one tool program that saved its configuration data by serializing it into XML using a some common library. It also had a default configuration when installed. Only in a different country it always crashed on startup... with a NumberFormatException since the locale-specific decimal separator was different and the configuration had plenty of floating-point numbers.

It is pretty stupid when locale-infested string classes may arbitrarily decide that A and  and Á are actually the same letter and software subtly behaves differently depending on location, with no way to change it apart from creating your own string class. Not to mention the software overhead... in most C++ STL implementations, an innocent-looking '#include <string>' actually brings in around 300k of headers as well.

I would quite prefer this ""wtf"" code.

Re: nice_num, mean_programmer

2008-11-28 17:57 • by lol (unregistered)
http://pastebin.com/m78db4adf

Re: nice_num, mean_programmer

2008-11-28 18:02 • by Josh in California (unregistered)
Did you really, actually make fun of the fact that this algorithm CORRECTLY divides by 10 rather than 1000?

AHAHAHAHA!

Epic fail.

Re: nice_num, mean_programmer

2008-11-28 18:13 • by Adam (unregistered)
This post is an embarrassment to the author.

Re: nice_num, mean_programmer

2008-11-28 18:21 • by Mike (unregistered)
actually the posted code is a rip from an ANSI C92 string formating function

Re: nice_num, mean_programmer

2008-11-28 18:42 • by JS (unregistered)
Sometimes I am really glad I have my ED instruction. ;-)

Re: nice_num, mean_programmer

2008-11-28 18:47 • by modo (unregistered)
231489 in reply to 231401
JPhi:
GettinSadda:


Remind me again just how you get commas in numbers using standard printf?


...

And for all of you asking "isn't there a library function to do that", the answer is NO. ... If I was faced with the comma problem, I would have done exactly what the OP(rogrammer) did.

... program that was done quickly an efficiently.

sprintf("%'20ld", n) ..?

Of course this C might not be ISO, and so might not have the "'" modifier. So, the answer is maybe.

Re: nice_num, mean_programmer

2008-11-28 19:00 • by BJ Upton (unregistered)
231490 in reply to 231409
Osno:
I got the meaning of the function on my first read, and I'm not even a C programmer. Ergo, comments would be redundant here.

I'd change the name (a little) to pretty_print, or something more meaningful, and solve the few minor defects the function has, but that's it.

I think we're way past the "uses foo as a name function" WTF. If we're back to posting stuff because of bad naming conventions, plus the ban on TopCoder, this site is doomed.


I miss TopCod3r. He was one of the best things on the site.

Re: nice_num, mean_programmer

2008-11-28 19:01 • by BJ Upton (unregistered)
231491 in reply to 231488
JS:
Sometimes I am really glad I have my ED instruction. ;-)


See your doctor if your instruction last longer than 4 hours.

Re: nice_num, mean_programmer

2008-11-28 19:01 • by Rick (unregistered)
To the OP:

Apparently you've never actually tried to convert an integer to a C-string before. This is not goofy or "WTF." It is a well-known and elegant algorithm. Look up the wikipedia entry for the function "itoa" http://en.wikipedia.org/wiki/Itoa

Go an implement the commas the way that you described. I will laugh at your result: a base-1000 representation of the number instead of a decimal representation.

Re: nice_num, mean_programmer

2008-11-28 19:27 • by Programmer (unregistered)
Funny that you should make fun of that code -- because it actually tells me more about you than the guy who wrote it:

- you an lack adequate grasp of simple mathematical
constructs like modulus

- you are not very good at reading and understanding code
(it took me about 5 seconds to figure out what the code
did and a few seconds more to verify it didn't have any
bugs that were very obvious. And I suck at reading
code. You must be really, *really* slow)

Of course, the guy who wrote it should have anticipated that even a short snippet like that might confuse the abnormally obtuse and added a comment that spells out what it does. And I agree the name should reflect better what the function does.

But that still doesn't change the fact that you are an incompetent idiot.

Re: nice_num, mean_programmer

2008-11-28 19:28 • by lolwtf
231494 in reply to 231404
The only problems here:
1) Uses a global buffer. This is a WTF.
2) Buffer overflow on 64-bit systems.
3) A bit ugly. Could use some comments and nicer names.

Gieron:
Paolo G:
bitpirate:
The real WTF is assuming that all locales use "," for their thousands separator. "1.000.000" is common for a million in Europe.

Yes, dot is the standard in continental Europe (which uses a comma instead of a decimal point), but the comma is used in the UK.

In Sweden we use spaces: 1 000 000
That must get fun when you have two numbers next to eachother separated by spaces.

Re: nice_num, mean_programmer

2008-11-28 19:29 • by Flow (unregistered)
231495 in reply to 231414
Evo:
Moo:
The largest possible string for a given input is "-2,147,483,648\0", which is 15 characters, so there is no buffer overflow.


I agree with you in everything but this sentence. The size of long may be anything, as long as it is at least as long as an integer. It may be several megabytes for all you'd know. In practice, it will be either 4 or 8 bytes. On my 64 bits processor, it's 8 bytes, which makes the largest possible string:
"-2,305,843,009,213,693,952\0"
which is 27 characters long.


Sure. But since we already can assume it's embedded code, let's also assume the engineer knows the prcoessor is 32-bit, and only 32-bit for now. So therefore all that's missing is a comment to this effect.

Re: nice_num, mean_programmer

2008-11-28 19:31 • by dk (unregistered)
Function is perfectly fine...
WTF is this whole thread with 64bit longs, multithreading, %100 instead of %10 etc, not the code pasted by the author.

Cheers to everyone.

Re: nice_num, mean_programmer

2008-11-28 19:36 • by Programmer (unregistered)
So Jake Vinson is a lead developer and he can't even understand something as simple as formatting an integer value as a string. And he has been at it for 10 years.

The real WTF is what he does as a lead developer. Who on earth would hire someone who after ten years isn't even smart enough to understand a piece of code any college freshman with a programming 101 should be able to grasp.

Where have all these idiots on thedailywtf come from? There used to be smart people here. At least occasionally.

Re: nice_num, mean_programmer

2008-11-28 19:39 • by zzo38
A few minutes? No, it takes a few seconds to figure out.

Re: nice_num, mean_programmer

2008-11-28 19:52 • by Dennis (unregistered)
231499 in reply to 231470
eyepatch:
Agree'd. Not an enterprisey solution.


Is that a contraction of "agree would"?

Re: nice_num, mean_programmer

2008-11-28 19:58 • by Jeltz (unregistered)
231500 in reply to 231498
A sampel solution for how to solve the common bug with INT_MIN in this code. But a common bug in a border case is not a WTF. As you see this code is a bit simpler than the alleged WTF and would still be easier to read even when the commas are added. But it is just a minor bugfix and clean up. Nothin seriosuly wrong with the alleged WTF.

http://clc-wiki.net/wiki/K%26R2_solutions:Chapter_3:Exercise_4

Re: nice_num, mean_programmer

2008-11-28 20:12 • by methinks (unregistered)
231501 in reply to 231401
JPhi:
We don't want this to be like that English nazi site with 1000's of posts making fun of signs that use "your" instead of "you're".


1) What's wrong with pointing out stupid mistakes? It might help preventing more of the same in the future.

2) Perhaps we in Europe's german speaking countries are a little bit more sensitive, but I always find it disturbing to use the term "Nazi" in connection with every-day stuff like spelling or the like.
What's wrong with words like "pedant" or "stickler"?

Re: nice_num, mean_programmer

2008-11-28 20:39 • by methinks (unregistered)
231502 in reply to 231466
Jeltz:
And single letter variables are not bad in any way as long as they are few and their scope is short. I have never understod this fobia.


I do agree about the variables. But single letter transcriptions of certain greek letters are definitely not ok ;o)

Re: nice_num, mean_programmer

2008-11-28 20:54 • by TopCod3rsBottom
231506 in reply to 231497
Programmer:
Where have all these idiots on thedailywtf come from? There used to be smart people here. At least occasionally.
Hey! *I* will do the trolling at this venue, thankyouverymuch... Go find another bridge to lie-in-wait under.

Re: nice_num, mean_programmer

2008-11-28 20:57 • by Nobody (unregistered)
231510 in reply to 231410
shepd:
Although, once we grow up, we drop the pretentiousness and just do what the USians do.


And in return we USians are seriously considering you for our 51st state (minus Quebec of course)

Re: nice_num, mean_programmer

2008-11-28 20:57 • by TopCod3rsBottom
231511 in reply to 231494
lolwtf:
Gieron:

In Sweden we use spaces: 1 000 000
That must get fun when you have two numbers next to eachother separated by spaces.
Duh! In that case they use a comma...

Re: nice_num, mean_programmer

2008-11-28 21:03 • by JimBob (unregistered)
231542 in reply to 231426
Daniel:

It looks like old code.

Um, what does that mean? And how can you tell?

Re: nice_num, mean_programmer

2008-11-28 21:06 • by pile (unregistered)
My version of "perfectly good code" is:

* documented
* has a name of the function that is more representative of what it is
* says what it does in the header
* isn't called "_num" when it outputs a pointer to a string
* has some convention for handling foreign formats (like . instead of , as a separator)

I agree. Crappy code. Especially if you have to waste time trying to figure out what it does. Programmers like this give C a bad name.

Re: nice_num, mean_programmer

2008-11-28 21:45 • by Anonymous (unregistered)
231742 in reply to 231556
pile:
My version of "perfectly good code" is:

* documented
* has a name of the function that is more representative of what it is
* says what it does in the header
* isn't called "_num" when it outputs a pointer to a string
* has some convention for handling foreign formats (like . instead of , as a separator)

I agree. Crappy code. Especially if you have to waste time trying to figure out what it does. Programmers like this give C a bad name.


Again: lack of commenting and bad naming hardly makes for a WTF worth of mentioning here.

Maybe Jake is TC. I mean, look at the coincidences: TC is a lead developer (most of the time) that posts absurd WTF solutions as perfectly acceptable solutions while Jake is a team lead that posts perfectly acceptable solutions as WTFs.

And also, since when locale is absolutely mandatory on every piece of code? Last time I checked, locale may or may not be a requirement. Even if this is not embedded code, the coder may have a very good understanding of his target PC and may not needed this to be portable through locations and time (meaning, 64 bit may be overkill for this code). Even though adding locale is trivial to implement, it still will make the code (or the calling code) more confusing and slow. It may even take it to the point where it takes a few minutes to understand it...

Re: nice_num, mean_programmer

2008-11-28 22:35 • by neophrene (unregistered)
231794 in reply to 231475
Rambaldi:

Standard C doesn't have a bool type.


WAOUH

I just found a time machine to travel 10 years in the past. Yeepee!

(and i also found TRWTF: it's Rambaldi)

Re: nice_num, mean_programmer

2008-11-28 22:44 • by anon (unregistered)
this code will run on anything from a $2 microcontroller to a billion dollar supercomputer.

damn it, if its not leaking, slow or giving the wrong answer than WTF is wrong with it?

fuck you style idiots with your hands on your hips complaining about modulus math. you want comments? here's one: step off!

Re: nice_num, mean_programmer

2008-11-28 22:45 • by pythonic (unregistered)

/**
* formats number with comma delimiters, implemented with
* go-faster stripes, but uses ~4k memory.
*/

static char* format_c03d = ",000,001,002,...";

static char*
format_number_with_comma_delimiters(char *dst, int64_t number)
{
int64_t n;

dst += 32;
*dst = '\0';
n = number;
while (n) {
dst -= 4;
*(u_int32_t*) dst = *((u_int32_t*) format_c03d + abs(n % 1000));
n /= 1000;
}
while (*dst == '0' || *dst == ',')
dst += 1;
if (*dst == '\0')
*--dst = '0';
else if (number < 0)
*--dst = '-';
return dst;
}

Re: nice_num, mean_programmer

2008-11-28 23:13 • by joeyadams
I've been programming these kinds of confusing but efficient functions for a few years now. I still have trouble writing and rereading them. However, I do use a few conventions:

Start, end pointers
char *s, *e; //refers to a string starting at s and ending right before e
/* ... */
while (s<e) {
char c = *s++;
}

Pointer, remaining
element *item;
unsigned long count;
/* ... */
for (;count--;item++) {...}

Though these sort of things may be convoluted, they are C, and they are efficient :)

Re: nice_num, mean_programmer

2008-11-29 00:41 • by Rick (unregistered)
231800 in reply to 231378
summerian:

No, it does not have to process one digit at a time. You just check if the remainder is below 10 or 100 to add leading "00" or "0".

But it guess it's the same either way.


Apparently you don't understand how the code works. Yes you DO have to process it one digit at a time.

*--buffer = '0' + (n % 10);

There's no ASCII code for '11' or '100' or '12'. There's only '0' to '9'. If you go modding and dividing by 1000 then the part that converts the number to a character won't work.

Re: nice_num, mean_programmer

2008-11-29 01:32 • by Kragen Javier Sitaker (unregistered)
Pursuant to Jake Vinson's suggestion, I restructured the code to use an outer loop that divides by 1000. I understand it's a bit risky to take programming advice from someone who's so junior they don't understand why someone would use the "%" operator in a decimal print routine, but I thought I would see how it went. I do not think the result is an improvement in clarity.


/* nested loops, as suggested by Jake Vinson */
static char *nested_nice_num(long n)
{
int neg = 0, d = 3;
char *buffer = prtbuf;
int bufsize = 20;

if (n < 0)
{
neg = 1;
n = -n;
}
buffer += bufsize;
*--buffer = '\0';

for (;;) {
int nd = n % 1000, ii;
n /= 1000;
for (ii = 0; ii < 3; ii++) {
*--buffer = '0' + (nd % 10);
nd /= 10;
if (!nd && !n) break;
}
if (!n) break;
*--buffer = ',';
}

if (neg) *--buffer = '-';
return buffer;
}


I agree with the other comments that ① the original is a perfectly reasonable piece of code for environments where you don't have a sprintf available; ② it's slightly trickier than it needs to be, probably in order to be fast; ③ a sprintf version would be simpler, if not faster; ④ the original poster is an idiot; ⑤ a one-line comment
/* Convert signed integer to comma-separated decimal string */
would be a major improvement, as would renaming the function "comma_sep".

Here's a version using sprintf (and still using statically-allocated 20-byte buffers, to compare apples to apples). As a special bonus, it formats -2,147,483,648 as "-2,147,483,648" instead of "-.,/,),,(-,*,(" (on an ASCII machine).


#define BUFSIZE 20
static char prtbuf[BUFSIZE];
static char prtbuf2[BUFSIZE];

static char *sprintf_nice_num(long n)
{
char *s = prtbuf2, *t = prtbuf;
int d = sprintf(prtbuf, "%ld", n);
if (n < 0) d--, *s++ = *t++; /* no comma after the minus! */
for (; d--, *s++ = *t++;) if (d && !(d % 3)) *s++ = ',';
return prtbuf2;
}

Re: nice_num, mean_programmer

2008-11-29 01:35 • by Shinobu (unregistered)
231802 in reply to 231446
Nazca:
Heck... I suppose you'll find this a wtf:

const int ALLOW[256] =

{
/* 0, 1, 2, 3, 4, 5, 6, 7, 8 9, A, B, C, D, E, F */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*0x*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*1x*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*2x*/
-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,0x00,0x00,0x00,0x00,0x00,0x00, /*3x*/ /* 0 = 0x30, 9 = 0x39 */
0x00,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747, /*4x*/ /* A = 0x41 */
-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,0x00,0x00,0x00,0x00,0x00, /*5x*/ /* Z = 0x5a */
0x00,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747, /*6x*/ /* a = 0x61 */
-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,-747,0x00,0x00,0x00,0x00,0x00, /*7x*/ /* z = 0x7a */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*8x*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*9x*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*Ax*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*Bx*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*Cx*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*Dx*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /*Ex*/
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 /*Fx*/
};
char chk_validity(char *s)
{
static char *c;
for (c=s;*c;c++) if (ALLOW[c] != 0) return (char)0;
return (char)1;
}


Addendum (2008-11-28 13:52):
for (c=s;*c;c++) if (ALLOW[c] == 0) return (char)0;

*coughs, looks sheepish, and hopes no one replied yet*
You forgot to dereference that pointer, spunky.

Anyway, regarding the article itself, I'll have to join the chorus. This is definitely not a WTF.
‘takes a few minutes to figure out’: Well, I guess that makes me a genius, as I read through the thing in about three seconds. Or the submitter a moron. In all honesty I think the latter is more likely.
‘is trying to accomplish’: Accomplishes.
‘works backwards’: That's inherent in the problem. You simply can't do this working from the other end.
Yes, the code has a few minor issues, as previously pointed out by others, but all in all, it's okay. Definitely not a WTF.
Oh, and as for the ‘comments defense’: get over yourself. In this case reading the comments would actually have taken more time than reading the code. The art of commenting is also in a large part the art of knowing when to leave them out.

Re: nice_num, mean_programmer

2008-11-29 03:19 • by John (unregistered)
231804 in reply to 231408
Robajob:
JPhi:
We don't want this to be like that English nazi site with 1000's of posts making fun of signs that use "your" instead of "you're".


I do.


I do too!

But what REALLY puzzles me is that some writers confuse 'then' and 'than'

It may be understandable for someone for whom English is a second or third language, but this is the kind of basic detail grasped by young kids.

At least, I thought so.

Re: nice_num, mean_programmer

2008-11-29 03:34 • by owillebo (unregistered)
This is not C++ but that assembly like language called C

Re: nice_num, mean_programmer

2008-11-29 04:04 • by Mod Vinson (unregistered)
231806 in reply to 231796
pythonic:

*(u_int32_t*) dst = *((u_int32_t*) format_c03d + abs(n % 1000));
n /= 1000;


Hey! Stop using that goofy modulus math!

Re: nice_num, mean_programmer

2008-11-29 04:19 • by Watcher (unregistered)
So what's wrong with variable names?
neg stands for negative, n for number, d for digit.

Or may be you prefer code like that:

for(int iteration = 0; iterator < max; iterator++) { ... }

Re: nice_num, mean_programmer

2008-11-29 04:50 • by Frzr (unregistered)
Nice function, try calling it with this argument:

long x = (long)0x80000000;
char *p = nice_num(x);
printf("result: %s\n", p);

printf uses s to print strings, i for decimals

2008-11-29 05:03 • by Steve (unregistered)
I keyed this in for a stroll down memory lane. Been a while since I used C/C++. The printf statement needs an s instead of an i to format the string, as opposed to what the person above said. Here's a working version for the mildy curious. Now I'll tinker with it to remind myself how C works.

#include<stdio.h>

static char prtbuf[20];

static char *nice_num(long n)
{
int neg = 0, d = 3;
char *buffer = prtbuf;
int bufsize = 20;

if (n < 0)
{
neg = 1;
n = -n;
}
buffer += bufsize;
*--buffer = '\0';

do
{
*--buffer = '0' + (n % 10);
n /= 10;
if (--d == 0)
{
d = 3;
*--buffer = ',';
}
}
while (n);

if (*buffer == ',') ++buffer;
if (neg) *--buffer = '-';
return buffer;
}

int main(){
printf("the number is %s\n", nice_num(100000));
return 0;
}

Here's the output:
/tmp/>a.exe
the number is 100,000



Re: nice_num, mean_programmer

2008-11-29 05:07 • by NiceWTF (unregistered)
231813 in reply to 231430
thosrtanner:
Why would it need to fill the buffer with spaces? It returns a pointer to the start of the string it has generated, i.e. the '-' sign or the first digit.


You're right, I missed that. So in that case there really is nothing significantly WTF-worthy about this function.

Re: nice_num, mean_programmer

2008-11-29 05:34 • by GettinSadda
231814 in reply to 231489
modo:
JPhi:
GettinSadda:


Remind me again just how you get commas in numbers using standard printf?


...

And for all of you asking "isn't there a library function to do that", the answer is NO. ... If I was faced with the comma problem, I would have done exactly what the OP(rogrammer) did.

... program that was done quickly an efficiently.

sprintf("%'20ld", n) ..?

Of course this C might not be ISO, and so might not have the "'" modifier. So, the answer is maybe.
Funny, my copy of ISO/IEC 9899:1999 doesn't contain any reference to the "'" modifier - maybe your definition of ISO standard C is different to mine!
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6Next »

Add Comment