> By default, Java's Object.equals() only
> returns true if the 2 objects being compared are, in fact,
> the same instance of an object. You need to implement all
> class specific value comparisons yourself.
>
> By default, C++'s operator== compares each
> data member in a class so you usually get a sensible
> object value comparison without having to overload
> anything.
>
> Just the facts.

Or not, as the case might be ;-)

By default, C++ does not provide operator== for user-defined types: that task falls to the programmer.

For equality, Java defaults to identity equality, C++ defaults to nothing, and C# defaults to identity equality for identity-based objects (of class type) and field-by-field comparison for value-based objects (of struct type).

Kevlin

> > Well, it is a problem in C++ that there are not
> standard
> > libraries handling I/O streams with all the associated
> > member methods for asking questions like isEof(),
> > availCount() etc.
>
> Standard C++ provides:
> bool basic_ios::eof() const;

Yes, there is basic_ios, istream, ostream, sstream etc. But I am not enamored by these APIs. They have disconnects and complexities that are just amazing to me to see at such a mature point in the development of this language. Looks like a design by committee where no one was talking (or perhaps even thinking).

> A standard POSIX implementation provides:
> extern int select (int __nfds, fd_set *__restrict
> __readfds,
> fd_set *__restrict __writefds,
> fd_set *__restrict __exceptfds,
> struct timeval *__restrict __timeout);
>
> It may not be pretty, but the complete functionality of
> select is missing from Java's standard
> streams. You need to complicate your design with extra
> threads to mimic it. Also,
>

InputStream.available()

always returns 0
> unless overridden by a derived class which often is not
> the case.

Have you looked at Java since 1.0? The nio package provides access to using native select() or poll() implementations on socket and file streams. There are more enhancements in the works I understand for JDK1.6/6.0

> > But, then someone has to remember to define the
> operator
> > overload for the associated types.
>
> Using the & operator on 2 object
> instances/references to determine if they refer to the
> same object requires no operator overloading.

But, that is more of that confusing syntax stuff that doesn't provide the user with any good sub-conscience glue. Making users type obj1.equals( obj2 ) is not a bad thing either...

> By default, Java's

Object.equals()

only
> returns true if the 2 objects being compared are, in fact,
> the same instance of an object. You need to implement all
> class specific value comparisons yourself.

By default == and .equals() are equivalent for any class that does not override .equals(). In applications where it make sense, you can redefine .equals() to be value based instead of instance based.

> By default, C++'s operator== compares each
> data member in a class so you usually get a sensible
> object value comparison without having to overload
> anything.

I believe this was pointed out to be in error. Would be interesting to see how that would be implemented without == being assigned to a member method to begin with.