RE: [NeoStats-Devel] Status

Justin Hammond wrote:
> > > Mark, One thing I was wondering about (I installed Visual Studio 
> > > finally) is that if you can put together a "programing guideline" 
> > > for NeoStats? Not just covering things like module API, 
> but also the 
> > > abstraction interface you put in. (eg, ns_malloc, versus 
> os_malloc, 
> > > versus malloc?!?! That still confuses
> > > me)
> > 
> > Yes I can do this. 
> > 
> > As a quick note for our purposes, malloc/free should never 
> be used in 
> > our code. We should always use ns_malloc/free. The reasons for 
> > os_malloc/free are mainly for libaries (pcre etc) that allow us to 
> > reassign the malloc/free calls to avoid problems on Win32 
> linking the 
> > CRT in multiple locations and to allow us to provide OS specific 
> > optimised versions without affecting the code base.
> > 
> > os_xxxx calls are provided for most library functions 
> mainly to solve 
> > the
> > Win32 CRT link issues so any library call should be os_ rather than 
> > the standard function. The other reason for os_xxxx calls 
> is largely 
> > down to the fact that *nix treats files and sockets as 
> streams using 
> > the same functions.
> > Win32 does not so close(socket) fails on Win32. 
> os_sock_close(socket) 
> > chooses the correct function on Win32. In addition, the 
> os_xxxx calls 
> > provide automatic logging and debug information.
> > 
> 
> Could we update the headers, so that the os_calls are not 
> defined in the standard module or core files (ie, only put 
> those os_defines into a separate header, and only include 
> that header where we specifically need that abstraction?

I am not sure I follow you. 

You pretty much specifically need the abstraction if you call any C library
function. The alternative to the os layer is every module writing code for
*nix and code for Win32 and handling the problems of a multiply linked CRT.
The majority of standard library calls should be made through the os
abstraction layer since for example, fopen will not work in a Win32 module
so all file routines go through the os abstraction layer so the core can
handle the file opening. Any socket access has to go through the os_sock
layer due to differences between Win32 and *nix. Any memory allocation and
freeing must go through the provided abstraction layer since the core cannot
free memory allocated by a DLL and vice versa but there are times when this
is necessary and is made possible by the core handling all memory
allocations. 

Much of the core and all modules use the abstraction layer so I do not see a
benefit in making all files include another file. In 3.0 modules just
include "neostats.h" and that is everything they need from NeoStats
including abstraction layers and APIs. 

Mark.