Differences between C++ and Java

[d2003xx]

Hi,

Both C++ and Java are object oriented. What are the major differences
between them then? Thank you in advance.

C++ is just a language, Java is a complete platform.

 

[Roedy Green]

Stack based objects tend to be confusing if you are used to the Java
model where objects are always allocated on the heap and managed by
references (similar to pointers.)

Jet sometimes allocated objects on the stack as an optimisation. You
are totally unaware of this. It is just another form of automatic
garbage collection, somewhat more efficient for special cases.

See http://mindprod.com/jet.html

 

[Wojtek]

Think of it as a java primitive, but as an object. You don't use new
when using primitives in java. You wouldn't call java primitives useless?

Who called it useless? I was just not clear about it.

No. Myclass o creates an instance of MyClass on the stack. Once o goes
out of scope, the destructor is automatically called. In C++ MyClass o =
new MyClass() is not even legal syntax. Instead, you must use a pointer,
MyClass* o = new MyClass(). This will allocate o on the heap. It will
not get automatically destroyed, it must explicitly be deleted.

Ok, so for allocation purposes it is treated as a primitive? How do
you pass parameters to the constructor?

 

[Jonathan Mcdougall]

No, in C++ memory management is done automatically when using the

Do you know how a stack works!??
The whole point of a stack is, there's nothing to manage (with regard to
memory), the program 'just' runs and puts variables on the stack or
retrieves them from it.

The C++ run-time system must put the object on the stack, call
constructors, check the scope of the given object, call destructors
and pop the object. That is the management. The programmer has
nothing to do, except defining an object.

Dynamically alocated objects have the very same steps, but you are in
charge of creating the object (new), checking its scope and destroying
it (delete).

You could also say whether my room is clean, is also a matter of opinion.

I find my room to be very clean, but I'm sure you wouldn't think so

Seriously, to take a real example, I find java's Collections very
unclean, compared to C++'s std::vectors. I understand they both allow
different things, but the needed casting can make a very simple
operation look very odd.


Jonathan

 

[Jonathan Mcdougall]

No, in C++ memory management is done automatically when using the

But what use is this? Is "f()" a static method? If so, then why have
the line "MyClass o" at all?

To actually get an object MyClass, do you not need to "o = new
MyClass()"? And then, if you do not manage the "delete o", does not
the object become unreferenced and therefore a memory leak? And now
you must manage it yourself (as per your last sentence).

Please get a good book on C++, I will not explain the language here.

I worked beside people who were working on a rather large C++ project.
This project had memory leaks. It was actually easier to occasionally
bounce the application to recover lost memory than to locate and find
all the memory leaks.

There was bad desing and bad programming.

And if you are thinking that the original authors of the project were
lazy and stupid, then maybe you are right. But EVERYONE makes mistakes
in programming. And memory leaks usually only show up in production.

