On Fri, 2008-06-27 at 14:05 +0200, Manuel Teira wrote:
> ...
> class AsynchConnector :
> //Bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6710638
> //Should be private inheritance
> #ifdef __SUNPRO_CC
>     public
> #else
>     private
> #endif
>     DispatchHandle {
> public:
> ...
> 

I must say I find this terribly ugly, but I suppose it does point out
the cause of the change.

> I have another bunch of changes, most related with inclusion 
> differences. Perhaps they could be added without wrapping them in a 
> #ifdef clause, but I'm not sure. My plan is to open a new JIRA for those 
> changes, and expose them to your consideration. What do you think? (I'm 
> talking about this kind of modifications) :
> 
> -bash-3.00$ svn diff ../../src/qpid/sys/posix/AsynchIO.cpp
> Index: ../../src/qpid/sys/posix/AsynchIO.cpp
> ===================================================================
> --- ../../src/qpid/sys/posix/AsynchIO.cpp       (revision 671815)
> +++ ../../src/qpid/sys/posix/AsynchIO.cpp       (working copy)
> @@ -19,6 +19,10 @@
>   *
>   */
>  
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>  #include "qpid/sys/AsynchIO.h"
>  #include "qpid/sys/Time.h"
>  
> @@ -31,6 +35,11 @@
>  #include <signal.h>
>  #include <errno.h>
>  
> +#ifdef SUNOS
> +//strerror, memmove prototypes
> +#include <string.h>
> +#endif
> +
>  #include <boost/bind.hpp>

I really think this kind of change is unnecessary and misguided. There
is actually no platform portability issue here. Simply, the includes are
incorrect.

It is easy to do if you (as I often do myself) just add #include lines
in response to compile errors. However the correct thing to do (not
often done) is to add include lines when the standard says they are
necessary and not rely on some random include file you included to get
definitions for you.

So take out the #include "config.h" stuff and just include "string.h"
directly. At very worst it can't cause problems on Linux.

There are very few cases now where you need to do conditional includes
along these lines.

Andrew


Reply via email to