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.
@seaturnip said:
@belgariontheking said:@sootzoo said:@belgariontheking said:@m0ffx said:
"Worst. Namechange. Ever" is a quote from a comment/forum post (forgot which).Which in turn was a reference to a Simpsons episode in which Comic Book Guy is reviewing the previous night's Itchy and Scratchy episode. What he said was "Worst. Episode. Ever" and the middle word has been changed out to refer to many other things, like presidents.
If you were wondering, yes, you win the Geekiest Reply of the Century Award for that comment. And it's only 2007 - good show!
They actually call me Wikipedia at work because of the way I know everything about the most random stuff, like how the salt used on roads is not your normal table salt.
Depends actually; sometimes it's regular sodium chloride, sometimes it's calcium chloride. Both work, although the latter is somewhat more effective.
Doesn't everybody know this kind of thing anyway? Especially non-obscure Simpsons references.
I agree. If you don't know the "Worst. $Something. Ever." quote is from the Comic Book Guy, you might as well turn in your geek card at the door.
@stratos said:
but before that, open up your favourite pixel pushing program and make a design. Because your site looks like shit, and that's just the nice way of saying it.
This appears to be a site about/for/by gay people
If there is one thing I have learned from TV, it is that gay people are
far superior to the rest of us concerning design, colors, etc.
So this could be an early view of how the next fashion in web design is going to be.
(Just joking)
The world is flat all around the world!
@PJH said:
@PSWorx said:But the pointer returned by foo() does point to the stack - which causes the program to fail. That was the whole point I tried to make.
No it shouldn't. You've just repeated (in a different way) what you said in your first quotation. Either that, or I'm failing to understand what you're trying to say.
If you're allocating memory on the heap, then the pointer returned for that memory must be pointing into the heap.
The only things allocated on the stack are automatic variables and memory reserved with alloca(), thus their addresses will be in stack space.
I think you are actually talking about two different int* foo() ;-)
@PSWorx said:
int* foo() {
int x; //Memory for one integer will be reserved
x = 5; //Something gets written to that memory
int* y = &x; //Allocate memory for y and sore the address of x there
return y; //copy
the contents of y (=the address of x) to the calling function and
return. The memory for x and y gets freed automatically.}
In this function x (and y) is allocated on the stack, thus the returned pointer is to the stack.
@PJH said:
int* foo(){ return new int;}
Here the returned pointer is to somewhere in the heap.
If you look at the timestamps you will notice that the side bar is ordered by when the topic was created, while the forum is ordered by the last reply.
It has - as far as I know - been that way for a long time.
@Sunstorm said:
Furthremore, are you a guy pretending to be a girl in order to generate an aura of compliance?
The Interweb, where men are men, women are men, and little girls are FBI-agents.
@Lingerance said:
which polarity is ground: positive or negative?
Ground is not polarity - ground is ground ;-)
Normal practice is that the "ground" terminal for both left and right speakers are the same - which is exactly what is used in your plug. You cannot however be certain that this is the same "ground" as the chassis of your equipment. (depending on the quality of your equipment)
I suggest you disassemble and find out how it is done before you make something new.