|
|
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 - Eternal Idol
Páginas: 1 ... 15 16 [17] 18 19 ... 205
401
« en: Sábado 24 de Octubre de 2009, 19:23 »
Ah, tiene la obligacion, es decir que como imagine desde un principio esto es una TAREA y no una duda. Bueno, intente hacer lo que le dije, y podra ver cual es el valor de cs.
402
« en: Sábado 24 de Octubre de 2009, 19:13 »
SIGIO (which is not specified in POSIX.1-2001) is ignored by default on several other Unices. http://linux.die.net/man/7/signalSIGIO is somewhat more complex than SIGPIPE. First, a call to ioctl() to request the enabling FIOASYNC is required to enable generation of this signal. Second, another call to ioctl() is required to request SIOCSPGRP, which sets the target process group. A target process group is either a process (specified by a positive process id) or a process group (specified by a negative process id). http://docs.hp.com/en/32650-90372/ch02s14.htmlSi lo anterior no funciona (los ioctl's) por lo que pude entender del libro "UNIX Programacion Avanzada" SIGIO es una señal que aparecio en BSD y puede que necesites usar la funcion que aparecio para las señales que incorporaron: sigvec.
403
« en: Sábado 24 de Octubre de 2009, 19:05 »
Bien, igual no entiendo como a alguien le puede interesar un detalle (irrelevante si se me permite) del funcionamiento interno de un S.O. arcaico y obsoleto como MS-DOS.
Haciendo un programa que ejecute a este y depurando al primero deberias poder comprobar si tus calculos son correctos.
404
« en: Sábado 24 de Octubre de 2009, 18:16 »
De nadas 
406
« en: Sábado 24 de Octubre de 2009, 16:07 »
Efectivamente el problema esta en otra parte, si un programa le pasa un puntero erroneo a tu libreria no hay mucho mas que hacer ademas de capturar la excepcion pero es preferible no hacerlo y que el programa muera en lugar de enmascarar el problema real. http://stackoverflow.com/questions/5510 ... lidity-c-c
407
« en: Sábado 24 de Octubre de 2009, 15:49 »
Si tenes un puntero invalido lo mas probable es que haya un problema en otra parte del programa ... ¿Para que quers hacer esto?
408
« en: Sábado 24 de Octubre de 2009, 14:47 »
¿Es una duda realmente? Usa debug.exe y fijate ...
409
« en: Jueves 22 de Octubre de 2009, 19:38 »
No, no es standard, supongo que es parte de esa API que menciono su- y MinGW tiene la costumbre de usar la CRT del VC++. En la MSDN. No logro que haga el enlazado pero asi deberia compilar:
410
« en: Jueves 22 de Octubre de 2009, 10:15 »
Si estas en una maquina de 64 bits, si que puede... en 32 bits se supone que tambien, no se si en el Glibc actual arreglaron el problema, pero aqui lo documentan muy bien. Si, pero en una de 32 bits no, el standard no lo soporta. Ahi lo que documentan es la API que tiene las funciones esas que terminan en 64 (ftello64 por ejemplo esta mencionada) pero no son standard. Me explique mal 
stat si es estandar, pero stat64 no lo es. Exacto, no hay funcion standard que te sirva para obtener el tamaño de un archivo de mas de 4GB en un Windows o GNULinux de 32 bits, de una manera u otra tenes que recurrir a funciones no standard (VC++ soporta _stat64 por cierto, con guion bajo por no ser standard).
411
« en: Miércoles 21 de Octubre de 2009, 23:15 »
De nadas Las funciones de la API estan declaradas en windows.h (o en alguna otra cabecera que esta incluya directa o indirectamente), por ejemplo MessageBox sera MessageBoxA sino esta definido UNICODE/_UNICODE y MessageBoxW si lo esta. Extracto del SDK: WINUSERAPI int WINAPI MessageBoxA( __in_opt HWND hWnd, __in_opt LPCSTR lpText, __in_opt LPCSTR lpCaption, __in UINT uType); WINUSERAPI int WINAPI MessageBoxW( __in_opt HWND hWnd, __in_opt LPCWSTR lpText, __in_opt LPCWSTR lpCaption, __in UINT uType); #ifdef UNICODE #define MessageBox MessageBoxW #else #define MessageBox MessageBoxA #endif // !UNICODE
412
« en: Miércoles 21 de Octubre de 2009, 19:37 »
No se hacen tareas.
413
« en: Miércoles 21 de Octubre de 2009, 18:31 »
Si, deberias hacerlo.
414
« en: Miércoles 21 de Octubre de 2009, 17:56 »
col sigue siendo un puntero nulo ............................. lo primero que hara strlen es *col para ver donde termina la cadena .....
415
« en: Miércoles 21 de Octubre de 2009, 17:27 »
Esto ya esta mal:
int tam=strlen(col)+1;
Ahi si le pasas NULL hay una excepcion como te dije, no es una cadena es un puntero nulo ...
416
« en: Miércoles 21 de Octubre de 2009, 17:25 »
yo lo que suelo hacer para portabilidad es usar el patrón factory y crear una clase para win32 y otra para unix. Una buena solucion para C++  entonces simplemente uso la api en uno y la stat en el otro. ¿Pero stat no es capaz de devolver el tamaño de un archivo de mas de 4GB, verdad?
417
« en: Miércoles 21 de Octubre de 2009, 14:57 »
De nadas
418
« en: Miércoles 21 de Octubre de 2009, 14:53 »
Si en el constructor estas haciendo simplemente una asignacion a un puntero a char entonces esta claro, tendras un puntero nulo y si lo desreferencias dara una excepcion ... podes pasale una cadena vacia "" en lugar de NULL ... o tener un buffer estatico ... hay varias formas de solucionarlo digamos.
419
« en: Miércoles 21 de Octubre de 2009, 13:46 »
No sé... creo que no estaria un buena idea de hacer un kernel de un s.o. en c++. O habra que hacer tantas partes en C o assemblador que al final no quedara mucho c++. Windows no tiene practicamente, por no decir ninguna aunque estoy casi seguro, ni una linea de assembly en el Kernel (hay algunas en el HAL eso si, fue diseñado de tal manera que el Kernel fuera portable). Muchas cosas se podrian expresar mejor en C++, se ahorrarian bastante codigo ... al menos esa es mi experiencia despues de escribir modulos de modo Kernel (drivers) para Windows en C y C++. El c++ tiene una capa mas que el c, y para cosas que tienen que ser muy muy rapidas, y dependiente de la architectura (procesador, hw en general) el c es mejor.
Mira, cuando hablaba de videojuegos, hay partes que son hechos en C (o en scripts como dices), las partes mas "criticas" digamos, pero en forma de libreria independientes. No, C no es mas rapido que C++ de por si, todo depende las caracteristicas que uno use de C++ y del compilador, no te olvides que llevan años mejorando la optimizacion y no existe ninguna razon por la cual C++ tenga que ser mas lento que C, especialmente cuando podes escribir codigo que en realidad sea C.
420
« en: Miércoles 21 de Octubre de 2009, 12:51 »
¿Cual es el error exacto? Cuanto mas informacion (como una minima expresion compilable del codigo) des mas posibilidades habra de que te ayudemos.
421
« en: Miércoles 21 de Octubre de 2009, 12:49 »
Por ejemplo, si tengo que hacer un pequeño progama que verifica, cada x secundos, si hay un fichero en una carpeta dada, y si hay un fichero, hace un par de copias de este fichero en otras carpetas, lo voy a hacer en C. Un main() de 20 lineas y basta.
Para hacer un videojuego de tipo word of warcraft, es impensable hacerlo en C. Se puede resolver el mismo problema con C perfectamente y en la practica muchas veces lo son (otra cosa es que sea preferible, yo me quedo con C++). Los videojuegos suelen usar internamente scripts, esto lo hacian ya en los Monkey Island de principio de los 90s con engines escritos en assembly para 16 bits. Sin ir mas lejos la amplisima mayoria de los Kernels, de los S.O. modernos, como Windows o Linux, y sus drivers estan escritos en C, son de una gran complejidad y pueden ser escritos en C++ tambien. Si vale, pero digo en la manera de programar. De vez en cuando, tengo que hacer un poco de php, y me da igual que sea interpretado o compilado. Lo que veo es que el codigo resultante es muy parecido al C. Es en este sentido que hablaba. Son otros paradigmas si ... PD. goto y void* se usan en C++, lo que no podes hacer son castings implicitos como los tipicos de malloc.
422
« en: Miércoles 21 de Octubre de 2009, 12:33 »
El punto 4 no se como lo podes justificar. Y PHP es un lenguaje interpretado ...
423
« en: Miércoles 21 de Octubre de 2009, 08:43 »
Si no hay funcion standard entonces da lo mismo usar un servicio de un S.O. en particular (ademas que estos suelen ser mas potentes y con #ifdef se soluciona cualquier problema de portabilidad del codigo).
424
« en: Martes 20 de Octubre de 2009, 23:11 »
Los #define tienen que estar antes del #include de windows.h para que funcione. #define UNICODE #define _UNICODE #include <windows.h> #include <tchar.h> int WINAPI WinMain(HINSTANCE actual, HINSTANCE previa, LPSTR parametros, int cmd) { MessageBox(NULL, _T("cual"), NULL,0); }
425
« en: Martes 20 de Octubre de 2009, 22:58 »
¿Esa funcion es standard? Sino lo es entonces es un codigo poco elegante ...
Páginas: 1 ... 15 16 [17] 18 19 ... 205
|
|
|
Mostrar Mensajes
