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 !!mJCwdV5J0Xy2A212011-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?
>>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 !!mJCwdV5J0Xy2A212011-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);
}
>>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:
Anonymous2011-12-09 11:01
i h4x0red you're macro
Name:
Anonymous2011-12-09 11:04
implying FV knows how to code properly
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-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:
Anonymous2011-12-09 11:18
>>12 raise abstraction level
the abstraction levels raised so much that they had overflown
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-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:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-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:
Anonymous2011-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
>>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!
>>21
Its FV, what were you expecting... something good?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-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:
Anonymous2011-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 !!mJCwdV5J0Xy2A212011-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 !!mJCwdV5J0Xy2A212011-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:
Anonymous2011-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 !!mJCwdV5J0Xy2A212011-12-09 12:02
>>27
Macros could named like u4fact(x) to signify type.
Name:
Anonymous2011-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 !!mJCwdV5J0Xy2A212011-12-09 12:09
>>29
So i'm accidentally writing u4fact(char) and not noticing my own idiocy?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 12:28
>>34
-1 is not bad input to malloc.
But it should be, since allocating -1 bytes is impossible.
Name:
Anonymous2011-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 !!mJCwdV5J0Xy2A212011-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:
Anonymous2011-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:
Anonymous2011-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.
Name:
Anonymous2011-12-09 12:41
>>38
This would mean that you can handle two times less memory.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 12:41
>>40
i usually compile with relaxed typecasts checks, Digital Mars C option -Jm
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 12:46
>>41
You could sacrifice a little capability for safety, if you really need safety.
If you accidentally pass negative numbers, not intending it, the enterprise_safe_malloc will catch them.
Name:
Anonymous2011-12-09 12:52
>>43
If you pass in a signed number any enterprise compiler will warn you that you're doing it fucking wrong and basically tell you your program could have undefined behavior
Anyone that isn't retarded wouldn't ignore something like that.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 12:57
>gcc -Wconversion mall.c
mall.c: In function 'main':
mall.c:5:2: warning: negative integer implicitly converted to unsigned type [-Ws
ign-conversion]
Yes Fronzenvoid, you're retarded. codepad
You think codepad is going to warn you about being a moron?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 13:07
>>46
I wouldn't need relying on the compiler, since the enterprise_safe_malloc work on all compilers and all user configurations.
Its moron-proof, enteprise-proof, and it provide you with all the safety you much desire.
You can't go wrong with enterprise_safe_malloc despite anything you try.
C isn't suppose to be moron-proof so that morons like yourself won't break things when you try to do stuff that you don't understand like assigning -1 to a unsigned int.
For the many morons out there, like yourself, the compiler is suppose to catch your moronic acts so you don't go off sending your shitty code to the public.
I wouldn't need relying on the compiler
but you already do rely on it to compile your code to begin with so how about you use it properly.
Based on your performance from this thread i would also suggest getting *lint and using it because im sure your code is filled with errors and bugs all over the place due to your retarded train of thought.
You might as well just go use java.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 13:29
If wanted safety, i won't use Java. Ada is much safer.
>>49
Yeah, Ada's safety worked out great for the Ariane 5.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-10 8:52
>>53
Its the safest choice available and its pretty optimized compared to Java.
Name:
Anonymous2011-12-10 11:43
In what world is allowing creating functions like UC_16S_EN_16NS and using it a safe feature? Casting from big storage types to smaller storage types should be made harder with some sort sort information destruction monad. I'm starting to think Ada might be a glorified BASIC with better typing. After the Ada mandate ended projects started using SEPPLES. The JSF uses SEPPLES. wtf http://www2.research.att.com/~bs/JSF-AV-rules.pdf
Name:
Anonymous2011-12-10 14:56
he forgot to enclose his macro parameters in parentheses when he used them
:(
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-10 16:16
>>56
I usually don't need it, since i don't abuse my macros and writing extra parens is not my style.
Name:
F r o z e n V o i d ®2011-12-10 17:48
>>57
I usually don't need it,
since i only abuse functions implemented by macros and
writing cleaner, safe, and unambiguous expressions is not my style.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-10 18:11
>writing cleaner, safe, and unambiguous expressions is not my style.
I just don't dedicate time to it, the macro was just copypasted in a few seconds
If i was optimizing the stuff and using it often, i could rewrite it. Its not some paradigm
"Frozen writes unmaintable code" is just an assumption: the code is written mostly for my own use, i don't really think
you should reuse something like void.h like you do with libraries, you should write your own header which fits your needs/style better(call it macro.h or generic.h if you like).
If you expect to reuse code which i write(actually the code i write for /prog/) you will be limited into the functionality and style i designed, so
don't expect me following some rules.I (personally) dislike standards and rules, but as long as they don't interfere with the process i accept them. Some standard serve a concrete, useful purpose, some are purely arbitrary: i don't have to follow everything to write code. It just needs to compile.
I just don't dedicate time to it, the macro was just copypasted in a few seconds
Copy and paste... Okay I guess? No.
If i was optimizing the stuff and using it often, i could rewrite it. Its not some paradigm
Agree. But won't you spend a lot more time to understand your own code which you wrote some time (days, weeks, months...) ago?
"Frozen writes unmaintable code" is just an assumption: the code is written mostly for my own use, i don't really think
you should reuse something like void.h like you do with libraries, you should write your own header which fits your needs/style better(call it macro.h or generic.h if you like). If you expect to reuse code which i write(actually the code i write for /prog/) you will be limited into the functionality and style i designed, so
Aw shit. I really believed that you in fact were a better programmer outside /prog/, maybe doing something useful!
don't expect me following some rules.I (personally) dislike standards and rules, but as long as they don't interfere with the process i accept them.
Okay, I do too, I find that they somewhat limit my way of thinking. But be advised that this attitude looks childish, in the same way that teens don't like their houses' rules.
Some standard serve a concrete, useful purpose, some are purely arbitrary: i don't have to follow everything to write code. It just needs to compile.
Agree, you seem very practical. With the same argument, I can tell you that racket seems superior to me, and can code anything that compiles and solves my problems. Plus: in much less time than I would do with C, and writing understandable code for at least the next few months.
After all, I do not hold any grudges against you. ОК товарищ?
Name:
Anonymous2011-12-10 19:25
>>59
1. you write shitty code that doesn't always port
2. you style of writing is ugly as shit and non-readable
3. you don't know how to program
4. you don't know C barely
5. you don't know what the standard is
6. you are retarded
Name:
Anonymous2011-12-11 16:54
>>59 the code is written mostly for my own use, i don't really think i don't really think
Do you feel?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-12 11:46
>>62
When you ask me "Do you think or feel when coding" i won't be able to tell.
I certainly don't think when i have the program mentally constructed: i just write it down.
I certainly have to think to create new algorithms or functionality: but what i think is about what i feel the program needs.
Synergy between blindly following your vision creative "Flow" and conscious, rational inventing of new stuff is very productive when its combined.
Now, in this case, we're declaring ShapeType to be a typedef'ed name of an anonymous enumeration. ShapeType is really just an integral type, and should only be used to declare variables which hold one of the values listed in the declaration (that is, one of kCircle, kRectangle, and kOblateSpheroid). You can assign a ShapeType variable another value by casting, though, so you have to be careful when reading enum values.
Name:
Anonymous2013-09-01 15:30
I found an annoying bug that happens when you move to the next floor. It stays loading forever.
Thankfully, because the game auto-saves every time you go to the next floor, you can try to load the game. It may require a few tries.