2010-07-08 12 views
22

Attualmente ho un backend C++ che ho bisogno di connettermi con una GUI, e dato che non ho mai costruito una GUI prima, ero confuso su dove cominciare.Java vs C++ per creare una GUI che abbia un backend C++

Mi piace scrivere codice in C++ e Java, quindi preferirei che la mia GUI fosse in una di quelle lingue. Inoltre, la GUI deve essere ragionevolmente indipendente dal sistema operativo su Windows e Linux (e, si spera, quindi sui Mac).

Ora capisco che se uso Java per farlo, ho bisogno di alcuni wrapper per farlo - ma ho anche sentito (rigorosamente di seconda mano) che scrivere una GUI in C++ è un dolore.

Non voglio riscrivere troppo del mio codice backend in Java (che non ??) e speravo in input su:

  • Does entrambe le lingue offrono seri vantaggi/svantaggi rispetto al altro?
  • Quanto è grave il problema del wrapping e quanta riscrittura verrebbe se avessi usato Java.
  • Ci sono risorse specifiche che dovrei considerare che la gente pensa sarebbe rilevante?

Grazie e Saluti tutti :)

+10

Implementare la GUI in assembly. –

+2

Hai ancora bisogno di una libreria - o almeno di un protocollo - per il targeting. –

+4

@Hamish Grubijan: Oh sì? Bene * I * implementerebbe la GUI nel codice macchina raw! – Randolpho

risposta

11

Si dice che conosci già C++ e Java e che non hai mai fatto una GUI prima. Ciò significa:

  • , non importa se si va per una GUI Java o un ++ GUI C, è necessario imparare a gestire il quadro GUI
  • se si è scelto di Java, è anche bisogno di imparare come interfacciare tra le due lingue

Quindi stare in C++ ti fa risparmiare una cosa da imparare. Beh, è ​​sempre una buona idea imparare qualcosa, ma potrebbe essere una cattiva idea imparare due nuovi concetti allo stesso tempo. Ad ogni modo, l'apprendimento potrebbe essere il peso minore, suppongo che ci sia un sacco di lavoro reale involontario, anche quando usi strumenti come SWIG.

Si potrebbe voler sapere se scrivere una GUI in Java o farlo in C++ è più facile. Dipende dal Framework scelto. Per Java, hai AWT e Swing che fanno parte della distribuzione Java predefinita, e poi c'è SWT che viene utilizzato, per esempio, da Eclipse. Per C++, ci sono molti toolkit, con Qt, GTK e wxWidgets che sono i più popolari, e tutti e tre supportano tutte le principali piattaforme. La maggior parte di questi toolkit "C++" con interfaccia grafica ha anche un collegamento Java o anche una porta Java, quindi è possibile utilizzarli anche con Java.

