Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[EnigmaticHat]

I have such a bad habit of that, when something goes wrong I start adding debugging lines and then the problem is fixed I delete the debug lines (that are often far too vague to be readable, like printing the letter "a" whenever something happens).  Really need to be better about that.

The only thing I say is that in my experience if a piece of code is going to be running hundreds of times per frame/tick/whatever, printing to console each time can slow your program down significantly.  Sometimes printing to console is more expensive than whatever you're trying to log.  It can obscure where the real performance bottlenecks are.  But as you said the print lines can be commented out until needed.

[RadtheCad]

Yeah, in my last few home projects I've used C and I've gotten used to adding successive printf's to home in on problems/crashes/bugs in general. 

I've tried to get better about using more efficient methods- I recently forced myself to look up how to use gdb (gnu debugger). Very useful (if you compile your code with the debug flag).  You run the executable through gdb, it tells you what function it crashed in.  Now I only need to add printf's throughout a single function!

(I keep telling myself it's not so bad, because it motivates me to make my functions smaller, which is a good thing for readability/maintainability anyway).

[WealthyRadish]

I'm not sure if this has earned me a place in programmer hell, but in C++ I often use preprocessor directives to enable and disable debug output/logging instead of commenting and uncommenting the statements.

[MorleyDev]

Preprocessors in C++ are a fair enough way of doing it, so long as they are wrapped in a logging function and not just sprinkled everywhere.

Most of the time I try to go for an existing logging library, since it lets the logging be controlled at runtime and makes it easier to log to another source like a file instead of just the console. But I'm not sure what a good one to recommend for C++ is. I know boost has boost::log, and they're a fair few header-only ones for C++ floating around the interwebs.

[Eschar]

You are only checking 4 neighbours of each tile so the number of "wall_rock"s is never going to be 5. Also the index -1 refers to the last element of a list (not sure if this is intended behaviour or not).

*facepalm*
I think that's it. Thank you.

I was reading the older posts in this thread, and came across this embarrassingly relevant quote:

I've helped enough people debug their code to know that the problem is almost always in the one place they are 100% certain works and so didn't bother testing as the possible origin of the bug. That and preconceptions about the code will impede one's ability to debug it when it fails to run as expected.

[Telgin]

Preprocessors in C++ are a fair enough way of doing it, so long as they are wrapped in a logging function and not just sprinkled everywhere.

Most of the time I try to go for an existing logging library, since it lets the logging be controlled at runtime and makes it easier to log to another source like a file instead of just the console. But I'm not sure what a good one to recommend for C++ is. I know boost has boost::log, and they're a fair few header-only ones for C++ floating around the interwebs.

Agreed.  A dedicated logging function or system is a good idea.  There are a lot of potential things you can do with it, like logging to a centralized database like Graylog, but honestly the biggest draw to me is being able to selectively enable and disable the logging.

A small part of me dies inside when I see naked debugging logging statements being committed to Git and then spamming the live server's logs.  We finally implemented a way of switching debugging logging on and off based on environment variables, and that got a lot better.

[McTraveller]

Debated whether to put this here or in the WTF thread.  But I think here is relevant because it's related to the previous comment about comments. (meta!)

I was informally reviewing some code, and saw the following (anonymized, of course):

Code: [Select]

for(i = 0; i < limit; i++)
{
    if( array[i] == item_of_interest )
    {
        /* break out of the loop, because we found the thing we want */
        found_index = i;
     }
}

It's totally awesome when one line of code doesn't match the comment next to it.

[Telgin]

At least it looks like the code and comment would be correct if a break statement were inserted.  Could be worse!

Interestingly, I was going to say that this is an example of a somewhat useless comment that only rots when the surrounding code changes, but it might actually be pointing out a bug in the missing break statement.  Then again, it could actually be comment rot, and that break could have been there previously and subsequently removed for good reason.  Hard to tell.

[wierd]

If you are iterating through a several hundred thousand deep index (customer DB for a fortune 500, etc) it makes no sense at all to KEEP PARSING until you hit the bottom, if you have found your target record.

More sensible would have been to control the loop with a local variable like "RecordFound" as an integer.  Set it to zero before the loop, then set it to either 1 when you find it, or 2 when you hit the bottom of the array.  While RecordFound is < 1, do the loop. On each increment, check if i = > MaxIndex.   You could set any number of other conditions greater than 1 for any errorcodes hit when accessing the record index table (such as "NOT POPULATED!" or  even "access denied".) and return that value along with the record index.

But meh.

[bloop_bleep]

Why do you need to set it to two when you hit the end of the array? I usually just make it a bool, set it to false before the loop, and true if I find the correct element. If it's still false by the end of the loop, that means the entire array was looped through without finding it.

[wierd]

It lets the caller know very quickly and efficiently if the requested data was not found, or if there was an error while parsing the array (and what it was)

Remember, people are idjits.  They will try to pass uninitialized variables to your function. They will try to pass arrays with zero members. They will try to pass arrays of the wrong type. If it is boneheaded and stupid, they will try to do it.

Being able to return a status code that is appropriate to their brand of stupid, helps them realize why they are not getting the result they are expecting.  Simply killing your loop at the bottom of the array, and failing to populate the desired return variable will just make the shmuck calling your function scratch his head and be angry (and likely curse your function for not being magical enough.)

EG-- let's say that our codemonkey INTENDS to pull a table from the CUSTOMERS database, containing customer names, and push it into an array named CustomerNames[].  However, he is a bonehead, and HAS NOT ACTUALLY DONE THAT YET, and just has an uninitialized array of that name.  He **THINKS** he has, but no-- he really has not.  He calls your function; The array has zero members. From the start, the loop terminates right away. (perhaps even causes a general exception.) This looks the same as "parsing the whole list, and not finding the record."  Suppose he KNOWS the record is in the table he thinks he is pulling. (say, this is a test database, and he KNOWS it is there, because HE PUT IT THERE.)  How does he know that he should check if his array is initialized or not?

Why not tell him politely?

[Reelya]

You should make it an enum then, to make the status clearer. Same code though.

[MorleyDev]

I'd use std::optional if writing a custom find/findindex, assuming latest C++ standard. Makes the type system force the developer to handle the not found case whilst also acting as documentation that it can return nothing in the type system, which is the best place for such documentation

I also try and avoid break when possible. The vast majority of the time, if you need to break out of a for-loop then the code belongs in it's own function and you can then return out of the entire function. No stateful variable retvalue shenanigans needed.

As for the idea of a different result for an empty array, searching an empty array and finding nothing and searching a full array and finding nothing are equivalent operations, to my mind, so I'd have both return the same thing: None.

It's not the responsibility of a find function to care about the length of the array it receives, and having to handle more than "found" or "not found" complicates all of the calling code despite often searching an empty array actually being a valid operation, especially if your find is chained after other operations that could have filtered data out of the array beforehand.

I'd argue you stand a chance of catching developers out in a far more obtuse and hard to reason about way by the result of a find on an empty array being different from on a populated array. The fear of someone making a specific mistake with a simple algorithmic find function should not be leaking extra complexity into the rest of the code base or complicate legitimate occurrences that can't be differentiated from inside the find by breaking the concept of an 'exists/doesn't exist' find in the first place.

Unintialised data raises a general exception because that is a potentially unrecoverable general exception, no need to add any extra checks over what should be a crashing error.

(Of course, in C++ in practice I'd most likely use one of the find algorithms the standard library already contains, instead of rolling my own. Same as with LINQ in C# or streams in Java. It's actually pretty rare to need to care about the index when dealing with sets of data when using those kinds of algorithms).

[McTraveller]

First some context - I write embedded real-time code. I get to avoid using all those bloated, overkill "standard" libraries. Why use a library when a three-line search function works?

Also:

It's not the responsibility of a find function to care about the length of the array it receives

I don't know how you can implement a search that can determine "not found" if it doesn't know the number of items in the collection it is searching.  Or are you suggesting some kind of abstract "get next item" interface even to arrays so the find function doesn't need to know length?  Sounds like unnecessary complexity to me.

[bloop_bleep]

Standard library containers have a size() member function. As should all containers.