¿Hasta dónde llegar con un lenguaje fuertemente escrito?

Sí, la idea vale la pena, pero (IMO) escribir una clase completa y separada para cada rango de enteros no tiene sentido. Me he encontrado con suficientes situaciones que requieren enteros de rango limitado que he escrito una plantilla para el propósito:

template <class T, T lower, T upper>
class bounded { 
    T val;
    void assure_range(T v) {
        if ( v < lower || upper <= v)
            throw std::range_error("Value out of range");
    }
public:
    bounded &operator=(T v) { 
        assure_range(v);
        val = v;
        return *this;
    }

    bounded(T const &v=T()) {
        assure_range(v);
        val = v;
    }

    operator T() { return val; }
};

Usarlo sería algo como:

bounded<unsigned, 0, 16> channel;

Por supuesto, puede ser más elaborado que esto, pero este simple todavía maneja alrededor del 90% de las situaciones bastante bien.

No, no es exagerado - siempre debe tratar de representar abstracciones como clases. Hay un millón de razones para hacer esto y la sobrecarga es mínima. Sin embargo, yo llamaría al Canal de la clase, no a CChannel.

No puedo creer que nadie haya mencionado enum's hasta ahora. No le dará una protección a prueba de balas, pero aún mejor que un tipo de datos entero simple.

Parece exagerado, especialmente el accessor operator unsigned char(). No estás encapsulando datos, estás haciendo las cosas evidentes más complicadas y, probablemente, más propensas a errores.

Los tipos de datos como su Channel suelen ser parte de algo más abstracto.

Entonces, si usas ese tipo en tu clase ChannelSwitcher, podrías usar el tipo comentado justo en el cuerpo ChannelSwitcher (y, probablemente, tu tipo será public).

// Currently used channel type
typedef unsigned char Channel;

Si lanza una excepción al construir su objeto "CChannel" o en la entrada del método que requiere la restricción hace poca diferencia. En cualquier caso, está haciendo aserciones de tiempo de ejecución, lo que significa que el sistema de tipos realmente no le está haciendo ningún bien, ¿verdad?

Si quieres saber hasta dónde puedes llegar con un lenguaje fuertemente escrito, la respuesta es "muy lejos, pero no con C++."El tipo de poder que se necesita para imponer estáticamente una restricción como," este el método solo se puede invocar con un número entre 0 y 15 " requiere algo llamado tipos dependientes--es decir, tipos que dependen de valores.

Para poner el concepto en una sintaxis pseudo-C++ (pretendiendo que C++ tenía tipos dependientes), puede escribir esto:

void Func(unsigned char channel, IsBetween<0, channel, 15> proof) {
    ...
}

Tenga en cuenta que IsBetweenestá parametrizado por valoresen lugar de tipos. Para llamar a esta función en su programa ahora, debe proporcionar al compilador el segundo argumento, proof, que debe tener el tipo IsBetween<0, channel, 15>. Es decir, tienes que demostrar en tiempo de compilación que channel está entre 0 y 15! Esta idea de tipos que representan proposiciones, cuyos valores son pruebas de esas proposiciones, se llama la Correspondencia Curry-Howard .

Por supuesto, probar tales cosas puede ser difícil. Dependiendo del dominio del problema, la relación costo/beneficio puede inclinarse fácilmente a favor de simplemente abofetear las comprobaciones de tiempo de ejecución en su código.

Si algo es excesivo o no a menudo depende de muchos factores diferentes. Lo que puede ser exagerado en una situación puede no serlo en otra.

Este caso podría no ser excesivo si tuviera un montón de funciones diferentes que todos los canales aceptados y todos tenían que hacer la misma comprobación de rango. La clase Channel evitaría la duplicación de código, y también mejoraría la legibilidad de las funciones (al igual que nombrar la clase Channel en lugar de CChannel - Neil B. tiene razón).

A veces cuando el rango es lo suficientemente pequeño, en su lugar definiré una enumeración para la entrada.

Si agrega constantes para los 16 canales diferentes, y también un método estático que obtiene el canal para un valor dado (o arroja una excepción si está fuera de rango), esto puede funcionar sin ninguna sobrecarga adicional de creación de objetos por llamada al método.

Sin saber cómo se va a usar este código, es difícil decir si es excesivo o no o agradable de usar. Pruébelo usted mismo-escriba algunos casos de prueba utilizando ambos enfoques de una clase char y una clase typesafe - y vea cuál como. Si te cansas de él después de escribir algunos casos de prueba, entonces probablemente sea mejor evitarlo, pero si te parece que te gusta el enfoque, entonces podría ser un guardián.

