|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - Amilius
Páginas: 1 [2] 3 4 ... 27
26
« en: Lunes 28 de Febrero de 2011, 20:11 »
Sigo manteniendo mi opinión de que string es mucho mejor que char*. Muy cierto, sin embargo una cosa es administración de memoria y otra es simplemente leer esa memoria en un algoritmo. En otras palabras es mejor dejar que la clase string se encargue de reservar y liberar la memoria de la cadena. Y, sólo cuando no hay a mano una función a medida de lo que necesitamos, usar c_str(). #include <iostream> #include <string> static int cuenta(const char *a); int main() { std::string cad; std::cout << "Digite una Cadena:" << std::endl; getline(std::cin, cad); std::cout << "Palabras: " << cuenta(cad.c_str()) << std::endl; getline(std::cin, cad); return 0; } static int cuenta(const char *a) { int c = 0; while (*a) { while (isspace(*a)) a++; c++; while (*a && !isspace(*a)) a++; } return c; }
27
« en: Sábado 26 de Febrero de 2011, 01:49 »
Tal vez esos parches soporten instalación silenciosa, claro, dependiendo del tipo de instalador. Si son MSI es casi seguro que la soportan. De esa forma sería posible que escribas un .bat para ejecutar esos instaladores.
28
« en: Jueves 24 de Febrero de 2011, 19:14 »
Una biblioteca gráfica debería permitirte acceder directamente a los datos con un puntero a cada fila. En DirectX puedes tener "superficies" donde la imagen entera está reservada en un bloque contiguo de memoria. Esto es más eficiente que acceder un pixel a la vez.
En lugar de usar bool para cada pixel en tu arreglo sería mejor que uses un entero de 32 bits para almacenar 32 pixeles a la vez (o 64 bits para AMD64). Luego es posible acceder a un pixel específico usando desplazamientos y máscaras. Esto reduciría el consumo de memoria del actual cercano a 1 MB a menos de 32 KB.
29
« en: Martes 15 de Febrero de 2011, 02:32 »
Simple: imprimirlo antes.
Como de antemano es posible saber si ya imprimiste un número (actualizando una variable "bool"), no imprimas un espacio antes del número si aún no imprimiste un número.
30
« en: Lunes 14 de Febrero de 2011, 16:51 »
Hola, la última versión del código B54 compila sin problemas con Delphi 6.
32
« en: Viernes 11 de Febrero de 2011, 20:34 »
Es más simple usando bitmaps con transparencia. Luego tendrías que conseguir de gráficos del tablero y las fichas, mejor si son ".png". Finalmente simplemente los dibujas en orden de atrás adelante.
33
« en: Jueves 3 de Febrero de 2011, 23:53 »
a ver si interprete bien dcis q debo crear un subprograma q asigne a una variable booleana si es fin de archivo ?????...ah otra cosa esta bie lee ants del bucle (ciclo)????
disculpa si mis preguuntas son medio pero ac poco empece a programar algo d un mes gracias x la respuesta!!!
PD:si leo luego de preg el fin de archivo(o sea dentro del while) se pierd el registro del medio Lo que dije es que primero preguntes por el final de archivo y luego leas. No tengo compilador de pascal a mano, pero esto debería funcionar: procedure actualizar(var socio:tsocio;var pago:tpago;var socion:tsocio); var rsoc,rnew:reg1; rpago:reg2;cuenta:word; begin clrscr;cuenta:=0; assign(socio,'c:userstomassocio.dat');assign(pago,'c:userstomaspago.dat');assign(socion,'c:userstomassocion.dat'); reset(socio);reset(pago);rewrite(socion); while(not(eof(socio)))and(not(eof(pago)))do begin read(socio,rsoc);read(pago,rpago); if rsoc.cod=rpago.cod then begin rnew:=rsoc; rnew.deuda[rpago.mes]:=0; write(socion,rnew);inc(cuenta); end end; writeln('se ingresaron',cuenta,'registros'); close(socio); close(pago); close(socion) end;
34
« en: Jueves 3 de Febrero de 2011, 22:24 »
No todas las implementaciones de eof() funcionan igual. Siendo que pascal fue bien pensado para manejar archivos tiene la mejor y más simple implementación: eof() retorna verdad si y sólo si estás en la posición final del archivo ¿O acaso tendría que ser de otra forma?. En otros lenguajes como C, C++ las librerías estándar implementan el eof de tal forma que es necesario ejecutar antes una operación de entrada/salida. En otras palabras implementan "Error, fin de archivo" en lugar de implementarlo correctamente como simplemente "Fin de archivo".
Por lo tanto en pascal primero tienes que preguntar si estás al final del archivo, si no es el caso entonces recién lees el registro.
35
« en: Lunes 31 de Enero de 2011, 20:38 »
El problema es que no estás reservando memoria y sigues con tu puntero en 0. Esa forma de llamar a un constructor hace que OTRO objeto sea creado en pila y destruido antes de ejecutar la siguiente línea.
36
« en: Viernes 28 de Enero de 2011, 23:45 »
Lo correcto es decir C++ soporta POO.
37
« en: Viernes 28 de Enero de 2011, 23:32 »
El problema está en el uso del constructor en tu operador '=', '+' y el método resize.
Tienes que modificar tu código para mover el código del constructor a resize. De tal forma que sólo tengas new y delete en la función resize. El destructor podría llamar a resize (0,0) para liberar la memoria. Si resize recibe un parámetro que sea 0 debería liberar la memoria y poner _data en 0.
38
« en: Viernes 28 de Enero de 2011, 23:18 »
No siempre, además que de no está garantizado que se "almacene" la dirección de memoria. Todo ello está a discreción del compilador. Por ejemplo, para casos muy simples como este: int a = 0; int& b = a; b++; printf("%i", b);
Un buen compilador puede determinar que el anterior código es equivalente a: int a = 0; a++; printf("%i", a);
que es más eficiente que: int a = 0; int* b = &a; (*b)++; printf("%i", *b);
39
« en: Jueves 27 de Enero de 2011, 20:53 »
Además te falta declarar un constructor que pueda inicializar "_res", de lo contrario no está garantizado que el resultado sea el esperado.
40
« en: Jueves 27 de Enero de 2011, 20:11 »
Es mejor decir simplemente "a es otro nombre para x".
Los detalles internos de implementación dependen del compilador que generalmente lo implementa como si hubieras usado punteros, pero es libre de implementarlo de otras formas.
41
« en: Jueves 27 de Enero de 2011, 19:22 »
Eso no es C++. Claro que si es. ¿O crees que es condición suficiente no usar clases para utilizar un compilador de C? Basta que uses al menos una característica introducida en C++ y ya no podrás usar un compilador que sólo soporte C. Por lo tanto es evidente que es código C++ aunque no utilices clases. En todo caso lo correcto es decir "Eso no es POO", que es muy distinto. Y por cierto si tienes conocimientos de la implementación de los mecanismos de POO es posible programar orientado a objectos usando sólo C.
42
« en: Jueves 27 de Enero de 2011, 14:51 »
Si programas en C++ no es obligatorio usar clases. Además existe la posibilidad de evitar complicaciones innecesarias y código menos legible al poder pasar parámetros por referencia/alias. Además que usar el par new/delete tiene la ventaja de hacer el código más breve: no es necesario un casting extra para new, y delete puede ser llamado sin necesidad de verificar el puntero. Si el puntero es 0 delete no realiza ninguna operación. (En todo caso siempre es necesario inicializar los punteros a 0. También es necesario poner a 0 los punteros ya liberados si existe riesgo que puedan ser nuevamente liberados.).
Otras ventajas que no implican directamente POO:
- No tienes que definir todas tus variables al inicio de tus funciones.
- Puedes usar templates en lugar de macros de preprocesador para operar con tipos genéricos.
- Sobrecarga de operadores y funciones.
Respecto a que es "difícil cambiar el chip" para pasar de estructurado a objetos es más un problema de enseñanza. Se debe usar objetos sólo cuando conviene usar objetos. No estoy para nada de acuerdo con los puristas que quieren meter objetos a todo lo que ven, son iguales a los que quieren meter patrones de diseño hasta para un "hello world".
Creo que la forma correcta de pasar de estructurado a objeto es mostrar un ejemplo más complejo, donde sea evidente las ventajas de pasar de estructurado a objetos. Es cuestión de convencer al alumno que POO les puede simplificar el trabajo en lugar de complicarlo. Luego para explicar a detalle recién se debería utilizar los ejemplos sencillos para cada aspecto de POO.
43
« en: Lunes 24 de Enero de 2011, 21:34 »
Respecto del punto 2: A menos que exista una buena razón siempre debes devolver una referencia al objeto, en lugar de un objeto. De lo contrario cada vez que retorne esa función llamará al constructor copia, haciéndola muy ineficiente. Objeto& Objeto::operator=(Objeto const &objeto1) { this->info=objeto1.info; this->info2=objeto1.info2; return *this; }
También es importante el "const" del parámetro "objeto1". Es bastante útil para que el compilador sepa que nuestra intención es no modificar el estado del parámetro. Sin embargo tienes que tener cuidado de declarar constantes los métodos que no modifiquen el estado de un objeto. Esto se hace agregando a la declaración del método un const inmediatamente después del cierre de paréntesis de parámetros. En casos especiales, como cacheo de acceso a datos, si necesitas modificar alguna variable en un método constante tienes que declararla como "mutable".
44
« en: Viernes 21 de Enero de 2011, 01:17 »
El archivo adjunto contiene una breve descripcion y codigo de shaders DX9 que funcionan con Media Player Classic (MPC).
Autor: Amilius
45
« en: Jueves 20 de Enero de 2011, 00:40 »
Pasa por que es lo que tiene que pasar. Si quieres que salga 146: #include <stdio.h> int main() { unsigned char runa3[4][4]; runa3[0][3]=146; printf("%dn", runa3[0][3]); return 0; }
46
« en: Viernes 14 de Enero de 2011, 22:44 »
FILE *f = fopen("Archivo.txt", "r"); if (f) // Siempre verifica que tus punteros sean válidos. { char linea[4];// NUNCA te olvides del carácter nulo de finalización de cadena int miarray[60]; for(int i=0; i<60; i++) { if(fgets(linea, sizeof(linea),f)) { miarray[i]=atoi(linea); } else { miarray[i]=1000; } } fclose(f); }
P.D. Deberías aplicar un corrector ortográfico a tus textos.
47
« en: Viernes 14 de Enero de 2011, 22:19 »
Aquí tienes un ejemplo usando std::string : #include <string> #include "stdio.h" int main() { const int MAX_CADENAS = 5; // Arreglo de tamaño definido en tiempo de compilación std::string cadena[MAX_CADENAS]; // Arreglo de tamaño definido en tiempo de ejecución int max_cadena2 = MAX_CADENAS + 3; std::string* cadena2 = new std::string[max_cadena2]; cadena[0] = "Primera cadena"; for (int i=0; i<MAX_CADENAS; i++) { printf("cadena[%i]:%sn", i, cadena[i].c_str()); } cadena2[max_cadena2 - 1] = "Ultima cadena"; for (int i=0; i<max_cadena2; i++) { printf("cadena2[%i]:%sn", i, cadena2[i].c_str()); } // Puesto que creamos el arreglo con new debemos destruirlo con delete[]. delete[] cadena2; return 0; }
48
« en: Viernes 14 de Enero de 2011, 21:51 »
Es bueno saber que aún existen programadores que no desean desperdiciar memoria(espacio) obscenamente. Sin embargo también es bueno evitar desperdiciar tiempo (de proceso) o hacer el programa innecesariamente complejo. Un byte por número me parece el punto de equilibrio ideal. Puedes ahorrar más espacio usando algoritmos de compresión, por ejemplo la biblioteca 7z. Pero esto sólo tiene sentido si tus datos ocupan varios MBytes, no vale la pena por 100 Bytes. De hecho para lograr el mínimo teórico tendrías que lograr comprimir esa información hasta alcanzar su estado máximo de entropía. Una forma simple sería calcular las diferencias (recodificación para hacer más evidente correlaciones en la información a comprimir) y luego aplicar un codificador de entropía como este: http://en.wikipedia.org/wiki/Huffman_coding. Datos originales : 1 , 2 , 4, 5, 7, 9, 12, 15, 16, 20 Diferencias(comenzando con 0): 1, 1, 2, 1, 2, 2, 3, 3, 1, 4 Si sólo exitieran 4 valores para las diferencias (1, 2, 3 y 4) el algoritmo huffman codificaría dichos números en 2 bits, ahorrando 75 bytes para ese caso muy particular. (En general asigna códigos de tamaño variable más chicos a elementos más frecuentes y códigos de tamaño variable más largos a los menos frecuentes). Sin embargo también es necesario guardar la tabla de traducción de nuevos códigos de 2 bits a sus originales de 8 bits (o el árbol de codificación que a veces ocupa menos espacio). También es necesario espacio para guardar la implementación del algoritmo necesario para descomprimir la información. Asi que por todo lo anterior no es práctico comprimir una cantidad de información tan pequeña, a menos que sea por fines puramente académicos.
49
« en: Martes 11 de Enero de 2011, 21:13 »
Queda mucho mejor de esta forma: char c; i = 0; while (i < 25) { printf("Introduce un elemento del arreglo: "); scanf("%c", &c); if ('#' == c) { break; } if (((c >= 'a') && (c <= 'z')) || ((c >= '0') && (c <= '9')) || ((c >= 'A') && (c <= 'Z'))) { vector[i] = c; i++; } }
50
« en: Miércoles 17 de Noviembre de 2010, 22:17 »
Siempre tienes que asegurarte que tu puntero apunte a un objeto antes de dereferenciar: Verifica que no es nulo y cuando destruyas el objecto haz que el puntero sea nulo. Por cierto basta con escribir "Compuesto c;" para declarar y construir el objeto. Compuesto c; const punto* p = c.mostrarALTOQ(); if (p) { printf("punto p es : %f", p->x); } else { printf("punto p indefinido"); }
Esos NULL no son necesarios, además como el método no cambia nada debería ser constante (const después del nombre del método) y es mejor que retorne un puntero a un punto constante para no modificar por accidente lo apuntado por PuntoI (const al inicio): const punto* Compuesto::mostrarALTOQ() const { punto *p = PuntoI; while (p) { printf("n(%f,%f,%f)n", p->x, p->y, p->z); p = p->sig; } return PuntoI; }
Páginas: 1 [2] 3 4 ... 27
|
|
|
Mostrar Mensajes
