[opensuse-es] [OT] Libritos sobre Python
Todavía tengo una seria confusión respecto a lo que debe de ir en la lista. Por eso le puse [OT]. ¿Qué es? Recopilación de manuales de Python, según el artículo de Ars Technica: http://arstechnica.com/news.ars/post/20081202-getting-a-grip-on-python-six- ways-to-learn-online.html Google está apostando por este, y como viene incluido en Linux,pues hay que distribuir conocimiento. =P Espero que les aproveche. =) Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++? -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-03 a las 10:25 -0500, Shinji Ikari escribió:
Todavía tengo una seria confusión respecto a lo que debe de ir en la lista. Por eso le puse [OT].
Es un lenguaje usado en linux, así que yo no lo veo OT.
¿Qué es? Recopilación de manuales de Python, según el artículo de Ars Technica: http://arstechnica.com/news.ars/post/20081202-getting-a-grip-on-python-six- ways-to-learn-online.html
Ah, pues pa'apuntarlo :-)
Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++?
Ni idea, y menos con el gcc, no le sigo la pista. Si lo instalas, en el suse viene un directorio con libros. Antes incluso había un directorio con libros en español, pero lo quitaron. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk2qzsACgkQtTMYHG2NR9WdGACggIYm4sgDrq65RJWHwj9IUX3d nBwAniesxd92zpKYGR9A7Assuup7rsck =3KrT -----END PGP SIGNATURE-----
On Wednesday 03 December 2008 10:52:24 Carlos E. R. wrote:
El 2008-12-03 a las 10:25 -0500, Shinji Ikari escribió:
Todavía tengo una seria confusión respecto a lo que debe de ir en la lista. Por eso le puse [OT].
Es un lenguaje usado en linux, así que yo no lo veo OT.
Jo, es que yo soy extremista, en una escala de 0 a 10, difícil que yo pueda quedarme en 5. =P Por ejemplo ahora estoy tentado a poner un OT respecto a la cierto artículo de phoronix sobre pruebas reales de ext4 que va a estar disponible con el kernel 2.6.28... lo están probando contra xfs. ¡Jo! vea, otra vez que me desvío y debería estar leyendo este librucho de administración. =/ Pero encaminándonos, parto que la lista es de openSuSE, por tanto los temas principales se deben de referir a esta distribución y los usuarios de esta distribución, temas distintos a eso pues son OT, por tanto el tema de los libros de python, el cual no es específico para openSUSE, ni tampoco se refiere a una necesidad actual (problema) de algún usuario, según este pechito, califica como OT. =P
¿Qué es? Recopilación de manuales de Python, según el artículo de Ars Technica: http://arstechnica.com/news.ars/post/20081202-getting-a-grip-on-python-si x- ways-to-learn-online.html
Ah, pues pa'apuntarlo :-)
Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++?
Ni idea, y menos con el gcc, no le sigo la pista.
He intentado con netbeans y con gcc, pero da el mismo error.. obvio por que netbeans usa gcc, luego Sun tiene su propio paquete, SunStudio, 12 creo, el cual no he conseguido instalar adecuadamente... se toma la libertad de instalar netbeans 5.5 (ya están en la 6.5). Habrá que investigar... apenas termine de leer este librucho. =/
Si lo instalas, en el suse viene un directorio con libros. Antes incluso había un directorio con libros en español, pero lo quitaron.
Otra cosa más por investigar. Por alguno de mis recursos warez, estaban dando Borland C++ 3.1, ese que va en DOS, vaya tiempos aquellos donde estaba aprendiendo programación por procedimientos y las cosas eran simples... todo tiempo pasado fue mejor =P Tal vez pueda emularlo o instalarlo en el VirtualBox con el XP. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Shinji> Por alguno de mis recursos warez, estaban dando Borland C++ 3.1, ese que va en Shinji> DOS, vaya tiempos aquellos donde estaba aprendiendo programación por Shinji> procedimientos y las cosas eran simples... todo tiempo pasado fue mejor =P Shinji> Tal vez pueda emularlo o instalarlo en el VirtualBox con el XP. Con VMWare y MSDOS 6 el Borland C++ funciona muy bien. Por Programación por procedimientos imagino que te refieres a lo que yo entiendo como programación jerarquizada (por funciones) en contrapartida a la programación "moderna" por objetos.
On Wednesday 03 December 2008 14:00:10 J.M.Queralt wrote:
Shinji> Por alguno de mis recursos warez, estaban dando Borland C++ 3.1, ese que va en Shinji> DOS, vaya tiempos aquellos donde estaba aprendiendo programación por Shinji> procedimientos y las cosas eran simples... todo tiempo pasado fue mejor =P Shinji> Tal vez pueda emularlo o instalarlo en el VirtualBox con el XP.
Con VMWare y MSDOS 6 el Borland C++ funciona muy bien.
Por Programación por procedimientos imagino que te refieres a lo que yo entiendo como programación jerarquizada (por funciones) en contrapartida a la programación "moderna" por objetos.
Voy a tener que desenterrar los diskettes de DOS, si es que los encuentro. Si no hay.. queda warez y bittorrent no mas. =P No recuerdo ahora el nombre de ese estilo de programación, ¿procedural? lo que si recuerdo es que las funciones eran las que devolvían un valor y los procedimientos no. Hacerlo en Pascal es sencillo, también en C. No llegue a profundizar mucho en POO, ni en Pascual ni en C++. =/ Según este artículo de Wikipedia: http://en.wikipedia.org/wiki/Programming_paradigm define procedural como lineal... =( Yo dividía el programa en procedimientos y funciones, no incluía todo en main. (paradigma lineal como Basic) =/ Jarl, que este post es completamente OT ;P~ -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Shinji> Voy a tener que desenterrar los diskettes de DOS, si es que los encuentro. Si Shinji> no hay.. queda warez y bittorrent no mas. =P No es necesario, en el propio web de VMWARE hay una máquina virtual en DRDOS con unos cuantos juegos para cuando te canses de programar. :-) El link: http://www.vmware.com/appliances/directory/126
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-03 a las 14:18 -0500, Shinji Ikari escribió:
Por Programación por procedimientos imagino que te refieres a lo que yo entiendo como programación jerarquizada (por funciones) en contrapartida a la programación "moderna" por objetos.
Voy a tener que desenterrar los diskettes de DOS, si es que los encuentro. Si no hay.. queda warez y bittorrent no mas. =P
No recuerdo ahora el nombre de ese estilo de programación, ¿procedural? lo que
Si, el nombre es procedural, y no es realmente "el antiguo". Una buena parte del linux está hecha así. Y tampoco es todo "procedural" u "orientado a objetos", hay otros sistemas. Incluso el "orientado a objetos" puede ser lineal si no lo juntas con sistemas de eventos y mensajes.
si recuerdo es que las funciones eran las que devolvían un valor y los procedimientos no.
Si, pero esa diferencia es del pascal. En C todo son funciones, lo que pasa es que puedes definirlas para que no devuelvan nada, y también puedes ignorar el valor de retorno.
Hacerlo en Pascal es sencillo, también en C. No llegue a profundizar mucho en POO, ni en Pascual ni en C++. =/
Según este artículo de Wikipedia: http://en.wikipedia.org/wiki/Programming_paradigm
define procedural como lineal... =( Yo dividía el programa en procedimientos y funciones, no incluía todo en main. (paradigma lineal como Basic) =/
Por dividirlo no deja de ser lineal. Ni siquiera por usar OOP, aunque lo parezca.
Jarl, que este post es completamente OT ;P~
¡En absoluto! - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk3GRoACgkQtTMYHG2NR9XChwCeOMGNJZCHmqaF/XZlMEToqzZT w9kAnjNOrCmrdKtl2zyRWT6kdf+biC9k =mGII -----END PGP SIGNATURE-----
El jue, 04-12-2008 a las 00:41 +0100, Carlos E. R. escribió:
Si, el nombre es procedural, y no es realmente "el antiguo". Una buena parte del linux está hecha así. Y tampoco es todo "procedural" u "orientado a objetos", hay otros sistemas. Incluso el "orientado a objetos" puede ser lineal si no lo juntas con sistemas de eventos y mensajes.
Me parece que le estais dando vueltas a nada. En mi opinión : Lo unico que cambia es la manera de enfocar el problema. Los sistemas orientados a objetos, lo unico que hacen es intentar modelar el problema. Los "procedurales"( suena horrible) interpretan el problema desde el lado del programador. Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema. Linux utiliza "casi" programacion orientada a objetos. Revisad bien el sistema de estructuras, pariente cercano del de clases. Los primeros compiladores orientados a objetos, solo eran un frontend del compilador habitual. Al fin y al cabo, el codigo maquina es el que es. Independientemente de los compiladores utilizados. La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-04 a las 00:54 +0100, lluis escribió:
El jue, 04-12-2008 a las 00:41 +0100, Carlos E. R. escribió:
Si, el nombre es procedural, y no es realmente "el antiguo". Una buena parte del linux está hecha así. Y tampoco es todo "procedural" u "orientado a objetos", hay otros sistemas. Incluso el "orientado a objetos" puede ser lineal si no lo juntas con sistemas de eventos y mensajes.
Me parece que le estais dando vueltas a nada.
En mi opinión :
Lo unico que cambia es la manera de enfocar el problema.
Los sistemas orientados a objetos, lo unico que hacen es intentar modelar el problema.
Sí, un intento más.
Los "procedurales"( suena horrible) interpretan el problema desde el lado del programador.
Igual que los OOP - aunque lo nieguen. ¡No van a estar orientados al usuario! El usuario no programador no tiene ni idea de qué hacer con un objeto.
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal.
Linux utiliza "casi" programacion orientada a objetos. Revisad bien el sistema de estructuras, pariente cercano del de clases.
El kde sí, pero el gnome, no.
Los primeros compiladores orientados a objetos, solo eran un frontend del compilador habitual.
Al fin y al cabo, el codigo maquina es el que es. Independientemente de los compiladores utilizados.
Obviamente.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal". Eso se presta muy bien a los programas que interactúan con el usuario, por ejemplo a un editor de texto, pero en cambio se presta mal si quieres hacer una tubería o un convertidor de formatos. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk3IjAACgkQtTMYHG2NR9UlRQCfUDd5AmHRcIvJ9y++MlZ00qWX JBsAn3Z+NROfyOzO6NynTNzKvMXhRObT =sQK4 -----END PGP SIGNATURE-----
El jue, 04-12-2008 a las 01:19 +0100, Carlos E. R. escribió:
Igual que los OOP - aunque lo nieguen. ¡No van a estar orientados al usuario! El usuario no programador no tiene ni idea de qué hacer con un objeto.
No es orientado al usuario, es orientado al problema a solucionar.
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal
No lo se, hace mas o menos 20 años que yo hago cosas que no coinciden con esa definicion. Me parece que no es asi.... Desde las epocas del Algol, no hay programas lineales a menos que sean de gestion.
Linux utiliza "casi" programacion orientada a objetos. Revisad bien el sistema de estructuras, pariente cercano del de clases.
El kde sí, pero el gnome, no.
El Kernel.
Los primeros compiladores orientados a objetos, solo eran un frontend del compilador habitual.
Al fin y al cabo, el codigo maquina es el que es. Independientemente de los compiladores utilizados.
Obviamente.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal".
Eso se presta muy bien a los programas que interactúan con el usuario, por ejemplo a un editor de texto, pero en cambio se presta mal si quieres hacer una tubería o un convertidor de formatos.
Ejem... Eventos imprevisibles... interrupciones. porque en el Hard son eso. A ver un procedimiento.. es una rutina.. son 40 instrucciones..es lo mismo. Un programa tiene una estructura secuencial o lineal por si mismo, dependiendo de si decide en funcion de su estado anterior. Repasar maquinas de estados finitos. Un programa, no es mas que una maquina secuencial, que puede o no depender de sus estados anteriores. Un convertidor de formato, es un programa con un unico evento... convertir
- -- Saludos Carlos E.R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkk3IjAACgkQtTMYHG2NR9UlRQCfUDd5AmHRcIvJ9y++MlZ00qWX JBsAn3Z+NROfyOzO6NynTNzKvMXhRObT =sQK4 -----END PGP SIGNATURE-----
-- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-04 a las 01:34 +0100, lluis escribió: Otro correo que no me llega por la cuenta principal.
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal
No lo se, hace mas o menos 20 años que yo hago cosas que no coinciden con esa definicion. Me parece que no es asi.... Desde las epocas del Algol, no hay programas lineales a menos que sean de gestion.
Que va. Se hacen por miles. Todos los scripts de bash son secuenciales, por ejemplo. Todos los programas en C (y algunos en c++) son secuenciales. Ten en cuenta que aunque tengan procedimientos, que aunque sigan estructuras de control, bucles, bifurcaciones... son secuenciales.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal".
Eso se presta muy bien a los programas que interactúan con el usuario, por ejemplo a un editor de texto, pero en cambio se presta mal si quieres hacer una tubería o un convertidor de formatos.
Ejem...
Eventos imprevisibles... interrupciones. porque en el Hard son eso.
No es lo mismo un evento que una interrupción. Una interrupción es bajo nivel, dispositivos, hardware. Un evento es alto nivel, y no necesariamente se correponde con una interrupción. Es algo asociado a programación orientada a objetos. Se trata de que al definir una función, un método, en su cabecera (o en un fichero auxiliar de definición de la interfaz), declaras que esa función ha de recibir el evento de "pulsar OK", que puede producirse por pulsar la tecla Enter, por pulsar "alt O", por hacer click sobre el rectangulito adecuado... esas tres cosas distintas producen el mismo "evento". El bucle de control del programa, o el sistema operativo, le pasa el control al programa, que hasta ese momento no estaba ejecutandose, y le dice: oye, que se ha producido un evento, y es este. Y una serie de funciones harán, por "arte de magia", que se llame al evento por defecto de la clase "dialogo" que responde al "OK", o al que lo ha heredado, o al que lo ha sobrecargado. Y no está relacionado con las interrupciones. A ver si nos entendemos. Yo no se si ahora a eso lo llaman de otra forma, yo lo aprendí como eventos, en la nomenclatura de Borland. En el windows son "mensajes". Y estos métodos manejadores de eventos son llamados fuera de secuencia de manera imprevisible, porque dependen de decisiones del usuario. Así, un programa típico en pascal tipo delphi o lazarus (o su equivalente en c++), sólo tiene esto en su "main": begin Application.Initialize; Application.CreateForm(TContador, Contador); Application.Run; end. A partir de que llamas a "Application.Run" ya no tienes ni idea de qué se va a ejecutar, ya no depende de tí. Bueno, si se sabe, pero no es tan simple. Se rompe la secuencia, ya no es "secuencial". Ni procedural. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk4pmIACgkQtTMYHG2NR9X7fgCcC58J0JJEUQ2+GweDWYWpaL1W p0gAni5cZoNGUaoHNh69YpMt9QD8wqh0 =m67K -----END PGP SIGNATURE-----
El vie, 05-12-2008 a las 04:56 +0100, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-12-04 a las 01:34 +0100, lluis escribió:
Otro correo que no me llega por la cuenta principal.
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal
No lo se, hace mas o menos 20 años que yo hago cosas que no coinciden con esa definicion. Me parece que no es asi.... Desde las epocas del Algol, no hay programas lineales a menos que sean de gestion.
Que va. Se hacen por miles.
Todos los scripts de bash son secuenciales, por ejemplo.
Si, y eso es un lenguaje de programación frecuentemente utilizado para aplicaciones complejas :-)
Todos los programas en C (y algunos en c++) son secuenciales.
No es verdad, dependiendo de como se programe no hay ningun motivo para hacer algo controlado por eventos en C.
Ten en cuenta que aunque tengan procedimientos, que aunque sigan estructuras de control, bucles, bifurcaciones... son secuenciales.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal".
Los eventos no son algo magico que nace en el programa, son sucesos exteriores( con alguna excepcion) que se tratan a partir de interrupciones en cualquier sistema decente. Puede haber excepciones, como el Timer del sistema, pero al fin y al cabo eso tambien es una interrupcion.
Eso se presta muy bien a los programas que interactúan con el usuario, por ejemplo a un editor de texto, pero en cambio se presta mal si quieres hacer una tubería o un convertidor de formatos.
Ejem...
Eventos imprevisibles... interrupciones. porque en el Hard son eso.
No es lo mismo un evento que una interrupción. Una interrupción es bajo nivel, dispositivos, hardware.
Un evento es alto nivel, y no necesariamente se correponde con una interrupción. Es algo asociado a programación orientada a objetos.
Si, vale, un evento es consecuencia de una interrupción tratada. No tiene porque estar asociado a POO.
Se trata de que al definir una función, un método, en su cabecera (o en un fichero auxiliar de definición de la interfaz), declaras que esa función ha de recibir el evento de "pulsar OK", que puede producirse por pulsar la tecla Enter, por pulsar "alt O", por hacer click sobre el rectangulito adecuado... esas tres cosas distintas producen el mismo "evento". El bucle de control del programa, o el sistema operativo, le pasa el control al programa, que hasta ese momento no estaba ejecutandose, y le dice: oye, que se ha producido un evento, y es este. Y una serie de funciones harán, por "arte de magia", que se llame al evento por defecto de la clase "dialogo" que responde al "OK", o al que lo ha heredado, o al que lo ha sobrecargado.
Y eso.... es precisamente a otro nivel, lo que hace una interrupción.
Así, un programa típico en pascal tipo delphi o lazarus (o su equivalente en c++), sólo tiene esto en su "main":
begin Application.Initialize; Application.CreateForm(TContador, Contador); Application.Run; end.
A partir de que llamas a "Application.Run" ya no tienes ni idea de qué se va a ejecutar, ya no depende de tí. Bueno, si se sabe, pero no es tan simple. Se rompe la secuencia, ya no es "secuencial". Ni procedural.
No, claro no es secuencial, al menos entendiendo por eso, la ejecucion lineal. Si es secuencial en el contexto de una maquina de estados. -- Saludos Lluis
El vie, 05-12-2008 a las 16:18 +0100, lluis escribió:
Todos los programas en C (y algunos en c++) son secuenciales.
No es verdad, dependiendo de como se programe no hay ningun motivo para hacer algo controlado por eventos en C.
Me autocorrijo, debe decir :
No es verdad, dependiendo de como se programe no hay ningun motivo para no hacer algo controlado por eventos en C. Ademas, como ejemplo, el uCosII, esta escrito en C, es un sistema operativo de tiempo real y esta controlado por Eventos( interrupciones). -- Saludos Lluis
On Wednesday 03 December 2008 19:19:59 Carlos E. R. wrote:
El 2008-12-04 a las 00:54 +0100, lluis escribió:
El jue, 04-12-2008 a las 00:41 +0100, Carlos E. R. escribió:
Si, el nombre es procedural, y no es realmente "el antiguo". Una buena parte del linux está hecha así. Y tampoco es todo "procedural" u "orientado a objetos", hay otros sistemas. Incluso el "orientado a objetos" puede ser lineal si no lo juntas con sistemas de eventos y mensajes.
Me parece que le estais dando vueltas a nada.
En mi opinión :
Lo unico que cambia es la manera de enfocar el problema.
Los sistemas orientados a objetos, lo unico que hacen es intentar modelar el problema.
Sí, un intento más.
O.O??!! Raíces de POO en los 60s, lo dice su artículo de Wikipedia, no le desprecien. http://en.wikipedia.org/wiki/Object-oriented_programming luego en el enlace que pase anteriormente mencionan otros paradigmas: http://en.wikipedia.org/wiki/Programming_paradigm muchos la verdad. Métodos para abordar un problema nunca faltan, algo por lo que hay que sentirse orgullosamente humanos. ;) Sin embargo la reutilización del código, herencia, me parecen características muy interesantes. Por ejemplo, un método para mostrar mensajes. Si uno es principiante, hace un método por cada mensaje que tenga que mostrar. =)
Los "procedurales"( suena horrible) interpretan el problema desde el lado del programador.
Igual que los OOP - aunque lo nieguen. ¡No van a estar orientados al usuario! El usuario no programador no tiene ni idea de qué hacer con un objeto.
El lusuario se confunde con muchas cosas, en la mañana leí de uno que exigió que se desconecte los cables de poder de los ordenadores para evitar que fugue información confidencial... y de otros con el posavasos para el portátil. El POO es una forma de abstraerse del problema, la cuestión, al menos para mi fue que en lugar de mostrarme que tenia que ir de lo grande a lo pequeño, se dedicaron de lleno a describir que es un objeto y las características de POO cuando no veía el problema de la programación procedural. =/
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal.
O.O?? bueno, somos lineales también, todo de golpe no nos puede entrar. Primero mecánica estática y luego la dinámica y antes de eso matemática, que siempre va a estar allí. Pero ojo que lo que dice aquí se puede confundir un poco con lo que dice después respecto a los eventos, el usuario al ser impredecible... como hacer un programa que no sea lineal. Suena confuso ¿no? No se en que parte exactamente leí respecto a la programación para ordenadores con varios procesadores. Apple sacará su siguiente versión enfocada en eso.
Linux utiliza "casi" programacion orientada a objetos. Revisad bien el sistema de estructuras, pariente cercano del de clases.
El kde sí, pero el gnome, no.
A mi me confunde un poco eso de los objetos, después de todo ¿qué es struct?, es un objeto al que se le pueden definir varias características (variables), pero no funciones... me he olvidado de muchas cosas. =( Lo primero que aprendí a leer fue Pascal, luego llego C para complicar las cosas. Algo que recuerdo también es cierta mención de un docente acerca de que se debería enseñar a programar orientado a objetos primero y luego los procedimientos. ¿Preferible aprender java primero y luego C?
Los primeros compiladores orientados a objetos, solo eran un frontend del compilador habitual.
Al fin y al cabo, el codigo maquina es el que es. Independientemente de los compiladores utilizados.
Obviamente.
O.O!! ¿entonces GCC sacaría el mismo resultado que el compilador de Borland o el de Metrowerks (Codewarrior, lo recuerdo cuando era maquero =P~)? Creo que Intel también está en esas cosas.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal".
Hmm, eso me recuerda cuando vi algunas líneas de programación para mac, los eventos tenían nombres propios, completamente relacionados con el OS. Una interrupción se referirá a algo de más bajo nivel, como Assembler supongo. No se mucho de programación en ambientes gráficos, pero supongo que es un marco que contiene los métodos para los eventos y los procedimientos y funciones que hace el programa, tal que el marco es el que se encarga de capturar los eventos y pasarlos a las funciones correspondientes que responden, y simultáneamente los procedimientos y funciones principales del programa se siguen ejecutando, como minimizar el navegador, mientras está cargando un página. Lo cual indica que estos tienen prioridad en la ejecución, por que mientras se está realizando alguna tarea, el usuario puede cerrar la ventana. Los tíos que hacen esas cosas son humanos ¿verdad? y si no es así, ¿donde hacen los implantes de cerebros positrónicos? =P
Eso se presta muy bien a los programas que interactúan con el usuario, por ejemplo a un editor de texto, pero en cambio se presta mal si quieres hacer una tubería o un convertidor de formatos.
Por eso salieron los IDEs y la programación visual, se aprovecha de las librerías u otros estándares establecidos con el OS o en nuestro caso el desktop, y así el programador solo se enfoca en las funciones principales. Hay mucho por estudiar. =/ -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-03 a las 20:36 -0500, Shinji Ikari escribió:
modelar el problema.
Sí, un intento más.
O.O??!! Raíces de POO en los 60s, lo dice su artículo de Wikipedia, no le desprecien. http://en.wikipedia.org/wiki/Object-oriented_programming
Si no lo despreciamos.
luego en el enlace que pase anteriormente mencionan otros paradigmas: http://en.wikipedia.org/wiki/Programming_paradigm
muchos la verdad. Métodos para abordar un problema nunca faltan, algo por lo que hay que sentirse orgullosamente humanos. ;) Sin embargo la reutilización del código, herencia, me parecen características muy interesantes. Por ejemplo, un método para mostrar mensajes. Si uno es principiante, hace un método por cada mensaje que tenga que mostrar. =)
No obstante, la reutilización del código no es una característica exclusiva de la POO. Puedes hacerlo perfectamente con programación estructurada, o secuencial. Y puedes también no reutilizar código con POO. Lo único es que se suele enseñar a reutilizar al enseñar POO, y que invita más a hacerlo, lo facilita. Sólo tienes que fijarte que los programas que usan POO son a menudo mucho mayores que los "normales", y más lentos, luego no están reutilizando y optimizando tanto los recursos como sus proponentes defienden. Las cosas no son tan meridianamente claras.
Los "procedurales"( suena horrible) interpretan el problema desde el lado del programador.
Igual que los OOP - aunque lo nieguen. ¡No van a estar orientados al usuario! El usuario no programador no tiene ni idea de qué hacer con un objeto.
El lusuario se confunde con muchas cosas, en la mañana leí de uno que exigió que se desconecte los cables de poder de los ordenadores para evitar que fugue información confidencial...
Lo cual es absolutamente cierto, y no es broma.
y de otros con el posavasos para el portátil.
Lo cual creo que es sólo una leyenda urbana.
Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o modularizar el problema.
Lineal sólo significa que el programa sigue una secuencia definida de sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás otra, detrás otra... en una secuencia definida; aunque lo dividas en procedimientos, funciones, o incluso objetos, la secuencia es lineal.
O.O?? bueno, somos lineales también, todo de golpe no nos puede entrar. Primero mecánica estática y luego la dinámica y antes de eso matemática, que siempre va a estar allí. Pero ojo que lo que dice aquí se puede confundir un poco con lo que dice después respecto a los eventos, el usuario al ser impredecible... como hacer un programa que no sea lineal. Suena confuso ¿no? No se en que parte exactamente leí respecto a la programación para ordenadores con varios procesadores. Apple sacará su siguiente versión enfocada en eso.
Me sospecho que no has pillado la diferencia entre programación secuencial o por eventos, o estructurada o orientada a objetos :-) secuencial: 1: abre el fichero 2: lee el primer campo 3: Procésalo (puede ser un procedimiento o un método) 4: repite hasta terminar el fichero 5: imprime los resultados. En ese programa se sabe exactamente lo que va a hacer, cuando, y en que orden: es secuencial. Por eventos: - procesar tecla <-- disparar si evento: pulsación de tecla 'Q' terminar programa. - procesar tecla <-- disparar si evento: pulsación de tecla 'C' cambiar color del reloj - avanzar reloj un segundo <-- disparar si evento: ha pasado un segundo - inicializar pintar un reloj en pantalla main: 1: decirle al sistema operativo que me mande eventos de tecla y de segundos 2: pintar reloj fin. Sólo la parte 1 y 2 se sabe cuando se ejecutan. Los tres métodos de procesar teclas o avanzar el reloj no se sabe en qué orden se van a ejecutar: no es secuencial, es casi aleatorio: depende de lo que haga el usuario, de eventos externos.
Algo que recuerdo también es cierta mención de un docente acerca de que se debería enseñar a programar orientado a objetos primero y luego los procedimientos. ¿Preferible aprender java primero y luego C?
Las opiniones son como el c..., cada uno tiene una -- que dijo cierto actor de manera un tanto bruta :-P
Los primeros compiladores orientados a objetos, solo eran un frontend del compilador habitual.
Al fin y al cabo, el codigo maquina es el que es. Independientemente de los compiladores utilizados.
Obviamente.
O.O!! ¿entonces GCC sacaría el mismo resultado que el compilador de Borland o el de Metrowerks (Codewarrior, lo recuerdo cuando era maquero =P~)? Creo que Intel también está en esas cosas.
No, no serán iguales.
La utilización de Eventos ( alias interrupciones) es comun a todas las formas de programación.
No, los eventos no son las interrupciones, eso es otra cosa. Son los eventos en OOP: se asocia un "método" a un determinado evento, que puede ser, por ejemplo, que el usuario hace click en la barra de tareas, o que selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta un "método", que no deja de ser una función con otro nombre. Como los eventos, que la mayoría son originados por el usuario, son imprevisibles, la secuencia de ejecución del programa es también imprevisible: es entonces cuando el programa deja de ser "secuencial" o "lineal".
Hmm, eso me recuerda cuando vi algunas líneas de programación para mac, los eventos tenían nombres propios, completamente relacionados con el OS. Una interrupción se referirá a algo de más bajo nivel, como Assembler supongo.
Tampoco, pero... bueno, algo parecido. Es más complejo de explicar, no voy a entrar en eso aquí. Es una funcionalidad del procesador.
No se mucho de programación en ambientes gráficos, pero supongo que es un marco que contiene los métodos para los eventos y los procedimientos y funciones que hace el programa, tal que el marco es el que se encarga de capturar los eventos y pasarlos a las funciones correspondientes que responden, y simultáneamente los procedimientos y funciones principales del programa se siguen ejecutando, como minimizar el navegador, mientras está cargando un página. Lo cual indica que estos tienen prioridad en la ejecución, por que mientras se está realizando alguna tarea, el usuario puede cerrar la ventana.
Puede haber eventos con prioridades (no te se decir seguro), pero lo normal es que se procesen en el orden en que llegan. Según como hayan hecho las cosas, se podrían ejecutar varios simultáneamente. O parecerlo.
Los tíos que hacen esas cosas son humanos ¿verdad? y si no es así, ¿donde hacen los implantes de cerebros positrónicos? =P
Eso en el aula de métodos complejos :-p - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk3Sj0ACgkQtTMYHG2NR9Ux1ACeKyNx9/3SImCf6PvgkJTgYB41 l5UAn39rsJlBwE8bvOyuM1Vk0qrjIyCT =Rm3s -----END PGP SIGNATURE-----
On Wednesday 03 December 2008 22:10:52 Carlos E. R. wrote:
El 2008-12-03 a las 20:36 -0500, Shinji Ikari escribió:
modelar el problema.
Sí, un intento más.
O.O??!! Raíces de POO en los 60s, lo dice su artículo de Wikipedia, no le desprecien. http://en.wikipedia.org/wiki/Object-oriented_programming
Si no lo despreciamos.
Pues vale, =P~ Sobre el enlace que pase, ya están un poco desfasados. Acaba de salir Python 3. O.O!! Enlaces y comentarios en /. y en Phoronix. http://developers.slashdot.org/article.pl?sid=08%2F12%2F04%2F0420219&from=rss http://www.phoronix.com/scan.php?page=news_item&px=NjkwMQ y claro en python.org, las cosas nuevas: http://docs.python.org/dev/3.0/whatsnew/3.0.html =) Habrá que esperar a openSuSE 11.2 o inclusive aún más para que se incluya. <snip>
No obstante, la reutilización del código no es una característica exclusiva de la POO. Puedes hacerlo perfectamente con programación estructurada, o secuencial. Y puedes también no reutilizar código con POO. Lo único es que se suele enseñar a reutilizar al enseñar POO, y que invita más a hacerlo, lo facilita. Sólo tienes que fijarte que los programas que usan POO son a menudo mucho mayores que los "normales", y más lentos, luego no están reutilizando y optimizando tanto los recursos como sus proponentes defienden. Las cosas no son tan meridianamente claras.
¿Mayores? Eso lo determina el programador, hay varios truquillos que sorprende verlos. =) La recursividad es peculiar y voraz, el clásico factorial es peligroso, bueno, eso me lo enseñaron en la U. Pero, a quien más le debe de preocupar los algoritmos y métodos son a los científicos. Su trabajo depende al 100% de eso. Ni que decir del tiempo que disponen para obtener resultados. Me pregunto como es que "hackean" al Seti para obtener resultados más rápidos,eso lo mencionan o mencionaban en la página de Seti. Supongo que la gente de Sun les seguirá apoyando. Luego hay que ver como ha variado la forma de programar estos años, se reutiliza código, el cual muchas veces no está muy optimizado y se arma cada gorda... el ejemplo está allí con el M$ Vista y su .net, ya les pasé ciertos enlaces acerca de .net y por que Apple está atrayendo cada vez más desarrolladores. (No es por la danza de desarrolladores de Ballmer, =P) <snip>
El lusuario se confunde con muchas cosas, en la mañana leí de uno que exigió que se desconecte los cables de poder de los ordenadores para evitar que fugue información confidencial...
Lo cual es absolutamente cierto, y no es broma.
preguntar por que salen estrellitas en lugar de la clave, ¿también es valido?
y de otros con el posavasos para el portátil.
Lo cual creo que es sólo una leyenda urbana.
O.O! He hecho algo helpdesk, y no llego a entender por que la gente no puede memorizar algunos pasos simples... o como leí... doblar un disco de 5 1/4 para que entre en el bolso y claro.. por que se les llaman flexibles. Odiaba cuando reseteaban los ordenadores solo con la intención de cerrar la sesión. Misantropía al máximo nivel: http://es.wikipedia.org/wiki/Misantrop%C3%ADa O como alguien escribió: "We cannot treat computers as Humans. Computers need love." No me extraña que exista el BOFH. Las historias son muy buenas, de lectura obligatoria para todo SysAdmin ;) <snip>
O.O?? bueno, somos lineales también, todo de golpe no nos puede entrar. Primero mecánica estática y luego la dinámica y antes de eso matemática, que siempre va a estar allí. Pero ojo que lo que dice aquí se puede confundir un poco con lo que dice después respecto a los eventos, el usuario al ser impredecible... como hacer un programa que no sea lineal. Suena confuso ¿no? No se en que parte exactamente leí respecto a la programación para ordenadores con varios procesadores. Apple sacará su siguiente versión enfocada en eso.
Me sospecho que no has pillado la diferencia entre programación secuencial o por eventos, o estructurada o orientada a objetos :-)
secuencial:
1: abre el fichero 2: lee el primer campo 3: Procésalo (puede ser un procedimiento o un método) 4: repite hasta terminar el fichero 5: imprime los resultados.
En ese programa se sabe exactamente lo que va a hacer, cuando, y en que orden: es secuencial.
Por eventos:
- procesar tecla <-- disparar si evento: pulsación de tecla 'Q' terminar programa.
- procesar tecla <-- disparar si evento: pulsación de tecla 'C' cambiar color del reloj
- avanzar reloj un segundo <-- disparar si evento: ha pasado un segundo
- inicializar pintar un reloj en pantalla
main: 1: decirle al sistema operativo que me mande eventos de tecla y de segundos 2: pintar reloj fin.
Sólo la parte 1 y 2 se sabe cuando se ejecutan. Los tres métodos de procesar teclas o avanzar el reloj no se sabe en qué orden se van a ejecutar: no es secuencial, es casi aleatorio: depende de lo que haga el usuario, de eventos externos.
O.O, ¿residentes en memoria como el antivirus? los eventos son parte del OS, y normalmente no se programa estas respuestas, están predeterminadas por el desktop. Lo mismo que la posición de los botones, por ejemplo, al usar software que hace uso de otro idioma, los botones siguen saliendo en el idioma del OS, aunque hay excepciones.
Algo que recuerdo también es cierta mención de un docente acerca de que se debería enseñar a programar orientado a objetos primero y luego los procedimientos. ¿Preferible aprender java primero y luego C?
Las opiniones son como el c..., cada uno tiene una -- que dijo cierto actor de manera un tanto bruta :-P
O.O?! De gustos y colores, mucho han escrito los autores. =P~ <snip>
Obviamente.
O.O!! ¿entonces GCC sacaría el mismo resultado que el compilador de Borland o el de Metrowerks (Codewarrior, lo recuerdo cuando era maquero =P~)? Creo que Intel también está en esas cosas.
No, no serán iguales.
<snip>
Hmm, eso me recuerda cuando vi algunas líneas de programación para mac, los eventos tenían nombres propios, completamente relacionados con el OS. Una interrupción se referirá a algo de más bajo nivel, como Assembler supongo.
Tampoco, pero... bueno, algo parecido. Es más complejo de explicar, no voy a entrar en eso aquí. Es una funcionalidad del procesador.
Registros, int 20 y 21 ;P
No se mucho de programación en ambientes gráficos, pero supongo que es un marco que contiene los métodos para los eventos y los procedimientos y funciones que hace el programa, tal que el marco es el que se encarga de capturar los eventos y pasarlos a las funciones correspondientes que responden, y simultáneamente los procedimientos y funciones principales del programa se siguen ejecutando, como minimizar el navegador, mientras está cargando un página. Lo cual indica que estos tienen prioridad en la ejecución, por que mientras se está realizando alguna tarea, el usuario puede cerrar la ventana.
Puede haber eventos con prioridades (no te se decir seguro), pero lo normal es que se procesen en el orden en que llegan. Según como hayan hecho las cosas, se podrían ejecutar varios simultáneamente. O parecerlo.
Los tíos que hacen esas cosas son humanos ¿verdad? y si no es así, ¿donde hacen los implantes de cerebros positrónicos? =P
Eso en el aula de métodos complejos :-p
Leches, me hace falta un par. O aprender a dormir como los delfines XD ¡O irme a la matrix! -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Wednesday 03 December 2008 10:52:24 Carlos E. R. wrote:
El 2008-12-03 a las 10:25 -0500, Shinji Ikari escribió:
Todavía tengo una seria confusión respecto a lo que debe de ir en la lista. Por eso le puse [OT].
Es un lenguaje usado en linux, así que yo no lo veo OT.
Jo, es que yo soy extremista, en una escala de 0 a 10, difícil que yo pueda quedarme en 5. =P Por ejemplo ahora estoy tentado a poner un OT respecto a la cierto artículo de phoronix sobre pruebas reales de ext4 que va a estar disponible con el kernel 2.6.28... lo están probando contra xfs. ¡Jo! vea, otra vez que me desvío y debería estar leyendo este librucho de administración. =/
Tampoco sería OT, pues es un sistema de ficheros de linux.
Pero encaminándonos, parto que la lista es de openSuSE, por tanto los temas principales se deben de referir a esta distribución y los usuarios de esta distribución, temas distintos a eso pues son OT, por tanto el tema de los libros de python, el cual no es específico para openSUSE, ni tampoco se refiere a una necesidad actual (problema) de algún usuario, según este pechito, califica como OT. =P
No, el ámbito de la lista es linux en general y opensuse en particular. Un tema que aplica a todo el linux entra dentro. Un tema que sólo aplica a debian o ubuntu, no entra - pero si algún usuario de la lista, acostumbrado a suse, nos pregunta sobre como se hace algo que sabe hacer en suse pero no en red hat, pues le respondemos si lo sabemos. Del antiguo FAQ de la lista: ] P2. Cu?l es el contenido apropriado para esta lista? ] R2. Preguntas y respuestas sobre productos y sus componentes de SuSE ] y Linux en general. ] ] P3. Cu?l contenido NO es apropriado para esta lista? ] R3. Mensajes comerciales, personales, ofertas de trabajo y sobre ] temas que no tienen que ver con computaci?n/Linux. Pero hay que recordar que la lista inglesa tiene una lista auxiliar para los OT, mientras que la lista española no la tiene - ergo se suele ser tolerante con los OT. También hay que recordar que en opensuse, en inglés, hay listas especializadas, como la de programación, la de factory... nosotros sólo tenemos una en español, y no hay tráfico suficiente para separarla en varias. Por eso, si tenemos que hablar sobre programación en linux en español, la lista correcta es esta, y no es OT. Es parte del linux. Por eso he quitado la marca de [OT] de este correo.
Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++?
Ni idea, y menos con el gcc, no le sigo la pista.
He intentado con netbeans y con gcc, pero da el mismo error.. obvio por que netbeans usa gcc, luego Sun tiene su propio paquete, SunStudio, 12 creo, el cual no he conseguido instalar adecuadamente... se toma la libertad de instalar netbeans 5.5 (ya están en la 6.5). Habrá que investigar... apenas termine de leer este librucho. =/
Yo se que los estandares han ido cambiando, y tengo la fuerte sospecha que el gcc trata de seguir el estandard.
Si lo instalas, en el suse viene un directorio con libros. Antes incluso había un directorio con libros en español, pero lo quitaron.
Otra cosa más por investigar. Por alguno de mis recursos warez, estaban dando Borland C++ 3.1, ese que va en DOS, vaya tiempos aquellos donde estaba aprendiendo programación por procedimientos y las cosas eran simples... todo tiempo pasado fue mejor =P Tal vez pueda emularlo o instalarlo en el VirtualBox con el XP.
Si, no debería dar muchos problemas para emularlo, aunque los IDE tienen sus historias. Y éste IDE tiene un debugger integrado, así que... es delicado. Mi sospecha es que funcionará. Y lo mejor que tenía el BorlandC es que venía con una caja de libros que valía su precio en oro. La documentación organizada en Linux no es precisamente su fuerte. La hay, pero es tan organizada ni completa. Es dispersa. Pero no creo que esa versión antigua del borlandc sea adecuada hoy en dia. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk29RwACgkQtTMYHG2NR9VlIgCfRUH2eAZHgkO9YVdoeKzneyd8 2t4An1J+QKgygJkTZLfMalIzTm2vUjO/ =lh1L -----END PGP SIGNATURE-----
El Wednesday 03 December 2008 16:25:29 Shinji Ikari escribió:
Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++?
-- Carlos A. Hola a todos .
cout y cin si funcionan con iostream, pero tienes que usar el espacio de nombres "std", te paso dos ejemplos: 1- en la propia llamada a la función: #include <iostream> int main(int argc, char *argv[]){ std::cout << "pep"; return 0; } 2-avisando al compilador: #include <iostream> using namespace std; int main(int argc, char *argv[]){ cout << "pep"; return 0; } Y como con casi todo encontrarás mas información "googleando". Un saludo -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Thursday 04 December 2008 12:39:31 JFSS wrote:
El Wednesday 03 December 2008 16:25:29 Shinji Ikari escribió:
Si conocen algún buen recurso para C++, me lo podrían pasar, todavía no entiendo por que cout y cin no funcionan con iostream =/ ¿han cambiado las librerías de C++?
-- Carlos A.
Hola a todos .
cout y cin si funcionan con iostream, pero tienes que usar el espacio de nombres "std", te paso dos ejemplos:
1- en la propia llamada a la función: #include <iostream>
int main(int argc, char *argv[]){ std::cout << "pep"; return 0; }
2-avisando al compilador: #include <iostream>
using namespace std; int main(int argc, char *argv[]){ cout << "pep"; return 0; }
Y como con casi todo encontrarás mas información "googleando".
Un saludo
Vale, logra compilar con lo añadido. ;) Sin embargo me entristece que no estén disponibles algunas librerías. No hay conio.h... y ahora es iostream sin la h. =/ De pronto, todos los años que deje de ver C se me vienen encima. =( De todas maneras gracias, ;) -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thursday 04 December 2008 20:32:00 Shinji Ikari escribió:
Vale, logra compilar con lo añadido. ;) Sin embargo me entristece que no estén disponibles algunas librerías. No hay conio.h... y ahora es iostream sin la h. =/ De pronto, todos los años que deje de ver C se me vienen encima. =(
De todas maneras gracias, ;)
-- Carlos A.
Me temo que estas cosas han evolucionado un poco. ;) mira esto: http://en.wikipedia.org/wiki/Conio.h Lo de no poner la h viene del nuevo estándar c++ (creo recordar). En un programa con Qt4 pondrías #include <QComboBox> y si editas el archivo "QComboBox" veras que solo tiene una linea: #include "qcombobox.h". Moraleja: con Qt4 puedes incluir con o sin .h :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Thursday 04 December 2008 14:47:18 JFSS wrote:
El Thursday 04 December 2008 20:32:00 Shinji Ikari escribió:
Vale, logra compilar con lo añadido. ;) Sin embargo me entristece que no estén disponibles algunas librerías. No hay conio.h... y ahora es iostream sin la h. =/ De pronto, todos los años que deje de ver C se me vienen encima. =(
De todas maneras gracias, ;)
-- Carlos A.
Me temo que estas cosas han evolucionado un poco. ;) mira esto: http://en.wikipedia.org/wiki/Conio.h
Lo de no poner la h viene del nuevo estándar c++ (creo recordar). En un programa con Qt4 pondrías #include <QComboBox> y si editas el archivo "QComboBox" veras que solo tiene una linea: #include "qcombobox.h".
Moraleja: con Qt4 puedes incluir con o sin .h :)
Parece que en C también, si uno se pone a buscar, no se encuentra un iostream.h, hay pero sin la extensión. =/ Esto aclara un poco las cosas: http://www.steveheller.com/cppad/Output/basics10.html parece un manual adecuado para actualizarse respecto a C. A ver si consigo hallar la diferencia entre gcc -x c++ y g++ -x c++ que predice dolor en la cabeza de este amateur. =P Gracias por la info. Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!! -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2008/12/5 Shinji Ikari
Gracias por la info. Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!!
Sin ánimo de "flamear", personalmente no entiendo porqué te sorprendes por esto. Yo he visto equipos de personas llevando proyectos bestias, muy bestias, y usando el IceWM como desktop, atajos de teclado para casi todo "artesanales", ventanas sin bordes "fijas" y tirando de Vim una cosa mala. Vim, igual que Emacs, dá para eso y mucho más. Otra cosa es que estés más o menos acostumbrado, o vengas de entornos tipo Windowze, donde (que no digo que sea tu caso) la gente es incapaz de vivir sin un ratón. Saludines. -- Have a nice day ;-) TooManySecrets ============================ Dijo Confucio: "Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos." ============================ =��u��y��jV���+��"�f�u맙��j7������zϮ�˛���m�)z{.��+���j��zw�zZ�yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��
On Friday 05 December 2008 10:19:16 TooMany Secrets wrote:
2008/12/5 Shinji Ikari
: Gracias por la info. Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!!
Sin ánimo de "flamear", personalmente no entiendo porqué te sorprendes por esto. Yo he visto equipos de personas llevando proyectos bestias, muy bestias, y usando el IceWM como desktop, atajos de teclado para casi todo "artesanales", ventanas sin bordes "fijas" y tirando de Vim una cosa mala. Vim, igual que Emacs, dá para eso y mucho más. Otra cosa es que estés más o menos acostumbrado, o vengas de entornos tipo Windowze, donde (que no digo que sea tu caso) la gente es incapaz de vivir sin un ratón.
Saludines.
Lo digo por que la autocompletación me parece una característica muy útil. Sin embargo me parece que vi pone ciertos comandos a color, según lo que se esté haciendo. No es que tenga nada en contra de vim, pero por ejemplo me parece algo más de trabajo moverme de la ventana de editor de texto al navegador. Mejor es tener una visión dividida en Quantas. =) Todo entra por los ojos, no me culpen por mi inexperiencia. =/ Yo creo que aquí varios somos incapaces de sobrevivir sin los escritorios virtuales. XD También me he dado cuenta de que pasar de un monitor grande a uno más pequeño es doloroso. =/ Preferencias de cada uno. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2008/12/5 Shinji Ikari
Lo digo por que la autocompletación me parece una característica muy útil. Sin embargo me parece que vi pone ciertos comandos a color, según lo que se esté haciendo. No es que tenga nada en contra de vim, pero por ejemplo me parece algo más de trabajo moverme de la ventana de editor de texto al navegador. Mejor es tener una visión dividida en Quantas. =)
No hombre no... De hecho, una vez le pillas el truco (osea, igual que en el Quantas o cualquier otro IDE, acordarse de las combinaciones/comandos de teclas), todo va rodado. Lamento mucho no recordarlo, pero Vim es capaz de hacer autocompletado, y además "inteligentemente". Osea, que sabe qué lenguaje estás usando y autocompleta en función de él. Ahora estoy en el trabajo y no puedo... ¡si, lo tengo! CTRL-N. Con ese comando te autocompleta en Vim. Y con CTRL-P (si mal recuerdo) puedes pasearte (recuerda que él ordena alfabéticamente) hacia arriba de lo que él te propone. Además, creo que en las más nuevas versiones de Vim te aparece (hecho en curses) una lista desplegada con las opciones a elegir y todo ;-) -- Have a nice day ;-) TooManySecrets ============================ Dijo Confucio: "Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos." ============================
El vie, 05-12-2008 a las 08:57 -0500, Shinji Ikari escribió:
Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!!
Cuando mejor conoces un sistema, menos falta te hacen todas las ayudas graficas, que al fin y al cabo son eso, ayudas. -- Saludos Lluis
El Friday 05 December 2008 14:57:09 Shinji Ikari escribió:
A ver si consigo hallar la diferencia entre gcc -x c++ y g++ -x c++ que predice dolor en la cabeza de este amateur. =P
Gracias por la info. Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!!
-- Carlos A.
Un simple man gcc ayuda ;) o mejor aun en konqueror man:gcc que es mas "visual" :)) Gcc no es ningún compilador, mas bien es un frontend que llama al adecuado con el lenguaje del archivo fuente. del man de gcc: "Compiling Programs source files conventionally use one of the suffixes .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx; header files often use .hh, .hpp, .H, or (for shared template code) .tcc; and preprocessed files use the suffix .ii. GCC recognizes files with these names and compiles them as programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc). However, the use of gcc does not add the library. g++ is a program that calls GCC and treats .c, .h and .i files as source files instead of C source files unless -x is used, and automatically specifies linking against the library. This program is also useful when precompiling a C header file with a .h extension for use in compilations. On many systems, g++ is also installed with the name c++. When you compile programs, you may specify many of the same command-line options that you use for compiling programs in any language; or command-line options meaningful for C and related languages; or options that are meaningful only for programs. " You can specify the input language explicitly with the -x option... (C, Java o cualquiera de los soportados). Por cierto, sobre manuales de C++ (y otros lenguajes) tienes la serie Thinking in... mira estos enlaces: http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html http://www.mindviewinc.com/Books/ Y la traducción al castellano: http://arco.esi.uclm.es/~david.villa/pensarC++.html Un saludo. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Friday 05 December 2008 19:31:50 JFSS escribió:
El Friday 05 December 2008 14:57:09 Shinji Ikari escribió:
Se me olvidaba, pasa de comprender a gcc y mira cmake. Te genera los makefile con las opciones de compilado y enlazado además de controlar las dependencias con un simple comando tal que: cmake ../src -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-05 a las 08:57 -0500, Shinji Ikari escribió:
Sorprende en verdad que la gente que está en el desarrollo de KDE4 use vim para la edición y ventanas de consola. O.O!!
No es tan sorprendente... yo uso para el correo Alpine, aka Pine, que es modo texto. y tengo más de dos docenas de xterms abiertos: rara vez uso un navegador de ficheros gráfico como el konqueror o el nautilus. Sin embargo, para programar decentemente prefiero un IDE, aunque no me importa en absoluto que trabaje en modo texto - lo cual no quiere decir que no use el ratón ni coloreado por sintaxis ni autocompletado. Simplemente es más eficaz y rápido. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk5guwACgkQtTMYHG2NR9U4QACdET4XhaljzxwuB2YrE2dhPp+g 3KEAoJiq63RGcmQQltkU+qfYRokq3FM2 =JH18 -----END PGP SIGNATURE-----
participants (8)
-
Carlos E. R.
-
Carlos E. R.
-
Carlos E. R.
-
J.M.Queralt
-
JFSS
-
lluis
-
Shinji Ikari
-
TooMany Secrets