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

java-programmer, Java vs C++, A Newbie's perspective. On 2006-07-02, Stefan Ram <email***@***.com> wrote:
> "fiziwig" <email***@***.com> writes:
>>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)

And for regular expressions use a Pattern and pass the StringBuffer to
matcher() and use the appendReplacement/appendTail methods.
(Requires another temp StringBuffer but you could wrap it all up in a
new Class "StringBufferOnSteriods"
>
> 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
>

java-programmer >> Java vs C++, A Newbie's perspective. On 2006-07-02, Stefan Ram <email***@***.com> wrote:
> "fiziwig" <email***@***.com> writes:
>>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)

And for regular expressions use a Pattern and pass the StringBuffer to
matcher() and use the appendReplacement/appendTail methods.
(Requires another temp StringBuffer but you could wrap it all up in a
new Class "StringBufferOnSteriods"
>
> 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
>

java-programmer >> Java vs C++, A Newbie's perspective. Timo Stamm wrote:
> | 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

java-programmer >> Java vs C++, A Newbie's perspective. Moiristo wrote:

> 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

java-programmer >> Java vs C++, A Newbie's perspective. Moiristo schrieb:
> 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.

java-programmer >> Java vs C++, A Newbie's perspective. Timo Stamm <email***@***.com> wrote:
> Moiristo schrieb:
> > 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.

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.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

java-programmer >> Java vs C++, A Newbie's perspective. Chris Smith wrote:
> Timo Stamm <email***@***.com> wrote:
>> Moiristo schrieb:
>>> 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.
>
> 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.

java-programmer >> Java vs C++, A Newbie's perspective. Jeffrey Schwab <email***@***.com> wrote:
> 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.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

java-programmer >> Java vs C++, A Newbie's perspective. Chris Smith wrote:
> Jeffrey Schwab <email***@***.com> wrote:
>> 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);

The rough equivalent would be:

void do_something(list<Auditable*> events);

> 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. :(

java-programmer >> Java vs C++, A Newbie's perspective. Jeffrey Schwab wrote:
> Chris Smith wrote:
>> Jeffrey Schwab <email***@***.com> wrote:
>>> 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);
>
> The rough equivalent would be:
>
> void do_something(list<Auditable*> events);

Ah! I missed the case of "events" being a list of some derived type
from Auditable, which was of course your point. For this, you have to
use something called "template templates." I don't know whether you can
specify specifically that the elements are of types derived from
Auditable right in the same line; you might have to put a (compile-time)
check in the body of the template. If you want, I'll give it a shot. :)

java-programmer >> Java vs C++, A Newbie's perspective. Jeffrey Schwab <email***@***.com> wrote:
> > public void doSomething(List<? extends Auditable> events);
>
> The rough equivalent would be:
>
> void do_something(list<Auditable*> events);

~$ cat main.cpp
#include <list>
using namespace std;

class Auditable { };
class Event1 : public Auditable { };
class Event2 : public Auditable { };

void do_something(list<Auditable *> events);

int main(int argc, char *argv)
{
list<Event1 *> e;
do_something(e);

return 0;
}
~$ g++ main.cpp
main.cpp: In function `int main(int, char*)':
main.cpp:13: error: conversion from `std::list<Event1*, std::allocator
<Event1*>>' to non-scalar type `std::list<Auditable*, std::allocator
<Auditable*> >' requested

> > 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.

Since the do_something() example didn't work, I suppose that doesn't
bode well for other things done in pretty much the same way.

> 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.

Yes, absolutely; which makes templates a great mechanism for
abbreviating and abstracting code, but not for more powerful type
checking.

> > 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.

You seem to have assumed a rather narrow definition of "macro". That
explains some of the confusion here. I did not mean to imply such a
narrow definition of a macro. Nevertheless, no checks that are
interesting in terms of the expressive power of the type system are
performed prior to macro expansion. Templates allow all sorts of
interesting evaluation to occur within the compiler (an entire Turing
complete language, in fact), but very little additional expressive
power.

