Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 01:52:00 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 256 257 [258] 259 260 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733423 times)
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5140 on: October 06, 2016, 04:54:16 AM »

People using .get on unique pointers makes me sad Sad
That's what I'm doing after the long discussion we had recently after which it was concluded that I should just pass regular pointers around (for nullability) that are owned (as unique pointers) by someone else. Then this was cemented after watching some of the cppcon talks about ownership and never assuming ownership of a raw pointer and not passing around smart pointers all the time.

So I have the unique pointers in an object and then there are getters to get those by name as regular pointers (because there might not be anything by that name, in which case null is returned), which calls get() on the internal pointer to return the raw one stored in it. All other code knows it does not own regular pointers and won't attempt to modify or delete them.

Maybe that's not the issue you meant tho?

Yeah sorry I was a little vague. What I'm referring to is when some function A takes a raw pointer from the calling function B which is passed in via get. The unique is function local in function B and function A stores it for a later time. Unique destructs at the end of its scope and the stored raw pointer is now invalid. Dangling pointers.

Logged

oahda
Level 10
*****



View Profile
« Reply #5141 on: October 06, 2016, 04:59:07 AM »

Oh. That's not good indeed. :c Where did you come across this usage?
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5142 on: October 06, 2016, 05:06:55 AM »

Oh. That's not good indeed. :c Where did you come across this usage?

Errr.. Not at liberty to say :D

Although I wonder if this is something that could be somewhat solved with pointer attributes (C++ 17?). If you mark your intent to store the pointer would it be possible for the compiler to detect potential sources of dangling pointers like this?

I'd have to think for a while if that's even possible..
Logged

oahda
Level 10
*****



View Profile
« Reply #5143 on: October 06, 2016, 05:12:26 AM »

That sounds like something for the tool that Herb was talking about. Maybe.



Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5144 on: October 06, 2016, 07:05:12 AM »

Cool I'll check that out. You are inadvertently aiding my health as I only watch cppcon videos on the treadmill :D
Logged

Thomas Hiatt
Level 0
***



View Profile
« Reply #5145 on: October 08, 2016, 08:07:41 AM »

Either debuggers are horrible or I don't know how to use them. Every time I have a problem where I expect a debugger to help me it just wastes my time and I get demotivated and stop working.

Code:
int ct = 0;

while(length_squared(vertices[i] - triangles[ct].center) > triangles[ct].radius_squared)
{
    vec2 td = (vertices[triangles[ct].p1] + vertices[triangles[ct].p2] + vertices[triangles[ct].p3]) / 3.0f;

    if(segmentIntersection(td, vertices[i], vertices[triangles[ct].p1], vertices[triangles[ct].p2]))
    {
        ct = triangles[ct].a1;
    }
    else if(segmentIntersection(td, vertices[i], vertices[triangles[ct].p2], vertices[triangles[ct].p3]))
    {
        ct = triangles[ct].a2;
    }
    else if(segmentIntersection(td, vertices[i], vertices[triangles[ct].p3], vertices[triangles[ct].p1]))
    {
        ct = triangles[ct].a3;
    }
}

In some circumstances, this code gets stuck in and infinite loop. I would like to be able to use the debugger to look at the values to see wtf is actually going on. The only values I can actually look at are 'ct' and 'i', if I want to look at the others I have to type out all the different operator calls longhand into the watch window, and sometimes even that doesn't work

I don't really know how debuggers work, but I feel like I should be able to highlight any section of code and mouse over it to what its value is or will be. If debuggers can't provide that simple functionality why would anyone choose to use them rather than spending a minute to put some print statements in their code?
Logged
oahda
Level 10
*****



View Profile
« Reply #5146 on: October 08, 2016, 12:33:43 PM »

I solve 99.99% of my problems by printing stuff myself at least. But breakpoints are occasionally useful. Won't say I'm an expert on the debugger, and they all probably work differently anyway. Whichever one Xcode uses underlyingly with LLVM and the way it interfaces with it usually works well for me at least.
Logged

powly
Level 4
****



View Profile WWW
« Reply #5147 on: October 08, 2016, 01:22:05 PM »

In the world of debuggers, there are two categories: the one in visual studio and everything else. The former is in nearly all cases vastly superior to print-debugging, the latter is usually a waste of time.

Okay, maybe I exaggerated a bit, but if you're using something else, give VS a try. It does exactly what you suggest; you can hover over any variable (also structs, lists and so on) and see its current contents. It's very neat in many other aspects as well (but obviously not perfect, either.)
Logged
bateleur
Level 10
*****



View Profile
« Reply #5148 on: October 10, 2016, 11:34:01 PM »

In some circumstances, this code gets stuck in and infinite loop.

I realise you're mainly grumpy about debuggers (I feel similarly and mostly don't use them), but one thing I do recommend is that you always, always add an else clause at the end of an if chain like this and put error handling code in there (eg. print out the values of everything and then breakpoint). It costs basically nothing and saves a huge amount of time by catching problems early.
Logged

