|Lo que no hay que hacer en C/C++. Nivel basico|

[Capitan ShinChan]

Una puntualización, corregidme si me equivoco.

Yo suelo programar de vez en cuando en C, sobretodo programas simples para hacer tareas rutinarias de cálculo y trabajo básico con archivo. Además de algunas cosas más complejas orientadas a sistemas operativos (los clásicos problemas de los filósofos, productor-consumidor, etc...).

Suelo usar a menudo la funcion strcpy y nunca he tenido ningún problema. Creo que antes que ir a buscar funciones alternativas, deberíamos pararnos y ver cómo podría fallar nuestro código. Con una simple sentencia if-else se pueden ahorrar muchos problemas. Es más, la mayoría de mis códigos están llenos de condicionales de este tipo para evitar por ejemplo que se produzcan sobreescrituras de memoria, comprobar que las funciones no devuelven ningún error, etc...

[@synthesize]

Una puntualización, corregidme si me equivoco.

Yo suelo programar de vez en cuando en C, sobretodo programas simples para hacer tareas rutinarias de cálculo y trabajo básico con archivo. Además de algunas cosas más complejas orientadas a sistemas operativos (los clásicos problemas de los filósofos, productor-consumidor, etc...).

Suelo usar a menudo la funcion strcpy y nunca he tenido ningún problema. Creo que antes que ir a buscar funciones alternativas, deberíamos pararnos y ver cómo podría fallar nuestro código. Con una simple sentencia if-else se pueden ahorrar muchos problemas. Es más, la mayoría de mis códigos están llenos de condicionales de este tipo para evitar por ejemplo que se produzcan sobreescrituras de memoria, comprobar que las funciones no devuelven ningún error, etc...

Con un strncpy te ahorras estar comprobado código con if-else...

[abelique]

gracias copañero un buen aporte
solo soy un novato en c\c++
y me ha encantado la informacion aportada y la manera tan detallada de explicarlo todo
De verdad gracias

[rob1104]

Todo muy bien, pero solo tengo una duda.

Por ejemplo, si la función gets() es peligrosa e inestable, ¿Por qué sigue en el estandar?, ¿Solo por compatibilidad?

Saludos

[Blackhawk222]

Muy bueno Estoy por empezar a programar en C++ y seguro me va a servir.
Gracias Y Saludos

[Eternal Idol]

Muy bueno Estoy por empezar a programar en C++ y seguro me va a servir.
Gracias Y Saludos

Entiendo que el avatar sea un chiste pero no tiene que serlo tambien su tamaño 

[Littlehorse]

Todo muy bien, pero solo tengo una duda.

Por ejemplo, si la función gets() es peligrosa e inestable, ¿Por qué sigue en el estandar?, ¿Solo por compatibilidad?

Saludos

Si, principalmente por compatibilidad con código antiguo.

Muchas otras funciones son explotables (he mencionado algunas en el primer post, no todas) pero con ellas se pueden evitar errores haciendo chequeos de los datos, manejo de memoria, chequeo de limites, etc. Es decir, a pesar que no sea recomendable utilizar funciones que sean inseguras desde su base, por lo menos existe la posibilidad de solucionarlos agregando código, aunque obviamente, ese agregado de código puede generar que el programa final sea propenso a errores, por lo menos existe la posibilidad. Lo ideal siempre sera utilizar alternativas seguras, y en la medida de lo posible, que sean estándar.

Por otro lado, con gets no hay nada que puedas hacer para evitar que sea explotable. Utilizarla es asegurarte como mínimo una posibilidad de desbordamiento de buffer. De hecho esta marcada como obsoleta en las ultimas revisiones de C99 y la mayoría de los entornos de trabajo conocidos emiten advertencias al utilizarla.

Saludos

[rob1104]

Gracias Littlehorse, nunca está de más saberlo. Aunque ahorita estoy un poco más enfocado en programación Windows en entornos RAD, es importante conocer las carencias de los lenguajes para no caer en errores básicos.

Saludos

[someRandomCode]

Me quedé con lo de un post anterior.
Deprecated significa DECREPITO, no banneado.
Esas funciones están decrepitas porque otra ya indexa sus funcionalidades y ha sido favorecida por algún motivo, y como tal, el uso de la nueva y no de la decrepita esta favorecida.
Y las otras que tienen poison como pragma comment van a hacer que si le pasamos al compilador (bueno, a GCC voy a dar el ejemplo) -Wall o -pedantic nos advierta o nos tire error.
Lo cierto es que todavia son usables, estan bajo una capa de transición y como venimos haciendo eso con aplicaciones de 16 bits hasta Vista, podemos esperar que duren bastante mas ahi estando.

[Merlow]

Siento revivir un poco el post pero es para agradecerte la explicacion. Como bien dices yo soy uno de esos que esta ahora en la universidad y aciertas tambien en que nos han "enseñado" a incluir la libreria conio.h