> > 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. :(

It means that given:

class Dog { public: void run(); };
class Thread { public: void run(); };

and:

class Scheduler<T> { ... t.run(); ... };

it is just as valid to the language to declare Scheduler<Dog> as
Scheduler<Thread>, and there's no mechanism in the language to prevent
that from occurring. The example becomes more relevant when you
consider operator overloading, but I think it's easier to understand
with plain methods. This is just an example of the minimal thing that
would be prevented by an extension to the type system to handle
reasonable constraints about parameterized types. It's not the only
possible benefit of such an exercise. If you'd like to point to others,
I'm all ears.

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

Feel free to correct me if I'm wrong about something. So far in this
thread, I don't believe I have been wrong about anything. So far, it
appears that asking whether Java generics or C++ templates are more
powerful is much akin to asking whether the President of the United
States is more powerful than a locomotive. Depending on whose
definition of "powerful" you adopt for evaluating the question, you come
up with different answers. It further appears that you responded to my
message without taking the time to understand the sense in which
generics in Java are powerful. Understandably, then, you reached an
incorrect conclusion.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

java-programmer >> Java vs C++, A Newbie's perspective. Chris Smith schrieb:
> Timo Stamm <email***@***.com> wrote:
>> Moiristo schrieb:
>>> 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.
>
> I'd say that's a somewhat meaningless comparison. They have different
> purposes.

On a very abstract level, they both serve the same purpose of generic
programmming. As Bjarne Stroustrup said: "we need to parameterize our
containers with the element type and do operations on parameterized
containers." That's what Java Generics do.

Timo

java-programmer >> Java vs C++, A Newbie's perspective. Timo Stamm <email***@***.com> wrote:
> On a very abstract level, they both serve the same purpose of generic
> programmming. As Bjarne Stroustrup said: "we need to parameterize our
> containers with the element type and do operations on parameterized
> containers." That's what Java Generics do.

To me, it looks as if they only serve the same purpose on a NOT very
abstract level. Ultimately, generic collections of reference types in
Java are possible not because of generics, but because of the existence
of a universal supertype for all reference types. Generic collections
or primitive data are not possible because Java doesn't provide a
universal supertype for primitive data (neglecting boxing conversions),
and generics don't change that.

It's important for Java programmers to understand that generics in Java
are a type system feature. They do not in any way relate to what the
code does! Java's generics define a somewhat intricate language for
expressing syntactic constraints on situations in which certain code is
appropriate. Once it is determined that the code is appropriate, the
code is executed exactly as if it had not been written with generics at
all. Generics allow the programmer to limit the range of uses of some
piece of code, and then rely on the information added by these
constraints later on.

This is a huge difference from C++ templates, the whole purpose of which
is to write templates for code, which are expanded to different code
under different uses. While some of the possible expansions of
templates may differ from each other only in type checking, there are
others that differ from each other in terms of static resolution of
method calls, or even (with template specialization) completely
different structures of code. At the same time, C++ templates do NOT
provide any fundamentally new vocabulary for expressing type
constraints. Every pure type constraint on code using C++ templates is
a type constraint from the non-templated subset of the C++ language
after expansion of the templates. (I'm neglecting the type constraints
that are defined on non-type template parameters, as in
"template<int a>", because they are outside the scope of the discussion
here.) Unlike Java, in which generics augment the subtype relation with
wildcard types that allow more flexible typing of expressions, C++
templates don't introduce any type relationships that wouldn't otherwise
be there.

Clearly, it's possible to find similarities between these two features,
but I certainly wouldn't call them abstract. Instead, the similarities
seem to be that both features are used in the context of collection
classes.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

java-programmer >> Java vs C++, A Newbie's perspective. Chris Smith wrote:
> fiziwig <email***@***.com> wrote:
>>
>> 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.

> 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

In general it is probably not a good idea to use setLength(0) to reuse a
StringBuffer. In the past the JDK had code to optimize conversion from a
StringBuffer to a String. The new String would actually not be a copy of
the contents of the StringBuffer, but instead they would share the same
char array. If after converting to a string you modified the
StringBuffer, then the StringBuffer would do a copy for its own use so
that it could modify it.

There would also be a problem with this sharing behavior with memory
usage. The char array in the StringBuffer can be larger than the amount
of text that it holds. You could for instance have a StringBuffer with a
char array that is several K but only holds a few characters. If you did
a toString then the String would then inherit this extra space.

By reusing the StringBuffer repeatedly you tended to accumulate extra
space as the capacity of the StringBuffer would be whatever was the
largest amount of text you had in it and you would then pass on this
bloat to the strings you created.

Looking at the source, I don't think this is the case any more in 1.5,
but is something to be aware of.

--
Dale King

java-programmer >> Java vs C++, A Newbie's perspective. Dale King <email***@***.com> wrote:
> Looking at the source, I don't think this is the case any more in 1.5,
> but is something to be aware of.

I'm looking at the source, and it looks like this hasn't changed. I
agree it's something to be aware of, and that reusing a StringBuffer
unnecessarily is not the greatest idea. That said, if there's actually
a *reason* to reuse the StringBuffer, such as if most of the content
will be remaining the same, the problem is easily avoided by use of the
new String(String) constructor.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

java-programmer >> Java vs C++, A Newbie's perspective. Chris Smith wrote:
> Dale King <email***@***.com> wrote:
>> Looking at the source, I don't think this is the case any more in 1.5,
>> but is something to be aware of.
>
> I'm looking at the source, and it looks like this hasn't changed.

It most certainly looks like it has changed to me. When you call
toString on a StringBuffer in 1.5 it makes a copy of the char array.
Prior to 1.5, the String class would not get a copy but would get the
actual char array in the StringBuffer and the StringBuffer would be
marked so that a copy needed to be made before any modification.

I think with the advent of StringBuilder in 1.5 and the gotchas that
this created they decided the optimization was no longer necessary.

> I
> agree it's something to be aware of, and that reusing a StringBuffer
> unnecessarily is not the greatest idea. That said, if there's actually
> a *reason* to reuse the StringBuffer, such as if most of the content
> will be remaining the same, the problem is easily avoided by use of the
> new String(String) constructor.

Actually, I don't think that would solve the issue. As I remember that
would not eliminate the wasted space. That would just give you 2 String
objects pointing at the same char array with wasted space. I believe you
actually had to use substring in order to trim the unused char array space.

If you are using 1.5 it looks like reusing StringBuffer (and more likely
StringBuilder) is not a problem. If you are using 1.4 or before you need
to be careful and understand the gotchas.

I found an old thread on this topic:

http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/e4144e0c6ffbcfae?tvc=2

--
Dale King

java-programmer >> Java vs C++, A Newbie's perspective. >Java makes the hard stuff easy, and __the easy stuff hard.__
It's because Java is right and force you to do all in correct way. For
example, when it's possible that Exception could be thrown then you
MUST say how to handle it.
Even when you say _do nothing_ {} you must say it.

In C++ you just ignore (or may ignore/or may not) all troubles till
they appear.
Java forces you to write correct code.
C## has special key _unsafe_ to be like C++. Which makes is similar and
as bad as C++.

(I have assembler, C, C++ and Java experience for 10 years each).
Alex.

fiziwig wrote:
> 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

java-programmer >> Java vs C++, A Newbie's perspective. Dale King <email***@***.com> wrote:
> Chris Smith wrote:
> > Dale King <email***@***.com> wrote:
> >> Looking at the source, I don't think this is the case any more in 1.5,
> >> but is something to be aware of.
> >
> > I'm looking at the source, and it looks like this hasn't changed.
>
> It most certainly looks like it has changed to me. When you call
> toString on a StringBuffer in 1.5 it makes a copy of the char array.
> Prior to 1.5, the String class would not get a copy but would get the
> actual char array in the StringBuffer and the StringBuffer would be
> marked so that a copy needed to be made before any modification.

You're right. I was confusing the (char[],int,int) constructor with the
(int,int,char[]) constructor.

> > I
> > agree it's something to be aware of, and that reusing a StringBuffer
> > unnecessarily is not the greatest idea. That said, if there's actually
> > a *reason* to reuse the StringBuffer, such as if most of the content
> > will be remaining the same, the problem is easily avoided by use of the
> > new String(String) constructor.
>
> Actually, I don't think that would solve the issue. As I remember that
> would not eliminate the wasted space. That would just give you 2 String
> objects pointing at the same char array with wasted space. I believe you
> actually had to use substring in order to trim the unused char array space.

Actually, it's the opposite. The substring method does not copy the
contents but just returns a new String object pointing to the same
backing. The String(String) constructor does do the copy if the
existing char[] is too big. If you look at the code there, it
specifically checks whether the original String has a char[] that's
longer than its effective length... and if so, it allocates a different
char[] of the right size, and copies the relevant data into it.

(Notice that substring does use the String(int,int,char[]) constructor,
which does NOT copy anything.)

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation