Mensajes

Utilizando solo C o C++ no es posible. La única solución es utilizar una biblioteca de terceros (como en tu ejemplo) o bien el API del sistema operativo (Mas información en MSDN: Consoles).

Un saludo

El problema se debe a la sentencia:

Código (c) [Seleccionar] Expandir

char * datos="";
En ella declaras el puntero "datos" que utilizaras en la llamada a "read", el problema se debe a que ese puntero:
1) Apunta a una cadena literal y estas no deben modificarse.
2) Aun cuando fuera posible el array solo tiene capacidad para un elemento (el '\0').

Si vas a leer cien caracteres puedes simplemente declarar un array con esa capacidad y pasarlo a la función.

Y para conocer el tamaño en bytes del archivo si estas utilizando Linux (como parece ser el caso) puedes utilizar la función stat.

Un saludo

[leosansan]

No me ha dado ningún error al compilarlo pero me imagino que estaré haciendo una burrada así que espero que me ayuden.

Los errores son dos y se encuentran en el bloque "else" del condicional, estos son la falta del operador '&' en la llamada a "fscanf" y el uso del operador de asignación '=' cuando debería ser el de comparación "==". Esa parte con las correcciones:

Código (c) [Seleccionar] Expandir

}else {
   while (fscanf(f, "%c", &c) != EOF)
      if ((c == 'z') || (c == 'Z'))
         x++;
}

Ademas declaras dos variables de tipo "FILE *" cuando solo necesitas una, puedes eliminar la variable "s" sin problemas.


En cuanto al programa de leosansan hay que tener cuidado cuando se utilizan las funciones "getchar", "fgetc" y "getc" ya que su tipo de retorno no es "char", es "signed int". Ello porque esas funciones deben retornar el carácter (puede ser cualquiera) mas un valor único para indicar el estado de fin de archivo (EOF).

En buen cristiano hay que cambiar el tipo de la variable "c", mas o menos así:

Código (c) [Seleccionar] Expandir

int c;

/* ... */

while ((c = getc(fichero)) != EOF)
   if (c == letra || c == LETRA)
      nletra++;

Un saludo

[si se viola una de sus reglas]

cPor qué no pruebas a correr el código que expuse?.

Porque eso es lo peor que se puede hacer en este escenario. C no es un lenguaje con "rueditas" y debido a sus reglas "tasajear" código para en base al resultado sacar conclusiones no es una buena idea. Lo explico mas adelante.

¿No será que "quieres decir otra cosa?

No, estas leyendo de mas en mis mensajes.

porque decir que no "funciona" cuando sí funciona es erróneo.

Cuando se trata del lenguaje C y sus estándares hay que ser muy cuidadoso con el lenguaje (con el otro, me refiero al español).

Yo no dije que en tu caso el programa no funcione correctamente, eso lo podemos dar por un hecho. Yo indique que es un error. Voy a explicar con mas detalle.


El estándar de C define el lenguaje y el comportamiento que tendrán los programas desarrollados con el pero, si se viola una de sus reglas, se genera "comportamiento no definido". Si revisamos uno de los últimos borradores (N1124) del estándar C99 tenemos:

6.5.2.2  Function calls

[...]

2 If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters.

[...]

6  If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined.

En base a esa parte podemos concluir que, si se llama a la función "srand" sin argumentos cuando su prototipo (cortesía de <stdlib.h>) indica que se debe pasar uno, se genera comportamiento no definido.

¿Porque es un error? Porque, como su nombre sugiere, una vez se genere el comportamiento no definido (en nuestro caso con la llamada a "srand") ya no hay garantías sobre el comportamiento del programa.

Cualquier cosa puede pasar, por ejemplo el programa:
* Funciona correctamente.
* Genera resultados inesperados.
* Simplemente revienta.
* etc.

Y ese es el problema: el compilador se "lava las manos" y lo que sea que resulte del programa es responsabilidad de programador (por violar las reglas del lenguaje).


