Autor Tema: Uso De Strcmp (Leído 6764 veces)

Penguin-man · « **en:** Viernes 17 de Noviembre de 2006, 22:05 »

Hola, estaba buscando alguna funcion que me permitiera comparar cadenas de caracteres y me encontre con una llamada strcmp en la libreria string.h

La probe y si funciona pero no entiendo muy bien que hace

Código: Text

 
 /*longitud de las cadenas*/
 
         printf (&#34;&#092;n%s es de %d caracteres de largo&#092;n&#34;,str1,strlen(str1));
 
         printf (&#34;&#092;n%s es de %d caracteres de largo&#092;n&#34;,str2,strlen(str2));
 
         /*comparar cadenas*/
 
         i=strcmp(str1,str2);
 
         if (!i)       printf (&#34;&#092;nLas cadenas son iguales&#092;n&#34;);
 
         else         if (i&#60;0) printf (&#34;&#092;n%s es menor que %s&#34;,str1,str2);
 
         else printf (&#34;&#092;n%s es mayor que %s&#34;,str1,str2);

Lo que no entiendo es por ejemplo su uso, que valor debelvae si son iguales, o diferentes y eso de

if(!¡) alguien podria explicarme?

JuanK

strcmp devuelve 0 si las cadenas son iguales, de lo contrario devuelve diferente 0 bien sea positivo o negativo dependiendo cual cadena sea 'mayor' que la otra.

así que

Código: Text

if (!i) 
 

esta diciendo en este caso que si i es igual a 0 , aunque también validaría que si i es igual a nulo

decir que

Código: Text

if(!i)
 

es lo mismo que decir que

Código: Text

if(i==0)
 

o

Código: Text

if(i==NULL)
 

Desglosando:

Código: Text

if ( !i)
 

i es igual a 0 o a NULL , en lenguaje C se entiende se entiende que 0 o NULL es falso y cualquiera diferente de 0 o NULL es verdadero.

El el operador ! es una negación lógica así que negar algo que es falso es decir que ese algo sea verdadero. Por esta razón al cumplir la validación:

Código: Text

if ( !i)
 

en tu ejemplo se entiende que las cadenas son iguales.

robertogt

strcmp, lo que hace es que devuelve un cero si las dos cadenas son exactamente iguales, es decir 'hola' no es lo mismo que 'Hola', devuelve un numero menor a cero si la segunda cadena es mayor a la primera, por ejemplo 'aa' es menor que 'ab', y devuelve mayor a cero si la primera cadena es mayor a la segunda, ahora si no quieres que importe el CASE de las cadenas, podes usar strcmpi.

F_Tanori

Hola mira

Esa funcion devuelve 0 si las dos cadenas son iguales el signo de (!) es el NOT de C el if es una comparacion que espera un valor logico
binario 0/1 entonces

entonces cuando la funcion devuelve 0 'niegas' el resultado y eso es lo que interpreta el if

IF (!i) "Si es 0 entonces es 1 " (la table de verdad del NOT)

Saludos

Se me adelantaron

--------------

JuanK

Citar

if es una comparación que espera un valor logico

hasta ahí bien...

Citar

binario 0/1 entonces

Ahi 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.

Citar

IF (!i) "Si es 0 entonces es 1 " (la table de verdad del NOT)

Casi... pero no solo negar 0 es 1, negar NULL también es 1.

Eternal Idol

NULL es 0.

JuanK

Cita de: "Eternal Idol"

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í?

Es decir cada compilador es libre de asignarle el valor que quiera desde que haga de esa posición apuntada un valor reservado.

F_Tanori

Cita de: "JuanK"

Citar
binario 0/1 entonces
Ahi 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.

Citar
IF (!i) "Si es 0 entonces es 1 " (la table de verdad del NOT)
Casi... pero no solo negar 0 es 1, negar NULL también es 1.

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

Finalmente lo que evalua el if es si la condicion es verdadera o no (1/0)

entonces el if siempre espera 1/0

no estoy diciendo que siempre tengas que comparar

if (i==1)

o if(i==0)

sino el resultado final de la evaluacion de la condicion

x=(i==0) //=1

if (x) <---- el if estaria recibiendo la condicion ya 'resuelta'

equivalente a

if (i==0)

asi que no entiendo porque dices que no

Espero haberlos confundido

Saludos

Eternal Idol

Cita de: "JuanK"

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:
#define NULL 0

http://www.cplusplus.com/ref/cstdlib/

¿Como pensas que definen una constante a la pila que es variable y asignada en tiempo de ejecucion por el S.O.?

NULL es 0 ...

JuanK

Citar

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

Es que no revienta al enviar otro valor, por eso mi acotación, tu dices que e

Citar

el if es una comparación que espera un valor lógico
binario 0/1

No es cierto,al if le puedes pasar cualquier cosa diferente 1 y 0, creo que es solo confusión de términos.

Citar

Finalmente lo que evalua el if es si la condicion es verdadera o no (1/0) entonces el if siempre espera 1/0

Valida si es verdadero o no, pero no valida que sea 1 o 0, valida como ya lo mencione antes.

Citar

if (x) <---- el if estaria recibiendo la condicion ya 'resuelta'

equivalente a

if (i==0)

asi que no entiendo porque dices que no

No, porque nadie te puede asegurar que x realmente no sea 0 sino NULL.

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

JuanK

Citar

¿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 que
#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.

Eternal Idol

Cita de: "JuanK"

Decir que
#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, 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 ...

F_Tanori

Cita de: "JuanK"

No, porque nadie te puede asegurar que x realmente no sea 0 sino NULL.

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 que esta confundiendo las cosas eres tu

if compara falso/verdadero, 0/1, encendido/apagado, nel/simon es una logico boleano
por cierto strcmp no devuelve null

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

JuanK

Cita de: "Eternal Idol"

Cita de: "JuanK"
Decir que
#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, 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 ...

El preprocesador es del compilador.

Eternal Idol

Cita de: "JuanK"

Ni idea, no debería ser algo opcional sino estándar.

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...

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

Eternal Idol

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.

JuanK

Cita de: "F_Tanori"

Cita de: "JuanK"
No, porque nadie te puede asegurar que x realmente no sea 0 sino NULL.

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 que esta confundiendo las cosas eres tu

if compara falso/verdadero, 0/1, encendido/apagado, nel/simon es una logico boleano
por cierto strcmp no devuelve null

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

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.

De resto creo que ya te confundiste incluso con lo que yo dije. Aunque estamos haciendo una avalancha con una sola bola de nieve.

Eternal Idol

Obviamente el if permite usar muchos mas valores que 0b y 1b como dice JuanK, lo que si es 0b o 1b es su resultado ... los ifs suelen ser "traducidos" a cmp's.

JuanK

Cita de: "Eternal Idol"

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.

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.

JuanK

Conclusiones:

1- Si bien NULL puede o no ser igual 0, lo mas seguro es que nunca exista un compilador que le asigne diferente 0. El 100% de las implementaciones mas populares actualmente lo hacen así.

2- Si bien los if pueden recibir cualquier valor, al final la condición muy probablemente se evaluara con cmp buscando igualdad o desigualdad con 1 o con 0.