Problemas con aplicaciones en Win32 y ficheros

[McBain]

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.

[_Grey]

quiza incluyendo un :

using std::fstream;

o directamente un:

using namespace std;

despues de los includes.

Saludos.

[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?

[Jare]

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.

[zupervaca]

No entiendo tu post, ¿que tiene de malo el C++/CLR?

[Zaelsius]

No entiendo tu post, ¿que tiene de malo el C++/CLR?

Portabilidad, por ejemplo.

[Jare]

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. :)

[zupervaca]

En el primer post lo ha dejado bastante claro:

Estoy 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.

Recomendar 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

sino 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.

[McBain]

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.

[Diferencial]

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?

[Zaelsius]

Creo que debes descargar e instalar el MS Platform SDK para tener acceso a las librerias desde VC++ 2005 Express.

[Diferencial]

Gracias ZaelSiuS estas en lo cierto.

[Jare]

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.

Otra 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.

[Ruben]

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

[Jare]

-¿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.