Mensajes

Cuidado. Atractividad y amigabilidad son gustos.

No fue un triste movimiento, fue un buen paso de Windows para adaptar VB a .NET

Así es, desde un principio dejé claro que todo lo que he dicho no es más que una opinión subjetiva de un cuasi-detractor de VB. No me agrada, ni me agradará, y aún no comprendo como pueden seguir usando un lenguaje tan obsoleto como VB cuando no es siquiera POSIX. Una cosa es VB .NET y otra VB.

Y aún así, si no fuera por no perder programadores de su lado, no veo otro motivo para que Microsoft adaptara VB a .NET... es decir, lo veo inútil, teniendo C#.

Estamos empezando a comparar .NET con otros lenguajes y eso nos desvía del tema. C++ le da mil vueltas, la WinAPI te da la libertad y el control que siempre quisiste tener sobre la memoria, excepciones, event loops, hooking, compilado no interpretado, herencia multiple (en .NET es ir poniendo interfaces a lo loco -.-) . Para aprender dignamente necesitas de un buen inglés además de mucha lectura, documentación, esfuerzo y programación. Suelo crear wrappers en algunos proyectos para usar DLLs nativas desde .NET, no veas el buen equipo que hacen.

En fin, todo esto un programador novel no lo sabe, y por lo tanto escogerá aquello que le es más fácil o intuitivo, pero que no digan que VB es más lento que C#, pues esa es otra carrera.

Saludos.

Bueno, mi analogía con C/C++ fue sólo para referirme a la sintaxis, quizá se preste a malinterpretación, pero el asunto es que alguien que viene acostumbrado de hacer lo que le venga en gana con el sistema desde una sintaxis que lleva años estudiando y practicando, que le induzcan otra que no se asemeja en nada, simplemente provocará repudio. Es por eso que C# por mucho, llevará la delantera contra VB .NET.

Ojo que nadie ha dicho que VB .NET sea más o menos rápido que C#, pero sí menos amigable y/o atractivo... creo que VB .NET fue un triste movimiento de Microsoft en busca de actualizar, preservar y obligar a programadores VB a migrar a .NET (pues si no, los perdían, ya que VB, como se ha demostrado, está pasando al olvido por sus mismos patrocinantes), pues si bien analizas y comparas, ¿qué sentido tiene crear dos lenguajes íntegramente iguales en cuanto a funcionalidad y completamente diferentes en cuanto a sintaxis?

Por causalidad, ¿has intentado compilar un proyecto que se ubique en la raíz del disco C?

Intenta compilar en un directorio el cual su ruta no incluya espacios y/o caracteres no ASCII estándar.

[*]

Llevo años programando en .NET concretamente C# y VB. VB .NET fue mi primer lenguaje de programación orientado a objetos y debo destacar su sintáxis legible a primera vista, lo práctico que es (gracias al Framework) y lo sencillo que es aprenderlo. Eso sí, si te compras un libro BÁSICO de C# o VB .NET vas a ver prácticamente lo mismo, la única diferencia sería la sintáxis, ya que las diferencias entre C# y VB realmente están a la hora de utilizar contextos que requieren una compilación insegura, normalmente punteros ya que su integridad no se puede verificar. Guardan más diferencias, pero sencillamente esa es una de las más relevantes.

Si vienes del mundo de Java o C/C++ entonces C# es tu amigo, ya que la sintáxis es casi calcada a la de estos lenguajes. VB .NET no se asemeja a ningún lenguaje ademas que su propósito en su día fue crear un lenguaje para principiantes. Hoy día con el proyecto .NET estoy en desacuerdo con dicha afirmación, ya que VB .NET se ha convertido en un lenguaje potente que nada tiene que envidiar a C#.

