problemas con fseeks

[rir3760]

Tengo entendido además que por lo general los sistemas Windows codifican el fin de línea con dos caracteres (0x0D + 0x0A, o en decimal 13 + 10), mientras los UNIX usan simplemente el 0x0A.

Correcto, en MS-DOS (QEPD) y MS Windows el avance de linea se indica con '\r' + '\n', en Linux con '\n'.

Me tratas de decir que si por ejemplo fgetc() encuentra una sucesión CR + LF , entonces lee un sólo '\n' y avanza el indicador de posición de archivo en dos bytes, de modo que la próxima llamada a fgect() leerá el siguiente carácter después del LF. ¿¿Es eso así??

Exacto siempre y cuando el modo del stream sea texto, si el modo es binario (por ejemplo cuando se abre un archivo indicando el modo "rb") se presenta el problema que mencionas (cada carácter se retorna tal cual sin importar su valor).

Un saludo

[x64core]

==============
Ah, y x64Core, no ingresé a este foro para pelear con nadie, sino para ayudar a los demás. Simplemente tengo una filosofía de que me gusta hacer las cosas a mano, en lugar de recurrir a recursos o softwares sofisticados.

Por ejemplo, uso la IDE más sencilla y sólo como editor, pues rara vez compilo usando los íconos de la barra de herramientas. Yo compilo desde la terminal y le meto yo mismo las directivas de "include" y de "lib" en la orden de compilación.

Hasta ahora me ha funcionado y he creado aplicaciones de cierta complejidad. Por supuesto me lleva más tiempo pero estoy seguro de que he construido y verificado POR MÍ MISMO cada línea de mi código, por eso confío en él.

De nuevo, no es por polemizar, simplemente es mi filosofía de trabajo. Cada quién tiene la suya y se le respeta  

Escribir los include's y lib's siempre no te parece que es simplemente una perdida de tiempo?, Yp sé que al inicio es una forma para
saber como realmente funciona el proceso de compilación, qué tipo de archivos y como son procesados por el compilador y el linker
esta bien, pero escribirlos por toda la vida, en todos tus programas simplemente lo veo una perdida de tiempo, al menos se debe crear
un script que lo haga por ti. Y lo digo para que la gente no lo haga, lo cual no es necesario, yo sé que estaría cuestionando la manera
en que cada persona lo hace pero es simplemente una recomendación y si a pesar de eso yoel_alejandro, crees que es siempre
conveniente escribir siempre los include's y lib's talvez nos puedes explicar el ¿porqué?

[Yoel Alejandro]

Escribir los include's y lib's siempre no te parece que es simplemente una perdida de tiempo?, Yp sé que al inicio es una forma para
saber como realmente funciona el proceso de compilación, qué tipo de archivos y como son procesados por el compilador y el linker
esta bien, pero escribirlos por toda la vida, en todos tus programas simplemente lo veo una perdida de tiempo (...) crees que es siempre
conveniente escribir siempre los include's y lib's talvez nos puedes explicar el ¿porqué?

Bueno, una razón es básicamente para saber. Otra es porque generalmente cuando se está desarrollando un trabajo grande, uno crea clases que llevan ficheros include personalizados, y si lo vuelves una biblioteca, tendrás directorios de lib. Estos claro no son los de la biblioteca estándar de C que los incluye el compilador sino los directorios personalizados que uno crea.

En mi caso, normalmente paso por fases experimentales de prueba donde las bibliotecas van a un directorio "temporal" donde son probadas y luego a su lugar definitivo. Así que estoy creado, moviendo y eliminando directorios todo el tiempo  

Con una IDE de desarrollo de C++ se puede "editar" el proyecto para añadir o eliminar estos ficheros, pero como es una interfaz gráfica que se maneja con ratón, en lo personal siento que me manejo mucho más rápido con el teclado que con el ratón (me gusta usar puro Alt+Tab, Alt+Repag, Ctrl+AvPag, Shitf+F10 y cosas por el estilo). Por eso es que todo lo hago por la cónsola y por supuesto compilar mis proyectos de C es una de esas actividades.

Por otra parte, ¿qué son las IDE's gráficas sino una interfaz con un script o conjunto de comandos corriendo detrás? Siendo así, prefiero ir de una vez a los comandos y saltarme lo visual, jeje

Aquí mismo para meter texto en negrita, o hacer los codes, prefiero escribir las etiquetas a mano (\[ b \], \[i\], etc) que pulsar el iconito, no se ... me parece maś rápido ....

Ahora, en lo de hacer scripts de compilación tienes razón, últimamente he estado preparando ficheros Make para facilitar la tarea ...

Pero hasta para compilar un ejemplo pequeñito (como problemas pequeños que plantean usuarios de aquí y quiero probar compilando en realidad) apelo a mi gcc/g++ y cónsola, no se ..... es un hábito que se me ha quedado.

Es la ventaja de Linux, que todo lo puedes hacer con el teclado, incluso configurar tu fichero fstab para montar y desmontar las unidades externas usb manualmente. La última vez le quité los permisos de ejecución al nautilus para obligarme a navegar por directorios usando exclusivamente la consola y dejar de usar el explorador gráfico que ya me fastidia (jeje), ...... Quién sabe, a lo mejor un día te quedas sin escritorio gráfico (una vez me pasó) y luego ¿cómo vas a hacer?  

Bueno pero como decimos son cosas de gustos y filosofías, cada quién tiene la suya  

