[Mono-dev] Mono's BitConverter.

[Miguel de Icaza]

Hello Jonathan,

    Thanks for the feedback, currently I have implemented:

	* [Type]From[Endian] (byte [] data, int index) static
	  methods of DataConverter class.

	* A DataConverter class that also provides abstract
	  methods for Get[Type] and GetBytes ([Type]) and
	  a couple of properties:

		DataConverter LittleEndian  { get; }
		DataConverter BigEndian     { get; }
		DataConverter Host	    { get; }

	  The idea here is that there are certain streams
	  that will all be encoded in a particular endian mode
	  and depending on the host we can provide a fast Copy or
	  Swap operations.

	* A Pack method, looks like this:

		byte [] Pack (string description, params object [] args)

	  See the attached source code for the actual format of the 
	  description string, but it allows code like this:

		Pack ("^idf$8x", intval, doubleval, floatval, string);

	  The above would produce a big-endian encoded, int, double,
	  float, followed by a UTF8 encoded string and a null char.

I have not implemented the stream methods yet nor the GetAsBytes
methods.

> I would suggest that IList be the return type instead of ArrayList, as
> this would allow changing the actual collection if necessary (to e.g.
> List<object> or an object[], etc. -- in fact, it should be possible to
> return a object[] if each template parameter is a single character, as
> the number of objects to return will always be template.Length, so the
> overhead of a re-sizable array wouldn't be needed).

I agree with this suggestion, but I have not implemented it yet (Unpack)

Am wondering if we should just return an array of objects, as that would
have all the interesting interfaces implemented already (IList,
IEnumerable) and they are part of the public contract.

> It might be useful to have an `IEnumerable' overload to Pack() as well,
> so that if the arguments are already in a collection class they can be
> reused as-is:
> 
> 	byte[] Pack (string template, IEnumerable arguments);

This is a very good idea.   But I do not want to loose the params
version of it.

> Finally, we need to specify the [Endian] for Pack, so it should be
> PackLittleEndian() and PackBigEndian().

I dealt with this differently, the specification string will start in
host packing mode, and will continue packing data in that mode until
told otherwise.   

To control the packing mode, you use one of these values:

	^ switch to big endian packing
	_ switch to little endian packing
	% switch to native packing.

> ByteConverter could be trimmed down by removing some of its methods --
> it might be practical to remove the non-Stream overloads, as you can
> always construct a System.IO.MemoryStream and get a byte[] from that
> after converting *all* of your data -- but this might not be ideal
> either.  I don't think the Stream overloads should be removed, as
> they're an ideal way to keep GC pressure lower (fewer byte[] should need
> to be created).  Alternatively, perhaps we don't need the unsigned
> flavors, which would require only 56 methods.

I agree, we need to have the Stream methods.  

We already have been bitten by the completely unsuitable BitConverter,
so I rather do the right thing here and provide correct implementations
of things that developers typically need.

One last thing: this code currently has no tests, and I have not tested
it beyond compiling the code.

Miguel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitconverter.cs
Type: text/x-csharp
Size: 23967 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070324/0dc80dba/attachment.bin