I'm getting really irritated at a lot of self proclaimed C programmers for abusing the fuck out structures and pointers. It's easy to get out of hand and make your code look like shit and it seems people want to do it even when it's not necessary. The problem is even a lot of legitimately experienced C programmers do the same shit. Go look at the source to your favorite software written in C.
A good example is that stupid dubs checker thread that faggot just made. It should be written like this
#include <stdio.h>
#define base 10
int check(int i, int b) {
return(i%b == (i/b)%b);
}
>>5
The Plan9 one is shit and the GNU one is good, tell me something that I don't know.
Name:
Anonymous2012-01-29 19:54
>>6
I've read my K&R you worthless piece of shit. Please post the passages from K&R that say the lack of a space between return, if, and while with its' parenthesis make it a function call.
Name:
Anonymous2012-01-29 20:01
>>8
Listen you dumb piece of crap, do I have to tell you what you have read? Are you seriously too fucking dumb to understand basic English? Do you even know what "imply" means? Go review basic education you fucking moron, your code sucks by the way, so you better rethink your life choices because you're never going to be a successful programmer. Now fuck off you fucking retard, your posts are worthless.
>>19
No it's not. People like you are the reason no one sees the beauty in C.
Name:
Anonymous2012-01-30 2:26
>>29
There's no beauty in C. That's what I like about it. It's awkward and close to the hardware and has no pretenses. It's a language for manipulating memory. That's it.
Name:
Anonymous2012-01-30 2:35
>>30
That's why you embed higher level languages into it. Perfect combination.
Name:
Anonymous2012-01-30 3:03
>>30
Its simplicity, orthogonality and extensibility make it beautiful. C is a very simple language and its power comes from combining simple parts to make a more powerful whole. All of the complex declarations and data types in C can be decomposed into simpler parts. In contrast to other languages where operations like I/O and memory allocation are accessed using a fixed set of statements or keywords, C uses standard library functions that appear exactly like any other functions.
I was just about to commend /prog/ about how its quality has improved over the last few days. Ah well.
>>1
While I get what you are saying, using pointers over array subscripts actually tends to give you a slight boost in performance.
There is definitely a tendency to get away from the UNIX philosophy of keeping everything as simple as it can be while achieving optimal results, where complex mechanisms are used for the simplest of tasks, but I think pointers are needlessly feared.
Likewise, prototypes are important for reusability. If anyone were to reuse your dub-checker the lack of prototypes would turn off all type-checking for external calls. This is bad.
>>3
They are key words, my dear troll. Go ahead and try to make a function named if.
Name:
Anonymous2012-01-30 7:06
I am the guy who did the checker yesterday.
While the formula i%b == (i/b)%b is a *very* nice hack, what if I want to include trips and quads later? While it is flexible by accepting any given base, it's only a boolean for answer. NOT what I had in mind. I had in mind telling what the number might be too, not just saying "hey, there's dubs in base 13. to find it, go fuck yourself".
My solution unites the hackish of dealing with basic pointers and structures with ENTERPRISE level possibilities of expanding. With basically a little loop and a pointer change, the program is able to see dubs, trips, quads... The user name it.
All in my first program in pure C. Sorry if it isn't a compiler.
I think quality has improved. Not all contributions needs to be from PHDs. Both implementations are a fun read, even if "wrong". There were a few really good questions and answers, and if there's a suitable trolling/discussing ratio, the community can only improve.
Compared to the wasteland of the last year, seems like a good start.
/* Actual dubs checking: four lines of code. */
int check(int num, int base) {
int count = 0, digit = num % base;
while (num % base == digit) {
count++; num /= base;
}
return count;
}
int main(int argc, char **argv) {
if (argc != 2) {
fprintf(stderr, "Usage: %s <postnum>\n", argv[0]);
return 1;
}
int postnum = atoi(argv[1]), base, result;
if (postnum <= 0) {
fprintf(stderr, "Invalid post number: %s\n", argv[1]);
return 1;
}
for (base = 2; base < postnum && base < MAX_BASE; base++) {
result = check(postnum, base);
if (result < 2) continue;
if (result >= 10) {
printf("* %ds in base %d: ", result, base);
} else {
printf("* %s in base %d: ", names[result], base);
}
while (result--) {
putchar(alphabet[postnum % base]);
}
putchar('\n');
}
return 0;
}
$ gcc -o dubs dubs.c && ./dubs 39
* trips in base 2: 111
* dubs in base 12: 33
>>36
| using pointers over array subscripts actually tends to give you a slight boost in performance
What makes you say that? Whether you dereference a pointer or use array subscript notation won't make a difference.
Because when you compile a C program under the GNU C compiler, the compiler, by default, will leave on a bunch of GNU specific extensions.
Name:
Anonymous2012-01-30 16:59
>>52
Array[i] is instantly converted into *(address of the first element of the array+i) in C, behind the scenes. Dereferencing a pointer is just *(adress). If you are running along an array and increasing i each time, it is slightly more efficient to increase a pointer each time and dereference it rather than increase i each time and then add it to the pointer.
Furthermore, if you pass an array to a function what you are passing is an automatic pointer to its first element. Since you already have a pointer separate from from the one 'holding' the array, you can use it to run along the array as long as you do not need to do more than one pass over the array. Defining an additional variable to do what one you already have is capable of is wasteful in this situation.
Name:
Anonymous2012-01-30 17:06
>>55 Array[i] is instantly converted into *(address of the first element of the array+i) in C.
That only happens when you when an array is passed to a function. Otherwise no special conversion happens.
you already have a pointer separate from from the one 'holding' the array
I think you just need to shut your mouth on something you clearly don't understand, and like, maybe write some C code.
Name:
Anonymous2012-01-30 17:11
>>57
Try this you moron. Write a program that uses popen(). By default, when you compile it using the GNU C compiler, there will be no warnings. Now take this same piece of code and try to compile it on a Windows box.
So why would it compile do a clean build on one box and not another? It's because of the bloat GNU extensions.
>>63
Its cool that you apparently know the language better than the guy who invented it and wrote the manual. That is why you don't actually need to refute the quote from the book or back any of what you are saying, right?
Name:
Anonymous2012-01-30 17:42
>>65
You're not drawing a clear distinction between an array and an array element. Now shut up. You're not only fucking stupid, but you're also fucking annoying. Now scrub another toilet you fucking mental midget.
Name:
Anonymous2012-01-30 17:43
>>65
I'm not the one making retarded statements. In your case, since you are a total fucking dumbass, I would cite either the standard or K & R. This is because you don't have the mental capacity to put this shit into your own words.
Just because the syntax for return, if, and while is similar to the syntax for function calls does not mean that they are functions. They're statements. Technically not even functions in C are really functions, they're subroutines/procedures, but that's true of most languages.
Name:
Anonymous2012-01-30 17:55
>>71
No you stupid fucker. For the second time, an "array" and an "array element" are two different things.
>>70
Show, don't tell, my dear Kodak. I gave you a direct quote from the horse's mouth. For one who admires standards so much you have not, as of yet, shown me in an official document that I am wrong. Writing angry words in my general direction will not actually prove anything beyond the fact that you are vexed.
Is not correct. Look up the phrase "pointer constant" in one of tne standards you fucking moron.
Name:
Anonymous2012-01-30 18:02
>>81
I never said nor implied that. Again, I think you need to cite citing the standard since you don't have the mental capacity to put anything you've read into your own words.
Hint: if you use the word "moron" during a discussion to fortify your arguments, that's a sign you're pretty bad at discussing. If you're not using it to fortify your arguments, then don't type it out. I'm looking at you, >>83 and/or kodak.
>>82
An array's name is primarily used in the following contexts:
To pass it to a function - example: f(arr) - in which case what is passed is the address of the first element.
To access one of its members - example: arr[i] - in which case it is converted to the form *(arr+i), arr again replacing the address of the first element.
To assign the array's first member to a pointer without specifying which member in the previous form of arr[i] - example: int *ptr=arr - in which case the array's name is again synonymous for the address of the first element.
In every context in which an array's name is used, it is treated as the address of the first element. Thus one can think of an array's name as a pointer who's value cannot be changed.
Even in the internal representation, if you want to access anything, you need its address.
Name:
Anonymous2012-01-30 18:13
>>84
Again, for the third time, I'm not the dumbass that said...
>An array name is essentially a pointer constant.
This statement alone implies that you are totally clueless. Again, I think you just need to shut the fuck up and read the standard. Because again, you clearly don't have the mental capacity to put what you read into your own words.
I am infinitely amused you have locked on to the one thing I could not provide a concrete quote on and focused on that, refusing to admit you were wrong on what I did prove.
Name:
Anonymous2012-01-30 18:19
>>85 To access one of its members - example: arr[i] - in which case it is converted to the form *(arr+i), arr again replacing the address of the first element.
No you stupid shit. A name is an *identifier*. Man, I swear, you are one stupid son of a bitch.
Name:
Anonymous2012-01-30 18:21
>>88
You are wrong on a few other things. However, you seem to have gotten your panties in a bundle when I called you out for the stupid shit that you are.
>>93
Again, K&R disagrees. I even gave you the exact quote and the page number. How hard is this for you to check?
Name:
Anonymous2012-01-30 18:29
ITT C++ programmers.
Name:
Anonymous2012-01-30 18:36
>>94
I have the book. Nowhere does it say "It's not *(address of the first element of the array + i)". Again, this is because you are giving your own creative interpretation of the language.
>>96
Cool. Then what does the quote 'In evaluating a[i], C converts it to *(a+i) immediately; the two forms are equivalent.' (p99 2e) means?
'Any operation that can be achieved by array subscripting can also be done with pointers. The pointer version will in general be faster but, at least to the uninitiated, somewhat harder to understand.' (p97 2e) Why would the pointer version would be, generally, faster if the above is not true?
Name:
Anonymous2012-01-30 18:45
Check my dubs.
Name:
Anonymous2012-01-30 18:46
>>99
Exactly what it means. The fact that you insist it's an address just implies that you're a mental midget. The fact that you got your panties in a bundle about this means that not only are you a mental midget, but also, that you're a retard.
>>101
>Exactly what it means.
Cool. Guess I'm right then.
Name:
Anonymous2012-01-30 18:53
>>102
Right about what? Nowhere does it say it's an address. A possible reason for this wording might be because on some computers, the offset in an array isn't an address. Now again, stop giving your own creative description of the langauge you fucking moron.
Name:
Anonymous2012-01-30 18:55
>>102
Here's a possible scenario you little fucking annoying faggot. Let's say I have a machine called the "death star". Yeah, it's named after star wars. This computer will load the array into the memory is such a way that the PC counter starts at 100. Now when I get the next element of the array, the CPU will just to goto 101.
This is because it would take too long for the PC to load the actual address and then jump to that point.
>>1
C makes it hard to ``do the right thing''. Using lots of structures, pointers and dynamically allocating memory is how you do it ``right'' as that's what you'd have to do in a higher-level language to do some simpler things. The things we take for granted in higher-level languages show their cost in C. The tendency in C is to microoptimize and make quick hacks to reduce the code size, although that's not really good programming practice - if you're doing it properly, you get faster code, if you make mistakes, you get bugs, crashes and vulnerabilities.
I have yet to use a non-standard function, unless I have been severely trolled by K&R and K.N.King. Can you check my code and find a GNU'ed function? (And yes, I tried compiling it with another compiler. 49KiB with GCC, 5KiB with the other, shit was so cash) The most special stuff I used were malloc() and free(), come on.
>>59 I really think you thought that I meant "any" code. I said "code" referring specifically to mine. Of course a code targeting a specific implementation will get bloated if the compiler is bloated.
An integer n, is said to have dubz in base b, if and only if the following is satisfied:
n mod b = floor(n/b) mod b
Theorem 1.1:
Let n be an integer, b be a base, and let r = n mod b. Then n has dubz in base b if and only if:
n mod b^2 = r(b + 1)
Proof:
Part 1:
First assume that n has dubz in base b, with r = n mod b. We will show that n mod b^2 = r(b + 1)
Decompose n into its quotient and remainder, q and r:
n = qb + r
We have that floor(n/b) = q. Because n has dubz in b, we have the following:
n mod b = floor(n/b) mod b
n mod b = q mod b
So q will have remainder r when divided by b. Let p be the quotient of q and r.
q = pb + r
n = qb + r q = pb + r
n = (pb + r)b + r
n = pb^2 + rb + r
n = pb^2 + r(b + 1)
n mod b^2 = r(b + 1)
And we have arrived at the needed conclusion.
Part 2:
Now suppose that n satisfies:
n mod b^2 = r(b + 1)
where r = n mod b. We would like to show that n has dubz in base b. The steps are essentially
the same as Part 1 in reverse:
n mod b^2 = r(b + 1)
Let p be the quotient of n and b^2. We can express n in terms of its quotient and remainder with b^2.
n = pb^2 + r(b + 1)
n = pb^2 + rb + r
n = (pb + r)b + r
We have now decomposed n into its remainder and quotient of b, and found the quotient to be q = pb + r.
But q has remainder r when divided by b, the same remainder that n has when divided by b.
n = qb + r q = pb + r
n mod b = q mod b
n mod b = floor(n/b) mod b
Thus, we have shown that n mod b yields the same remainder as floor(n/b) mod b. Therefore n has dubz in base b.