Otras instrucciones
Las instrucciones vistas hasta ahora son comunes a muchos lenguajes de programación. Sin embargo, en C# también se ha incluido un buen número de nuevas instrucciones propias de este lenguaje. Estas instrucciones se describen en los siguientes apartados:
Instrucciones checked y unchecked
Las instrucciones checked y unchecked permiten controlar la forma en que tratarán los desbordamientos que ocurran durante la realización de operaciones aritméticas con tipos básico enteros. Funcionan de forma similar a los operadores checked y unchecked ya vistos en el Tema 4: Aspectos léxicos, aunque a diferencia de éstos son aplicables a bloques enteros de instrucciones y no a una única expresión. Así, la instrucción checked se usa de este modo:
Todo desbordamiento que se produzca al realizar operaciones aritméticas con enteros en <instrucciones> provocará que se lance una excepción System.OverflowException. Por su parte, la instrucción unchecked se usa así:
unchecked
<instrucciones>
|
En este caso, todo desbordamiento que se produzca al realizar operaciones aritméticas con tipos básicos enteros en <instrucciones> será ignorado y lo que se hará será tomar el valor resultante de quedarse con los bits menos significativos necesarios.
Por defecto, en ausencia de estas instrucciones las expresiones constantes se evalúan como si se incluyesen dentro de una instrucción checked y las que no constantes como si se incluyesen dentro de una instrucción unchecked. Sin embargo, a través de la opción /checked del compilador es posible tanto hacer que por defecto se comprueben los desbordamientos en todos los casos para así siempre poder detectarlos y tratarlos.
Desde Visual Studio.NET, la forma de controlar el tipo de comprobaciones que por defecto se harán es a través de View à Propety Pages à Configuration Settings à Build à Check for overflow underflow.
El siguiente código muestra un ejemplo de cómo usar ambas instrucciones:
using System;
class Unchecked
{
static short x = 32767; // Valor maximo del tipo short
public static void Main()
{
unchecked
{
Console.WriteLine((short) (x+1)); // (1)
Console.WriteLine((short) 32768); // (2)
}
}
|
En un principio este código compilaría, pero los desbordamientos producidos por el hecho de que 32768 no es un valor que se pueda representar con un short (16 bits con signo) provocarían que apareciese por pantalla dicho valor truncado, mostrándose:
Sin embargo, si sustituyésemos la instrucción unchecked por checked, el código anterior ni siquiera compilaría ya que el compilador detectaría que se va a producir un desbordamiento en (2) debido a que 32768 es constante y no representable con un short.
Si eliminamos la instrucción (2) el código compilaría ya que (x+1) no es una expresión constante y por tanto el compilador no podría detectar desbordamiento al compilar. Sin embargo, cuando se ejecutase la aplicación se lanzaría una System.OverflowException.
Instrucción lock
La instrucción lock es útil en aplicaciones concurrentes donde múltiples hilos pueden estar accediendo simultáneamente a un mismo recurso, ya que lo que hace es garantizar que un hilo no pueda acceder a un recurso mientras otro también lo esté haciendo. Su sintaxis es la siguiente:
lock (<objeto>)
<instrucciones>
|
Su significado es el siguiente: ningún hilo puede ejecutar las <instrucciones> del bloque indicado si otro las está ejecutando, y si alguno lo intenta se quedará esperando hasta que acabe el primero. Esto también afecta a bloques de <instrucciones> de cualquier otro lock cuyo <objeto> sea el mismo. Este <objeto> ha de ser de algún tipo referencia.
En realidad, la instrucción anterior es equivalente a hacer:
System.Threading.Monitor.Enter(<objeto>);
try
{
<instrucciones>
}
finally
{
System.Threading.Monitor.Exit(<objeto>);
}
|
Sin embargo, usar lock tiene dos ventajas: es más compacto y eficiente (<objeto> sólo se evalúa una vez)
Una buena forma de garantizar la exclusión mutua durante la ejecución de un método de un cierto objeto es usando this como <objeto> En el caso de que se tratase de un método de tipo, en tanto que this no tiene sentido dentro de estos métodos estáticos una buena alternativa sería usar el objeto System.Type que representase a ese tipo. Por ejemplo:
class C
{
public static void F()
{
lock(typeof(C))
{
// ... Código al que se accede exclusivamente
}
}
}
|
Instrucción using
La instrucción using facilita el trabajo con objetos que tengan que ejecutar alguna tarea de limpieza o liberación de recursos una vez que termine de ser útiles. Aunque para estos menesteres ya están los destructores, dado su carácter indeterminista puede que en determinadas ocasiones no sea conveniente confiar en ellos para realizar este tipo de tareas. La sintaxis de uso de esta instrucción es la siguiente:
using (<tipo> <declaraciones>)
<instrucciones>
|
En <declaraciones> se puede indicar uno o varios objetos de tipo <tipo> separados por comas. Estos objetos serán de sólo lectura y sólo serán accesibles desde <instrucciones>. Además, han de implementar la interfaz System.IDisposable definida como sigue:
interface IDisposable
{
void Dispose()
}
|
En la implementación de Dispose() se escribiría el código de limpieza necesario, pues el significado de using consiste en que al acabar la ejecución de <instrucciones>, se llama automáticamente al método Dispose() de los objetos definidos en <declaraciones>.
Hay que tener en cuenta que la llamada a Dispose() se hace sea cual sea la razón de que se deje de ejecutar las <instrucciones> Es decir, tanto si se ha producido una excepción como si se ha acabado su ejecución normalmente o con una instrucción de salto, Dispose() es siempre llamado. En realidad una instrucción using como:
using (R1 r1 = new R1())
{
r1.F();
}
|
Es tratada por el compilador como:
{
R1 r1 = new R1()
try
{
r1.F();
}
finally
{
if (r1!=null)
((IDisposable) r1).Dispose();
}
}
|
Si se declarasen varios objetos en <declaraciones>, a Dispose() se le llamaría en el orden inverso a como fueron declarados. Lo mismo ocurre si se anidasen varias instrucciones using: primero se llamaría al Dispose() de las variables declaradas en los using internos y luego a las de los externos. Así, estas dos instrucciones son equivalentes:
using (Recurso obj = new Recurso(), obj2= new Recurso())
{
r1.F();
r2.F();
}
using (Recurso obj = new Recurso())
{
using (Recurso obj2= new Recurso())
{
r1.F();
r2.F();
}
}
|
El siguiente ejemplo resume cómo funciona la sentencia using:
using System;
class A:IDisposable
{
public void Dispose()
{
Console.WriteLine("Llamado a Dispose() de {0}", Nombre);
}
public A(string nombre)
{
Nombre = nombre;
}
string Nombre;
} class Using
{
public static void Main()
{
A objk = new A("objk");
using (A obj1 = new A("obj1"), obj2 = new A("objy"))
{
Console.WriteLine("Dentro del using");
}
Console.WriteLine("Fuera del using");
}
}
|
La salida por pantalla resultante de ejecutar este ejemplo será:
|
Dentro del using
Llamando a Dispose() de objy
Llamando a Dispose() de obj1
Fuera del using |
Como se deduce de los mensajes de salida obtenidos, justo antes de salirse del using se llama a los métodos Dispose() de los objetos declarados en la sección <declaraciones> de dicha instrucción y en el mismo orden en que fueron declarados.
Instrucción fixed
La instrucción fixed se utiliza para fijar objetos en memoria de modo que el recolector de basura no pueda moverlos durante la ejecución de un cierto bloque de instrucciones.
Esta instrucción sólo tiene sentido dentro de regiones de código inseguro, concepto que se trata en el Tema 18: Código inseguro, por lo que será allí es donde se explique a fondo cómo utilizarla. Aquí sólo diremos que su sintaxis de uso es:
fixed(<tipoPunteros> <declaracionesPunterosAFijar>)
<instrucciones>
|
|