>>1
You should never malloc on one level and have the user free on another, terrible design.
Name:
Anonymous2012-10-03 19:17
>>1,5
Here is a version that accepts any type of array provided by the user, if the user wants to use malloc it can and more importantly the user may do malloc and free on the same level also the user may use stack arrays like a normal human being, you also avoid casting away type information through void pointers and look, you may even use different types of arrays in it.
>>6
You can do a fold implementation with the same style by the way, but first I want to let it be known that I do not endorse actually writing code in this style.
Obviously these macros need sanitation when it comes to side-effects etc. but that is pretty trivial when we're already using extensions and is left as an exercise for the reader.
>>13
You don't open/malloc on a higher level (inside a scope) and then let that bubble out to the user, design like that is extremely error prone. If you absolutely have to do it you should always provide an equivalent close/free function. If you can you should always let the user provide the allocated memory, since then they are free to allocate and deallocate however they wish.
Mandating malloc in your program through your API like this (you tell the end user to free the result, at least I hope you do) is also bad, since you can't ever change the function to not use malloc, this is another reason for providing an equivalent close/free function.
Not to mention that malloc typically performs bad in multi-threaded programs and can also fail (which you don't even account for in your map function).
Either way, you can program a map function, or better, a function-like macro that can't fail, won't use dynamic memory allocation and the user won't have to free the result unless they called malloc themselves in less and clearer code than what you wrote, I think the advantages are obvious.
Name:
Anonymous2012-10-04 12:40
Or you can just write a destructive version of map and stop being autistic .
I highly doubt a single map function would act as an API hidden from the 'user' to begin with.
In the end your issue come down to a codemonkey that didnt read the api docs or source code to realize he needs to free the reault.result with that being said i doubt he would have even remembered to free his own allocations within the same scooe.scope
Name:
Anonymous2012-10-04 12:54
>>17 Or you can just write a destructive version of map and stop being autistic .
What if you need another array? I'm all for just writing a god damned for loop anyway.
I highly doubt a single map function would act as an API hidden from the 'user' to begin with.
Normally it would be bundled with other functional stuff, seems like OP is trying to implement some. And obviously it wouldn't be hidden, it would be part of the API.
In the end your issue come down to a codemonkey that didnt read the api docs or source code to realize he needs to free the reault.
This isn't the issue, people who know you have to use free with malloc sometimes forget to use free because humans make mistakes also when large bodies of code create something complex it might be difficult to trace where you should free anyway, it's just a good principle to never let pointers to things you have to clean up escape from your control.
Look, it's pretty clear, one implementation of this function can fail through use of malloc and easily leads to errors, it's also less flexible in terms of control for the end user and it has more code, whilst the other can't fail and the user controls the allocation and has less code, as I said, the advantages are obvious.
How does gcc handle scope names if i named another variable _i when using the that?
Name:
Anonymous2012-10-04 14:42
Probably can compile most useful features of Symta directly into C/C++, but it requires `eval`, due to macros. Also, there would be no closures, because C/C++ doesnt support generating functions of fly. There is http://www.gnu.org/software/lightning/ but I hate Stallman because he is Jewish hypocrite.
#define MAX_LSTS 1024
#define MAX_ELTS 1024
int _Pool[MAX_LSTS][MAX_ELTS+1];
int _PoolP=0;
int *newList(int N) {
_Pool[_PoolP%MAX_LSTS][MAX_ELTS] = N;
return _Pool[_PoolP++%MAX_LSTS];
}
int len(int *Xs) {return Xs[MAX_ELTS];}
int *rng(int S, int E) {
int I = S<E ? 1 : -1;
int *Xs = newList(abs(E-S)+1);
int *P = Xs;
int *T = P + len(Xs);
while (P<T) {
*P++ = S;
S += I;
}
return Xs;
}
int *each(int *Xs, void (*f)(int)) {
int I, N = len(Xs);
for (I=0; I<N; I++) f(Xs[I]);
return Xs;
}
>>36
If only he kept all his idiotic bullshit in just one thread. But no, he has to shit up the entire fucking board. At least if he used a tripcode or name I could just filter out his posts.
>>23
This isn't what he's suggesting, that is what I am suggesting.
>>24 Can i use this in C89/99?
You can use the map macro, but you won't really gain any thing over just a for loop. You obviously can't use the nested function thing, that's GCC specific.
How does gcc handle scope names if i named another variable _i when using the that?
Just like it would any other scope, it works fine.
>>26
It's O(n) slower than not doing anything at all, and this is noticeable when you don't have to do it.
>>45
It's about O(n/c + k) where k is at most 1/500 the time it takes a neuron to fire and c in the thousands. You won't—can't—notice it unless n is astronomical.
What's slow is managing that memory. Which is waaaaaaaay more than O(n) if it contains pointers or lives for any appreciable amount of time.