Java vs C++, A Newbie's perspective.

[fiziwig]

I'm pretty new to Java, but with loads of C++ experience. Today I
started working on a new ap just for fun and I was trying to decide
whether to use C++ or Java.

After some fiddling around with both I came to an intersting
conclusion, to wit:

Java makes the hard stuff easy, and the easy stuff hard.
C++ makes the easy stuff easy and the hard stuff hard.

When will they invent a language that makes it ALL easy?!

Please tell me it's going to get better as I learn more Java, 'cause I
REALLY like it, but it sure can be a pain at times. ;-)

--gary

 

[Stefan Ram]

Java makes the hard stuff easy

(X-post and Followup-To set to comp.lang.java.advocacy.)

»Java books are usually about doing stuff. C++ books
are mostly about not shooting yourself in the foot.« --
Bjorn Borud

»Memory management in multi-threaded applications is one
of the biggest challenges C++ programmers face. It's a
nightmare. All kinds of techniques and protocols have been
developed to help make the task easier, but none of them
work very well. At the very least they all require a
certain discipline on the part of the programmer that is
very difficult to maintain. And for complex pieces of code
that are being worked on by more than one person it is
very, very hard to get it right.

[Ron Garret now describes that a bug occurred, that has
to do with multi-threading and memory management in C++.]

On top of that, this kind of bug is actually impossible to
introduce except in a language with manual memory
management like C++. In a language with automatic memory
management like Java or Lisp the system automatically
notices that the memory is still in use and prevent it
from being reused until all threads were actually done
with it. By the time this bug was found and fixed (...) I
was a mental wreck, and well on my way to becoming a
physical wreck as well. My relationship with my wife was
beginning to strain. My manager and I were barely on
speaking terms. (...) « -- Ron Garret

 

[josh.s17]

Have you got any specific example of this. I think I know what you mean
as I came from a C++ background as well.

 

[fiziwig]

Have you got any specific example of this. I think I know what you mean
as I came from a C++ background as well.

The straight jacket I'm fighting with right now is trying to use a
StringBuffer object as a string buffer.


I build a long working string from some input data and then output it
to a file, then I want to start over with the next batch of input by
emptying out the string buffer and putting the new stuff into it. In
the process I'm doing loads of search and replace on the text in the
StringBuffer, causing it to grow in length. But guess what, no replace,

replaceAll,...etc. methods in StringBuffer. What good is a string
buffer without search and replace? So what do I do, shuffle the text
back and forth between a String and a StringBuffer to do the search and

replace?

With my scant knowledge of Java I assumed there would be a setText
method for StringBuffer to replace existing text with new text each
time I'm ready to start a new batch. But nope. No such method. Nor is
there a deleteText method for string buffer. In C++ I could write
buffer[0]=NULL; and be done with it, but with a StringBuffer I guess I
have to use the delete method for the whole length of the contents.
Kind of a pain. So much power and so many blind spots where sorely
needed methods just don't exist. The class should have been called
StringAppender, 'cause that's all it knows how to do. And that's the
one thing I DON'T need it to do for me.

So instead of being able to manipulate the data in place in a single
re-usable
buffer I have to create and discard new String objects right and left
making the garbage collector have a nervous breakdown. It's enough to
make me want to code my ap with a character array the old fashioned
way.

--gary

 

[Stefan Ram]

StringBuffer, causing it to grow in length. But guess what, no replace,
replaceAll,...etc. methods in StringBuffer. What good is a string
buffer without search and replace?

http://download.java.net/jdk6/docs/api/java/lang/StringBuilder.html#indexOf(java.lang.String)
http://download.java.net/jdk6/docs/api/java/lang/StringBuilder.html#replace(int, int, java.lang.String)

Nor is there a deleteText method for string buffer.

http://download.java.net/jdk6/docs/api/java/lang/StringBuilder.html#delete(int, int)

For other similar operations see:

http://download.java.net/jdk6/docs/api/java/lang/StringBuilder.html
http://download.java.net/jdk6/docs/api/java/lang/StringBuffer.html

 

[Chris Smith]

The straight jacket I'm fighting with right now is trying to use a
StringBuffer object as a string buffer.