Finora ho usato Swing, Qt e alcuni altri che non aiutano nella vostra situazione (l'interfaccia utente che è arrivata con Borland C++ Builder e WinForms su .NET).Fondamentalmente, i concetti sono gli stessi per tutti questi framework, e non ho trovato nessuno di loro più difficile o più facile dell'altro. L'unica eccezione è forse Java, perché non ho mai utilizzato quei LayoutManager, anche se gli altri toolkit hanno equivalenti a LayoutManager che sono facili da padroneggiare. Ma forse questo è solo me.

Le persone inoltre ti diranno che le GUI Java sono sempre brutte e non si adattano al sistema host. Bene, la maggior parte delle GUI Java lo sono, ma IMHO non è a causa di Java, ma a causa di una cattiva programmazione. Sono necessarie due righe di codice per consentire a un'app Swing di adattarsi all'aspetto del sistema operativo e la maggior parte dei programmatori semplicemente non mette abbastanza impegno nelle proprie GUI Java per copiare e incollare quelle due linee ... puoi immaginare quanto si preoccupano del resto del loro design GUI.

Per la situazione attuale, consiglierei una GUI in C++, ma se sai come sono i tuoi piani futuri e se sai che farai GUI Java per il resto della tua vita, allora probabilmente è ok per iniziare ora e prendi lo sforzo extra di

E se avete scelto C++ per la GUI, le persone vi diranno ogni genere di cose per portarvi in ​​qualsiasi direzione. Tutti e tre i grandi framework portatili hanno i loro pro e i loro contro, ma non credo che esista uno dei migliori o peggiori tra loro. Consiglierei Qt semplicemente perché l'ho già usato, ma se mi piacerebbe aver usato GTK o wxWidgets, probabilmente lo suggerirei.

34

Date un'occhiata al Qt.

Nella mia esperienza la comunicazione tra due diversi runtime linguistici è sempre impegnativa. Se si dispone di un'applicazione non banale per creare le seguenti sfide spesso: -

  • Gestione degli errori.
  • Gestione della memoria.
  • Multithreading e sincronizzazione Semantica.

Oltre ad aumentare un livello di indirezione a causa di involucri, richiede un sacco di pensare come le circostanze in cui è necessario passare attraverso le strutture di dati GUI e backend ecc

Per esempio: - Prendere in considerazione che passa un Java String dalla GUI per eseguire il backend del C++. In sostanza, dobbiamo estrarre i caratteri da un oggetto Java String e renderli disponibili allo sviluppatore C++ senza perdere la memoria che li contiene. Questo è un esempio di un problema di base (ci sono anche altri aspetti come la codifica in cui i caratteri devono essere restituiti).

4

Non posso dire molto sull'abbinamento di Java e C++, ma suggerisco di dare un'occhiata a Qt. È una libreria C++ per un sacco di cose, come l'accesso ai file e alla rete, ma è più famosa per lo sviluppo della GUI. Ha anche un bel IDE dove puoi costruire la tua GUI con il drag-and-drop. Direi anche che Qt è agonostico rispetto al sistema operativo delle librerie GUI.

2

Scrivere una GUI in C++ non è più un problema che farlo in Java.

Esistono numerose librerie GUI multipiattaforma. GTK, gtk--, FoX, WX, ecc. Non consiglierei Qt poiché non è realmente C++ (usa una versione estesa del linguaggio che richiede un preprocessore speciale prima della compilazione). Inoltre costa una fortuna se non vuoi dare via il tuo prodotto.

BTW, non è così che si usa la parola "quindi".

+9

* Molte * applicazioni commerciali possono utilizzare Qt tramite la LGPL senza alcun costo. –

+1

+1 per non consigliare Qt. Vorrei anche citare Ultimate ++, gtkmm e FLTK tra le librerie C++ portatili. –

+0

Controllerò GTK - grazie :) Per quanto riguarda la parola 'Hence', l'ho usata nel contesto in cui la mia GUI in Linux si sarebbe tradotta in Mac OS X. In realtà non ho indicato chiaramente la parte OSX, I Ammetterò, ma ho visto quindi usato in modo simile nel testo pubblicato. Ma di nuovo, le interpretazioni fanno un linguaggio ... – sparkFinder

-1
  1. Il wrapping non è una riscrittura, è solo un adattatore per far incontrare entrambe le lingue. È immediato
  2. Dato che non sembra essere corretto su una lingua, sceglierei .NET Gui (con C++ CLR) avrai una GUI indipendente dalla macchina e potrai facilmente comunicare con la tua codice esistente.

Per i principianti WinForms è forse più semplice, ma provare a utilizzare WPF, è la variante più moderna per lo sviluppo di GUI nel mondo .NET.

Personalmente userei C# /. NET per la GUI e utilizzare una DLL wrapper CLR C++. Ma non è l'unica soluzione.

Sotto Linux, la migliore implementazione .NET è MONO. Per tutte le app WinForms che ho sviluppato (non sono le più folli), hanno funzionato senza modifiche. Con C++/Qt dovrai ricompilare per ogni SO di destinazione.

+0

Ha chiesto la piattaforma indipendente. Windoze, Linux e Mac. Penso che contenga C# /. NET. – bradgonesurfing

+0

La versione Mono di GTK potrebbe consentirlo. –

+0

Un downvote, sapevo che era una stupida idea fare un suggerimento .NET ai fanatici del C++ :-D – jdehaan

-1

Non utilizzare Java per creare GUI a meno che l'indipendenza dalla piattaforma non sia obbligatoria. L'esperienza utente sarà lenta e l'interoperabilità con C++ sarà un problema.

Per creare una GUI nativa in C++, è possibile utilizzare GTKmm insieme a una libreria come Boost o QT. Inoltre, queste librerie sono disponibili per la maggior parte delle piattaforme (GNU/Linux, Windows, OS X) in modo che l'applicazione possa essere ricompilata ovunque.

modifica: utilizzare GLADE per creare rapidamente GUI e compilare gli slot di segnale con codice C++ in GTKmm.

+1

Quindi, come direbbe, usando gtkmm in C++ problemi di indipendenza della piattaforma di posa? – sparkFinder

