Visual C++ é un capitolo di C++, il viceversa oppure cosa? E' forse un fantasma?

[marchionili]

Ho iniziato a studiare C# ma ho scoperto che dietro questo linguaggio c'é lo zampino Microsoft (framework) e sono stufo ed arcistufo di usare linguaggi di questo tipo. Non voglio imparare ad usare uno strumento e dover fare la fine che ho fatto con Visual Basic 6. Per questa ragione ho deciso di studiare C++ che oltre ad essere intramontabile é anche di basso livello. Purtroppo non essendo un programmatore non posso permettermi di creare le interfaccie grafiche autonomamente percui pensavo di approfondire Visual C++. Inoltre le interfaccie grafiche di Visual Studio sono molto belle e non credo che nessuno saprebbe fare nulla di meglio. Vi vorrei fare ancora qualche domanda prima di iniziare a studiare definitivamente C++ però, VI PREGO E VI SCONGIURO, non ditemi di andare a leggere una guida (lo farò statene certi...) e NON usate paroloni complicati (NON SONO UN PROGRAMMATORE COME VOI) e usate pure l'italiacano, lingua ben conosciuta dagli ignorantoni come me.

DOMANDE

1) La parte "Visual" (VISUALE) di Visual C++ é fatta da Microsoft? Se faccio un programma in Visual C++ il codice é indipendente da Visual Studio ovvero gira anche su Linux e su Mac mentre l'interfaccia é modificabile solo su Visual Studio? Il codice (if, else, for, ecc... ) che c'é su Visual C++ ("Applicazione di Windows Form" che c'é su Visual Studio) é lo stesso che c'é in qualunque altro software di C++? Posso creare l'interfaccia in Visual Studio e poi ricrearne un'altra in un secondo momento A MANO con il codice? Se desidero creare un software che intendo utilizzare "in eterno" in qualunque tipo di ambiente "anche sulla luna" (NON SOLO SU WINDOWS) posso crearlo su Visual Studio oppure devo usare un altro programma e usare Visual Studio solo all'ultimo per la creazione dell'interfaccia grafica?

2) Se creo un programma su Visual Studio in Visual C++ e poi decido di comperarmi un Mac oppure di passare a Linux lo posso fare a patto di RIFARE l'interfaccia grafica A MANO e compilare nel dovuto formato (rpm per linux e xxx per mac)?

3) Per imparare ad usare Visual C++ mi posso leggere questa guida qui:
http://programmazione.html.it/guide/leggi/34/guida-c/
oppure ne devo cercare una dedicata anche all'ambiente visuale? Perché su internet non si trova nulla di Visual C++? Mi consigliate un libro su Visual C++ non troppo soporifero (alla fin dei conti per ora devo fare un semplice programma di calcolo...)?

Ciao e grazie per la pazienza

P.S.: Per creare le interfaccie grafiche in C++ si può usare qualche programma simile in html e css oppure si deve usare per forza C++? I programmatori bravi (con le p@lle grosse e [] usano solo C++ per i loro software?)
Il linguaggio C ormai é vecchio ed é stato soppiantato da C++, non é vero?

[MItaly]

1. Il C++ standard non include nulla che riguardi la grafica, qualunque strumento per la GUI è in un certo senso proprietario.
"Visual C++" non vuol dire niente, è semplicemente il nome del pacchettone IDE+compilatore+un tot di librerie. Quando disegni un'interfaccia in VC++ di fatto stai usando due pezzi: il form designer (per poter disegnare il form graficamente) e un qualche toolkit (libreria) per la GUI. VC++ offre due form designer e tre librerie:
- il form designer "classico" genera dialog da inserire in file di risorse; si usa per creare finestre in applicazioni unmanaged (ovvero, native e scritte in C++ standard più qualche libreria). Le librerie che si impiegano usando i file di risorse sono le MFC (scritta in un C++ abominevole) o ATL (o la sua espansione WTL), o, se ti vuoi del male, direttamente le API di Windows. Tutte soluzioni non portabili, dato che MFC e ATL sono dei "thin wrapper" attorno alle API di Windows, che ovviamente sono platform-specific.
- il form designer di Windows Forms, che genera direttamente codice C++/CLI. Il problema qui è che usa la libreria Windows Forms, che è una libreria .NET, e di fatto per usarla non userai C++ standard, ma C++/CLI, un dialetto del C++ per permette di lavorare il .NET Framework (di fatto il backend del compilatore genererà codice intermedio per .NET e codice nativo se richiesto, patchati insieme tramite PInvoke). Personalmente ritengo estremamente stupido usare C++/CLI salvo in casi eccezionali, se si lavora con il .NET Framework tanto vale usare C#.

2. No. I toolkit nativi di VC++ sono strettamente relativi a Windows. Esiste un port funzionante di Windows Forms per Mono (una versione open source del .NET Framework), ma non mi risulta che esistano altri compilatori C++ oltre a quello Microsoft che siano in grado di gestire C++/CLI. Da questo punto di vista risulta molto meglio C# (linguaggio che Mono supporta tranquillamente, anche se, se l'obiettivo è fare GUI portabili, conviene usare altri toolkit grafici, come GTK#).

3. Le guide di C e C++ di questo sito non sono un granché...

In ogni caso, se vuoi creare applicazioni portabili ti conviene usare un toolkit grafico multipiattaforma come le wxWidgets o le Qt (entrambe opensource), magari usando un IDE che le supporti nativamente.

E in ogni caso non scarterei a priori C# (usando le GTK# se vuoi essere portabile), se vuoi sviluppare secondo una filosofia RAD è sicuramente più indicato.

[alka]

Originariamente inviato da marchionili
Ciao e grazie per la pazienza

La pazienza sta per finire visto che questa è l'ennesima volta che apri una discussione che spazia su tutto lo scibile in cui chiedi informazioni che si possono trovare tranquillamente ovunque con quella banale, semplice ed esaustiva ricerca che ti ostini a non fare e chiedi di non ricordarti.

Visto che perseveri senza neanche accennare a dare un minimo retta a quanto ti viene chiesto, la prossima volta ti segnalo per il ban, ricordati la finalità di questa sezione del forum (e anche delle altre): hai un problema specifico con un linguaggio di programmazione? posta il codice e l'errore o il comportamento anomalo che ottieni e saremo ben felici di aiutarti, mentre tutte le altre discussioni filosofiche, generiche, astratte e che trovano risposta sul Web in 5 minuti evitale.

Spero di essere stato chiaro questa volta.