17 Aug, 2011, kiasyn wrote in the 21st comment:
Votes: 0
isn't openoffice java?
18 Aug, 2011, Runter wrote in the 22nd comment:
Votes: 0
re always fix warnings

I fix actual bugs. Not warnings on legit code. Btw, usually "fixing a warning" means rewriting code in a grosser way to get the compiler to shut up.

Oh, and let's remember…different compilers have different warnings. Do you plan on fixing all warnings for all compilers, or just your favorite one?

Personally I prefer to just write valid C that compiles as I expect and I use the warnings as a chance to ensure I'm reflective on my logic. I.e. I don't ignore them, but I don't necessarily fix them just to get the compiler to shut up.
18 Aug, 2011, Rarva.Riendf wrote in the 23rd comment:
Votes: 0
kiasyn said:
isn't openoffice java?

Mostly no.

Quote
I fix actual bugs. Not warnings on legit code. Btw, usually "fixing a warning" means rewriting code in a grosser way to get the compiler to shut up.

I was talking about Valgrind warnings, there are very few of them that can be safely ignored.

(and could you state an actual example of a ROM based code that would need a grosser way code to compile without any warnings ?
I only have the isdigit isspace etc stuff actually annoying in mine).
18 Aug, 2011, Runter wrote in the 24th comment:
Votes: 0
You see people writing code casting char * to get a compiler to shut up all the time. You see people taking perfectly legit nested if statements and adding brackets. The list goes on, but I don't know what all compilers out there actually warn about. It wouldn't be called a warning, though, unless it was something potentially legit in the first place.
18 Aug, 2011, Rarva.Riendf wrote in the 25th comment:
Votes: 0
Runter said:
You see people writing code casting char * to get a compiler to shut up all the time. You see people taking perfectly legit nested if statements and adding brackets. The list goes on, but I don't know what all compilers out there actually warn about. It wouldn't be called a warning, though, unless it was something potentially legit in the first place.

Ok I see what you mean, I agree. (gcc is less annoying than g++ last I tried as well). But my concern was really about Valgrind warnings. I could not care less about code style and forced casting in a compiler. (and all is isdigit etc is about casting warning as a matter of fact heh)
18 Aug, 2011, David Haley wrote in the 26th comment:
Votes: 0
Quote
It is a leak as it is memory you won't recover though it wont be used ever again. (You could, but you dont, so it is the same effect than a dereferenced pointer)

No, it's not the same effect at all. Unreferenced memory is lost forever, and if that memory is allocated in some repeated event, you're going to be progressively leaking more and more memory.

Quote
And you can have enough of them to go past your allocated memory.

Yes, you can also allocate too much perfectly legitimate memory.

Quote
That is why your cleaning method should clear everything you know you are actually using.

Yes, but not for the reasons you're giving. You're not fixing memory leaks by cleaning memory at shutdown that will be released on shutdown anyhow.

It's good practice because then if you decide to have reusable or otherwise reentrable game state, you know that your cleanup routines actually work, and in some (relatively unusual) cases you might be releasing resources with other processes. Resources with the OS tend to not matter because the OS will clean those up when the process dies, although in some cases it takes it a while (bound sockets are an example on some OSs).
18 Aug, 2011, Rarva.Riendf wrote in the 27th comment:
Votes: 0
David Haley said:
Quote
It is a leak as it is memory you won't recover though it wont be used ever again. (You could, but you dont, so it is the same effect than a dereferenced pointer)

No, it's not the same effect at all. Unreferenced memory is lost forever, and if that memory is allocated in some repeated event, you're going to be progressively leaking more and more memory.