Si esta es una API que va a ser utilizada por muchos, entonces tal vez abrirla a alguna revisión podría darle comentarios valiosos, ya que presumiblemente conocen el dominio de la API bastante bien.

En mi opinión, no creo que lo que está proponiendo sea una gran sobrecarga, pero para mí, prefiero guardar la escritura y simplemente poner en la documentación que cualquier cosa fuera de 0..15 es undefined y usa una assert () en la función para detectar errores en compilaciones de depuración. No creo que la complejidad añadida ofrezca mucha más protección para los programadores que ya están acostumbrados a la programación en lenguaje C++, que contiene una gran cantidad de comportamientos indefinidos en sus especificaciones.

Tienes que hacer una elección. No hay una bala de plata aquí.

Rendimiento

Desde la perspectiva del rendimiento, la sobrecarga no va a ser mucho, si es que lo es. (a menos que tengas que contar los ciclos de cpu), por lo que lo más probable es que este no sea el factor determinante.

Simplicidad / facilidad de uso, etc

Haga que la API sea simple y fácil de entender/aprender. Debe saber / decidir si numbers / enums / class sería más fácil para el usuario de la api

Capacidad de mantenimiento

1. Si estás muy seguro del canal tipo va a ser un entero en en el futuro previsible, me iría sin la abstracción (considerar usando enumeraciones)

2. Si tiene muchos casos de uso para un valores acotados, considere el uso de la plantillas (Jerry)

3. Si piensas, el Canal puede potencialmente tienen métodos que sea un clase ahora mismo.

Esfuerzo de codificación Una vez cosa. Así que siempre piensa en el mantenimiento.

El ejemplo del canal es difícil:

• Al principio parece un tipo entero de rango limitado simple, como se encuentra en Pascal y Ada. C++ no te da forma de decir esto, pero una enumeración es suficiente.

• Si miras más de cerca, ¿podría ser una de esas decisiones de diseño que probablemente cambiarán? ¿Podrías empezar a referirte a "canal" por frecuencia? Por cartas de llamada (WGBH, adelante)? Por la red?

Mucho depende de su plan. ¿Cuál es el objetivo principal de la API? ¿Cuál es el modelo de costos? ¿Se crearán canales con mucha frecuencia(sospecho que no)?

Para obtener una perspectiva ligeramente diferente, veamos el costo de meter la pata:

• Expones el rep como int. Los clientes escriben mucho código, la interfaz se respeta o su biblioteca se detiene con un error de aserción. Crear canales es muy barato. Pero si necesitas cambiar la forma en que estás haciendo las cosas, pierdes " hacia atrás bug-compatibility " y molestar a los autores de clientes descuidados.

• Mantenlo abstracto. Todo el mundo tiene que usar la abstracción (no tan mal), y todo el mundo está a prueba de futuros cambios en la API. Mantener la compatibilidad con versiones anteriores es pan comido. Pero crear canales es más costoso, y lo que es peor, la API tiene que indicar cuidadosamente cuándo es seguro destruir un canal y quién es responsable de la decisión y la destrucción. El peor escenario es que crear / destruir los canales conducen a una gran fuga de memoria u otro fallo de rendimiento, en cuyo caso se vuelve a la enumeración.

Soy un programador descuidado, y si fuera por mi propio trabajo, iría con la enumeración y me comería el costo si la decisión de diseño cambia en el futuro. Pero si esta API fuera a salir a muchos otros programadores como clientes, usaría la abstracción.

Evidentemente soy un relativista moral.

Un entero con valores solo entre 0 y 15 es un entero de 4 bits sin signo (o medio byte, nibble. Me imagino que si esta lógica de conmutación de canal se implementaría en hardware, entonces el número de canal podría representarse como eso, un registro de 4 bits). Si C++ tuviera eso como tipo, se haría aquí mismo:

void Func(unsigned nibble channel)
{
    // do something
}

Por desgracia, no lo hace. Podría relajar la especificación de la API para expresar que el número de canal se da como un carácter sin signo, con el canal real siendo calculada usando una operación de módulo 16:

void Func(unsigned char channel)
{
    channel &= 0x0f; // truncate
    // do something
}

O bien, utilice un campo de bits:

#include <iostream>
struct Channel {
    // 4-bit unsigned field
    unsigned int n : 4;
};
void Func(Channel channel)
{
    // do something with channel.n
}
int main()
{
    Channel channel = {9};
    std::cout << "channel is" << channel.n << '\n';
    Func (channel); 
}

Este último podría ser menos eficiente.

Voto por su primer enfoque, porque es más simple y más fácil de entender, mantener y extender, y porque es más probable que se mapee directamente a otros idiomas si su API tiene que ser reimplementada/traducida/portada/etc.

Esto es abstracción mi amigo! Siempre es mejor trabajar con objetos