I feel like I should know this but seems like no
-
A socket, pipe, or shared memory region?
A network connection to localhost?
Running the backend as a child process of the frontend, and using standard io?
-
Think about why you're wanting to do this. Is there a material benefit you'll get from splitting your codebase like so? Enough to overcome the fact that you've split your codebase into two very different languages?
When you're going between languages like this, you either need some kind of communication protocol (e.g. JRPC, TCP, or maybe something home cooked) or you need a stable ABI to allow the programs to talk to each other directly.
My point is, you probably don't want to do what you're trying to do. Unless you have a really good reason, pick one language and stick with it.
-
i second the comment that you need to consider why you want to do this. You generally need a pretty good reason to split your codebase into multiple languages.
As far as actually doing it, you have a ton of different options, some of which have been mentioned here. Some i can think of off the top of my head:
- create a library (dll or so file or the like)
- set up a web server and use communication protocols (either web socket or rest API or the like)
- use a 3rd party communication/messaging framework like MQ or kafka or something
- create your own method of communication. Something like reading and writing to a file on disk, or a database and acting on the information plopped in
basically every approach is going to require you to come up with some sort of API that the two work together through, though, an API in the generic sense is basically a shared contract two disconnected pieces of code use to communicate.
-
Does the frontend need to be written in C++, or can you write the frontend in java too (in a JFrame from the javax.swing package)?
-
or if you really wanted qt, using java qt bindings: https://github.com/OmixVisualization/qtjambi
-
Making things loosely coupled like this has a funny habit of making games harder to develop. If you don't NEED the front and backend to be separate components then go for a tightly coupled setup where the state lives in the frontend.
-
Also, a funny side effect of game programming is that loosely coupled components like this can make development harder. If it doesn't need to be split like this, you probably shouldn't.
-
In class i've learnt PyQT, that is for python, and the main language for all practically is Java, but I want to do it in C++, to learn C++ for my final project, and the QT main language is C++
-
on the other hand challenges like these give us valuable experience. Its not often one has the opportunity to write two programs in different languages from scratch and figure out the coupling. I know I would be excited if I got paid to do such things.
And loose coupling is a good constraint to force a good design for your application.
-
I once had to use a network API, which was only available for Python, with sensor drivers whose API was only available in C.
I just used a file as a buffer to transfer data between them and didn't need any other interfaces.
The price paid, was polling. -
No, is not mandatory, and i dont know if it could handle threads on the graphic one, and i think i couldn't try the main porpous of the practice
