How to write a blocking function in MSVC++

Mutex locks can be used to create blocking functions, a lot like the socket api’s recv() function.

Using Mutex objects
CreateMutex
WaitForSingleObject
ReleaseMutex

#include <stdio.h>
#include <conio.h>
#include <Windows.h>

// Super-short example that shows how to
// create a blocking function with mutex
// locks in MSVC++.

#define IsDown(x) (GetAsyncKeyState(x) & 0x8000)
HANDLE lock ;

DWORD WINAPI block( LPVOID data )
{
  puts( "Thread 2:  I have started.  I will check the lock.." ) ;
  WaitForSingleObject( lock, INFINITE ) ; // THE THREAD WILL BLOCK HERE
  // forever until the "lock" object is Released() by
  // the main thread
  puts( "Thread 2:  I AM FREE TO GO!!" ) ;

  return 0 ;
}

int main()
{
  // Get a lock on the lock variable
  lock = CreateMutexA(
    0,
    TRUE,  // When the mutex lock is created, start with it already "taken"
    "Main lock" // name for the lock
  ) ;

  puts( "Thread 1:  Starting new thread.." ) ;
  CreateThread( 0, 0, &block, 0, 0, 0 ) ;
  puts( "Thread 1:  Entering main loop.  Press the SPACEBAR to release the lock "
    "(to UNBLOCK) thread 2" ) ;
  while( 1 )
  {
    if( IsDown( VK_SPACE ) )
    {
      ReleaseMutex( lock ) ; // RELEASE OUR HANDLE ON THE
      // MUTEX LOCK, meaning the 'block()' function will
      // be free to continue execution
    }

    if( IsDown( VK_ESCAPE ) )
    {
      break ; // end the program
    }
  }

}

Apache 2.2 / php [crit] (OS 1813)The specified resource type cannot be found in the image file. : master_main: create child process failed. Exiting.

Trying to install Apache 2.2 and PHP on a Windows 7 x64 system, I got this error:

[crit] (OS 1813)The specified resource type cannot be found in the image file. : master_main: create child process failed. Exiting.

What you have to do is open PHP.ini and go to the bottom of the file and start commenting out extensions.

Basically some of the extensions don’t work, so you have to keep commenting them out until you find the culprit.

Best to keep it to the bare minimum extensions you know you will use..

Reading and understanding function pointer syntax

Function pointer syntax tutorial

Function pointer syntax is one of those weird, weird things that just doesn’t seem right.

double (*fun)(int,int,double*)

Can you read that?

In less than 2 paragraphs, you will!

First things first. What is a function pointer anyway? Why, its simply a variable that, instead of pointing to an object (like an int* will point to an integer, and a double* will point to a double), this weird, weird “function pointer” will actually point to __A FUNCTION__!!

WHAT?? You say. POINT TO A FUNCTION! Why, yes! It is no different than me pointing to a recipe. Its one thing to have a copy of the recipe for chocolate mousse in hand (an actual function body), and its another thing to have a hyperlink that merely __points__ to that chocolate mousse recipe (a pointer to the function). When you have a pointer to a function (hyperlink to a recipe) you can still execute it (make the recipe) but you need to remember to dereference the pointer first (follow the hyperlink to pull up the recipe).

Does that make a little bit of sense? Me hopes so.

Moving on to function pointer syntax then, it is actually not that bad to read. Say you had a function:

void SayIt()
{
  puts( "It. There.  Happy now?" ) ;
}

And you wanted to declare a function pointer to the SayIt() function in your main function:

int main()
{
  // DECLARE A FUNCTION POINTER TO THE
  // SayIt() function by the name of ptrSayIt
  void (*ptrSayIt)() ;
  // The above is probably the weirdest, non-C++ish
  // syntax you've come across.  It looks weird because
  // it is.  No, really, function pointer declaration
  // syntax is kind of mixed up.
  // 1.  First, the word VOID specifies the
  // return type of the function that you
  // will point to...
  // 2.  Second is (*ptrSayIt).  The bracket
  // and star combination (* there
  // says THIS IS A FUNCTION POINTER, NOT
  // A FUNCTION DECLARATION THAT RETURNS A POINTER
  // TO VOID* (which is what "void *ptrSayIt();" would mean!)
  // 3.  Third, the trailing brackets at the end ()
  // say that the function we are pointing to
  // won't accept any arguments when it is called.

  // If it helps, you can look at it as:
  // void(*)().  That is the type of the
  // ptrSayIt variable.  The "mixed up" part
  // is because this breaks the usual C declaration
  // syntax of TYPE    InstanceName,
  // and so its really weird to look at at first.
  // Then you kind of get used to it.  Keep reading!

  // Now the ptrSayIt variable points to the
  // SayIt function..
  ptrSayIt = &SayIt ; // you don't really need the & in front
  // but I put it to be clear

  // Now we can call the SayIt function __through__
  // the ptrSayIt pointer we just declared and set up!
  (*ptrSayIt)() ; // (*DEREFERENCE) the pointer first!
  // OUTPUTS:  "It.  There.  Happy now?"
  // TRY IT YOURSELF!
}

So this all seems very weird. But the program above works, I guarantee!

Lets do some more examples.

Declare a function pointer named Foo that points to a function marked by prototype:

int add( int a, int b ) ;

Answer:

int (*Foo)(int,int) ;

Reasoning: the return type of the function you are about to point to goes first.

int        // function pointer will point
// to a function returning int..

Then, you do this mixed up thing where you write the name of the pointer variable NOW, in brackets, with a * in front:

int (*Foo) // function pointer VARIABLE
// identifier/handle is Foo.  This is actually
// the WEIRDEST part of the syntax.

Then you follow up with the types of arguments that the function you are trying to point to will contain:

int (*Foo)( int, int )   // will point 
// to a function accepting 2 ints

Further reading

So what’s the use of function pointers? Why, many, many uses!

Now you can write functions that accept pointers to functions.. and so you can have a function have variable behavior based on what function you passed it…-

But you probably already think function pointers are cool. That’s why you stopped in to read about them!

Why not just override operator== to be a .Near() method?

In creating a Vector or Matrix4x4 class, it is tempting to think its a good idea to overload the == operator __not__ with an element by element comparison for exact equality (as it __should__ be!) but instead to equate it to some version of a .Near() method (where we check that each element is within some EPSILON of the corresponding element in the other matrix)

It turns out this is __not__ a very good idea for the following reason

Say you want to make a std::map<Matrix> for some reason. Now finding is based on operator== and operator<.

So you have a huge problem if you overloaded operator== to mean “approximately equal”!

More expensive key lookup, (lots of fabs()), and worse, more collisions where you may not want them!