Why doesn't anymore people define their variables?
int max(int a, int b)
{
if (a > b) {
#define result a
} else {
#define result b
}
return result;
}
Why doesn't anymore people define their variables?
int max(int a, int b)
{
if (a > b) {
#define result a
} else {
#define result b
}
return result;
}
@bobday said:
@gutch said:
There are 10 types of people in this world: those that understand binary, and those that don't.
That's only 2 dumbass.
Yes. This is one example of a joke which has been distributed by people who think they know binary, but don't.
Clearly the number 10 ( = 1010b ) should have been replace by 2 ( = 10b ).
</sarcasm>
Seriously, the normal convention is to use plain numbers only when speaking about base 10 (ten) numbers, or it is clearly stated that it is a different type.
- which is probably why I don't think this joke is funny.
I actually didn't know that the MMX/SSE extensions includes such vector registers. That is a great improvement to the general lack of registers on the x86. (I normally work with embedded DSPs)
In the "great" context of hoping the compiler does not use the registers (I've actually seen thinks like this in working code), maybe it could be done the other way around - copying the struct into the registers and then encoding that copy.
It would probably take a rewrite of the entropy_encode() function, but could possibly be faster due to the values already being in registers. But would still be a huge WTF.
I am a bit curious: Do I understand correctly that you just need the number of bits used, or do you need the encoded bits? If the latter then I assume the bits += is overloaded with some kind of memcpy too?
If you really think the data copying is the problem, then you should instead look into the entropy_encode() function.
It probably takes the bits from the struct, encodes them and then copies them back into the struct. So if you change the destination, you do not need the copy.
But please - do a profiling before changing anything. The entropy_encode() function most likely takes up most of the execution time anyway.
@mfah said:
Whenever I see the words "pointers" and "something totally unrelated breaks", I know for sure what's going on. You can try to fix thisby rewriting as much of the relevant code as you like, but you sir have a pointer bug, and unless this is the only part of your code you use pointers in, you will very likely continue to have a pointer bug afterwards.
Do I understand correctly that you think the general problem is using pointers, and that the fix is to rewrite the whole code base to not use pointers?
Pointers are not evil, and they are often necessary. (Even though some people think they are not using pointers when in fact they use lots of classes/functions which encapsulate pointers.)
The bugs with pointers are just generally more visible than other bugs, (E.g. uninitialized pointer vs. uninitialized int).
- and the concept of pointers can be confusing to some people.
And no - bugs are not solved by rewriting code. Bugs are solved by finding out exactly what is wrong and then changing that. (I know - this is not a perfect world...)
Oh. I actually read it as an int array being treated as a char array. I see now that there is an offset of two chars :-)
I still thinks it could be done more gracefully however, e.g. keep aligned untill passed to sp->send().
Back to the problem:
What do you mean by "memcpy doesn't match up anymore and causes some random, totally unrelated error to occur"?
memcpy() just uses the pointers passed to it, so if the wrong data is copied, you have a problem with your pointers.
Other things to check:
The four first words of the object - are you completely sure that they contain what you think they contain? And still, why not just refer to them with wp->valueName?
Buffer overflow - you don't check for the max size of wp->name.
I have a feeling your problem lies here:
@malfist said:
memcpy(buf+len,wp,4*sizeof(int));
At least use wp->someValue instead of just copying the first 4 words of the object.
I see no reason at all to use memcpy to copy single ints.
memcpy is fast when copying a number of words, but there is probably some overhead when copying only one int. (depending on compiler, architecture etc.)
I would instead just use something like:
*(destination++) = wp->maxStardock;
But why not define an object and send that?
worldScan* buf = new worldScan(worldId, wp);
sp->send((char*) buf);
would be much easier to read, more consistent, and could even be made to result in exactly the same char array being sent.
@joemck said:
And since this is Windows, it's no wonder it couldn't find /tmp unless Cygwin's supposed to be mapping it to C:\temp or something similar.
A standard out-of-the-box Cygwin install maps / to c:\cygwin\, which then contains the standard folders bin, usr, tmp, etc, ...
Other drives like D:\ can be accessed from within Cygwin by going to /cygdrive/d/
It looks like X throws a "standard fatal error" when it cannot access its log file, and that "standard fatal error" refers to the log file.
Simply a case of using a too general error description.
@asuffield said:
@clively said:Most rounding problems occur because people misuse the Double data type.
More precisely: most rounding problems occur because people have no clue what floating point is or why you might want to use it, let alone how to use it.
If you are dealing with money, you do not want to use floating point. Ever. Floating point is designed for physics. The floating point arithmetic operators do not behave like the integer arithmetic operators that you know.
I've always had the feeling that floating point numbers are the variable type equivalent of Visual Basic.
They are very good tools if you know how to use them, but it is too easy to use them without thinking.
But then again - I am doing embedded signal processing, and have no use for the exponential accuracy of floats.