I build a long working string from some input data and then output it
to a file, then I want to start over with the next batch of input by
emptying out the string buffer and putting the new stuff into it. In
the process I'm doing loads of search and replace on the text in the
StringBuffer, causing it to grow in length. But guess what, no replace,
replaceAll,...etc. methods in StringBuffer. What good is a string
buffer without search and replace? So what do I do, shuffle the text
back and forth between a String and a StringBuffer to do the search and
replace?

I have my complaints about Java, but it sounds like your problem has
less to do with the language and more to do with not knowing the API, or
apparently reading the API documentation. Do you have a copy of the API
documentation? setLength(0) clears the contents, indexOf searches, and
replace... well, replaces. You can even search with regular expressions
if you like, although it's a bit of a longer way around because you lack
the convenience functions from the String class. Nevertheless,
StringBuffer implements CharSequence, so it can be used for regular
expression searches just as well as anything else.

In C++ I could write buffer[0]=NULL; and be done with it

Wait a sec... You're supposedly writing code with char arrays in C++
instead of using the standard API std::string class? And then you say
C++ makes easy things easy? That, I really don't understand... unless
you consider not writing buffer overflows to be one of those things that
are just supposed to be hard...

Next time you may want to take more time to learn what you're doing
before you start blaming the tools.

 

[fiziwig]

Next time you may want to take more time to learn what you're doing
before you start blaming the tools.

True enough, and I will take it to heart. There's a LOT of classes to
learn in Java, and being only a few days into it, I've got a loooong
ways to go.

--gary

 

[Moiristo]

I'm pretty new to Java, but with loads of C++ experience. Today I
started working on a new ap just for fun and I was trying to decide
whether to use C++ or Java.

After some fiddling around with both I came to an intersting
conclusion, to wit:

Java makes the hard stuff easy, and the easy stuff hard.
C++ makes the easy stuff easy and the hard stuff hard.

When will they invent a language that makes it ALL easy?!

Please tell me it's going to get better as I learn more Java, 'cause I
REALLY like it, but it sure can be a pain at times. ;-)

--gary

This is what you are looking for:

http://www-instruct.nmu.edu/math_cs/tseethof/cprimer/

 

[Moiristo]

I'm pretty new to Java, but with loads of C++ experience. Today I
started working on a new ap just for fun and I was trying to decide
whether to use C++ or Java.

After some fiddling around with both I came to an intersting
conclusion, to wit:

Java makes the hard stuff easy, and the easy stuff hard.
C++ makes the easy stuff easy and the hard stuff hard.

When will they invent a language that makes it ALL easy?!

Please tell me it's going to get better as I learn more Java, 'cause I
REALLY like it, but it sure can be a pain at times. ;-)

--gary

Not directly on-topic, but this site compares java and c++ with each other:

http://www-instruct.nmu.edu/math_cs/tseethof/cprimer/

 

[Thomas Hawtin]

In C++ I could write buffer[0]=NULL; and be done with it

Wait a sec... You're supposedly writing code with char arrays in C++
instead of using the standard API std::string class? And then you say
C++ makes easy things easy? That, I really don't understand... unless
you consider not writing buffer overflows to be one of those things that
are just supposed to be hard...

The code looks just as valid if buffer was std::string instead of char*.
(g++ complains about implicitly casting NULL to char, but IIRC NULL is
defined to be 0 in C++. Character with ASCII code zero is properly known
as NUL.)

#include <string>
#include <iostream>

int main() {
std::string str("My string");
str[0] = NULL;//'\0';//
std::cout << str << std::endl;
}

Might not do what you expect (possibly it is platform dependent).

Tom Hawtin

 

[Timo Stamm]

Not directly on-topic, but this site compares java and c++ with each other:

http://www-instruct.nmu.edu/math_cs/tseethof/cprimer/

There is an error on the page "Commonalities":