What`s your point? A bad C++ programmer and a bad Java programmer are
as bad and make as bad programs.


Jonathan

 

[Jonathan Mcdougall]

But what use is this? Is "f()" a static method? If so, then why have

Who called it useless? I was just not clear about it.


Ok, so for allocation purposes it is treated as a primitive? How do
you pass parameters to the constructor?

// similar to import
//
# include <iostream>

class MyClass
{
// everything from here is public
public:

// constructor with no arguments
//
MyClass()
{
// similar to System.out.println("No arguments");
//
std::cout << "No arguments" << std::endl;
}

// constructor with 3 int arguments
//
MyClass(int i, int j, int k)
{
// similar to
//System.out.println("i:" + i);
//System.out.println("j:" + j);
//System.out.println("k:" + k);
//
std::cout << "i:" << i << std::endl <<
<< "j:" << j << std::endl <<
<< "k:" << k << std::endl;
}

void f()
{
// similar to System.out.println("Hello world!");
//
std::cout << "Hello world!" << std::endl;
}

}


int main()
{
std::cout << "Object on stack; default ctor" << std::endl;

MyClass o1;
o1.f();

std::cout << std::endl << std::endl;

std::cout << "Object on stack; 3-args ctor" << std::endl;

MyClass o2(1, 2, 3);
o2.f();

std::cout << "Object on heap; default ctor" << std::endl;

MyClass *o3 = new MyClass; // or new MyClass(), both accepted
o3->f();

std::cout << "Object on heap; 3-args ctor" << std::endl;

MyClass *o4 = new MyClass(4, 5, 6);
o4->f();
}


Output :

Object on stack; default ctor
No arguments
Hello world!

Object on stack; 3-args ctor
i: 1
j: 2
k: 3
Hello world!

Object on heap; default ctor
No arguments
Hello world!

Object on heap; 3-args ctor
i: 4
j: 5
k: 6
Hello world!


For further informations, please refer to comp.lang.c++


Jonathan

 

[Samuel Barber]

Just to be clear, C and C++ are two different languages. The set of
all valid C programs is not a subset of the set of all valid C++
programs.

But that's not why people consider C and C++ different languages. They
are different primarily because C++ has a lot of major features that C
lacks.

Here is an example of a C program that is not a C++ program:

int main(void)
{
int class = 0;
return class;
}

It's the class *feature*, not the mere presence of the keyword, that
makes C++ a different language.

Sam

 

[Roedy Green]

The C++ run-time system must put the object on the stack, call
constructors, check the scope of the given object, call destructors
and pop the object. That is the management. The programmer has
nothing to do, except defining an object.

You don't usually use the term "memory management" for a simple stack.
It refers to something more complicated where you have a heap, must
find a slot of suitable size, compact, shuffle etc.

Both C++ and Java use simple stack allocation for primitives. Both C++
and Java can allocate objects on a heap. The difference is Java gets
rid of the objects automatically, with C++ you must explicitly destroy
the objects. In addition C++ lets you explicitly allocate objects on
the stack, something you cannot do explicitly in Java, but which some
optimising compilers do when it is safe and optimal.

 

[Gary Labowitz]

cyberdude <[email protected]> wrote in message

C++ is just a language, Java is a complete platform.

I teach both languages. They are both a pain, largely because of the lack of
good standard textbooks. (But I digress.)
I get the students in Java who have already had C++. They don't know either
language well enough. I have often thought teaching Java first would be
easier on them and me, but there are some major concepts that drive them
wild with Java that don't occur in C++. And that brings me to my topic:
Not only did you cover a lot of things that make the languages different,
but you left out the most important one that drives us nuts.

With C++ you end up generating a self-contained executable. With Java you
make use of Java's dynamic loading of classes as needed.
The problem is, of course, explaining classpath, jars, and other loading
aspects of running a Java program. How many times have we had "How do you
create a Java executable?" on here?

The dynamic loading makes Java look like it has a smaller footprint. But I
still can't figure out which language is more efficient in generated code.
It would appear that embedded systems must be self contained and could be
used as a measurement, but NO, they all have to have a JVM built in.

Is it any wonder teachers go nuts with this stuff?

 

[Jonathan Mcdougall]

The C++ run-time system must put the object on the stack, call

You don't usually use the term "memory management" for a simple stack.
It refers to something more complicated where you have a heap, must
find a slot of suitable size, compact, shuffle etc.

Both C++ and Java use simple stack allocation for primitives. Both C++
and Java can allocate objects on a heap. The difference is Java gets
rid of the objects automatically, with C++ you must explicitly destroy
the objects. In addition C++ lets you explicitly allocate objects on
the stack, something you cannot do explicitly in Java, but which some
optimising compilers do when it is safe and optimal.

I agree with that. I wanted to point out that C++ had a garbage
collection-like system which is allocating on the stack, since the way
you talked about it was unclear.


Jonathan

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

Jet sometimes allocated objects on the stack as an optimisation. You
are totally unaware of this. It is just another form of automatic
garbage collection, somewhat more efficient for special cases.

Well, I shouldn't have said that objects are *always* allocated on the
heap (generally they are.) But there is no way the programmer can
control allocation/deallocation in Java, hence you can't really use C++
techniques (like RAII) in Java. Not that that would necessarily be bad,
just different.

 

[Roedy Green]

Is it any wonder teachers go nuts with this stuff?

If you just count questions, most of them have to do with installation
of either Java or a servlet womb. Problems with the language itself
are surprisingly low.

The mapping of packages to the file system via classpath and jars has
to be the biggest hurdle.

 

[Sudsy]

Gary Labowitz wrote:

easier on them and me, but there are some major concepts that drive them
wild with Java that don't occur in C++.<snip>

Interesting, since I believe that the optimum approach would be:
- C for the basic language syntax
- Java for the object-oriented approach
- C++ to combine the two
In this scenario you'd have to stay away from the more complex
Java issues (like classpaths and class loaders) and save them
for an "advanced course". Same with elements like templates in
C++. You have to grasp the advanced concepts to be a productive
commercial programmer but I think this ordering is better than
the typical C->C++->Java one.
YMMV.

 

[Gary Labowitz]

Gary Labowitz wrote:


Interesting, since I believe that the optimum approach would be:
- C for the basic language syntax
- Java for the object-oriented approach
- C++ to combine the two
In this scenario you'd have to stay away from the more complex
Java issues (like classpaths and class loaders) and save them
for an "advanced course". Same with elements like templates in
C++. You have to grasp the advanced concepts to be a productive
commercial programmer but I think this ordering is better than
the typical C->C++->Java one.
YMMV.

Indeed. I am now of the opinion that the C should be dropped completely. If
the track says OO in it, forget the C. It is useless. I'd rather just teach
C++ from scratch.

 

[Harald Hein]

In this scenario you'd have to stay away from the more complex
Java issues (like classpaths and class loaders)

There is nothing complex in classpath and class loader. Sorry, but a
programmer who doesn't get the simple concept of a search path "First
look here, then here, then here ..." should refrain from touching a
keyboard and maybe try to make a career in used-care sales.

 

[Gary Labowitz]

There is nothing complex in classpath and class loader. Sorry, but a
programmer who doesn't get the simple concept of a search path "First
look here, then here, then here ..." should refrain from touching a
keyboard and maybe try to make a career in used-care sales.

Ah, but Sudsy, what you say is exactly what's wrong. They do know that a
search path tells them to "look here." But classpath doesn't do that. It
says "Start here and first look for the directory/subdirectory(ies) that are
defined with the package name used and then look there, unless it's a jar in
which case expand the jar and find the directory/subdirectory(ies) structure
in the jar and then look there." That's what drives them nuts. And, of
course, "if the class file isn't in a package (naughty and hard to work
with) then the classpath doesn't have to find the directory structure ...
just look here."
This is NOT what they learned about PATH environment variable.

 

[Will Hartung]

Ah, but Sudsy, what you say is exactly what's wrong. They do know that a
search path tells them to "look here." But classpath doesn't do that. It
says "Start here and first look for the directory/subdirectory(ies) that are
defined with the package name used and then look there, unless it's a jar in
which case expand the jar and find the directory/subdirectory(ies) structure
in the jar and then look there." That's what drives them nuts. And, of
course, "if the class file isn't in a package (naughty and hard to work
with) then the classpath doesn't have to find the directory structure ...
just look here."
This is NOT what they learned about PATH environment variable.

This is true, but CLASSPATHs don't drift to terribly far. The CLASSPATH
simply enumerates a list of locations from which the stock class loader
searchs for a class. Jars are no different than directories. They really are
pretty simple. The real pre-requisite that brings it all together is
understanding Packages.

The other trick is to realize that the classes in the CLASSPATH are fused
together into a single namespace (the System ClassLoader), and how potential
conflicts are resolved (earlier on the CLASSPATH wins).

I appreciate that it is a bit of a hurdle for programmers to get over, and
unfortunately many never really seem to "get it", and just smash entries
together on a CLASSPATH until "things work" without understanding why they
work.

However, to disagree with "Sudsy", many new developers who are working with
web applications are immediately thrown into the abyss of ClassLoader Hell.
Consider that the most basic of webapps deployed underneath Tomcat 4.x has
no less than FIVE distinct ClassLoaders running, only one of which is
actually affected by the CLASSPATH environment variable.

If you think that a CLASSPATH is complicated, wait until you start
discovering that your application is challenging all of your belief because
the CLASSPATH doesn't seem to have the desired effect on it.

So, unfortunately, CLASSPATH and ClassLoaders can become Java 101 topics for
new developers, and it can be quite a leap to grasp.

In summary, CLASSPATH is really a pretty simply concept once you understand
that Jar file == Directory, but that doesn't necessarily mean that
CLASSPATHs and ClassLoaders are trivial to understand.

Regards,

Will Hartung
([email protected])