Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've written a .NET bitwise operations library as part of my projects (stuff ranging from get MSB set to some more complicated bitwise transformations) and I mean to release it as free software. I'm a bit confused about a design aspect of the library, though.

Many of the methods/transformations in the library come with different endianness. A simple example is a getBitAt method that regards index 0 as the least significant bit, or the most significant bit, depending on the version used.

In practice, I've found that using separate functions for different endianness results in much more comprehensible and reusable code than assuming all operations are little-endian or something.

I'm really stumped regarding how best to package the library.

  • Should I have methods that have LE and BE versions take an enum parameter in their signature, e.g. Endianness.Little, Endianness.Big?
  • Should I have different static classes with identically named methods? such as MSB.GetBit and LSB.GetBit

On a much wider note, is there a standard I could use in cases like this? Some guide? Is my design issue trivial? I have a perfectionist bent, and I sometimes get stuck on tricky design issues like this...

Note: I've sort of realized I'm using endianness somewhat colloquially to refer to the order/place value of digital component parts (be they bits, bytes, or words) in a larger whole, in any setting. I'm not talking about machine-level endianness or serial transmission endianness. Just about place-value semantics in general. So there isn't a context of targeting different machines/transmission techniques or something.

share|improve this question

3 Answers 3

up vote 2 down vote accepted

As in most instances of the design problem, the solution should be based on intended usage and context, instead of any alleged absolute.

You need to establish your requirements. What do you use the library for? What is your target audience for this library?

If the intended usage is to mix little-endian logic together with big-endian logic, then it's beneficial to add an extra argument for each method, such as Endianness.Little, just like you suggested. I wouldn't suggest a clone for each method, as that would grow rather quickly, and with today's IDEs and auto-completion it would be a visual disturbance, and also would have a (probably negligible) impact on compile time.

However, if you intend to use the library for different platforms, but on each one pick one scheme, then you're probably better off with passing an Endianness strategy to the constructor of a class that has higher level methods.

If you want to get the best of both worlds, at the expense of simplicity, you can pass a strategy in a constructor, and accept an optional strategy in each method, which defaults to the one provided in the constructor.

share|improve this answer
1  
Good answer - passing the Endianness as an enum in the constructor would be my preferred design, but it really depends on the intended usage. The ability to then override it in each method call is a good idea. –  Gavin Coates Oct 22 '12 at 8:58
    
I would add one more option: 2 diferent libraries compiled for big and little endian. You could use DEFINE macro. And it makes sense, because you usually don't need to work with different endianness in single application. –  Euphoric Oct 22 '12 at 9:00
    
There is a scneario in which it is a good idea: learning software. :) –  Yam Marcovic Oct 22 '12 at 9:04
    
Actually in my project I've had to work with different endianness. Some components had MSB-based semantics, while others LSB. That's why I've written code serving both versions. It's not that I was targeting different machines. It's just that different components were better implemented using different endianness. –  Greg Ros Oct 22 '12 at 9:04

I agree Yam that it depends on your usage of the library. Another interesting arrangement, if you're not going for insane levels of performance could be to create a class that holds both answers. GetBit will then return an instance of this class, with two properties presenting the results.

public class BitWiseResult 
{
  public <type-goes-here> MSB { get; set; } 
  public <type-goes-here> LSB { get; set; } 
}

public BitWiseResult GetBit() ...

This arrangement will be best used if you need to use both results interchangeably. It has the advantage of giving you the right result in the exact place where you need it, as opposed to changing a possibly distant function call or class instantiation.

share|improve this answer
    
An interesting option as well. Uses twice more space, though. Relevant in cases where you always need to get and use both. –  Yam Marcovic Oct 22 '12 at 11:13

If your library users will stick with one Endianness in their application I would use an abstract factory.

// setup
var factory = new LittleEndiannessFactory();

// usage
var algo = factory.CreateSomeAlgo();

Else you'll probably want them to specify the endianness in each method call.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.