| The following line is acceptable to C++ but not to Java:
|
| if(x = y){//some instructions}
|
| Note carefully, that while the above line is acceptable to a C++
| compiler, it is almost always a mistake.


Provided that x and y are boolean variables, the assignment is a boolean
expression. The following code will compile in Java:

boolean x = true;
boolean y = false;
if (x = y) {}

A decent Java compiler however will issue a warning about a possible
accidental assignment in place of a comparison.


I am missing a comparison between templates and generics, but I guess
the pages are older than Java 1.5.


Thanks for the link,
Timo

 

[Jeffrey Schwab]

I'm pretty new to Java, but with loads of C++ experience. Today I
started working on a new ap just for fun and I was trying to decide
whether to use C++ or Java.

After some fiddling around with both I came to an intersting
conclusion, to wit:

Java makes the hard stuff easy, and the easy stuff hard.
C++ makes the easy stuff easy and the hard stuff hard.

FWIW, I've said the exact same thing about Java. I wouldn't contrast it
with C++ in this respect, though, but with Perl. Perl makes "simple
things simple and hard things possible." I've more or less given up on
using Java for everyday tasks in favor of Ruby and C++, but I do look at
Java first for non-trivial applications.

C++ is good for small tasks and for large ones, but at some point you
have to make a definite transition from thinking small to thinking big.
It seems like there's always a hump somewhere in the middle that
forces you from about 1,000 loc to 5,000.

When will they invent a language that makes it ALL easy?!

When human thought is predictable and easy to codify. In other words:
Never.

Please tell me it's going to get better as I learn more Java, 'cause I
REALLY like it, but it sure can be a pain at times. ;-)

 

[Frank van Schie]

True enough, and I will take it to heart. There's a LOT of classes to
learn in Java, and being only a few days into it, I've got a loooong
ways to go.

Consider it a rule of thumb that, when you're trying to do something and
think "This is too hard! Why didn't they make an object that actually
does what people might want it to do!", there's a good chance they did,
and it's elsewhere in the API.

I trust you do have the Java API docs[0] in front of you when you code?

[0]: http://java.sun.com/j2se/1.5.0/docs/api/ or
http://java.sun.com/j2se/1.4.2/docs/api/

 

[Moiristo]

