int main()
{
int64_t* first_row = (int64_t*)malloc(sizeof(int64_t));
int64_t* previous_row;
int64_t* next_row;
int64_t i,size;
first_row[0] = 1;
size = 1;
print_row(first_row,size);
previous_row = first_row;
for(i = 0; i<30;i++) {
next_row = next_pascal_row(previous_row,size);
size++;
print_row(next_row,size);
free(previous_row);
previous_row = next_row;
}
free(next_row);
}
Opinions? Yeah, int64_t is probably a GNU extension, I don't care as long as it works with gcc. U mad? Also, post you're own solutions. If you can't do the Pascal, you can just go ahead and apply to your're nearest McDonald's, because you ain't worth shit.
Looks like crap. I did this, in C, in my college entrance exam (not in the US, I have no idea if there's such a thing there) and it didn't look like crap. I don't remember much else. Please, don't turn this into another fizzbuzz.
If you wish to assume the role of a post-USSR mathematical genius you better start posting some evidence that you're just a good-for-nothing blabbermouth.
Name:
Anonymous2012-01-05 18:33
>>1
And what do you do for a living? BTW, there are two three memory leaks in your program.
Name:
Anonymous2012-01-05 18:34
>>5
No there isn't. Every int64_t array that's malloced gets freed.
Name:
Anonymous2012-01-05 18:38
>>4
Fortunately, I missed USSR by one step to the west. I'm just about the furthest imaginable thing from a mathematical genius but I know how to write simple solutions to simple problems.
>>6
You still haven't told us what you do for a living. But yes, there is at least one memory leak. Pstt.. it's in main() you stupid fucker.
Name:
Anonymous2012-01-05 18:50
>>8
There is just one malloc()'d pointer in main() and it is free()'d because the for-loop is entered at least once. See, first_row is assigned to previous_row just before the loop and previous_row is free()'d after that. Pointers malloc()'d by next_pascal_row are free()'d by the same row, with the exception of the last one which is free()'d just after the loop.
But I provide expensive senior software engineering services to our client company as my nine to five job, if that was what you were asking.
This line will cause a memory leak if the sign changes. Now there is another leak in main(). And for anyone that has a clue about C, please don't help this mental midget.
>>12
Listen you stupid fucker. What happens if the bit pattern is becomes unsigned? There will be a memory leak.
A sign change here is an impossibility and makes no semantical sense.
A sign change is a possbility. The fact that you think it's impossible leads me to believe that you've never written a single line of real C code in your entire life. Also, a compiler can't detect a sementic error.
Name:
Anonymous2012-01-05 19:04
>>12
Now what's the range of int64_t you stupid shit jew? Now, compare this range to an unsigned int you stupid fucker. Now shut up and learn something.
>>15
Admit it. This guy is a bigger retard than FrozenRetard, I mean FrozenVoid.
Name:
Anonymous2012-01-05 19:09
>>13
uh what. int64_t* is a pointer type sharing the same value range as int*, void* or char*. The fact that it points to signed values is just a coincidence. Pointer is a pointer, and it's safe to cast the return value of malloc() to any kind of pointer.
I am not casting a pointer to a signed integer. Pay attention to the asterisks.
>>17
But what it points at will cause a memory leak. An yes, the bit pattern is signed. Maybe you should just shut the fuck up and take read the ANSI/ISO C89 standard. Also, you still haven't told me where the other memory leak in main() is?
Geeze, I'm I gonna have to run a memory profiler against your shit code and post the results for you?
Name:
Anonymous2012-01-05 19:12
Hacker News
I'm sorry, I can't hear you over the sound of a million dead Steve Jobs cocks in your mouth.
>>17
There is also a semenatic error in the for loop in print_row(). In other words, depending on the system, the results might not actually display to the screen.
>>18
As far as I know, I can malloc whatever I want and free cleans it up as far as I use the same pointer and don't do any dirty tricks. I also ran the code with instrumentation and checked that amounts of malloc and free match up.
GCC guarantees it.
Name:
Anonymous2012-01-05 19:17
>>20
But it works on my systems and adheres to the definition of printf(). If you're comjpiler doesn't support %lld, well, fuck you then.
Name:
Anonymous2012-01-05 19:19
>>21
Yes, that's true for a signed int. But again, what happens if the int becomes unsigned? Again, there will be a memory leak. And yes, there are trivial situations where something like this could happen.
>>22
I said it was a semantic error. In other words, the code will pass the compilation phase. However, the error will occur during run time. Holy shit you're one stupid fucker. Please tell me your trolling.
>>28
This is actually a simple solution to a simple problem. Won't bother if it's O(fast) but it's way better than that faggot's convoluted answer to a simple problem.
Hey, kodak. Fuck off, ``faggot".
Name:
Anonymous2012-01-05 21:00
>>32
>implying it wasn't long established that kodak is a shitty troll
var counter as integer;
var ptLine as integer[20];
procedure Step(istep as integer);
var couter as integer;
begin
ptLine[istep] := 1;
if (istep<>1) then write( " " + ptLine[1]);
if (istep>=3) then begin
for couter := 2 to istep-1 do begin
ptLine[couter] = ptLine[couter] + ptLine[couter-1];
write(" " + ptLine[couter]);
end;
end;
writeln(" " + ptLine[istep]);
end;
begin
for counter:=1 to 20 do begin
Step(counter);
end;
end.