Memory you do not use but still allocate in repeated event is also lost forever. Exact same result. I do not see why you have a hard time admitting it. A cleaing memory force you to think about everywhere you allocate memory. And thus lead you to those cases.
You could build a list of quests, always adding an element for each new quest but never free a quest when the quest is over.
This quest will never be accessed again, but still is referenced. It could be dereferenced it would be the exact same thing. The fact you could free it is irrelevant: you do not.
When you write a clearing method, you can add a check to see if the quest is still valid, and if you find it is not, it means there is a problem. the same exact problem there would be if you dereferenced the pointer. Like you can see with my shop clearing method where I did put a log: because no shop should ever exist after I cleared a mob. If I screwed somewhere it means that when you kill a shopkeeper the list will grow at a repop.
My pointer to the old shop would still be referenced, but I would not access it. Tell me why it is different than dereferencing the pointer.
It is a leak.
18 Aug, 2011, David Haley wrote in the 28th comment:
Votes: 0
Quote
My pointer to the old shop would still be referenced, but I would not access it. Tell me why it is different than dereferencing the pointer.
It is a leak.

No, it is not. You have a reference to it. It is not a leak.

It is a waste.

It is not a leak.

This is a definitional question…
18 Aug, 2011, David Haley wrote in the 29th comment:
Votes: 0
Besides, what are you going to do? Write a routine at shutdown that iterates through these things and frees them? Great – you've cleaned up at shutdown but done nothing to actually fix your wasted memory.
18 Aug, 2011, Runter wrote in the 30th comment:
Votes: 0
I think the distinction between being able to free the memory (even if you do not) and losing the pointer is an important one. Indeed, if the pointer is still around it's arguably a design flaw. If the pointer is lost it's indicative of a memory leak.
18 Aug, 2011, Rarva.Riendf wrote in the 31st comment:
Votes: 0
David Haley said:
Besides, what are you going to do? Write a routine at shutdown that iterates through these things and frees them? Great – you've cleaned up at shutdown but done nothing to actually fix your wasted memory.

Well beside the definition problem I will stop arguing about (if I refer to wikipedia definition, I am in the 'many people call it etc').
I explained why doing so will detect a problem (if I have a log telling me that I cleared a shop there it means that somewhere in the code I forgot to clear the memory when I should have) if you do not do that, I do not see how you will ever detect there is a design problem in the first place. (except by 'leaking' (or allocating whatever) enough memory till you actually a have a problem with it)

And a lost pointer is a design flaw as well….(just a different kind of one)
18 Aug, 2011, Vigud wrote in the 32nd comment:
Votes: 0
Runter said:
re always fix warnings

I fix actual bugs. Not warnings on legit code.
http://www.youtube.com/watch?v=4zgYG-_ha...
The Microsoft analysis tools are always on and warnings are errors. Cant build the game if it complains about anything. I think it's a good practice and I'll tell you why.

Quote
Btw, usually "fixing a warning" means rewriting code in a grosser way to get the compiler to shut up.
Actually, most of the warnings have to do with unspecified or undefined behavior and you shouldn't ignore that.

Quote
Oh, and let's remember…different compilers have different warnings. Do you plan on fixing all warnings for all compilers, or just your favorite one?
Yes, that's a very good practice. God only knows how many actual bugs went under our radar until we tried to run our MUD on another platform, compiled with another compiler. GCC is very, very good at hiding bugs in your code.

Quote
Personally I prefer to just write valid C that compiles as I expect and I use the warnings as a chance to ensure I'm reflective on my logic. I.e. I don't ignore them, but I don't necessarily fix them just to get the compiler to shut up.
There are types of warnings that I turn off by default and only turn on when I want to see absolutely every single thing that the compiler wants me to know about. One example would be the unused-parameter type of warnings, very annoying in case of Diku-based MUDs, where all commands and spells are functions that are always defined with the same parameters, but many of those functions don't make use of all function parameters. But almost all other types of warnings are useful and these things should be ironed out, even if you think they're harmless. Because they may be only harmless when compiled with your favorite compiler or build on your main platform and it can turn out problematic on another platform or with different compiler.
18 Aug, 2011, Vigud wrote in the 33rd comment:
Votes: 0
20.0/33