| The following line is acceptable to C++ but not to Java:
|
| if(x = y){//some instructions}
|
| Note carefully, that while the above line is acceptable to a C++
| compiler, it is almost always a mistake.


Provided that x and y are boolean variables, the assignment is a boolean
expression. The following code will compile in Java:

boolean x = true;
boolean y = false;
if (x = y) {}

You're right, the author should have mentioned that it does compile when
both variables are booleans

A decent Java compiler however will issue a warning about a possible
accidental assignment in place of a comparison.

Sun's javac doesn't give any warning, not even in verbose/debug mode.

I am missing a comparison between templates and generics, but I guess
the pages are older than Java 1.5.

A teacher gave me the link when Java 1.5 wasn't released yet. I would
say that generics are the same for both java and c++?

Thanks for the link,

np

 

[Chris Uppal]

I would
say that generics are the same for both java and c++?

Not even remotely similar. The two systems only just barely overlap. Whatever
you do, don't try to take C++ templates as a guide to Java generics.

-- chris

 

[Timo Stamm]

I would
say that generics are the same for both java and c++?

No, they are quite different. I think it is fair to say that C++
Templates are much more powerful than Java Generics.

 

[Chris Smith]

No, they are quite different. I think it is fair to say that C++
Templates are much more powerful than Java Generics.

I'd say that's a somewhat meaningless comparison. They have different
purposes. The purpose of Java generics has to do with opening up the
type system to allow basic uses of type polymorphism, but without the
possibility of accidental type errors remaining uncaught. The purpose
of C++ templates is to provide a more language-aware kind of macro
facility. These are almost entirely unrelated purposes. The fact that
they can both be used to provide general-purpose collection classes is
almost a coincidence.

If you want a macro facility, then C++ templates are far more powerful,
and Java generics are rather puny and pointless. If you want to express
precise type constraints on expressions, then Java generics are far more
powerful, and C++ templates don't actually even solve the problem at all
but rather shove the problem off, refusing to even think about type-
correctness until the macro expansion is done.

 

[Jeffrey Schwab]

I'd say that's a somewhat meaningless comparison. They have different
purposes. The purpose of Java generics has to do with opening up the
type system to allow basic uses of type polymorphism, but without the
possibility of accidental type errors remaining uncaught. The purpose
of C++ templates is to provide a more language-aware kind of macro
facility. These are almost entirely unrelated purposes. The fact that
they can both be used to provide general-purpose collection classes is
almost a coincidence.

If you want a macro facility, then C++ templates are far more powerful,
and Java generics are rather puny and pointless. If you want to express
precise type constraints on expressions, then Java generics are far more
powerful, and C++ templates don't actually even solve the problem at all
but rather shove the problem off, refusing to even think about type-
correctness until the macro expansion is done.

No, you've misunderstood. C++ templates are not just glorified macros
in any sense. They exist primarily to support compile-time
polymorphism. And IMHO, they are far more powerful than Java generics,
which just add a little compile-time type checking and automatic casting.

For the record, I have no interest in a which-language-is-better
discussion. But the info you've given is just dead wrong.

 

[Chris Smith]

No, you've misunderstood. C++ templates are not just glorified macros
in any sense. They exist primarily to support compile-time
polymorphism. And IMHO, they are far more powerful than Java generics,
which just add a little compile-time type checking and automatic casting.

For the record, I have no interest in a which-language-is-better
discussion. But the info you've given is just dead wrong.

No, I haven't misunderstood at all. Perhaps if you explained why you
disagree with my statement, we could have a productive discussion on the
matter. I am missing that part of your reply, though.

If you don't agree, perhaps you'd like to explain how C++ templates
provide anything powerful enough to express the equivalent of the
following method signature with Java generics:

public void doSomething(List<? extends Auditable> events);

or perhaps the C++ equivalent of:

public class MyClass<T extends Comparable<T>> { ... }

You see? You can't do it. These are type system features, and C++
templates don't provide them. In fact, type-checking a program that
uses a C++ template means expanding the template and then type-checking
the equivalent program without templates. The only checking that occurs
then is the minimal amount needed to prevent undefined behavior. In
particular, this scheme is vulnerable to spurious subsumption.

This is simple fact: C++ templates to not provide as powerful a language
for expression type constraints as Java's generics.

Your flippant comment about "generics... just add a little compile-time
type checking and automatic casting" is half wrong -- casts are
syntactic features in Java, and they don't get added by the compiler --
and half spectacularly right, but in a way that you don't seem to get.
Generics are about expanding the language for type checking to make it
considerably more powerful in being able to express type constraints.
That's what they do, and they do it better than anything in C++.

This is why I pointed out that it's ridiculous to talk about C++
templates being "more" or "less" powerful than generics, since they
serve different purposes.

 

[Jeffrey Schwab]

No, I haven't misunderstood at all.> Perhaps if you explained why you
disagree with my statement, we could have a productive discussion on the
matter. I am missing that part of your reply, though.

If you don't agree, perhaps you'd like to explain how C++ templates
provide anything powerful enough to express the equivalent of the
following method signature with Java generics:

public void doSomething(List<? extends Auditable> events);

The rough equivalent would be:

or perhaps the C++ equivalent of:

public class MyClass<T extends Comparable<T>> { ... }

This can be done in pretty much the same way as the do_something()
example, but it's typically not necessary. If you just use the
necessary features of T in the body of your template, the compiler will
choose the right code for you automatically. If there is an alternative
definition for the same template that *does* fit, it will be used; else,
you'll get a compile-time error. This feature is frequently used to
select among different implementations of a class or algorithm according
to the capabilities of T, and is generally referred to as SFINAE:
"Specialization Failure Is Not An Error."

You see? You can't do it. These are type system features, and C++
templates don't provide them. In fact, type-checking a program that
uses a C++ template means expanding the template and then type-checking
the equivalent program without templates.

Some checks are done before the expansion (unlike macros), but others
are done afterward. That part actually gets complicated.

The only checking that occurs
then is the minimal amount needed to prevent undefined behavior. In
particular, this scheme is vulnerable to spurious subsumption.

Not sure I understand the word "subsumption" in this context.

This is simple fact: C++ templates to not provide as powerful a language
for expression type constraints as Java's generics.

Your flippant comment about "generics... just add a little compile-time
type checking and automatic casting" is half wrong -- casts are
syntactic features in Java, and they don't get added by the compiler --
and half spectacularly right, but in a way that you don't seem to get.
Generics are about expanding the language for type checking to make it
considerably more powerful in being able to express type constraints.
That's what they do, and they do it better than anything in C++.

This is why I pointed out that it's ridiculous to talk about C++
templates being "more" or "less" powerful than generics, since they
serve different purposes.

I'm sorry for offending you. But you really don't seem to know what
you're talking about.