Soy de C++, pero como estamos en .NET pues prefiero C# ya que me da más control sobre la memoria. Aun así le doy la razón a mi compañero por un simple hecho, he desarrollado tools en ambos lenguajes para inyecciones DLLs, malware, cheats/bots, y debo afirmar que ambos lenguajes sirven para estos propósitos.
Arriba mencioné la compilación unsafe al utilizar un contexto no seguro (pointers), bueno, VB .NET no permite dicho modo de compilación, pero es bien sabido que se puede hacer un port de unmanaged a managed (C# unmanaged to VB .NET managed) , por lo que sería posible. Existen diferencias en su sintáxis y palabras reservadas (keywords) pero el código intermedio (MSIL) en Release es práctimente el mismo.

Eso sí, las tools de las que os hablo es preferible desarrollarlas en C++ como DLL y usarla en tus proyectos, sobre todo si se trata de Hooking o DLL inyection, ya que te obligaria a cargar el CLR en el proceso objetivo lo que podría causar un mal funcionamiento del proceso destino al haber cargado tantas dependencias en su espacio de memoria. C++ hace sencillo todos estos procedimientos.

No sé porque realmente la gente tiende a desprestigiar a VB .NET, ni caso, eso es porque nunca se han molestado ni en aprenderlo ni en medir su potencial comparándolo con C# por ejemplo. Eso sí, recomiendo no estancarse en VB y aprender más lenguajes, Java/C#/C/C++ guardan ciertas relaciones que hacen muy sencillo su aprendizaje.

Saludos.

Bajo mi punto de vista, creo que el odio viene por su sintaxis y sus usuarios, el/los cual(es) es/son, como se ha dicho anteriormente, un lenguaje con sintaxis para iniciados y por ahí derecho que, quienes lo usan, generalmente son novatos que se creen mecenas, los llamados Script Kiddies o Lamers de la red... adolescentes que en principio lo "aprenden" porque es lo primero que ven en Google al buscar cosas del tipo "komo programar un virus?" o "cmo acer un troyano?", etc... Esto sin contar la cantidad de gente que defiende VB sin argumentos, es decir argumentan cosas del tipo "me parece bonito y sencillo de aprender", en vez de basarse en argumentos robustos propios del lenguaje.

Además, uno de los puntos más esenciales en el odio a este (a mi criterio), es que cuando aprendes lenguajes del tipo C/C++, los cuales te ofrecen de manera nativa y sencilla el control total sobre una máquina, y te das cuenta de la utilidad y potencial de dichos lenguajes, empiezas a considerar a lenguajes como VB, lenguajes de juguete (sea o no .NET), ya que te das cuenta que lo único que te ofrecen diferente de C/C++ es un trabajo con la POO más directo... y es aquí donde C# lleva todas las de ganar, por el simple hecho de su sintaxis, la cual es en extremo atractiva al ser tan semejante a C++ (sí, ya sé que Java fue influenciado por C++ y luego C# por Java y C++), pero a lo que voy, es que al existir en .NET un lenguaje como C# que te ofrece lo mismo que VB .NET, te preguntas ¿para qué usar/aprender un lenguaje que en principio no me atrae y siento algo de repudio hacia él*, cuando existe C#, el cual se asemeja mucho más a C++ y me permite un uso idéntico de la plataforma .NET + código inseguro + POO?

* En síntesis, a mi criterio, el rechazo al lenguaje está basado en 3 puntos clave:

• Su sintaxis: Orientada a noveles, presenta una nueva estructura y obliga al programador a aprender de nuevo otra sintaxis que no se parece en nada a la cual ya venia trabajando.
• Sus usuarios: Estos defensores que, en general, no saben de qué hablan y se valen de cualquier cosa para defender un lenguaje, a mi criterio, inútil y que lo único que ha logrado (y lo podemos observar a lo largo de la red) es crear muchísimos pseudoprogramadores vagos y prepotentes.
• Su alcance: En comparación con C#, no he encontrado nada que se pueda hacer en VB que en C# no. Caso contrario si habláramos de VB, pues tendríamos que valernos de artificios para poder llegar a un fin que con C# se lograría de forma sencilla.

Sin embargo, esta es una opinión meramente subjetiva. No puedo firmar que VB sea un mal lenguaje, de hecho, para aquellos que tienen toda su vida programando en VB, todo lo que he dicho anteriormente, es una bonita falacia.

En fin, creo que y sin temor a equivocarme, quienes empezamos a aprender programación desde C/C++ y/o aquellos lenguajes que permiten una interacción más directa con las entrañas del S.O., preferiremos C# antes que VB, por su sintaxis más que nada.

[@FMLTGRD:]

tendrás que dar más info, que yo sepa no hay un "process" por defecto en el standard de c++

Creo que se refiere a la clase Process de C++/CLI...

@FMLTGRD: Si es así, lamento informarte que esa clase es propiedad de la plataforma .NET, por consiguiente no tienes código portable. .NET es código administrado NO estándar C++. (Aunque Nadella tiene pensado liberar la plataforma .NET, quien sabe que suceda con esas clases...)

He encontrado una web muy completa que te ayudaría a solucionar esa duda, da clic aquí.

Te recomiendo que te leas este post de Taringa que explica muy bien lo que necesitas  

http://www.taringa.net/post/ciencia-educacion/14450390/Lectura-de-cadenas-en-C.html

Revisando el tema, veo que la función que el tío ha creado es muy semejante a la que se forja en este tema, aunque la que se expone en el tema que cito, está más pulida (modestia aparte), sin embargo con punteros se perfeccionaría aún más... K&R hicieron una obra maestra.

D.E.P. Ritchie.

Hola, lee los temas con chincheta antes de publicar nuevos mensajes.

Aquí un tema que -considero- responde tu interrogante.

Qué ironía, empezó siendo un aporte, y terminó siendo una solución fomentada.
Borré el DevCpp, instalé el Code::Blocks y no tuve más problemas al compilar.

Gracias por tu solución zShackra!

Me alegra que te haya servido de algo... DevC++ es un IDE bastante deficiente.

[muy]

Probé el Visual Studio y me resultó incómodo, el Qt Creator no lo tenía conocido y acerca del Code::Blocks, oí muchas notas positivas al respecto, pero nunca lo probé.

Pues bueno, el Visual Studio por incómodo que sea, tiene el mejor depurador que he probado en sistemas NT, además de ser un entorno muy pero muy completo...

Code::Blocks es muy ligero y viene casi completamente configurado, aunque usa MinGW como compilador (al igual que QtCreator y DevC++), honestamente no les veo nada malo a los tres IDE, Visual Studio usa el compilador de Microsoft y aún así desenvuelve un trabajo espectacular.

Te sugiero darle una oportunidad al menos a Code::Blocks, creo y sin temor a equivocarme, que esos problemas que tienes con DevC++ desaparecerían con IDE's más trabajados (sin quitarle su mérito a Orwell, pero nada como un proyecto desarrollado por una comunidad y/o empresa).