If  you have written any programs based on PTLib/OpenH323/H323plus/OPAL, please read this, IT’S IMPORTANT!!

Adam Butcher from Selex Communications submitted patches a while ago to change BOOL to PBoolean. The reason was so that PBoolean could be defined as the ANSI standard bool type and we get a whole pile of beneficial compile time checks. The process found a couple of places where a function had a BOOL return type but integer (tri-state) values were being returned!

Well, Craig and I had thought of this for a while as being a “good thing” to do, but lack of time has always been an issue. Now, as we have been presented with all the hack work, it seems that this is it’s time.

Of course things are NEVER easy. The change has a nasty API issue that can silently stop user programs from working. It revolves around my #1 pet hate in C++, if you change the signature of a virtual function, overrides silently no longer override the virtual. For example:

   //------ in the library

   class OpalXXX

   {

        virtual void SomeFunction( PBoolean );

   };

   //------- in some unchanged dependent code in another application

   class MyXXX : public OpalXXX

   {

         virtual void SomeFunction( BOOL );

   };

The function MyXXX::SomeFunction() will not be called as it should be. And the stupid compiler (NONE of the compilers) give any warnings or indication there is an issue. Way back in the preliminary versions of C++ they did have a keyword “override” which would do exactly what we want, error if the base class does not have the function being overridden as virtual. The original designers (Stroustrup et al) took out, for presumably good reasons, though I cannot for the life of me think what! There is even a number proposals, e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2108.html, to put a variants of it back and Microsoft have even done so, http://msdn2.microsoft.com/en-us/library/41w3sh1c.aspx, on their latest compiler.

Anyway we have to deal with existing compilers and this problem is really insidious, but we think the gains are worth the pain. And we have provided a work around for people.

So, what we need from you guys is please check out the PTLib and OPAL in the branches:

https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/BooleanChange

https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/branches/BooleanChange

and compile your programs against it. Now by default it will use the ANSI bool form of PBoolean, so any overrides of PTLib or OPAL functions must be changed to use PBoolean instead of BOOL. For those not using MFC, this is really easy, just do a complete search and replace everywhere of BOOL to PBoolean (or better yet, just bool) and that should do the job. Oh, you might like to search and replace TRUE to true and FALSE to false while you are at it, though you don’t HAVE to do that.

Now, for those that simply do not wish to make these changes, we have a backward compatibility option: use the

  --disable-ansi-bool

option with configure (both Unix and Win32) and PBoolean is defined as BOOL instead of bool. This should (in theory) be 100% compatible with the previous signatures. So no changes to applications based on PTLib need be made.

But we need you guys to CHECK THAT THIS IS OK!

We are currently proposing to merge it into the trunk on Monday 26^th of November, we are happy to extend that if asked, but will not wait forever, the back merging is really painful!

P.S. A random note to developers, the PBoolean is only there for backward compatibility. It is recommended that any NEW functions all just use the bool keyword. Use lowercase true and false too.

P.P.S. Sorry about all the shouting ... J

Robert Jongbloed

OPAL/OpenH323 Architect and Co-founder.