Jump to content

  • Log In with Google      Sign In   
  • Create Account


iMalc

Member Since 05 Mar 2004
Offline Last Active Sep 11 2014 09:02 PM

Posts I've Made

In Topic: GOTO, why are you adverse to using it

06 September 2014 - 08:36 PM

 

Then of course there's the fact that when it comes to being in the workforce, you'll be a lot more likely to get a job and keep it if you don't use them.


That's just silly. If you use a goto in a place where it makes the code clear (granted, these situations are exceedingly rare), nobody will have a problem with it.

 

 

Then of course there's the fact that when it comes to being in the workforce, you'll be a lot more likely to get a job and keep it if you don't use them.


That's just silly. If you use a goto in a place where it makes the code clear (granted, these situations are exceedingly rare), nobody will have a problem with it.

I'm not trying to enter into whether it should be the case, but that's simply how it seems to be.
People who use gotos either in interviews, or in the workplace to any noticeable degree, are foolish.


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 02:58 PM

Why would I ever want to use a goto? I simply have no use for them. So unnecessary are they to me, that I am only ever reminded of their existence until someone on a forum brings it up. I'm not sure much adverse to it, it's just that I have so many other tools that do a much better job that it's totally redundant.

 

Then of course there's the fact that when it comes to being in the workforce, you'll be a lot more likely to get a job and keep it if you don't use them.

 

The exceptions are "gotos on steroids" argument is a weak one. It can be suggested that absolutely anything that changes program flow is a "goto on steroids". Exceptions differ hugely in that the thrower of the exception has no knowledge of where execution will resume from, unlike gotos that have a specific fixed target. Like it or not, they are the way languages tend to work now, and you'd be hard pressed to avoid them (or write sucky code if you do) in a language like C#.


In Topic: Colour Cycling - An Old School Technique

29 August 2014 - 03:39 PM

Ah that brings back fond memories of SimCity 2000.


In Topic: Interrupt handling very slow

06 August 2014 - 03:51 AM

Generally when the problem appears to be that the Windows message queue mechanism is too slow, that is usually not the case at all.

It can only deliver you the next message when you request it, and you normally only request it when you are finished dealing with the current message. So basically your own slow message processing slows down the receipt of further messages.

 

One mistake I've come across when processing Windows messages is when you only allow at most one Windows message to be processed each time around your main loop, seemingly giving maximum time to the rest of your drawing code. In reality what happens is that this slows the program down horribly. You should endeavour to process ideally all messages before doing any other stuff in your main loop. Although this may be counter-intuitive, it actually makes a world of difference. Give Windows more attention and promptly process its messages, and your program's performance will be greatly rewarded.

 

Those are not interrupts and no you do not need a mutex there. In fact the term "interrupts" doesn't have much applicability at all in a Windows program. The terms that you need to be familiar with are synchronous / asynchronous, blocking / non-blocking, or single-threaded / multi-threaded.

You can confirm this for yourself by placing a breakpoint within the HandleInterrupt function, and when the breakpoint is hit, examine the Call Stack window. When you can look back through the call stack of the same thread and find the original GetMessage or PeekMessage call, then what your application is doing is entirely synchronous, or blocking.


In Topic: (Super) Smart Pointer

12 July 2014 - 03:25 PM

The other way to do it is to have the object know at all times what lists it is stored in, and upon being deleted from the master list, fully removes itself from the other lists. This technique requires a lot of care in that you don't want to be iterating over a list containing the item, somewhere higher up the call stack, for example.

I would consider using the shared + weak pointer method first.


PARTNERS