The question may sound a little vague, but I wasn't sure how else to phrase it. I was wondering if you could make a C++ file that was similar to a JAR file (so it runs independently of eclipse/cmd). I was also wondering if there is a similar thing to a Frame/JFrame in C++. Not a problem here, I am merely curious.
NOTE: I am a C++ noob, but have been programming in java for over a year.
Your Java code is translated into JAR which is bytecode which is translated in run-time to machine code. You can run this file on each platform.
C++ is translated to machine code at the time of compilation. You can't transport compiled executable between platforms. For each platform you need to compile source files again.
Short answer: No.
Longer answer: No, because C++ is not platform independent. Even if you use only standard library functions like the standard containers, the executable you create can not run on other systems, sometimes not even on other version of the same platform (Linux is known for this).
Yes of course. C++ is a platform independent programming language, which means that you can compile every simple program on every platform, as long as you don't use platform specific features. This means you can compile it on every platform. But that does not mean that your executable is cross-platform, like a Java JAR.
When you compile it, you create a native executable.
In Windows, it compiles to an exe. In Linux / OS X (unix) an extension-free file.
So, it depends on what you really want. (Since your question is a bit vague)
And if you are searching for a single cross-platform solution: the answer is no.
If you are searching for a way to make your application start without terminal: the answer is yes. (But I don't know how, since I never used Windows)
Related
I'm just starting to learn Java (as the second language from Python), but I can't understand the very first point of it. From my understanding, it says:
"Making each kind of compiler (e.g. of C/C++) to each kind of CPU is too much of a hassle. Java, on the other hand, works universally once JVM is installed, because its intermediate code is interpreted by JVM, rather than making a specific native code."
...but don't you need to implement each kind of JVM to each kind of CPU? Is this really an advantage of Java over C/C++?
I think there's a duplicate about this in SO or elsewhere on the internet, but sorry, I couldn't think up any good search word.
each kind of JVM to each kind of CPU is implemented by folks from oracle and other JVM vendors: in case of C/C++ you have to compile YOUR application code for each CPU/OS
Yes, someone has to make a JVM to be able to run on different platforms, but that someone isn't you.
If you go to the download link for Java https://java.com/en/download/manual.jsp you can see there are various JVM builds for Windows, Mac, Linux and Solaris etc
As a programmer, you just have to write your own code and compile it into .class files. Then it's someone else's problem to provide a JVM to run those class files on a specific machine.
Yes someone need to implement each kind of JVM to each kind of CPU? And if this JVM is going to be used, it will also contain a jit compiler, so not much benefit compared to just writing a compiler.
But it might be talking about using the jvm as a target for your own compiled language.
Imagine this: You want to make your own language. Lets call it MyLanguage. Normally you would have to write a compiler, for each cpu, and lots of support code for each operation system you want to support.
But if you just write one compiler which compiles MyLanguage to java bytecode, then the user can run the java byte code on a JVM.
Your language can then be used on any processor/operation system currently supported by a JVM. And you only had to write one compiler.
This is for example what the developers of Scala did.
I am fairly new to Haskell and to programming in general, and I'd like to use Haskell for a project that I have in mind. My major concern is how difficult it will be to write a cross-platform program with Haskell. Ideally, I'd like my final product to work and be easy to install on most Windows, Mac, and Linux machines.
I haven't written any Java, but as I understand it, one of the major strengths of Java is that you can "write once, run anywhere." Since I haven't heard that claim made about Haskell, I assume that a bit more work goes into writing a cross platform Haskell program than in writing a cross platform Java program.
My question is, how much more work are we talking about? If I want my program to work on most Windows, Mac, and Linux machines, how much more of a headache will I be causing myself if I opt to use Haskell instead of a JIT compiled language like Java?
And as a follow-up question:
To what extent can the answer to my first question be applied to all non-JIT compiled languages generally? Are the challenges of creating cross platform software in Haskell more or less equivalent to the challenge of doing so with any other compiled language? How unique is Haskell in this regard?
Thanks!
You can roughly divide languages into two types- Those that require some type of helper program, and those that are compiled. Examples of languages that need helper software include- Java, which needs the jre, HTML needs a browser, interpreted languages like perl or python need the perl/python interpreter. C/C++ and GHC/Haskell are compiled languages, and can run on their own (Haskell has an interpreter also, but you probably can't assume that your users will have it installed).
There are different challenges associates with each approach. To run Java/HTML/Perl/Python, the user has to install the correct version of the associated helper program, but other than this, you can easily supply one version of your program and assume it will work anywhere. To distribute a compiled program, you generally have to compile it on each target OS and supply a separate version for each one. GHC has been ported to Linux, Mac, and Windows, so you can do this. Compiled programs can run on a target machine without installing anything else.... except perhaps a required library....
Library compatibility can be a problem in both types of languages.... Your user may need to install required libs (package managers like apt can do this automatically). This affects all languages (with or without helper software), and I don't consider it an advantage in one type of language vs another (although some languages like Python, and even Java to some extent advertise "batteries included", meaning that pretty much anything you will want is included in the base install).
So, if you stick to normal libs, and don't mind recompiling for each target platform, Haskell programs can work on all the common systems (much better than C/C++, which use slightly different variants on each OS).
See also Do ghc-compiled binaries require GHC or are they self-contained?
Technically, Java is compile once; run everywhere, as it compiles to an intermediate machine-like language. Haskell, like C/C++, compiles to native machine binaries, which means you need to compile everywhere (for every architecture/OS).
I have been hearing a lot lately regarding Scala, Clojure, etc which is supposed to run on JVM.
Does this means that those languages are implementing the Java API underneath?
What does it mean for a language to run under JVM?
Thanks.
It means that these languages can be compiled into Java bytecode, which the JVM executes.
It means that the language compiles down to JVM byte code at some point. The language doesn't need to implement the Java API; the Java API is already there (more or less all the time).
It just means if you have a JVM you should be able to run the language without another VM (although you'll need whatever class files the language compiler and libraries need, obviously).
There is a Virtual machine that java runs one (JVM ),which abstracts away more machine level worries. These languages just use it as an intermediate language oppose to writing architecture specific instructions.
Usually, it just means that you have to install JRE to make sure they can execute.
And usually they don't require JDK, which is used to compile .java code into .class byte file. Instead, they provide their own compiler which runs on the JRE you have installed.
So in summary, you just need a runtime support Java (some specific version).
if you need an in depth information: normabmcclelland#linuxmirroreast.com
Is Java completely Platform Independent ?
if not then, what care needs to be taken to see that your code written in Java can run on Multi Platforms. Basically it should work on Targeted Platforms like Windows (Various versions), Linux (all flavors), Mac and Solaris.
While in practice, most compiled byte code is platform independent, my experience in my 12 years of developing on the Java platform has taught me that there are still idiosyncrasies from platform to platform.
For example, while developing a Java 1.4 Swing application for PC and MacOSX the behavior of dialogs was different if the parent frame is null.
Another example might be with working with the file system and files in general. The Java API has methods to help shield the developer from differences in path separators (/ vs \). When writing to a file, it important to use the FileWriter API as intended so that return characters and such are generated properly for the platform that it is being written on.
So while the motto is "write once, run anywhere" my experience has been for production envs it is write once, test, everywhere.
As a result, having strong unit and integration tests can help with this, as you can execute those tests on the various platforms you want to distribute your software.
Despite some minor issues here and there, it is cool to see your code running on Linux, Unix, Windows and MacOSX (BSD Unix) using the same JARs.
As djacobson pointed out, the answer is a qualified "yes". For the most part, Java developers don't have to worry about platform dependencies. However, you may run into problems when you're dealing with APIs that handle traditional OS and platform functions.
When dealing with File I/O, for example, it's easy to make your code platform dependent by ignoring the differences between file/path separators across platforms (i.e. using '\' rather than File.separator).
For the most part, yes. Because Java compiles to bytecode that's executed by its virtual machine, it can generally be expected to behave the same way regardless of the system sitting under the virtual machine.
However. Not even virtual machines are immune to bugs. A quick Google search turns up the following, for example:
http://www.ibm.com/developerworks/java/library/j-diag0521.html
Differences in behavior can vary from JVM to JVM. Hopefully you won't end up with code that depends on any of these cases... but careful research is worthwhile to know what the limitations of your infrastructure are.
You problem will not be executing your code, but more likely the assumptions you have to make about file paths, available external commands (if you need them), necessary file permissions and other external factors that don't really fall under the "Java" problem domain. Unless you're planning on using native code (via JNI) extensively, Java will not be your problem, your environment will.
Which brings us back to the old adage: "write once, test everywhere".
Threading priorities is one thing to consider. Other OS like Solaris for example has more thread priorities than windows. So if you are working heavily on multi-threading, OS is something that may affect the program's behavior.
The main thing to be concerned with is UI code, to make sure that it is represented properly on all the platforms you will be running on.
Another source of possible issues is deploying to different app servers. There might be incompatibility issues between them.
Java other than that is platform independent, This is also one of its weaknesses, since you are coding to a common denominator and many features of each individual OS are not available.
There are very few and they should be pretty obvious. like System.getProperty("os.name") is clearly OS dependant or it wouldn't work. The most common one is System.exec() as it calls another application which is on your system, again you should know if the application you are calling works the same on every system or not (unlikely).
Along with the above concerns, the main problem I had was actually building on different platforms, which may not be what your asking, but may be something to watch out for.
OS X is especially guilty of this when using the Apple Distribution of Java (why anyone would want to put out their own packaging of Java I don't know but that is a separate argument, and on OSX i dont think you have a choice but to use their java). The Libraries that you may or may not be relying on are in completely different directories, eg libraries instead of lib if my memory serves me correctly. And the IBM java I think packages Classes in different Jars in some cases. Ridiculous!!
Hope that helps.
I've been learning compiler theory and assembly and have managed to create a compiler that generates x86 assembly code.
How can I take this assembly code and turn it into a .exe? Is there some magical API or tool I have to interact with? Or is it simpler than I think?
I'm not really sure what's in a .exe, or how much abstraction lies between assembly code and the .exe itself.
My 'compiler' was written in Java, but I'd like to know how to do this in C++ as well.
Note that if I take the generated assembly, it compiles to a .exe just fine for example with vc++.
Edit: To be more precise, I already know how to compile assembly code using a compiler. What I'm wanting is to have my program to basically output a .exe.
It looks like you need to spawn an assembler process and a linker process. On UNIX, it's as simple as invoking the fork() function, which would create a new process, and the exec() function, specifying the assembler and the linker executable names as the function's parameter, with suitable arguments to those executables, which would be the names of your generated assembly and object files. That's all you'd need to do on a UNIX system.
Normally you use an assembler and a linker to create an exe file. There is no magic involved. The different parts are assembled, a header and other boilerplate is added so the OS knows where the bootstrap code is located for the program and to organize the memory.
The VC++ compiler does that under the hood. You might consider playing a bit on Linux as you can better see the machinery working on Unix platforms. It is fundamentally the same, but it s just difficult to look through to UI on windows.
In principle, each assembly line corresponds to a machine instruction which is just a few bytes in the exe file. You can find them in the specs for the processor. So you can write your own asembeler if you know the codes and the exe format (header, relocation info etc).
How Do Assemblers Map x86 Instruction Mnemonics to Binary Machine Instructions?