161–170 of 178 posts
Earlier quoted context omitted.
I think the rationale is in EBCDIC support; the C standard didn't want to/couldn't mandate ASCII, and therefore could not use the ASCII NUL character. I honestly don't know whether POSIX/SUS mandates ASCII.
As far as I understand, no: http://www.opengroup.org/onlinepubs/000095399/xrat/xbd_chap0...
Earlier quoted context omitted.
Whoops, I forgot the point I was trying to make. NULL is (void * )(0), but the code void * p; memset(&p, 0, sizeof(p)); assert(p == NULL); isn't necessarily valid, since the binary representation of NULL isn't necessarily as a sequence of zeroes -- even though everybody writes code which assumes that it is.
Yeah, that's unportable. Although I'm not aware of any system where it doesn't work. For the record, regarding 0 in pointer context the C standard has this to say: An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that…
Funny how readable Python is: def condense(s, remove): return "".join([c for c in s if c != remove]) Cheating (2.6+): s.translate(None, remove)
The pythonic version would be s.replace(c, '')
Earlier quoted context omitted.
I think you exaggerate. If you actually look at advertisements for c/c++ developers, they tend to contain words to the effect, "Must have 4-5 years experience in high speed algorithmic trading", etc. But if you know any good-paying jobs that only require the skill level you suggest, point me in that direction. (I mean that--I can get away from my current huge and horrible codebase. Speaking of which, I remember being…
In the original C implementation function names could be as long as you wanted, but the compiler only looked at the first six chars.
I'm sure RiderOfGiraffes doesn't want a third entry from me at this point, so I figure I might as well just post it here: #define C char #define F for #define R condense_by_removing #define V void V R(C*A,C B){F(C*J=A;*J=*A++;J+=*J!=B);} or without #defines: void condense_by_removing(char*A,char B){for(char*J=A;*J=*A++;J+=*J!=B);}
Here is the same code, without syntactic obfuscation: void condense_by_removing(char* s, char c) { char* d = s; while (*d = *s++) d += *d != c; } I would have sworn I found a bug. There is none. Brilliant. Now, I wonder if we could further optimize it. For instance by accessing memory several bytes at a time, in a fashion similar to strcmp().
Works with gcc though.
Can somebody throw some light on how this works?
Earlier quoted context omitted.
Yes, but in doing so, you traded a memory write for a branch. And memory accesses are linear, so that's likely faster than the cannon. So surely we could go further? That's how I got the idea.
Many compilers will implement d += *d != c; with a branch, and depending on the data pattern the branch predictor will be bamboozled. The branchless version would involve a pair of subtractions and some bit banging.
Here's the code I tested. I think it works, but I barely checked it. I'm sure there are better ways to calculate 'increment'. Not sure if these would be enough to close the gap, though.
void condense_by_removing_branchless(char *z_terminated, char char_to_remove) {
char *condensed = z_terminated;
while (*z_terminated) {
*condensed = *z_terminated;
int diff = *condensed - char_to_remove;
int increment = -((diff | -diff) >> ((sizeof(int) * 8) - 1));
condensed += increment;
z_terminated++;
}
*condensed = 0;
}Earlier quoted context omitted.
In that case, I'd suggest `p_rd` (well, IMO, just `rd` would suffice) and `p_wr`. Then they're both fairly unambiguous abbreviations.
I think p_wt is better than p_wr. Honestly though, aligning the length of variable names is, in my humble opinion, retarded - he should have went for p_read and p_write.
Earlier quoted context omitted.
It's convention for C strings to be \0 terminated, and the standard library expects this just about everywhere (along with the kernel and just about everything else you might want to interface with). If you wanted to store a string as a (length, data) pair you could do that too, but you'd have to write most of your own string manipulation functions.
Interestingly, if you did store your string as (length, data) pairs, strlen would be an O(1) rather than an O(n), which would also impact strcat. Also, strtok could possibly become non-destructive. The length value of the pair could be an 8 bit character value at the beginning of the array (which is how Pascal did it). That limits you to strings of length 255. If you represented strings as a struct containing an inte…
char *d,*s;
for(d = s = z_terminated;
*s;
s += (char_to_remove== *s)?1:((*d++ = *s++),0))
{;}
*d = *s;