if es una comparación que espera un valor logicohasta ahí bien...
binario 0/1 entoncesAhi si ya no, porque si fuera asi el if reventaria al enviarle cualquier valor diferente de 1 o 0 y como ya lo mencione te compara 0, NULL o diferente de NULL.
IF (!i) "Si es 0 entonces es 1 " (la table de verdad del NOT) :PCasi... pero no solo negar 0 es 1, negar NULL también es 1.
NULL es 0.Pero tengo entendido que NULL es una constante definida independientemente en cada implementación de compilador así que puede o no ser un puntero a la posición 0 del stack no es así?
las comparaciones LOGICAS son falso o verdadero (0/1) entonces al resolver el if es 0 o 1Citarbinario 0/1 entoncesAhi si ya no, porque si fuera asi el if reventaria al enviarle cualquier valor diferente de 1 o 0 y como ya lo mencione te compara 0, NULL o diferente de NULL.CitarIF (!i) "Si es 0 entonces es 1 " (la table de verdad del NOT) :PCasi... pero no solo negar 0 es 1, negar NULL también es 1.
:rolleyes:
Pero tengo entendido que NULL es una constante definida independientemente en cada implementación de compilador así que puede o no ser un puntero a la posición 0 del stack no es así?NULL is a defined constant used to express null pointers, that is, an unassigned pointer or a pointer that points nowhere. It is defined as:
las comparaciones LOGICAS son falso o verdadero (0/1) entonces al resolver el if es 0 o 1
entonces no entiendo porque dices que reventaria al enviar otro valor :blink:
el if es una comparación que espera un valor lógico
binario 0/1
Finalmente lo que evalua el if es si la condicion es verdadera o no (1/0) :P entonces el if siempre espera 1/0
if (x) <---- el if estaria recibiendo la condicion ya 'resuelta'
equivalente a
if (i==0)
asi que no entiendo porque dices que no :P
¿Como pensas que definen una constante a la pila que es variable y asignada en tiempo de ejecución por el S.O.?
NULL es 0 ...
Decir queNo, el preprocesador se encarga de reemplazar la palabra NULL por 0. Nadie en su sano juicio usaria un compilador que no definiera NULL como 0 ...
#define NULL 0
Es decir que apunta a la dirección 0... que desde luego es la dirección del comienzo del segmento de datos... del stack.
La mayoria, si es que no la totalidad de los compiladores, asignan 0 a NULL,, pero no es obligación que lo hagan asi, es libre de la implementación del compilador determinar a donde lo dejan apuntando y que dirección tomar como nula.
No, porque nadie te puede asegurar que x realmente no sea 0 sino NULL.El que esta confundiendo las cosas eres tu
Por otro lado el ejemplo esta mal, no solo por el uso de i en un lado y de x en otro, sino que
en el caso que x sea 0:
if (x) --> se resuelve como falsa
y
if (i==0)--> se resuelve como cierta
El preprocesador es del compilador.Cita de: "JuanK"Decir queNo, el preprocesador se encarga de reemplazar la palabra NULL por 0. Nadie en su sano juicio usaria un compilador que no definiera NULL como 0 ...
#define NULL 0
Es decir que apunta a la dirección 0... que desde luego es la dirección del comienzo del segmento de datos... del stack.
La mayoria, si es que no la totalidad de los compiladores, asignan 0 a NULL,, pero no es obligación que lo hagan asi, es libre de la implementación del compilador determinar a donde lo dejan apuntando y que dirección tomar como nula.
Ni idea, no debería ser algo opcional sino estándar.Puede ser pero es algo tan logico que seria una locura que NULL no fuera 0. Una cosa es que pueda haber algun demento con un compilador raro que haga cualquier cosa, eso seria lo minimo, pero no podemos no dar por sentado que NULL es 0 ... NULL es 0 y sino cambien el compilador :lol:
Y compiladores.. que se yo, hay mucho linuxero desocupado con ganas de parecer un hippie diferente y en una de esas hacen uno y por ser gratis pega... :P :whistling:
El preprocesador es del compilador.Yo no dije lo contrario dije no a esto:
no creo estar confundido, normalmente el if evalúa falso o verdadero eso es cierto mirándolo a nivel logico, según tu solo 1 o 0 pero no es cierto de hecho, y eso si me corregiría eternal idol, el compilador en esos caso de comparación de igualdad resolvería ese if con una instrucción de TEST equivalente en opcode , que lo único que miraría seria revisar si un registro tiene un valor en 0 o diferente de 0.Cita de: "JuanK"No, porque nadie te puede asegurar que x realmente no sea 0 sino NULL.El que esta confundiendo las cosas eres tu
Por otro lado el ejemplo esta mal, no solo por el uso de i en un lado y de x en otro, sino que
en el caso que x sea 0:
if (x) --> se resuelve como falsa
y
if (i==0)--> se resuelve como cierta
if compara falso/verdadero, 0/1, encendido/apagado, nel/simon es una logico boleano
por cierto strcmp no devuelve null :P
lo que puse fue
x=(i==0) //=1
if (x) <---- el if estaria recibiendo la condicion ya 'resuelta'
if (i==0)
y es lo MISMO porque previamente le asignaste el resultado LOGICO de i==0 a x en lugar de pasarselo al IF
Tambien tengo entendido que NULL es 0 el if no revienta :P
:hola:
Considera, como creí que lo harías, que la dirección 0 del segmento de datos es la dirección 0 offset a partir de la dirección que el OS destine para cargar ese stack.Cita de: "JuanK"El preprocesador es del compilador.Yo no dije lo contrario dije no a esto:
"Es decir que apunta a la dirección 0... que desde luego es la dirección del comienzo del segmento de datos... del stack."
NULL no apunta a ningun lado. Si podemos darle el valor de NULL a un puntero, que seria el que apuntara a 0.
¿Es la direccion del comienzo de datos? ¿Si? ¿Entonces para que declaramos siempre los punteros a cero? ¿Para sobreescribir la memoria? NO. Los datos comienzan donde el S.O. lo diga igual que la pila y si escribimos en 0 siempre da una excepcion ya que nunca nos da el S.O. esa direccion.