Creo haber explicado la razón por la que hago las cosas de ese modo, y al mismo tiempo he tomado tiempo para describir una parte de mí, no se si en este foro hay una sección para los usuarios hablar de sí mismos, sus gustos, formas de trabajo, etc ...

[x64core]

Interesante, Programador C/C++,Scripting y como no, amante de Unix/Linux. Cómo es que no me extraña que un recién
usuario creado tenga tal conocimiento ( No por que sea un usuario de pocos 'posts' ), esa manera para desenvolverse
aquí en el foro, etc. Pero es bueno mirarte por aquí...

Y sí, ya esto es gusto de cada quien, yo en lo personal, mi entorno es Windows y dependiendo del proyecto que quiero
compilar uso el IDE, sino para proyectos pequeños ( pruebas de códigos, pequeñas clases, snippets, códigos de usuarios
del foro, etc. ) llamo a un pequeño programa que programé, el cual recibe como comando la ruta de archivo(s) fuentes,
cabeceras, archivos de recursos, [Liberarías adicionales] y crea un script en cual contiene las rutas relativas de los archivos.
sí, es un tipo de make pero me facilita más el trabajo a tan solo un click. La creación de este script además me permite
modificar/agregar/elimar parámetros hacia el compilador y linker ( Tipo de generación de código, Modificar valores de la cabera
del ejecutable generado, Tipo de optimización, conjunto de instrucciones, etc ).

Y bueno, mucho de que hablar.

[Yoel Alejandro]

Jaja, la verdad es que tengo tiempo programando (varios años), y no sólo en C, también he hecho scripts en Matlab, Assembler, VisualBasic y aplicaciones en el mini-VB que viene integrado con el Excel (estos últimos los dejé por lo limitado que eran).

Pero recién ahora fue que decidí ingresar a un foro para interacturar con otros miembros de la comunidad.

Respecto a los proyectos en C ¿te has animado a hacer alguna biblioteca/librería COMPLETA y lista para usar, y liberarla en la comunidad? Los fuentes por supuesto, más las instrucciones para su compilación e integración al sistema del usuario.

Yo estoy trabajando en una sencilla biblioteca de matrices bidimensionales numéricas, con clases y métodos predefinidas, donde el usuario declare el tamaño y ya se cree la matriz, además pueda redimensionarla en tiempo de ejecución (no que sea estática). Y de regalo, las operaciones algebraicas de sumar y multiplicar matrices, y quizás ....... resolver sistemas de ecuaciones jeje.

Yo doy por sentado que eso ya debe existir, y quizá muchas versiones de lo mismo, pero yo quiero hacer la mía y además con fines didácticos, liberar el código a la comunidad y explicar por qué se escribe esto y lo otro, etc  

[Yoel Alejandro]

rir3760, gracias por la explicación. Se me ocurre también otra forma en que la verificación manual sería necesaria (aparte de si el fichero se abre en binario), si por ejemplo el usuario que creó el txt dejó dos saltos de línea sucesivos (o sea, con una línea en blanco), entonces el programa lee '\n' y se detiene. La otra línea será sólo '\n' por lo que devolverá búfer vacío.

Si verificamos con CR-LF no pasa esto porque al encontrar la secuencia CR+LF+CR+LF él recorrerá hasta el último LF antes de salir.

Claro, otra forma de hacerlo sería incorporar la instrucción *buffer = '\0'; al inicio de la función readLine, de modo esté programado para devuelver un búfer vacío por defecto. Entonces, si devuelve vacío sabemos que había una línea en blanco (o saltos de línea repetidos), e invocamos otra vez a readLine

No se ..... tengo la sensación de que preguntar por '\n' y que fgetc se encargue de la conversión en cada tipo de sistema hará el programa más portable, pero por otra parte decodificar a mano hará el programa más seguro ...

¿Qué tal si alguien llenó el txt manualmente y puso una secuencia extraña tal como CR + LF + CR (o sea, una cantidad impar, ni dos ni cuatro)? ¿Qué me garantiza que fgetc() sabrá hacer "lo correcto" en este caso?

[rir3760]

si por ejemplo el usuario que creó el txt dejó dos saltos de línea sucesivos (o sea, con una línea en blanco), entonces el programa lee '\n' y se detiene. La otra línea será sólo '\n' por lo que devolverá búfer vacío.

Si verificamos con CR-LF no pasa esto porque al encontrar la secuencia CR+LF+CR+LF él recorrerá hasta el último LF antes de salir.

Entonces entras en un problema de diseño: tienes una función que se llama "ReadLine" pero esta no lee una sino un numero variable dependiendo de las lineas en blanco.

Si tomamos la biblioteca estándar de C como ejemplo estas solo leen lo necesario, nada mas. De no hacerlo habría problemas para procesar un stream ya que, a criterio de las funciones, se descartarían caracteres.

¿Qué tal si alguien llenó el txt manualmente y puso una secuencia extraña tal como CR + LF + CR (o sea, una cantidad impar, ni dos ni cuatro)? ¿Qué me garantiza que fgetc() sabrá hacer "lo correcto" en este caso?

Nada pero en ese escenario tendrás problemas no solo con tu programa sino con cualquier aplicación que espere los avances de linea de una forma mientras que en el archivo se indican con otra (si tienes Linux debes conocer aplicaciones como unix2dos y dos2unix que se encargan de la conversión).

Un saludo