La aritmética de punteros es la mayor magia del C. Puede que no te guste, pero para otra gente es una maravilla, y desde luego no se podría eliminar del lenguaje porque es su alma
¿Estás seguro de que no se puede considerar como de tipado fuerte? Que yo sepa, cada variable tiene un tipo, al contrario que otros lenguajes como Python, PHP o Ruby. Otra cosa es que luego el lenguaje te permita hacer burradas.
Las asignaciones de la línea if sólo están haciendo lo que tú le has dicho. Una vez asimilas que = es asignar e == es comparar no te vuelves a confundir.
La sintaxis del switch sí te reconozco que siempre me ha parecido cutre, aunque tampoco te sé decir cómo lo haría, y no recuerdo ahora cómo se hacía en otros lenguajes que no tomen la sintaxis de C.
Las macros es cierto que no las uso mucho, aunque, ya que se supone que C++ apesta, éste las soluciona un poco con funciones inline. No obstante quiero señalar que las macros sirven para hacer optimizaciones que en otros lenguajes simplemente no se pueden hacer, no es en ningún caso un mecanismo necesario del lengauje.
Lo de las llaves perdóname pero es una tontería. Depende de la costumbre, una vez estás habituado parece la manera más natural. Es más, pensar en tener que escribir begin y end, o incluso leerlo, me da pereza. Al fin y al cabo es una representación bastante gráfica.
Lo de las mayúsculas y minúsculas tampoco es para tanto, puede dar lugar a errores, pero sólo si no sigues un estilo predefinido (gran error). Si siguies por ejemplo el estándar de Java, sabes perfectamente con qué letra vas a escribir, con la ventaja de que en muchos casos es natural llamarle a la clase "Casa" y al objeto que vas a instanciar "casa"
Por el otro lado se te ha olvidado mencionar las cadenas de caracteres, cuyo manejo es bastante coherente pero muy, muy tedioso y peligroso si no tienes las cosas claras. Tampoco has dicho nada de tener el código repartido en ficheros.c y.h, algo que C++ sólo consigue hacerlo peor. Y en general que ciertas cosas son muy manuales y pueden llegar a ser toscas y tediosas.
Al final vuelvo a lo mismo: el C es para lo que es (de nada por la tautología). No digo que te tengas que restringir a los drivers, pero sí que el C es bueno cuando se necesita trabajar codo a codo con la máquina, cuando hay requisitos de eficiencia o para manejar la memoria en plan trituradora. También depende del tipo de pensamiento de la persona.
Ojo que Python tiene tipado fuerte. Lo que sucede es que el tipo se establece en tiempo de ejecución, la primera vez que se asigna un valor a una variable.
-- Asqueados [asqueados.net]: mas politica, informatica y payasadas que nunca
La aritmética de punteros es la mayor magia del C. Puede que no te guste, pero para otra gente es una maravilla, y desde luego no se podría eliminar del lenguaje porque es su alma.
Sí, efectivamente es el alma del C, y así va.
No es una maravilla, lo que es una maravilla es recorrer un array por indices y que el compilador se ocupe de gestionarlo internamente por punteros. Jugar con la dirección de memoria de una variable y cuanto espacio ocupa es una operación delicada que rara vez es necesario hacer. El programador no debería perder el tiempo en saber si físicamente son direcciones contiguas o cuanto espacio ocupa, y menos aún hacerlo rutinariamente.
Lo peor de los errores con punteros es que provocan errores impredecibles (entre ellos el famoso buffer overflow), es una sobreescritura nadie sabe donde. Usando indices de arrays, daría "error te has salido", corregirías el bug y ya está. De hecho, hay buenos programas que llevan años con un bug de ese estilo. Van bien, y de vez en cuando hacen una cosa rara. Pero a ver quien lo encuentra.
Lamentable.
¿Estás seguro de que no se puede considerar como de tipado fuerte?
Segurísimo. ¿puedes asignar byte a un char sin error?. ¿Puedes asignar un puntero a un int a un puntero a un char?. ¿Puedes asignar un float a un int?
Otra cosa es que luego el lenguaje te permita hacer burradas
Casi todos los lenguajes te permiten hacer burradas...si se lo pides. La cuestión es la facilidad con que puedes hacer una burrada sin pretenderlo. En pascal, p.ejm. si quieres asignar un puntero a integer a un puntero a un fichero, no te deja. Ahora, si te empeñas porque lo consideras necesario, le fuerzas la conversión explícitamente, y ya está.
Las asignaciones de la línea if sólo están haciendo lo que tú le has dicho. Una vez asimilas que = es asignar e == es comparar no te vuelves a confundir.
Esos errores los sigo cometiendo en PHP, y lo que es peor, cuesta un huevo de pillar. No soy yo el único, en el Kernel de Linux hubo un caso de estos.
El 99.9% de los casos en una condición quieres hacer una comparación, no una asignación, por tanto, lo lógico es que la sintaxis los diferencia claramente y evite la confusión.
no recuerdo ahora cómo se hacía en otros lenguajes que no tomen la sintaxis de C.
Muy simple, asumen que siempre hay un break. Evidentemente no se puede hacer una ejecución en cascada como en C (si se cumple B, ejecuta B, si se cumple A ejecuta A y B) ¿Pero quién quiere esto? ¿cuántas veces se necesita? Es heredado del ensamblador.
Otras cuestiones Vaya por delante, que las macros, llaves y mayúsculas/minúsculas, los considero más cuestión de gustos que defectos.
Las macros es cierto que no las uso mucho,
Las macros pueden ser útiles. Pero se ha abusado de ellas. En cualquier caso hay otras alternativas, de modo que cuando ves una instrucción no te despista porque está redefinida con una macro.
Lo de las llaves perdóname pero es una tontería.
Perdonado;-)
El problema se lo veo también al pascal con begin/end. Cada estructura debería cerrarse de una manera, p.ejm. en for/next while/wend case/cend funcion/eif. Significa captar que estructura no cerrada en 5 segundos a tardar 30 segundos si se ha liado.
Lo de las mayúsculas y minúsculas tampoco es para tanto, puede dar lugar a errores.
No es que dé errores, es que me repatea no acordarme si este identificador es MiFuncionInt o MiFuncionINT o m
Re:Estoy de acuerdo, pero...
(Puntos:2)( http://press.asqueados.net/ | Última bitácora: Jueves, 17 Abril de 2014, 09:50h )
Por el otro lado se te ha olvidado mencionar las cadenas de caracteres, cuyo manejo es bastante coherente pero muy, muy tedioso y peligroso si no tienes las cosas claras. Tampoco has dicho nada de tener el código repartido en ficheros
Al final vuelvo a lo mismo: el C es para lo que es (de nada por la tautología). No digo que te tengas que restringir a los drivers, pero sí que el C es bueno cuando se necesita trabajar codo a codo con la máquina, cuando hay requisitos de eficiencia o para manejar la memoria en plan trituradora. También depende del tipo de pensamiento de la persona.
Envíos descartados por Mu [barrapunto.com]
Re:Estoy de acuerdo, pero...
(Puntos:2)( http://press.asqueados.net/ | Última bitácora: Jueves, 06 Marzo de 2014, 11:47h )
Asqueados [asqueados.net]: mas politica, informatica y payasadas que nunca
Re:Estoy de acuerdo, pero...
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Viernes, 29 Diciembre de 2017, 18:26h )
Sí, efectivamente es el alma del C, y así va.
No es una maravilla, lo que es una maravilla es recorrer un array por indices y que el compilador se ocupe de gestionarlo internamente por punteros. Jugar con la dirección de memoria de una variable y cuanto espacio ocupa es una operación delicada que rara vez es necesario hacer. El programador no debería perder el tiempo en saber si físicamente son direcciones contiguas o cuanto espacio ocupa, y menos aún hacerlo rutinariamente.
Lo peor de los errores con punteros es que provocan errores impredecibles (entre ellos el famoso buffer overflow), es una sobreescritura nadie sabe donde. Usando indices de arrays, daría "error te has salido", corregirías el bug y ya está. De hecho, hay buenos programas que llevan años con un bug de ese estilo. Van bien, y de vez en cuando hacen una cosa rara. Pero a ver quien lo encuentra.
Lamentable.
Segurísimo. ¿puedes asignar byte a un char sin error?. ¿Puedes asignar un puntero a un int a un puntero a un char?. ¿Puedes asignar un float a un int?
Casi todos los lenguajes te permiten hacer burradas...si se lo pides. La cuestión es la facilidad con que puedes hacer una burrada sin pretenderlo. En pascal, p.ejm. si quieres asignar un puntero a integer a un puntero a un fichero, no te deja. Ahora, si te empeñas porque lo consideras necesario, le fuerzas la conversión explícitamente, y ya está.
Esos errores los sigo cometiendo en PHP, y lo que es peor, cuesta un huevo de pillar. No soy yo el único, en el Kernel de Linux hubo un caso de estos.
El 99.9% de los casos en una condición quieres hacer una comparación, no una asignación, por tanto, lo lógico es que la sintaxis los diferencia claramente y evite la confusión.
Muy simple, asumen que siempre hay un break. Evidentemente no se puede hacer una ejecución en cascada como en C (si se cumple B, ejecuta B, si se cumple A ejecuta A y B) ¿Pero quién quiere esto? ¿cuántas veces se necesita? Es heredado del ensamblador.
Otras cuestiones Vaya por delante, que las macros, llaves y mayúsculas/minúsculas, los considero más cuestión de gustos que defectos.
Las macros pueden ser útiles. Pero se ha abusado de ellas. En cualquier caso hay otras alternativas, de modo que cuando ves una instrucción no te despista porque está redefinida con una macro.
Perdonado ;-)
El problema se lo veo también al pascal con begin/end. Cada estructura debería cerrarse de una manera, p.ejm. en for/next while/wend case/cend funcion/eif. Significa captar que estructura no cerrada en 5 segundos a tardar 30 segundos si se ha liado.
No es que dé errores, es que me repatea no acordarme si este identificador es MiFuncionInt o MiFuncionINT o m