Otro ejemplo, por desgracia común, es el uso de "fflush(stdin)". El estándar define el comportamiento de la función pero solo para streams de salida. Si se trata de un stream de entrada (como es el caso de "stdin") y como el estándar no define el comportamiento en ese caso se genera ...

Pero te recuerdo que la duda era otra, ésta en concreto:
Respuesta a:

EDITO 2: Me surge otra pregunta, utilizar srand() sin semilla y srand() pero con una semilla que no cambie, es realmente lo mismo no?

SI, puedes ponerla sin semilla así "srand()" o con semilla, así  "srand(15)" y en ambos casos se genera el mismo juego de números aleatorios.

Espero ahora se entienda mejor: utilizar "srand()" es un error ya que no se puede garantizar el comportamiento del programa a partir de ese punto.

Un saludo

Pues como había dicho, acabo de compilar el programa con:
Lcc-win32
Pelles C
Dev-C++ (utiliza MinGW)
CygMing (la version 3.X y 4.X de gcc para Cygwin)

Y con todos ellos el resultado es el esperado:

Código [Seleccionar] Expandir

3.141590 3490
The above line contains 13 characters.

La única recomendación que puedo darte es instalar el IDE de nuevo y verificar que este configurado correctamente, para eso alguien mas deberá ayudarte (no tengo instalado Code::Blocks).

Un saludo

[requiere]

Me surge otra pregunta, utilizar srand() sin semilla y srand() pero con una semilla que no cambie, es realmente lo mismo no?

No.

La función "srand" requiere de un argumento, llamarla como indica leosansan (sin argumento) es un error.

Un saludo

[completo]

¿Que compilador estas utilizando?
¿Puedes publicar el código fuente completo del programa que esta dando resultados incorrectos?

Un saludo

[completo]

Primero la pedanteria: no se recomienda el uso de "gets", las razones se describen en el tema |Lo que no hay que hacer en C/C++. Nivel basico|.

En cuanto a tu programa lo mejor es que publiques su código fuente completo.

Un saludo

Hay que tener mucho cuidado con las afirmaciones que se hacen ...

Lo que expuse en el anterior post es que ese formato no es "aconsejable" ya que depende del compilador que cada uno use.

Honestamente no se donde leíste eso. No recuerdo un documento donde se desaconseje su uso, lo cual es entendible ya que el especificador "%n" es parte del estándar de C desde 1989.

Ya comente que en Code::Blocks no funciona, pero tampoco en Dev-C++, etc, sin embargo en el tal vez menos conocido Pelles C  sí da las salidas esperadas.

Acabo de compilar el programa:

Código (c) [Seleccionar] Expandir

#include <stdio.h>

int main(void)
{
   int numChars;
   float a = 3.14159;
   int b = 3490;
   
   printf("%f %d%n\n", a, b, &numChars);
   printf("The above line contains %d characters.\n", numChars);
   
   return 0;
}
Con los compiladores Pelles C, Lcc-win32, MinGW (cortesía de Dev-C++) y CygMing (las versiones 3.X y 4.X de gcc incluidas en el entorno Cygwin) y todos generan el mismo resultado:

Código [Seleccionar] Expandir

3.141590 3490
The above line contains 13 characters.

Un saludo

Como ves, si no es con array llegamos a punteros.
Más o menos, algo así:

Código (c) [Seleccionar] Expandir

#include <stdio.h>

/* ... */

nombre = (char *)malloc (80*sizeof(char));

Tres comentarios en relación al programa:

1) Antes de utilizar la función "malloc" debes incluir su prototipo mediante la inclusión de <stdlib.h>.

2) No es necesario convertir el valor de retorno de "malloc" al tipo "apropiado", un valor de tipo "void *" puede almacenarse de forma directa en una variable de cualquier tipo (por supuesto siempre que el tipo sea un "puntero a objeto").

3) La multiplicación esta de mas ya que "sizeof(char)" siempre es igual a uno.

Un saludo