|
|
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 - Karman
51
« en: Lunes 14 de Mayo de 2007, 03:47 »
el problema es que tu else está "colgado":
#define suma(a,B) \
if(a>b) { \
a+b; \
else \ //<--- no está definido su contenido...
a; \
}
así funciona bien:
#define suma(a,B) \
if(a>b) { \
a+b; \
}else{ \
a; \
}
Aunque también podrías hacerlo sin los {}...
S2
52
« en: Miércoles 9 de Mayo de 2007, 16:31 »
ha... me olvidaba decir que no es la única forma de usarlo con DLL's o procesos externos... pero es la que tiene más aplicación práctica... ya que si la función se encuentra dentro del código principal... no haría falta llamarla de esta forma... y un poco fuera de esto, tb suele usarse con programación orientada a objetos para redireccionar una llamada a un determinado objeto... pero esa parte ya es bastante más complicada... je
53
« en: Miércoles 9 de Mayo de 2007, 16:24 »
Un ejemplo aún más claro??? haber... vos creás una DLL para monitorear el acceso a un determinado recurso, o para procesar determinado tipo de mensajes... supongamos acceso a internet (es el único que se me ocurre), el tema es que no queres estar preguntando todo el tiempo si un determinado usuario está intentando conectarce (por eso el uso de una DLL), pero no queres establecer el comportamiento (que hacer si fulanito se conecta) en la DLL, sinó en tu programa principal que tendrá un conjunto de factores para determinar que hacer.... veamoslo de otra forma: Programa principal <---------------> DLL La única forma (o mejor dicho, la mejor forma) de que tu programa pueda realizar esto es mediante una función CallBack, supongamos lo siguiente: Código principal: .... int Anteconexion(type arg1,type arg2,...,type argn){ //aquí vendría la implementación para cada caso... } ...
y en alguna parte del código: determinarcbf(&Anteconexion);
donde determinarcbf() sería una función de la DLL que permitiría la vinculación de ambos procesos... Dentro de la DLL if(ConnectionQuery)//func. invent. que detectaría si un usuario quiere conectarce pAnteconexion(arg1,arg2,...,argn);
como verás, en la dll se llama al puntero enviado por el programa principal que será quien decida que hacer, incluso la DLL podría tener en cuenta el valor retornado por la función pAnteconexion() y permitir o denegar la conexión... La principal ventaja de todo esto es la de poder definir una gama de comportamientos para distintos programas (si la DLL es utilizada por más de uno), en lo que es el entorno Windows es muy común, como te dije, la posibilidad de definir el compotamiento de cada ventana es lo más común... espero esta vez logres entenderlo... S2
54
« en: Miércoles 9 de Mayo de 2007, 05:21 »
Una funcion callback es una función que será llamada posteriormente por un ente externo al código principal (el sistema operativo, una dll o lo que sea), esto qué quiere decir? bueno, básicamente es una función que es definida pero nunca es llamada en forma directa sinó a travez de un intermediario (lo que mensioné anteriormente), un ejemplo simple de esto lo ves cuando programás en windows con el entorno de ventanas... cada ventana tendrá su función callback en la que definiremos el comportamiento de la misma, pero esta función no es llamada en forma directa por nosotros sinó por el sistema operativo cuando se produce algún evento que la involucre...  S2
55
« en: Miércoles 2 de Mayo de 2007, 03:51 »
no, justamente fwrite y fread sirven para escribir o leer arreglos de N elementos en un archivo, estas funciones permiten esta opción en el 3º argumento... fwrite (&xname, sizeof(xname),[B] 1[/B], fstream); fread(&xname, sizeof(xname),[B] 1[/B], fstream);
en este caso lo puse en 1 porque no sabía cuantos elementos querías leer o escribir... pero podes cambiarlo según lo que quieras hacer... S2
56
« en: Lunes 30 de Abril de 2007, 22:00 »
con fwrite y fread... te quedaría algo así: structtype xname;// que sería el nombre de tu estructura... fwrite (&xname, sizeof(xname), 1, fstream);
y para recuperar: fread(&xname, sizeof(xname), 1, fstream);
S2
57
« en: Lunes 30 de Abril de 2007, 02:32 »
un ejemplo? imaginate una casa (clase), en la que viven personas (objetos), los objetos (personas) pueden acceder a la casa(clase) en la que viven y modificar sus atributos(piezas por ejemplo), mientras que las personas externas (otros objetos o funciones externos a la clase) solo pueden acceder a ella a travez de los dueños (en la vida real uno invita al otro a que pase... pero pasalo por alto... jo), pero a su vez, las personas que la habitan(objetos) pueden modificar atributos de los demás habitantes de la casa(los otros objetos) siempre que le dejen hacerlo (de como implementes los métodos), es un poco colgado... pero con una de pastillas  se entiende mi ejemplo... jo S2
58
« en: Sábado 28 de Abril de 2007, 19:40 »
si porque es una variable de la misma clase, aunque no lo sea del mismo objeto...
S2
59
« en: Sábado 14 de Abril de 2007, 20:50 »
char op=0; for(;;;){ if(kbhit()) op=getch(); if(op){ switch(op){ case 'd': // se hace algo break; case 'i': // se hace algo break; case 'r': // se hace algo break; default:// no hacemos nada... break; } op=0; } //se ejecuta el código }
S2
60
« en: Viernes 13 de Abril de 2007, 03:48 »
fijate acá: CodeProjectS2 
61
« en: Martes 10 de Abril de 2007, 05:43 »
mirá... creo que la única solución sería traerla al frente a la ventana origen o posicionarla de forma que entre en pantalla, capturarla y volverla a posisionar en su posición original...
S2
62
« en: Sábado 7 de Abril de 2007, 09:43 »
Ok... tené razón... 
63
« en: Sábado 7 de Abril de 2007, 09:01 »
1º:.... con la frace " últimante C++ se ha acercado mucho a los lenguajes de muy alto nivel con las clases..." me refiero que utlizando ciertas librerías podes crear programas complejos con relativamente pocas líneas (a diferencia de usar C)...
2º: sea linkeado estático o dinámico... ocupan más memoria... o sea... da igual si es un solo archivo que pesa 4 mb o son 300 para un solo programa... la cosa es que es ineficiente para programas chicos... pero está... 0 ganas de gastarme...
S2
64
« en: Jueves 5 de Abril de 2007, 20:38 »
y es facil... arrancá la otra aplicación con tu programa mediante ShellExecute()... hay otra función pero no me acuerdo el nombre... je
S2
65
« en: Jueves 5 de Abril de 2007, 20:08 »
viste... 
66
« en: Jueves 5 de Abril de 2007, 20:06 »
Si es tan obvio entonces no se para que empezaste tu respuesta asi:
si programás bajo consola tb podes usar las siguiente funciones que son compatibles con DOS y creo que con UNIX tb...
porque sí... no tengo respuesta para eso... S2
67
« en: Jueves 5 de Abril de 2007, 20:02 »
El tipo e velocidad que busca el usuario no es dependiente del lenguaje, ese tipo de detalles pasan desapercibidos para ellos, ya otra cosa son aplicaciones mal codificadas que en el lenguaje que sea siempre serán lentas... pero a nivel tecnico de velocidad que diferencian a los lenguajes para ellos no existe.. salvo que el usuario final sea un cientifico utilizando aplicaciones de mision critica.
No es tán así... pero más adelante aclararé este punto... En el hopotetico caso que que la diferencia fuera de 100 veces en tamaño en memoria alli habria un problema, pero una diferencia de 100 veces el tamaño solo se daria en programas totalmente diferentes. Un usuario final ni siquiera sabe que es una librería.
1º la diferencia de 100 la pude observar cuando se programa con algunas librerías de C++ sobre todo... para que te des una idea... el clásico "helo world" (programas identicos en lo que hacen) en C con API's suele pesar al rededor de 25kb mientras que con otros lenguajes o incluso con C pero con el wxwidgets pesa al rededor de 3 a 4 mb... lo cual es para mi una diferencia notable a la hora de carga en memoria y ejecución... 2º lo de las librerías te lo decía porque muchas veces tube problemas con vbasic y sus librerías, porque para el que lo compila funciona perfecto, ahora cuando hay que llevarlo a otra máquina(sin visual basic instalado), se complica y de manera grosa(hablando como usuario)... Ese no es el motivo.
En parte si... sobre todo cuando tenes que programar los gestores de recursos(hardware, red, etc), ojo no dije que sea la única razón... pero es una que me dijeron mis profesores... No lo he comprobado pero lo dudo muchisimo.
no lo dudes tanto...  No, de hecho C++ es mas complicado que los lenguajes de mas alto nivel, pero tiene ventajas tecnicas grandes puesto que se puede decir que es el ultimo buen lenguaje de alto nivel que aun genera código de máquina.
últimante C++ se ha acercado mucho a los lenguajes de muy alto nivel con las clases... es algo que me gustó de wxwidgets... las pocas líneas que hay que escribir para hacer cosas complejas....
68
« en: Jueves 5 de Abril de 2007, 19:41 »
bueno... en el archivo de que tengo lo toma directamente como standart... capaz les faltó ponerle el "Pseudo"...
2º es obvio que si funciona en consola funciona en el modo GUI, pero no es del grupo de las funciones que windows define para trabajar en el modo GUI, es más en el MSDN no aparece... va... el que yo tengo por lo menos no...
69
« en: Jueves 5 de Abril de 2007, 19:32 »
opendir está definida en la librería "dirent.h" y según mi archivo de ayuda de librerías estándares de la GNU, es standart... S2
70
« en: Jueves 5 de Abril de 2007, 19:18 »
me refería a la consola de windows...
71
« en: Jueves 5 de Abril de 2007, 19:13 »
Respecto a que el usuario le interesa que el programa funcione es en parte cierto y en parte no... muchas veces (y sobre todo cuando hay competidores) el usuario busca velocidad, amigabilidad, etc, etc... si vos tenes dos programas que hacen lo mismo, uno te ocupa 100 veces más memoria, es más lento y requiere de muchas librerías... cuál usarías??? Esa es en parte la razón por la cual aun habiendo lenguajes de tan alto nivel se sigan empleando lenguaje de bajo nivel para siertas cosas...
2º En realidad lo que decis del lenguaje no es tan así, programar en C++ con las MFC se asimila bastante a los que es un ejecutable final en Visual Basic (hablo de tamaño de código y de los ejecutables finales)... el C/C++ no sirve solo para hacer programas con elevado número de operaciones matemáticas... sinó mas bien, para poder hacer cosas complejas como simples en un solo lenguaje, es quizás por esto que la mayoría de los programas de Microchot están escritos en C++...
S2
72
« en: Jueves 5 de Abril de 2007, 18:15 »
tene razón... pero me parece que había una función standart para emular kbhit()... tendría que reveer mis códigos fuentes... je
73
« en: Jueves 5 de Abril de 2007, 17:56 »
si programás bajo consola tb podes usar las siguiente funciones que son compatibles con DOS y creo que con UNIX tb... int findfiles(char *orig){ struct dirent *pfile;DIR *opdir; if((opdir=opendir(orig))==NULL){ printf("Acceso Denegado a %s\n",orig); return -1; } if((pfile=readdir(opdir))!=NULL){ do{ printf("%s\n",pfile->d_name); }while((pfile=readdir(opdir))!=NULL ); }return 0; }
S2
74
« en: Jueves 5 de Abril de 2007, 17:47 »
saliendo del multithread y todo eso... la opción mas simple (para la complejidad de tu ejercicio) es mediante la función getc ()... la cual la insertás dentro del bucle y no detiene la ejecución del programa hasta que el usuario presione una tecla (la que vos quieras que sea para parar, continuar, terminar, etc), lo podrías implementar más o menos así: for(;;;){ //acá vendría la implementación del cronómetro... if(getc (stdin)=='\n'){// el "/n" es la tecla enter break;//salis del bucle... } }
S2
75
« en: Jueves 5 de Abril de 2007, 17:32 »
[editado]
S2
|
|
|
Mostrar Mensajes
