XTL 1.3.pl.2

[Jose Orlando Pereira <jop@di.uminho.pt>]

Hi,

This is a development version. Changes are:
 - several fixes by Allan Rae;
 - some preliminary support for Windows.

Disclaimer: I don't have Windows installed, so consider these
changes as experimental. With them I try to address the sugestions
of Asger Nielsen. If any of you are using XTL in Windows, please
let me know what you think.

The changes are (when in Win32, see config.h):
 - long long/unsigned long long are replaced by INT64/UINT64;
 - composites are not externalized with simple(), due
   to template specialization dificulties, as such a
   new method composite() is added to streams.
 - a macro named content() is used to redirect implicit calls to
   simple() to composite().

Two new methods are temporarily added: vector_s() and array_s(),
which internally call simple(). If anybody thinks it
is worth it to add pointer_s() etc, let me know.
The rationale is that pointers and references to atomic types are
not used that often and thus not supported with buggy compilers.
Vectors and arrays of atomic types are common, so I added the
necessary support.

Hopefully, one sunny day when compilers don't have bugs, we'll
remove content(), *_s(), etc, maybe leaving only some compatibility
defines behind.

Of course that this is an ugly kludge. I considered to add an extra
template parameter to these methods in order to pass a type tag
deciding whether simple() or composite() was used. With a good compiler,
I could give it a default value and make it invisible to the programmer.
Without, the programmer would have to do the selection. 

However, this would add yet another level of template instantiation
even on compilers that are not faulty. Template instantiation depth
is a concern in real apps. This is also why in the current version,
content() is a macro and not a function.

In addtion, I hope user code written for buggy compilers compiles
unmodified on good compilers.

The remaining major show stopper is the lack of byteorder.h. 
I have some doubts on the legality of ripping it from glibc for inclusion
in XTL, as I have a vague ideia that glibc is LGPL *only* when 
compiled with gcc. Otherwise, it is GPL.

Anyway, if htonX()/ntohX() are available, it should be possible to
use them when byteorder.h is not available.

Regards,

-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *

xtl-1.3.pl.2.diff.gz