Garthy
Level 9
****


Quack, verily


View Profile WWW
« Reply #5149 on: October 11, 2016, 12:26:57 AM »

Debuggers are like hammers, and a good logging library (or printfs) like a screwdriver. Sometimes you have to hammer in a nail, and sometimes you need to drive a screw. It's good to know both, so you can pick the best tool for the job.

For the code here I'd be tracing first. If I could recreate the problem easily I'd add a bunch of traces, or if not I'd put in a counter that counts iterations and starts tracing once there were more than say 10000 iterations of the loop. I might switch to debugging once I had a better idea as to what was going wrong if the traces were insufficient to solve it.

To make the code here work more gracefully with a debugger you could set a whole bunch of locals to values of interest, and turn off optimisations to ensure they aren't optimised out. In fact, you could tidy up all of the "vertices[i ]" and "triangles[ct]" references in this way, which would make it both easier to maintain and easier to debug.

Also, I think bateleur has spotted the (likely) bug in the code here. If none of the if statements trip, ct will never change and the loop is infinite. Of course it could also be cycling through a repeating set of values for ct as well. Or something else.
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #5150 on: October 12, 2016, 03:11:21 PM »

Subtraction doesn't work right when you forget to set the carry bit.  Took me a whole day to find that bug...
Logged



What would John Carmack do?
pturecki
Level 0
***



View Profile WWW
« Reply #5151 on: October 13, 2016, 01:20:06 AM »

Sometimes debugger helps finding a bug in seconds, sometimes not even in hours. I use printing/logging quite often (but definitely I use debugger more often than logging). And it depends on the bug type too.
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5152 on: October 15, 2016, 09:56:40 AM »

That inevitable point in time when writing a renderer where nothing displays on the screen but everything looks like it should be good. Happens at least once every time! BWAAAGASDSFSAF

edit : it was a viewport rectangle with a size of zero.

It's funny there seems to be a pattern that whenever I post publicly about a problem I almost immediately find the solution right after. It's also almost always something stupid like a zero viewport.  Shrug
Logged

standardcombo
Level 8
***


><)))°>


View Profile
« Reply #5153 on: October 18, 2016, 08:34:12 PM »

You got a rubber duck on your desk?
Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #5154 on: October 23, 2016, 09:11:16 AM »

seed = x*1000 + y

...

It has a clear pattern when trying to fill spatial hash index by x,y

Cry

Logged

Cheezmeister
Level 3
***



View Profile
« Reply #5155 on: October 30, 2016, 08:30:57 PM »

I just spent five bucks to get an experimental DigitalOcean droplet, then came here and saw that referral link. Bah!

And I do not, in fact, have a rubber duck on my desk, so I came here to gripe. Rabblerabblerabble.

If you're feeling charitable, don't be a sucker like me and get your referral credit here: http://www.digitalocean.com/?refcode=5a88e20f6dc9
« Last Edit: November 13, 2016, 02:41:27 PM by Cheezmeister » Logged

෴Me෴ @chzmstr | www.luchenlabs.com ቒMadeቓ RA | Nextris | Chromathud   ᙍMakingᙌCheezus II (Devlog)
Photon
Level 4
****


View Profile
« Reply #5156 on: November 08, 2016, 07:21:42 AM »

Pre-optimization.

Screamy

Sometimes its not merely the act of refraining that's hard... it's actually recognizing when you're doing it behind your own back.
Logged
shellbot
Guest
« Reply #5157 on: November 15, 2016, 03:12:29 PM »

Maybe it's just me because I've been away from OpenGL for a while, but modern OpenGL seems WAY more complicated that the past OpenGL...

I understand that it's "more efficient" or some shit like that, but I'm still completely lost Lips Sealed
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5158 on: November 15, 2016, 05:57:11 PM »

Maybe it's just me because I've been away from OpenGL for a while, but modern OpenGL seems WAY more complicated that the past OpenGL...

I understand that it's "more efficient" or some shit like that, but I'm still completely lost Lips Sealed

If you're referring to OGL 1.0 series where you go GLBegin, do stuff GLEnd I would have to agree. It definitely is way more complicated.
Logged

Garthy
Level 9
****


Quack, verily


View Profile WWW
« Reply #5159 on: November 15, 2016, 06:39:15 PM »

Modern OpenGL is far, far harder to pick up than earlier iterations. The fixed-function pipeline was much easier to pick up than being forced to jump right into shaders from the start (as you are required to do with modern OpenGL).

The payoff is worth it though. As soon as you need to do something more than moderately complex, shaders are far, far easier to work with.

I'm glad the days of playing roulette with supported FFP functionality are past us, although I think the barrier to entry for modern GL is too high now.
Logged
Pages: 1 ... 256 257 [258] 259 260 ... 295
Print
Jump to:  

Theme orange-lt created by panic