C++/CLI (managed) e c++ nativo

[Bloodxyz]

Salve, da tempo ho scritto un applicazione tramite console in c++ nativo.
Recentemente però ho dovuto rivedere tutto il progetto in quanto ho assolutamente bisogno di utilizzare dei bottoni, pulsanti.. ecc.. insomma il tutto andrà a finire in uno schermo Touchscreen.
Ho quindi creato un nuovo progetto Tramite "Windows Form".

Il problema è che ovviamente ci sono parametri per nativo diversi da quelli gestiti (tipico esempio std::string vs System::String^).

Dal momento che ho importato le vecchie classi (scritte in c nativo che accettano argomenti in std::string), mi conviene riconvertirle in c++ managed?

[shodan]

Personalmente cercherei di incapsulare lo strato C++ in un layer di conversione verso il .NET (per std::string puoi vedere qui: http://blogs.msdn.com/b/slippman/arc...02/147090.aspx) per non riscrivere tutto il codice. Occorre vedere, però, se il gioco vale la candela.

[MItaly]

Tra l'altro anche in C++ nativo puoi creare applicazioni grafiche, ma è un po' più complesso. Valuta se perdi più tempo ad imparare un toolkit grafico per C++ nativo o a fare il layer di "compatibilità" tra C++ nativo e C++/CLI.

[Bloodxyz]

Originariamente inviato da shodan
Personalmente cercherei di incapsulare lo strato C++ in un layer di conversione verso il .NET (per std::string puoi vedere qui: http://blogs.msdn.com/b/slippman/arc...02/147090.aspx) per non riscrivere tutto il codice. Occorre vedere, però, se il gioco vale la candela.

Si va be, ma se posso riscrivo direttamente le classi trasformandole da native a managed, saranno due o tre. La mia domanda era se nel mio caso era meglio trasformare tutto ad esempio ed usare System::String^ oppure continuare a fare la conversione ogni volta da System::String a std::string

Il codice in ogni caso copio e modifico quello che mi serve, anche perchè molte cose del vecchio non mi servono più, a questo punto direi di fare un implementazione completa .NET con il c++/Cli.

Per esempio: prima usavo "mysql_connector c++" e per interagire con i dati mi son fatto una semplice classe di connessione..

A sto punto per esempio, riscrivo usando il "mysql_connector .NET". Giusto?

[shodan]

Sempre a livello personale, se devo usare qualcosa del .NET, taglio la testa al toro e rifaccio tutto in C#.
Se le classi da convertire sono due o tre, potresti valutare anche questa opzione.

[Bloodxyz]

Considera però che il c# non lo conosco, l'unico utilizzato per ora è sempre stato il visual c++ versione console

Sto affrontando ora le "Windows Form", non so se è il caso di buttarmi sul c# e ristudiare come funziona..

[Paulin]

Originariamente inviato da shodan Sempre a livello personale, se devo usare qualcosa del .NET, taglio la testa al toro e rifaccio tutto in C#.
Se le classi da convertire sono due o tre, potresti valutare anche questa opzione.

Condivido appieno, se si sceglie di lavorare in CLI non ha più senso utilizzare un linguaggio così potente come il C++, il codice generato sarà comunque "Common Language Interface" che per essere interpretato ed eseguito avrà bisogno della Virtual Machine di Microsoft (il Net Framework). Con questa scelta si decide anche che le performance dell'applicativo non sono una priorità. A tal punto tanto vale sviluppare in VB, o ancor meglio in C# che è maggiormente mirato all'obiettivo Net Framework.

Originariamente inviato da Bloodxyz Considera però che il c# non lo conosco, l'unico utilizzato per ora è sempre stato il visual c++ versione console

Sto affrontando ora le "Windows Form", non so se è il caso di buttarmi sul c# e ristudiare come funziona..

Le Windows Form contengono indubbie facilitazioni, non sono però l'unica strada per accedere all'interazione utente di tipo "touch", immagino tu conosca le Windows Touch API(s)

Ciao

[Bloodxyz]

Condivido appieno, se si sceglie di lavorare in CLI non ha più senso utilizzare un linguaggio così potente come il C++, il codice generato sarà comunque "Common Language Interface" che per essere interpretato ed eseguito avrà bisogno della Virtual Machine di Microsoft (il Net Framework). Con questa scelta si decide anche che le performance dell'applicativo non sono una priorità. A tal punto tanto vale sviluppare in VB, o ancor meglio in C# che è maggiormente mirato all'obiettivo Net Framework.

Oddio a leggere questo mi fai pensare che abbia fatto un passo indietro... Ho scelto il c++ appunto perché sapevo che era un linguaggio potente..

Le Windows Form contengono indubbie facilitazioni, non sono però l'unica strada per accedere all'interazione utente di tipo "touch", immagino tu conosca le Windows Touch API(s)

Uhm non conosco quelle api, a me interessa in poche parole fare delle schermate form con dei larghi pulsanti da premere con uno schermo touch. Per questo ho dovuto optare per le windows form.

Vorrei parlarvi dell'applicazione, magari mi aiutate a evitare di rifare il progetto per la terza o quarta volta. Il programma deve stabilire un collegamento con delle apparecchiature elettriche (chiamate "phidgets") per controllare eventi riguardanti sensori, relè ecc..
Tramite questo, gestisce delle stanze particolari, quali lampade e altre apparecchiature elettriche. Questo è in poche parole il funzionamento del programma, tutte robe di questo tipo.

[Paulin]

Originariamente inviato da Bloodxyz Oddio a leggere questo mi fai pensare che abbia fatto un passo indietro... Ho scelto il c++ appunto perché sapevo che era un linguaggio potente..

Dipende cosa intendi per potente, il C++ unisce la potenza del C (intesa come capacità di scrivere routines a basso livello) alla potenza di un linguaggio alto e OOP (per la gestione di progetti con una notevole mole di codice in modo produttivo)
Considera che appoggiarsi sul Net Framework significa appoggiarsi su una "virtual macine", generi un codice che va interpretato al momento dell'esecuzione. Più o meno come lavorare in Java, su alcune routines potresti ottenere una velocità inferiore di 10 o 20 volte quella ottenibile con applicativi scritti in C e C++ il cui codice è direttamente eseguibile dal processore (ovviamente tramite il loader del sistema operativo).

Ad ogni modo è possibile mischiare codice gestito e nongestito, e non so se alla luce di questa possibilità sia possibile rivedere ciò che ho sopra scritto, bisognerebbe prendersi il tempo di leggere attentamentequesto documento: An Overview of Managed/Unmanaged Code Interoperability e correlati. Io non l'ho letto e penso che non lo farò, personalmente ho risolto evitando il /clr come la puzza e dedicando il mio tempo ad imparare altre cose.

Originariamente inviato da Bloodxyz Uhm non conosco quelle api, a me i
nteressa in poche parole fare delle schermate form con dei larghi pulsanti da premere con uno schermo touch. Per questo ho dovuto optare per le windows form.

Vorrei parlarvi dell'applicazione, magari mi aiutate a evitare di rifare il progetto per la terza o quarta volta. Il programma deve stabilire un collegamento con delle apparecchiature elettriche (chiamate "phidgets") per controllare eventi riguardanti sensori, relè ecc..
Tramite questo, gestisce delle stanze particolari, quali lampade e altre apparecchiature elettriche. Questo è in poche parole il funzionamento del programma, tutte robe di questo tipo.

Forse (non penso siano controlli di impianti industriali) potresti anche lavorare sul Net framework con i Windows Form, avrai un applicativo che impiegherà solo un po' più di tempo a caricare ed avviarsi.
Una alternativa senza bisogno del codice gestito è utilizzare una finestra di dialogo, ti puoi fare tutti i pulsanti che vuoi della dimensione che vuoi e tutti i controlli di cui hai bisogno. Inoltre fossi in te mi studierei il link che ti ho suggerito sopra su Windows Touch, comprende guida alla programmazione, esempi e guida di riferimento.

[Bloodxyz]

Ho controllato la documentazione relativa a Windows Touch, però è esclusiva per Windows 7, inoltre bisogna vedere se riesco a lavorarci (visto che sono un novizio e non tanto esperto).
Quindi tu dici che volendo posso utilizzare il codice nativo e fare dei "form" tramite finestre di dialogo.

Forse (non penso siano controlli di impianti industriali) potresti anche lavorare sul Net framework con i Windows Form, avrai un applicativo che impiegherà solo un po' più di tempo a caricare ed avviarsi.

Devo dirti la verità, ho notato già una differenza di velocità tra l'accesso ai dati mysql, tramite la classe scritta in .net e quella scritta per codice nativo (con lib e file da includere).

Beh, quella in .net mi sembra sia più lenta.

Considera che appoggiarsi sul Net Framework significa appoggiarsi su una "virtual macine", generi un codice che va interpretato al momento dell'esecuzione. Più o meno come lavorare in Java, su alcune routines potresti ottenere una velocità inferiore di 10 o 20 volte quella ottenibile con applicativi scritti in C e C++ il cui codice è direttamente eseguibile dal processore (ovviamente tramite il loader del sistema operativo).

L'applicativo andrà poi sistemato in diverse villette e gestirà un delle apparecchiature elettriche.

Ad ogni modo è possibile mischiare codice gestito e nongestito, e non so se alla luce di questa possibilità sia possibile rivedere ciò che ho sopra scritto, bisognerebbe prendersi il tempo di leggere attentamentequesto documento: An Overview of Managed/Unmanaged Code Interoperability e correlati. Io non l'ho letto e penso che non lo farò, personalmente ho risolto evitando il /clr come la puzza e dedicando il mio tempo ad imparare altre cose.

Avresti preferito il c#? O direttamente c++ nativo? O altro?
E' sempre il problema che non voglio spostarmi molto da questa sintassi, sto ancora imparando un po di cose e non posso andare direttamente sul complicato.