Want to learn to code? Don't copy and paste, type out other people's code (shockoe.com)

OK, I pulled colors as an example out of thin air but I'll see if I can make it work.

Let's say you have to write a routine that does something based on a color as the input. You have a few choices in terms of how to represent the colors:

    - The name of the color in a string
    - A typdef enum for your colors (integers)
    - A color-per-bit scheme (U8, U16, U32)
    - Channel-per-bit scheme (U8)
    - 4 or 6 bit packed RGB values (U16 or U32)
    - 8 bit packed RGB values (U32)
    - 8 bit unpacked RGB values (struct of three U8)
    - 16 or 32 bit unpacked RGB values (struct of three U16 or U32)
    - Unpacked RGB floats (struct of three floats)
    - and more...

I won't go into the implications of each of the above. Some of it is highly dependent on both the system and the objectives of the work being done.

Say, for example, that you choose to use the names of colors stored in strings as your color representation. Now you have to compare strings in order to identify the colors:

    if(strcmp(input_color, "red") == 0)
    {
      // Do something with red
    }
    else if (strcmp(input_color, "green") == 0)
    {
      // Do something with green
    }
    else if (strcmp(input_color, "blue") == 0)
    {
      // Do something with blue
    }
    ... etc

Regardless of language the strings need to be compared character by character. Even if a language or OO framework allows you to say something like if(string1 == string2) you have to keep in mind that what is going on behind the scenes is pretty much exactly what strcmp() has to do. Which means that the above is, at the very least, slow.

And, of course, it isn't very portable. What happens if the input has to be in German or Japanese?

The typdef enum representation gives you the ability to use a far more efficient construct to identify your colors:

    switch(color)
    {
      case COLOR_RED:
        // Do something with red
        break;
      case COLOR_GREEN:
        // Do something with green
        break;
      case COLOR_BLUE:
        // Do something with blue
        break;
    ... etc

This is much, much faster. It is, at the core, an if/else-if structure that is only comparing integers, which is a single machine language instruction. Fast and clean and language-portable by means of the proper text-to-integer function somewhere to deal with different languages.

If you are on an embedded system that can do bit testing in machine language it might make sense to encode one color per bit or one color channel per bit. for example, in some embedded C dialects you might be able to do something like this:

    if(color.0) // Select and test bit 0
    {
      // This is red
    }
    else if(color.1) // Select and test bit 1
    {
      // This is green
    }
    ... etc

At this level the advantages of doing this are tightly linked to the platform and the goals of the application.

If, for example, one needs to be able to expand the available range of color inputs beyond what can be described with simple words a discrete RGB representation might be the best choice. This is also the case if you wanted to future-proof the program and be ready for when more colors arrive.

Here you have several choices, two of which are to represent each channel with an 8 bit value or choose floats instead.

The 8 bit values can be packed nicely into a U32, making it very efficient. You could also create a struct to facilitate access to the components and let the compiler optimize for you.

The float example is interesting because the conversion from float to whatever (if necessary) can be of any bit width. So, for example, if the color needs to ultimately be mapped to an 8-bit-per-channel display device you can translate from float to 8 bits on output. All of your intermediate math and color manipulation would be done in full-resolution floats which means that you are not going to accumulate errors. This, for example, is important if you are applying ...

While I generally agree with what you are saying, it is very important to understand that built-in types are not magical. This is where coming from a low-level embedded C or assembly background can be very useful.

As an example, there are a number of sites showing the performance hit you take if you use some of the NS types in Objective-C. If I remember correctly, in some cases you are talking about NS types running 400 times slower than alternative code.

In my mind, the question of data representation could also include this very choice: Do I use an NSArray or do I do it "by hand", allocate memory and use a "simple" array?

Color.Bleu will give a compiler error. "Bleu" will not. And is "White" a valid color? No idea, need to check the docs. Try Color.White and the compiler or editor will tell you.

Yes, I work at CloudFlare.