+0

gtkmm non pone problemi di indipendenza della piattaforma tranne la distribuzione, solo che è necessario ricompilare l'applicazione per ogni piattaforma. utilizzando Java, potresti semplicemente dare via i file jar. – Max

+0

Utilizzando Java, basta dare via i file jar e compilati per ogni piattaforma C++ back-end - in questo caso. –

7

A seconda delle esigenze, una semplice interfaccia Web potrebbe essere la più semplice quando non si dispone di un codice di frontend esistente. Incorpora un piccolo server web nella tua applicazione e apri un browser su "http://localhost:12345" (o quale porta usi).

+0

downvote? Per aver suggerito una web gui? Oh bene :) –

+1

Fanatici, ti dico ;-). Questa è anche una buona alternativa, quante app sono abilitate al web oggi ... Penso che abbiano letto Web e che abbiano spaventato i downvoters. Ti ho messo di nuovo al livello 0. :-) – jdehaan

1

Non hai menzionato la ricchezza dell'interazione tra front e back end, che appesantirebbe l'importanza della lingua esistente nella tua decisione.

Ho lavorato con Qt, Swing e SWT e in genere ho utilizzato sia il codice C++ che Java con tutti questi toolkit. L'interazione tra le lingue può aggiungere ulteriori costi/rischi. Tuttavia, a volte tale costo è giustificato con altri benefici.

Se per qualsiasi motivo si sceglie un front-end Java, consultare JNA e SWIG.

2

Siamo onesti qui. C++ non è sulla mappa quando si tratta di GUI portatili.

Java ha un toolkit GUI maturo, portatile, ampiamente utilizzato, ampiamente documentato. C++ ha un sacco di librerie OSS half-assed che funzionano a malapena, nessuna è veramente portabile, oltre a costose librerie commerciali che non funzionano su tutti i target che sostengono, funzionano in modo chiazzato sui bersagli rimanenti e invertono il controllo in modo tale che tu sia bloccato nella loro struttura strana.

A meno che non sia necessario il C++ per altri motivi (di cui ce ne sono molti), scegliere Java per la GUI. La codifica cross-over è banale per qualcuno che conosce entrambe le lingue, ma può essere complicato da gestire, quindi dovrai minimizzare l'interfaccia nativa nel miglior modo possibile. Il mio consiglio qui è di fare un patto con la tua squadra che non tenterai mai di tenere puntatori (o riferimenti) attraverso l'interfaccia. Se lo fai diventa un po 'più disordinato e nessun debugger può salvarti quando le linee si ingarbugliano. Invece, utilizzare numeri interi o chiavi stringa e passarli attraverso l'interfaccia nativa.

+3

Mentre tu puoi essere onesto, sei disinformato. Le librerie UI migliori e più popolari sono scritte in C, C++ o C#. Java non ha un bell'aspetto nemmeno su una piattaforma ONE, non importa se è multipiattaforma. – rpg

+2

Il problema è: avete entrambi ragione (John e rpg). Le librerie UI C++ non sono molto buone e l'interfaccia utente Java non è gradevole su nessuna piattaforma. –

+2

Non si tratta di essere informati. È una questione di esperienza. :) Ho esperienza professionale con quasi tutti gli strumenti GUI mai scritti, portatili o nativi. Java è il migliore in termini di toolkit. In termini di come sembra ... beh, hai un punto. La GUI di Java è migliore delle app web arbitrarie, e migliore dei toolkit minori come Tk, FLTK, ecc., Ma peggio degli strumenti desktop nativi (.NET, Cocoa). Non è assolutamente perfetto. Anche se non mi piace Java in generale, devo dare credito in merito al credito, e ammettere che il toolkit GUI di Java è piuttosto solido. – John

1

Che ne dici di eclissi? Sembra buono e funziona bene su tutte le piattaforme. La mia ipotesi è che la maggior parte di eclissi sia Java.

+1

IBM lo ha usato per Notes, ma è lontano da un framework GUI generico. – MSalters

0

Perché non si impara la GUI C++ nativa come WINAPI o X11. Quindi rendi compatibile il software della console come winehq, cygwin o altra compatibilità open source o software emulato. Dal momento che non hai mai sviluppato la GUI su C++. Non andare per Java perché rendere più caricato le dimensioni della RAM. A meno che tu non abbia grandi dimensioni di RAM. Eclipse può utilizzare 500mb di RAM durante l'esecuzione senza alcun progetto aperto.