foreach para una table

No no, el que tuvo la culpa fui yo por andar de metiche :P

Finalmente lo que importa es que salimos aprendiendo todos.

Castclass es poco, a todo lo que agrega el compilador por nosotros, estas
pueden removerse (optimización en compilación) para aumentar "rendimiento"
sin embargo siempre tendremos el freno del CLR.

{
this.Saludo = Saludos!
this.Nombre = Misael Monterroca | Microsoft MVP C#;
this.Blog = http://www.neo-mx.com/blogs/neo-mx
}


"Octavio Hernandez" wrote in message
news:

Hola Daniel, Misael, Vyacheslav!

Perdonad la demora en responder, ayer he tenido un día "movido"...
Además he hecho unas cuantas pruebas por mi cuenta :-)

Vyacheslav: >> ¿Cómo ganar 2 ciclos de microprocesador?

Bueno, en el fondo tienes razón... El "culpable" de este hilo soy yo que
fue quien mencionó primero
el tema del rendimiento. Pero me alegro de haberlo hecho, porque he
aprendido algo...

Daniel: > Lo mandé solo por que muchas veces algunas cosas son distintas a
como uno imagina.

Exacto! Gracias por "darnos la luz".

Misael: >>>>> Exacto, y finalmente es menos costoso realizar la
comprobación de NULL,

que la comprobación de un tipo.

Creo que me he dado cuenta de dónde estaba el fallo en mi razonamiento:
asumir que un cast

(RadioButtonList) control

es una mera re-interpretación del significado de 4 bytes de memoria, como
ocurre en código no
manejado (C++, Delphi). En código manejado no se permite este tipo de
"agujeros potenciales",
y por eso los compiladores (VB también) producen una instrucción castclass
en el IL.

Saludos a todos,

Octavio