Re: XTL patches

[Asger Alstrup Nielsen <alstrup@sophusmedical.dk>]

> I agree that the smart config.h is the best option. In fact, there used
> to be a config.h in include/xtl, but after I started using byteswap
> macros from glibc I removed it as it was no longer being needed.

One of the things that caused problems on the Win32 platform was the
byteswapping part. The needed header file does not exist on Win32.
Since my use was restricted to one platform, I simply commented the
stuff out.
Maybe you should include the byteswap.h file in the distribution?

> There has not been much feedback, but I'll continue to publicize it
> on Freshmeat as I improve it. 

You could try to get wider exposure by asking for help on
comp.os.linux.announce, Linux Weekly News, and other of the existing
channels.

> I currently have some minor patches
> pending, and after integrating your previous contribution I'll release
> a new version soon.

That sounds good.

> I will be glad to apply patches in order to improve portability.
> However, I'd prefer that in doing so XTL gets closer to the ISO
> spec and not further away. As such, accomodating old compilers
> should be done by opting out some features and not by crippling
> the design for people using modern compilers. I believe this is
> what people at SGI have done with the STL.

That is a reasonable position.

> I also don't know what is the status of other compilers, as I
> use only Linux. Could you send the "ugly patches" for Win32 you
> mentioned in your previous message, so I can get an idea of
> what features are causing problems?

Primarily, the template support in Visual C++ 6.0 is not sufficient. It
could not resolve overloads like

	inline obj_input& simple(string& data) {
		...
	}


	template <class T>
	inline obj_input& simple(T& data) {
		...
	}

So, I had to rename the second one, and because of that, I had to
rewrite and hand-specialize the 

	template <class T>
	inline obj_input& container(T& data) {
		...
	}

family for my concrete needs.

Obviously, this is too dirty for inclusion in the main distribution, but
it might be a good idea to #ifdef the parts that do not work so that you
can at least use the minimal interface. Also, it might be advantageous
to expose a bit more of the interface in this situation so that it is
possible to implement the hand-specialized "container" methods in your
own code.

The second thing was the lack of byteswap, which I feel should be solved
simply by including the byteswap.h header file. 
The third issue was the small errors that I corrected in the two
patches.

Also, the compiler had trouble with stuff like

 	raw_format(Buffer& buf):generic_format<Buffer>(buf) {}

which I had to rewrite to

 	raw_format(Buffer const & buf)
		:generic_format<Buffer>(const_cast<Buffer &>(buf)) {}

which obviously is a complete and utterly mess, but never the less
needed. This is controversial, but I would be ready to #ifdef this part
since it's crucial for the correct functionality.

Finally, the "long long" type does not exist, so I had to comment those
out quite a few places. It would be better to #ifdef those.

All in all, I had to patch XTL pretty heavily to get it to work (I might
have forgotten a few parts), and not all of it was as elegant as it
could be. However, except for the container part, it was possible to
keep the external interface 95% intact despite a brain-dead compiler,
and that is IMO the primary thing.
FYI, the patched version also works with Intels C++ compiler.

If I had the time, I would volunteer to provide a series of patches
which addresses each of these issues, and then you could chose the ones
that were acceptable, but I'm afraid that I don't the time for that at
this point.

Nevertheless, I have a few other suggestions:

1) Consider writing a small round-up of what each header file does in
the README, or elsewhere.

It took me some time to figure out that I only had to use the objio.h
file for the basic functionality.

2) Consider renaming objio.h to xtl.h, or alternatively, provide an
xtl.h file which would be all you need to include to use the library.

This is obviously up for debate, but personally, I like to just include
one header file and have all the functionality available, even if it
slows down compilation a bit.

3) Consider implementing the file_buffer.
This was the only thing I really missed, and I implemented a stupid
wrapper using the mem_buffer. It would be nice to have one which does
not require all of the data to be in memory.

Also, you might want to make it more clear that the raw_format is
perfectly functional, and serves as a great minimum medium if
interoperatibility is not an issue.

Finally, wish-full thinking, you could consider providing an XML format
interface.

Greets,

Asger Alstrup