Estoy usando el Visual C++ Express para hacer un programa con ventanas de Windows, una de las cosas que hace es acceder a ficheros del disco. Sin embargo, no paro de obtener errores de de que el clase fstream no ha sido declarado (ya he comprobado que hice un #include <fstream>). ¿Alguien sabe que puede ser? ¿Alguien le ha pasado algo parecido? Desde luego, es muy frustrante.
quiza incluyendo un :
using std::fstream;
o directamente un:
using namespace std;
despues de los includes.
Saludos.
Sin nada que ver con el fstream, ¿no te es mejor comenzar a usar las clases para controlar archivos que vienen en el api del .net?
Cita de: "zupervaca"Sin nada que ver con el fstream, ¿no te es mejor comenzar a usar las clases para controlar archivos que vienen en el api del .net?
Lo de los ficheros no es nada comparado con usar las Forms de .NET en vez de Win32 para las ventanas. :) Pero eso implica pasarse de C++ a C++/CLR, que no es una decision a tomar a la ligera.
No entiendo tu post, ¿que tiene de malo el C++/CLR?
Cita de: "zupervaca"No entiendo tu post, ¿que tiene de malo el C++/CLR?
Portabilidad, por ejemplo.
Cita de: "zupervaca"No entiendo tu post, ¿que tiene de malo el C++/CLR?
Aparte de considerarlo personalmente como una aberración (aunque pueda resultar tremendamente util en ciertos casos), el hecho es que no es C++ sino un dialecto de C++, propietario de Microsoft, e intimamente ligado con la plataforma y el runtime .NET. Recomendar semejante salto por la ¿conveniencia? de los ficheros de .NET frente a las streams es, digamoslo asi, un poco atrevido. :)
En el primer post lo ha dejado bastante claro:
CitarEstoy usando el Visual C++ Express para hacer un programa con ventanas de Windows
Si va a usar herramientas de microsoft en un sistema operativo de microsoft lo mas logico es usar sus apis.
CitarRecomendar semejante salto por la ¿conveniencia? de los ficheros de .NET frente a las streams es, digamoslo asi, un poco atrevido
Otra vez que no te entiendo, el .net deja trabajar con streams. http://msdn2.microsoft.com/en-us/library/system.io.stream.aspx
Citarsino un dialecto de C++, propietario de Microsoft, e intimamente ligado con la plataforma y el runtime .NET
¿No era totalmente libre como el csharp? Sigo sin ver la importancia de que varien algunas cosas del C++ tradicional al fin y al cabo es un lenguaje mas para facilitar y acelerar la programacion.
Si me he enterado bien, esta es la respuesta a mis problemas:
http://msdn2.microsoft.com/es-es/library/8h8eh904(d=ide).aspx
Parece que voy a tener que tirar por la solución de zupervaca. Gracias por la atención.
Hola a todos,
voy aprovechar este hilo para una duda sobre vc++ 2005, estoy intentando hacer una ventana con la api de windows igual que hacia con el entorno de vc++ pero al incluir la libreria windows.h me sale un error de que no la encuentra. ¿Hay alguna forma de trabajar con la api con vc++ 2005 y poder incluir esta cabecera?
Creo que debes descargar e instalar el MS Platform SDK para tener acceso a las librerias desde VC++ 2005 Express.
Gracias ZaelSiuS estas en lo cierto.
Cita de: "zupervaca"Si va a usar herramientas de microsoft en un sistema operativo de microsoft lo mas logico es usar sus apis.
[...]
¿No era totalmente libre como el csharp? Sigo sin ver la importancia de que varien algunas cosas del C++ tradicional al fin y al cabo es un lenguaje mas para facilitar y acelerar la programacion.
Por supuesto C++/CLR tiene sus aplicaciones y su sitio dentro del panorama. Un articulillo interesante para leer es http://www.research.att.com/~bs/bs_faq.html#CppCLI y los links que incluye. Solamente digo que si alguien tiene un problema con los streams de C++, resolverlo pasandose a C++/CLR es matar moscas a cañonazos. Si .NET como plataforma y C++/CLR son el mejor entorno para tu aplicación, genial. Como solución a un malentendido con la libreria o una instalación errónea del compilador (sea lo que sea el problema original) de McBain, pues como que no me valen. Igual se podría haber pasado a Haskell, que tiene otras ventajas (y otros inconvenientes). ;)
Un detalle interesante es recordar que, aunque tu aplicación concreta sea para Windows, hay mucho código que podrías reutilizar posteriormente; si tu código usa un lenguaje y features estándares y portables, eso que habrás ganado.
CitarOtra vez que no te entiendo, el .net deja trabajar con streams. http://msdn2.microsoft.com/en-us/library/system.io.stream.aspx
Creo que esos no eran los streams a los que se referia con #include <fstream>
Edit: Boh, el vicio que tengo de escribir C++/CLR cuando el nombre oficial es C++/CLI.
Hi,
[EDITADO]
Por cierto, he usado visual c++ express desde octubre del año pasado, en varios proyectos. He manejado ficheros como se suele hacer en iso c++, con streams y sin ningun problema.
[/EDITADO]
es algo offtopic pero ya que veo a Jare animadillo... :P
-¿que diferencias hay entre c++/cli y managed c++?
-Algo que no entiendo muy bien es, si vas a desarrollar en .net ¿porque habiendo lenguajes tipo c# o vb.net la gente querria usar c++/cli o managed c++?
Lo unico que se me ocurre es por usar unmanaged c++. Ahora mismo, voy a mezclar en una aplicacion c# y unmanaged c++. C# y windows forms para el interfaz grafico y unmanaged c++ para los algoritmos. Asi que, necesito un wrapper entre estos dos, que lo voy a hacer con managed c++.
Aparte de usar managed c++ como wraper entre c# y unmanaged c++ no se me ocurre ningun motivo mas.
Un saludo,
Rubén
Cita de: "Ruben"-¿que diferencias hay entre c++/cli y managed c++?
-Algo que no entiendo muy bien es, si vas a desarrollar en .net ¿porque habiendo lenguajes tipo c# o vb.net la gente querria usar c++/cli o managed c++?
Mejor un hilo nuevo para eso, que ya se nos ha ido bastante la olla en éste.
CitarSolamente digo que si alguien tiene un problema con los streams de C++, resolverlo pasandose a C++/CLR es matar moscas a cañonazos
Creo que aqui se ha ido cambiando poco a poco lo que he dicho, mi frase inicial no era decir que cambiara a los streams de .net, le estaba preguntando si no le salia mejor comenzar a usar las clases de .net para usar arcihvos, pasarse a .net da muchas ventajas como la de tener un api tan gordo que hasta podria llegar a dar repelus aprenderselo entero.
CitarUn detalle interesante es recordar que, aunque tu aplicación concreta sea para Windows, hay mucho código que podrías reutilizar posteriormente
No es el caso de McBain ya que ha especificado claramente su objetivo, ademas es reutilizable si usas c++, y no se tu pero los proyectos no siempre se hacen en un mismo lenguaje.
CitarIgual se podría haber pasado a Haskell, que tiene otras ventajas (y otros inconvenientes).
Haskell no es comparable con .net, la verdad es que esta frase la habras dicho para sorprender un poco o algo asi, por que el api que tiene .net es tan grande o mas que el de java y haskell ... bueno es haskell :roll: (para el que quiera saber algo de el lo tiene en wikipedia)
CitarCreo que esos no eran los streams a los que se referia con #include <fstream>
No se, pero hay frases en tus post que no logro entenderlas, es como si yo hablara de .net y tu de otra cosa, esta direccion http://msdn2.microsoft.com/en-us/library/system.io.stream.aspx es la punta del iceberg de los streams en .net, si miras el namespace system.io a la que pertenece esta clase veras una serie de clases especificas para varios casos, si te refieres a otra cosa pues explicamela por que no se que es.
En conclusion, creo que ves el c++/clr como un lenguaje "suelto", pero la ventaja de este lenguaje es que te dan la potencia del c++ y todo el api de .net, ahora la eleccion de usarlo o no es de cada uno, yo como he dicho varias veces si me meto con .net uso csharp que para algo es el lenguaje mas preparado para el, no obstante yo veo una gran ventaja a .net y es que sus aplicaciones se compilan para la maquina en la que se ejecuta, es decir, en algunas casos podria llegar a ser mas rapido que el c++, el unico inconveniente que le veo es que es decompilable.
Hola a todos, aprovechando de nuevo el hilo como antes dije sobre que no encontraba la libreria de windows.h ahora si que la encuentra despues de descargar el MS platform sdk e instalarlo. Pero a la hora de enlazar me da muchos errores. Pero yo tengo configurado el entorno con las librerias que vienen con el platform sdk. ¿Alguna sugerencia?
Por si alguien le interesa el tema, pues hay que incluir tambien esta ruta en los includes MS Platform SDK\Include\mfc
y ademas tambien hay que coger y modificar este archivo corewin_express.vsprops se encuentra dentro del directorio VC\VCProjectDefaults
Cambiar esta linea :
AdditionalDependencies="kernel32.lib" a
AdditionalDependencies="kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib"