Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

RAW POWER OF ITERATIVE LOOP

Name: Anonymous 2011-12-09 9:08

Bask in the glory of such genius:
http://dis.4chan.org/read/prog/1323226650/65

Name: Anonymous 2011-12-09 9:10

LISP technology cannot handle such advanced code without overflowing the stack and crashing the LISP interpreter.

Name: Anonymous 2011-12-09 9:11

iterate my anus

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 9:14

>>1
Explain what is your problem with this macro? its identical to a function call.

Name: Anonymous 2011-12-09 10:45

It actually breaks because FV doesn't understand the need of once-only. For example, if fact was a function, fact(x++) would give different results than the c macro implementation (which is just a text substitution). This would be fixable by introducing a new lexical scope and a local variable which is bound assigned the value of the argument, however you'd then have the problem of potentially shadowing some function name/creating naming or symbol conflicts, all which wouldn't happen in Lisp due to one having easy access to gensyms.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 10:49

But i know exactly what happens inside my macro, and i won't make such a mistake in the first place.
If you want to use fact(x++), perhaps its better to ;x++; first and ;fact(x); later?

Name: Anonymous 2011-12-09 10:53

>>6
However that makes the macro non-general/non-reusable. You will also have to remember to work around all the special cases (such as having to bind the value to a variable before passing to a macro, or knowing all the names of the variables used by the macro, so you don't accidentally use them in your actual code).

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 10:54

here is a slower version,which handles the problem of people abusing the macro.
int c,*temp;
#define fact(x) ;for(temp=&x,c=*temp-1;c;c--)*temp*=c;
main(){
int x=5;fact(x);
printf("%d",x);
}

Name: Anonymous 2011-12-09 10:58

>>8
the problem of people abusing the macro
the problem of people abusing the macro
the problem of people abusing the macro
You're brilliant. Never change, FV.

Name: Anonymous 2011-12-09 11:01

i h4x0red you're macro

Name: Anonymous 2011-12-09 11:04

implying FV knows how to code properly

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:09

The macro in >>1 just replaces writing the loop. I don't mean to use it as some generic function, it just looks identical.
#define fact(x) ;for(c=x-1;c;c--)x*=c;
i could just write the loop inline, if i'm not reusing the macro.
By reusing the macro i save typing time and raise abstraction level(for free, since its just text replace)

Name: Anonymous 2011-12-09 11:18

>>12
raise abstraction level
the abstraction levels raised so much that they had overflown

Name: Anonymous 2011-12-09 11:18

fact(-1);

Name: Anonymous 2011-12-09 11:22

fact(fact(fact(fact(...))))

Preprocessor abuse at its best.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:22

>>14
Factorials for negative numbers are undefined. If you to implement specific error-handling code(bloated cludge to prevent using fact macro with negatives) inside every macro call, its your own choice: you could pass positive static integers arguments or use a specific function which would calculate dynamic arguments on the stack and even recursively call itself.

Name: Anonymous 2011-12-09 11:27

>>16
error handling bloated

You're an arrogant and bad programmer.

Inb4 "but ill never make a mistake"

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:29

>>17
The macro was designed to produce the fastest code. It won't check for error,dynamic arguments or invalid input.
Its just a quick replacement for full blown function(without the overhead of any function).

Name: Anonymous 2011-12-09 11:30

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -Brian W. Kernighan

Name: Anonymous 2011-12-09 11:31

>>16
Then, your macro is defective, because it doesn't handle all possible cases. You should've implemented an error-throwing guard. Oh wait, it's SEE!

Also, fact("hurr");

Name: Anonymous 2011-12-09 11:33

>>18
Err, since when multiplication is considered "the fastest" way to calculate factorial?

Name: Anonymous 2011-12-09 11:37

>>21
Its FV, what were you expecting... something good?

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:45

>>20
This will be catched by the compiler. It is not defective. It serves the exact purpose: to calculate factorial. it expect its argument to be positive integer. If you don't follow the macro rules, expecting it to handle all your idiocy automatically you will be mistaken.

Name: Anonymous 2011-12-09 11:48

>>23
Why don't you just use a static inline function instead of a macro?

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:50

>>21
The simplest way is to loop multiply all the numbers. You can write more complex(and faster) functions, but this is not about the maximum factorial performance: the performance class of multiplicative loop and optimized iterative functions is the same, unlike the class of recursive function call version.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 11:53

>>24
I would as easily use inline function, if there is guarantee that such inline functions are really inlined(and macros are guaranteed to inline automatically, without any overhead).
macros are just exactly like if you typed the entire function body in-place.

Name: Anonymous 2011-12-09 11:59

>>26
Yes but macros don't benefit from the static type system, functions do, and in this case I would rather have a guarantee that an integer is passed to the function.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:02

>>27
Macros could named like u4fact(x) to signify type.

Name: Anonymous 2011-12-09 12:05

>>28
Yes but the user of the macro might accidentally input something that isn't a "u4", humans make mistakes you know.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:09

>>29
So i'm accidentally writing u4fact(char) and not noticing my own idiocy?

Name: Anonymous 2011-12-09 12:09

>>30
You're always doing that.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:11

I just wonder how one would expect the macro which is named UnsignedInteger4BytesFactorial to handle char variables?

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:14

Also, if functions are so well designed to handle bad input, why malloc(-1) causes a segmentation fault?

Name: Anonymous 2011-12-09 12:17

>>33
-1 is not bad input to malloc. You are trying to allocate 0xFFFFFFFF bytes of memory and it segfaults because you run out of memory.

Name: Anonymous 2011-12-09 12:21

>>33
Read your standard.

malloc(-1) errors are implementation defined

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:28

>>34
-1 is not bad input to malloc.
But it should be, since allocating -1 bytes is impossible.

Name: Anonymous 2011-12-09 12:30

>>36
malloc takes an unsigned integer as the argument. It is not the fault of malloc if your intention was actually to allocate an illogical amount of bytes, rather than just using "-1" as a quick way of typing "0xFFFFFFFF".

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-09 12:34

>>37
What if -1 is in 64-bit system, its allocating 0xFFFFFFFFFFFFFFFF bytes?
Just because it doesn't not handle -1, does mean its a proper function.
enterprise_safe_malloc() would take a signed integer as argument and printf a detailed explanation of your attempt to allocate negative bytes.

Name: Anonymous 2011-12-09 12:35

>>36
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.
Read the standard moron.





malloc takes in a size_t

Do you know what a size_t is?

do you know what happens when you assign unsigned integers a negative number?

Name: Anonymous 2011-12-09 12:37

>>38
Do you disable warnings when you compile your code?

Try assigning a function that takes a unsigned integer a signed integer with -Wall


You're a moron, you don't know how things work and you think putting functions in macros are a better thing.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List