Differences between C++ and Java

Discussion in 'Java' started by Roedy Green, Nov 16, 2005.

  1. Roedy Green

    Roedy Green Guest

    A link to an essay on the differences between C++ and Java in the Java
    glossary has died, so I concocted this little essay to replace it at
    http://mindprod.com/jgloss/cpp.html

    In Java, the sizes of int, long etc. are rigidly defined in terms of
    bits. In C++ they are platform-dependent.

    In Java, the JVM behaves at if it were big endian, even if internally
    it is actually little-endian. In C++, the endianness is platform
    dependent.

    In Java, garbage collection of unreferenced objects is automatic. In
    C++, you manually manage memory.

    In Java, references are constrained to point only to the beginnings of
    objects. In C++, you can do arithmetic on pointers and make pointers
    point anywhere in the address space.

    In Java you cannot overload operators. In C++, you can.

    In Java, by default methods are virtual (overrideable). In C++, by
    default, methods are non-virtual.

    Java object code (class files containing JVM byte codes) will run
    unmodified on any platform. C++ object code must be first linked to
    produce an executable containing platform-specific machine
    instructions. It will run only on one platform.

    Java checks all subscripts that they are in bounds and all casts for
    validity. C++ does not.

    Java requires a JVM to execute. C++ programs are usually freestanding.
    Java does not use a preprocessor. C++ makes extensive use of a macro
    preprocessor.

    Anything else important to say?

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #1
    1. Advertising

  2. Roedy Green

    Pep Guest

    Roedy Green wrote:

    > A link to an essay on the differences between C++ and Java in the Java
    > glossary has died, so I concocted this little essay to replace it at
    > http://mindprod.com/jgloss/cpp.html
    >
    > In Java, the sizes of int, long etc. are rigidly defined in terms of
    > bits. In C++ they are platform-dependent.
    >


    You could argue that in Java they are still platform dependent, in that they
    are set as per the Java VM (virtual machine) which is always the same
    regardless of the physical machine that it is running on.

    > In Java, the JVM behaves at if it were big endian, even if internally
    > it is actually little-endian. In C++, the endianness is platform
    > dependent.


    Again you could argue that in Java the endianess is platform dependent,
    i.e.e as per the Java VM (virtual machine).

    >
    > In Java, garbage collection of unreferenced objects is automatic. In
    > C++, you manually manage memory.
    >


    But this does not guarantee when the garbage collection will be performed in
    Java, whereas in C++ you can determine when it will happen.

    > In Java, references are constrained to point only to the beginnings of
    > objects. In C++, you can do arithmetic on pointers and make pointers
    > point anywhere in the address space.
    >
    > In Java you cannot overload operators. In C++, you can.
    >
    > In Java, by default methods are virtual (overrideable). In C++, by
    > default, methods are non-virtual.
    >
    > Java object code (class files containing JVM byte codes) will run
    > unmodified on any platform. C++ object code must be first linked to
    > produce an executable containing platform-specific machine
    > instructions. It will run only on one platform.
    >


    Again, arguably Java byte code will only run on one platform, i.e the Java
    VM (virtual machine).

    > Java checks all subscripts that they are in bounds and all casts for
    > validity. C++ does not.
    >
    > Java requires a JVM to execute. C++ programs are usually freestanding.
    > Java does not use a preprocessor. C++ makes extensive use of a macro
    > preprocessor.
    >
    > Anything else important to say?
    >


    Not looking to cause an argument, just playing with words :)
    Pep, Nov 16, 2005
    #2
    1. Advertising

  3. Roedy Green wrote:
    > Anything else important to say?


    Interfaces

    Abstract classes are done differently

    MI in C++

    Generics are different

    Java has built in Threading and synchronization mechanisms


    If you start talking about standard library functionality then there's a
    lot more.

    robert
    Robert Klemme, Nov 16, 2005
    #3
  4. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 13:30:32 +0000, Pep <> wrote,
    quoted or indirectly quoted someone who said :

    >You could argue that in Java they are still platform dependent, in that they
    >are set as per the Java VM (virtual machine) which is always the same
    >regardless of the physical machine that it is running on.


    Dependent implies change with the thing depended on changes. The
    sizes are invariant in Java. They are part of the language spec. They
    apply even when there is no JVM, e.g. Jet.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #4
  5. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 13:30:32 +0000, Pep <> wrote,
    quoted or indirectly quoted someone who said :

    >Again you could argue that in Java the endianess is platform dependent,
    >i.e.e as per the Java VM (virtual machine).


    Unless there is something new in nio, I don't think you can get a
    program to produce different endianness files or socket streams on
    different machines with the same code. In other words, it does not
    depend on the platform. That even applies to 64 bit jvms.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #5
  6. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 13:30:32 +0000, Pep <> wrote,
    quoted or indirectly quoted someone who said :

    >
    >But this does not guarantee when the garbage collection will be performed in
    >Java, whereas in C++ you can determine when it will happen.


    There is no official GC in C++ is there? It is always an add on. In
    Java you can suggest when a good time to run might be, but you cannot
    force it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #6
  7. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 13:30:32 +0000, Pep <> wrote,
    quoted or indirectly quoted someone who said :

    >>

    >
    >Again, arguably Java byte code will only run on one platform, i.e the Java
    >VM (virtual machine).

    You are in the wrong major. Take up corporate law.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #7
  8. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 15:41:14 GMT, Roedy Green
    <> wrote, quoted or
    indirectly quoted someone who said :

    >>Again, arguably Java byte code will only run on one platform, i.e the Java
    >>VM (virtual machine).

    > You are in the wrong major. Take up corporate law.


    In java terminology Platform-independent refers to the ability to run
    Java byte code on many different platforms if they have a JVM
    implementation.

    Platform refers then not to the JVM but to the OS and hardware that
    host it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #8
  9. Roedy Green

    Pep Guest

    Roedy Green wrote:

    > On Wed, 16 Nov 2005 15:41:14 GMT, Roedy Green
    > <> wrote, quoted or
    > indirectly quoted someone who said :
    >
    >>>Again, arguably Java byte code will only run on one platform, i.e the
    >>>Java VM (virtual machine).

    >> You are in the wrong major. Take up corporate law.

    >
    > In java terminology Platform-independent refers to the ability to run
    > Java byte code on many different platforms if they have a JVM
    > implementation.
    >
    > Platform refers then not to the JVM but to the OS and hardware that
    > host it.


    Like I said, I'm only playing on words.

    Please don't get me wrong, I find Java to be a really useful language and
    certainly prefer the extensibility and ease of use of the language compared
    to that of C++.

    Pep.
    Pep, Nov 16, 2005
    #9
  10. Roedy Green

    AndyRB Guest

    Roedy Green wrote:
    > On Wed, 16 Nov 2005 15:41:14 GMT, Roedy Green
    > <> wrote, quoted or
    > indirectly quoted someone who said :
    >
    > >>Again, arguably Java byte code will only run on one platform, i.e the Java
    > >>VM (virtual machine).

    > > You are in the wrong major. Take up corporate law.

    >
    > In java terminology Platform-independent refers to the ability to run
    > Java byte code on many different platforms if they have a JVM
    > implementation.


    Which is alot more accurate than you original statement:
    "Java object code (class files containing JVM byte codes) will run
    unmodified on any platform"
    AndyRB, Nov 16, 2005
    #10
  11. Roedy Green wrote:
    >
    > Unless there is something new in nio, I don't think you can get a
    > program to produce different endianness files or socket streams on
    > different machines with the same code. In other words, it does not
    > depend on the platform. That even applies to 64 bit jvms.


    The only thing I can think of involves multi-threaded access to
    non-atomic longs (or doubles) on 32-bit platforms. I think the half
    written writes will give the exact opposite of the half read reads.

    java.nio.ByteOrder.nativeOrder() gives the byte order of the underlying
    hardware. But you wouldn't be able to tell if it was lying. And it
    doesn't support PDP-endian.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Nov 16, 2005
    #11
  12. Roedy Green

    Benji Guest

    Roedy Green, while chewing on bamboo shoots, wrote:
    >>But this does not guarantee when the garbage collection will be performed in
    >>Java, whereas in C++ you can determine when it will happen.


    > There is no official GC in C++ is there? It is always an add on. In
    > Java you can suggest when a good time to run might be, but you cannot
    > force it.


    I think he's referring to delete and free. it's technically "garbage
    collection" - just not automatic garbage collection. =P

    --
    Of making better designs there is no end,
    and much refactoring wearies the body.
    Benji, Nov 16, 2005
    #12
  13. Roedy Green

    Oliver Wong Guest

    "Roedy Green" <> wrote in
    message news:...
    [snip]
    > Anything else important to say?


    I did not know this, but apparently in C++, you can have a variable
    which is an object (as opposed to a reference to an object). I.e., in C++,
    you can have:

    <C++ Code?>
    Object* myObject;
    </C++ Code?>

    which is equivalent to

    <Java Code>
    Object myObject;
    </Java Code>

    but you can also have, in C++:

    <C++ Code?>
    Object myObject;
    </C++ Code>

    which has no equivalent in Java. That is to say, in C++, you can have a
    variable which a pointer to an object, or you can have a variable which is
    an object itself.

    I was quite surprised when I found out about this, and I wonder what the
    implications of it are when writing C++ code.

    See:
    http://groups.google.com/group/comp.programming/msg/033a72a206f985f9

    - Oliver
    Oliver Wong, Nov 16, 2005
    #13
  14. Roedy Green

    EdwardH Guest

    Worms and viruses that use buffer overflows can do it only due to C and C++.
    EdwardH, Nov 16, 2005
    #14
  15. Roedy Green

    Oliver Wong Guest

    "Pep" <> wrote in message
    news:dlfla8$qg5$...
    > Roedy Green wrote:
    >
    >> On Wed, 16 Nov 2005 15:41:14 GMT, Roedy Green
    >> <> wrote, quoted or
    >> indirectly quoted someone who said :
    >>
    >>>>Again, arguably Java byte code will only run on one platform, i.e the
    >>>>Java VM (virtual machine).
    >>> You are in the wrong major. Take up corporate law.

    >>
    >> In java terminology Platform-independent refers to the ability to run
    >> Java byte code on many different platforms if they have a JVM
    >> implementation.
    >>
    >> Platform refers then not to the JVM but to the OS and hardware that
    >> host it.

    >
    > Like I said, I'm only playing on words.
    >
    > Please don't get me wrong, I find Java to be a really useful language and
    > certainly prefer the extensibility and ease of use of the language
    > compared
    > to that of C++.


    I'm in agreement with Pep here. What we essentially have here is a
    programming language (Java) for which compilers output a something
    (bytecode), and for which we have emulators (JVMs) for running on all the
    platforms which cannot "natively" run that output, whatever that may mean.

    However, this does not directly address the issue of whether java is
    "Platform Independent" or not. The resolution to that issue depends on the
    definition used for "Platform Independent".

    I don't think that it is "useful" to say that a language is platform
    independent. I use "useful" here to mean that if the label "platform
    independent" is useful, then there should exist some things which are
    platform independent, and some things which are not.

    In theory, for any (language, platform) pair, a compiler could exists
    which compiles programs written in that language and produces native code
    for that platform. For example, you could have a compile which takes Intel
    x86 assembly with SS3 extensions and produces a native RISC excutable
    binary. Does that mean that "Intel x86 assembly with SS3 extensions" is
    platform independent? Probably not. With this interpretation, ALL languages
    are platform independent, so it is not a "useful" definition.

    Can we say that a particular sequence of bits is platform dependent? If
    we have a .EXE intended to "run" on a Win32 platform, we might try to "run"
    it on a MacOSX, or Linux platform and notice that it fails to give the
    desired behaviour. Does this mean that this sequence of bit is platform
    dependent? Maybe. But what if, by some amazing coincidence, the same
    sequence of bit could be interpreted as a valid executable file on two
    different platforms, but the behaviour would vary wildly? E.g. we have two
    different processors with different instruction sets, and the instruction
    represented by the word "0x00000001" on processor A means "add as an integer
    the value in register 1 to the value in register 2 and store it in register
    0" while that same word "0x00000001" means "pop 2 values off the stack and
    multiply them together, and push the result back onto the stack" for
    processor B.

    In the above scenario, the bitstream is a valid program on both
    platforms, and yet yields completely different results. It seems then that
    we should not say that a particular sequence of bits is platform dependent,
    but rather a (sequence of bit, intended behaviour) pair is platform
    dependent. Of course, as soon as we let "intended behaviour" slip into our
    definition, we're REALLY entering murky waters.

    We can take a much more pragmatic (though perhaps just as equally
    "murky") approach to defining it by asking this: "Does the user have to
    worry about what platform they're running on to use our program?" This
    definition might seem overly Java-centric though, in the sense that it was
    specifically crafted so that the answer would be "No" for Java and "Yes" for
    C++.

    My conclusion is that if you're target audience is "end-users", use the
    pragmatic definition listed above. It probably conveys the intended meaning
    using terms that are at least passingly familiar with the audience.

    If the target audience are compiler-writers, system engineers, or other
    people who are interested in technical details, just avoid the term
    "platform independent" altogether and say what you really mean.

    - Oliver
    Oliver Wong, Nov 16, 2005
    #15
  16. Roedy Green

    Oliver Wong Guest

    "EdwardH" <edwardh@N:O:S:p:A:M:edward.dyndns.org> wrote in message
    news:u0Mef.150744$...
    > Worms and viruses that use buffer overflows can do it only due to C and
    > C++.


    That's not nescessarily true. Any time you have a fixed size buffer, you
    can have a buffer overflow attack. And, AFAIK, every implementation of Java
    (the platform, not the language) uses fixed size buffers under the hood. In
    the case of Java, you're essentially trusting that Sun put enough checks to
    catch any time code tries to write data outside the bounds of the buffer it
    was assigned to.

    I believe when working with low level networking APIs in Java (e.g. the
    NIO package), you still need to specify a fixed buffer size. If the class
    library was implemented well, you'd get IndexOutOfBoundsExceptions whenever
    you tried to write outside of it, but there's always the possibility that
    there's a bug in the library that might let a buffer overflow attack go
    through.

    - Oliver
    Oliver Wong, Nov 16, 2005
    #16
  17. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 19:44:00 GMT, "Oliver Wong" <>
    wrote, quoted or indirectly quoted someone who said :

    > I was quite surprised when I found out about this, and I wonder what the
    >implications of it are when writing C++ code.


    It drives you nuts. In addition to that there are multiple ways of
    specifying the same thing.

    You need various addressing operators including . -> * [] &
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #17
  18. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 20:04:41 GMT, "Oliver Wong" <>
    wrote, quoted or indirectly quoted someone who said :

    > I don't think that it is "useful" to say that a language is platform
    >independent.


    Then you misunderstand something fundamental about Java, which we have
    gone over before, (trying to get you to understand the difference
    between native and byte code methods).

    Java goes to great lengths to be platform independent. If you write a
    program in 100% pure java (none of your own platform dependent native
    methods) then your code should work on ANY platform that supports the
    JVM without any modifications or tweaking. This is VERY unlike C/C++.

    Java does not LET you write code that depends on the platform. You
    CAN'T write a program in 100% pure java to tweak the windows registry,
    or get the Unix task number. That is deliberate. It is not being
    mean; it is to ensure your code will run everywhere.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #18
  19. Roedy Green

    Roedy Green Guest

    On Wed, 16 Nov 2005 20:04:41 GMT, "Oliver Wong" <>
    wrote, quoted or indirectly quoted someone who said :

    > I'm in agreement with Pep here.


    Then you too should drop out of computer science and take up the art
    of twisting the truth for profit, namely corporate law. Both of you
    are just playing silly word games.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 16, 2005
    #19
  20. Roedy Green

    Oliver Wong Guest

    "Roedy Green" <> wrote in
    message news:...
    > On Wed, 16 Nov 2005 20:04:41 GMT, "Oliver Wong" <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >> I don't think that it is "useful" to say that a language is platform
    >>independent.

    >
    > Then you misunderstand something fundamental about Java, which we have
    > gone over before, (trying to get you to understand the difference
    > between native and byte code methods).


    Of course, from my perspective, it is you who is misunderstanding. ;)

    For the discussion on native vs byte code methods, indeed, I was in
    error in that I had forgotten of the existence of the "native" keyword in
    Java. I think your mistake, though, is in confusing the concept of Java, the
    programming language, with Java, the platform. It's a common confusion, as
    both concepts have the same name (i.e. "Java"), but they are two distinct
    concepts. Sun officially acknolwedges this dinction, and you will frequenty
    see in their documentation reference to "the Java language" and "the Java
    platform" as two distinct concepts, for example.

    > Java goes to great lengths to be platform independent. If you write a
    > program in 100% pure java (none of your own platform dependent native
    > methods) then your code should work on ANY platform that supports the
    > JVM without any modifications or tweaking. This is VERY unlike C/C++.


    The counter argument to this is that the JVM is not qualitatively
    different from a traditional emulator. You could write an emulator such that
    C++ programs written for Unix run on Windows (see Cygwin) and vice versa
    (see Wine). Does this mean that C++ is also platform independent? Like I
    said in my previous post, I don't think it's useful to say a *LANGUAGE* is
    platform independent, because emulators, compilers or virtual machines could
    be constructed for any language/platform pair.

    > Java does not LET you write code that depends on the platform. You
    > CAN'T write a program in 100% pure java to tweak the windows registry,
    > or get the Unix task number. That is deliberate. It is not being
    > mean; it is to ensure your code will run everywhere.


    I'm not sure about the truth-value of your assertion here, as it depends
    on how you define a lot of things. Would you consider a Java program in
    which the keyword "native" never appears to be a 100% pure Java program? If
    so, I'm relatively confident I could write a Java program without ever using
    the "native" keyword which does one thing on Windows, and does something
    different on Unix.

    Anyway, I don't see how that truth-value has any effect on the original
    claim of "I don't think that it is 'useful' to say that a language is
    platform independent". Are you saying that there DOES exist an unambiguous
    definition for "platform independent" which can be applied to solely
    programming languages (and not to the various compilers, interpreters,
    virtual machines, and other tools that work with the language) which
    everyone should adopt? If so, what is that definition?

    If the definition says anything about what platforms programs written in
    the given language "runs" on, then I argue that this definition does involve
    the compilers, interpreters and virtual machines, and not just the
    programming language.

    This is why I believe that a programming language in isolation should
    not be said to be "platform independent" or not. Maybe I'm wrong, but I
    can't think of any reasonable definition that doesn't involve the tools
    mentioned above.

    - Oliver
    Oliver Wong, Nov 16, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cyberdude

    Differences between C++ and Java

    cyberdude, Sep 13, 2003, in forum: Java
    Replies:
    36
    Views:
    6,469
    Will Hartung
    Sep 17, 2003
  2. Paul Morrison
    Replies:
    1
    Views:
    1,679
    Joseph Dionne
    May 1, 2005
  3. Rasti
    Replies:
    5
    Views:
    435
    Joe Gottman
    Nov 6, 2003
  4. Home_Job_opportunity
    Replies:
    0
    Views:
    482
    Home_Job_opportunity
    Jan 8, 2009
  5. Home_Job_opportunity
    Replies:
    0
    Views:
    565
    Home_Job_opportunity
    Jan 14, 2009
Loading...

Share This Page