tips for C++ programmers

[Aaron Anders]

woo! i've passed SCJP 1.4 exam today, a BIG thank you to Dan for such a thought-provoking mock exam!
besides a thank you message, i'd like to point out a few java features that are foreign to C++ programmers, hope it helps...

pay SPECIAL attention to all runtime-related features, namely threading and gc

both are platform dependent, also gc generally guarantees NOTHING

threading is supported at grammatical level: synchronized keyword, plus lots of build-in methods

threading is also supported at runtime level: in C++, if main() is finished then program terminates, but in Java, even if main() is finished other threads will keep executing until all non-daemon threads finish execution

wait()/notify()/notifyAll() are introduced (solely, i think) for solving producer/consumer problems

for gc, understand how finally will affect program flow (e.g. if you return inside finally, the exception thown will be neglected and function will be returned normally, also exceptions thown inside finalizer are always ignored) and understand when will object be eligible to gc (e.g. string literals never get gc-ed)

also be careful for some special language features, to name a few

parameter passing mechanism is fixed, you'll be surprised that you can't even swap 2 ints in Java

rules on operator evalulations (e.g. i=i++; issue)

special treatment on "special classes", including String and arrays (e.g. "".equals(null) is legal in Java)

finals are constants, but blank finals are NOT (e.g. you can't use blank final as case label)

function overloading holds even among inheritance relationships

Java provides implicit overloaded operator + and += for String class (in C++, you can't "add" 2 string literals because they're considered as 2 char *)

Java doesn't support explicit operator overloading, so make-sense usages such as Integer+Integer are not allowed

constructor with return value is a legitimate member function

special static/instance initializer syntax and behavior (ref to JLS 8.3.2)

because every member function is virtual by default, so upon instance initialization, base class's constructor will invoke derived class's member function even though derived class hasn't fully initialized yet

downcasting is allowed even on array of object references

all collection classes store elements as Object, so they can't store any primitive type (at least before Java officially support C# style boxing/unboxing mechanism)

STL containers are type compatible with arrays, but this is not the case in Java... so Java provides 2 separate classes, java.util.Collections and java.util.Arrays, to perform algorithms

Java does have preprocessor it translate unicode sequences to corresponding character literals (e.g. '\u000a' trap)

assertions are always compiled to bytecode (you can't filter them out), you can only turn them off at runtime (which is default)

Java implements assertions via AssertionError class, i.e. comply with exception handling mechanism

Cheers!
SCJP 1.4 (95%)
[ February 09, 2003: Message edited by: Aaron Anders ]

[Dan Culache]

constructor with return value is a legitimate member function

Interesting! I didn't know that. Could you please give me an example.
Thanks.

[Dan Chisholm]

Congratulations Aaron!
Thank you for using my exam.

[Dan Chisholm]

Originally posted by Dan Culache:

Interesting! I didn't know that. Could you please give me an example.
Thanks.

Dan,
In other words, a class can contain a method that has the same name as the class. Although it looks like a constructor it is really just a method. The real exam does have trick questions that use methods that appear to be constructors. For example, a question might ask if Java will create a default constructor for a class that has a method that appears to be an explicitly declared constructor. You must always look closely to make sure that you really are looking at a constructor rather than a method that just looks like a constructor.

[Dan Culache]

Thanks Dan, that I knew but I thought he really meant "constructors". This was my point, the way to differentiate between a constructor and a method with the same name is the fact the constructor doesn't have a return value. But I thought he might have come upon some weird scenario... If not then I'm not sure you cannot do the same in C++ since C++ has basically the same overloading rules.
BTW your mock exam is great. Perfectly suited for overconfident folks like I am

[Aaron Anders]

Originally posted by Dan Culache:
Thanks Dan, that I knew but I thought he really meant "constructors". This was my point, the way to differentiate between a constructor and a method with the same name is the fact the constructor doesn't have a return value. But I thought he might have come upon some weird scenario... If not then I'm not sure you cannot do the same in C++ since C++ has basically the same overloading rules.
BTW your mock exam is great. Perfectly suited for overconfident folks like I am

ctor with return value is not allowed in C++
on my GCC 3.2, compilation results in error "return type specification for constructor invalid"
VC7's error message is a bit more comprehensible, "error C2380: type(s) preceding 'Test' (constructor with return type, or illegal redefinition of current class-name?)"
[ February 09, 2003: Message edited by: Aaron Anders ]

[Sridhar Srikanthan]

Congrats Aaron on a great score
Sri

[Sridhar Srikanthan]

for gc, understand how finally will affect program flow (e.g. if you return inside finally, the exception thown will be neglected and function will be returned normally, also exceptions thown inside finalizer are always ignored) and understand when will object be eligible to gc (e.g. string literals never get gc-ed)

Aaron, I am just confused, was it "finally" or "finalize" that you meant? i am sure it was a typo
Sri

[Dan Culache]

Yes Aaron, this is exactly what I was saying:

...the way to differentiate between a constructor and a method with the same name is the fact the constructor doesn't have a return value.

and

..C++ has basically the same overloading rules.

therefore in Java just like in C++ constructors DO NOT have a return value. Maybe my phrasing was not very clear but what I meant is that since you have it C++ it didn't belong under "special Java language features" that C++ programers should be aware of.
BTW thanks for checking it in C++ and
Congratulations on your success!
[ February 09, 2003: Message edited by: Dan Culache ]

[Aaron Anders]

Originally posted by Sri Sri:

Aaron, I am just confused, was it "finally" or "finalize" that you meant? i am sure it was a typo
Sri

"finally" is a keyword used for exception handling
"finalizer" means the gc-related method protected void finalize() throws Throwable
[ February 09, 2003: Message edited by: Aaron Anders ]

[Sridhar Srikanthan]

Originally posted by Aaron Anders:

"finally" is a keyword used for exception handling
"finalizer" means the gc-related method protected void finalize() throws Throwable
[ February 09, 2003: Message edited by: Aaron Anders ]

Aaron,
i know the difference between finally and finalize. I was asking what you meant when you said the exceptions thrown in finally will not be thrown ?
I guess it is finalize...because as far as i know ...
if there are exceptions thrown in finally, then you need to catch them using nested try-catch block inside the finally block or you have to declare the exception thrown in finally block in method declaration.
On the other hand, finalize method is called when the object is about to be GCed for the first time. If the object is resurrected from the finalize method, then finalize method is not called again...also... if there are exception thrown in finalize method, they dont really matter.
I thought you mixed up finally and finalize in your code......thats why I asked the question...

Thanks
Sri
[ February 09, 2003: Message edited by: Sri Sri ]

[Aaron Anders]

Originally posted by Sri Sri:
Aaron,
i know the difference between finally and finalize. I was asking what you meant when you said the exceptions thrown in finally will not be thrown ?
I guess it is finalize...because as far as i know ...
if there are exceptions thrown in finally, then you need to catch them using nested try-catch block inside the finally block or you have to declare the exception thrown in finally block in method declaration.
On the other hand, finalize method is called when the object is about to be GCed for the first time. If the object is resurrected from the finalize method, then finalize method is not called again...also... if there are exception thrown in finalize method, they dont really matter.
I thought you mixed up finally and finalize in your code......thats why I asked the question...
Thanks
Sri
[ February 09, 2003: Message edited by: Sri Sri ]

i may rephrase the statement as
(e.g. if you return inside finally, the exception originally thrown at try block will be neglected and function will be returned normally, also uncaught exceptions thrown inside finalizer are always ignored)
as C++ doesn't have finally block, C++ programmer may be surprised that finally will suppress the exception thrown at corresponding try block, but for Java/C# programmers, this behavior seems natural
JLS 12.6 states that "If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.", i think it can be interpreted as the statement above
[ February 09, 2003: Message edited by: Aaron Anders ]

[Sridhar Srikanthan]

for gc, understand how finally will affect program flow (e.g. if you return inside finally, the exception thown will be neglected and function will be returned normally

Aaron,
I understood what you were saying...
I am quoting from your first post wherein look for the italicized word. What i meant was it should have been a finalize() instead of finally.
Your JLS posting confirms that
If the above quote of yours is as it is, it can be inferred as in finally block if there is an exception , then it is ignored...which is not the case. See the code sample below and you will know what I am talking about

  import java.io.*;
public class Final {
public static void main(String [] args) {
try {
throw new IOException();
} catch (IOException ie) {
System.out.println("IOException caught");
} finally {
 // Exception thrown here must be caught 
 // or declare that the method throws IOException 
throw new IOException(); // in method declaration like
 // public static void main(String [] args) throws IOException
 // otherwise, the code will not compile
}
}
}

Please let me know your comments
Thanks
Sri

[Aaron Anders]

plz refer to the rephased statement:
(e.g. if you return inside finally, the exception originally thrown at try block will be neglected and function will be returned normally, also uncaught exceptions thrown inside finalizer are always ignored)
what i'm saying is situation like:

class Test
{
    public static void main(String [] args)
    {
        try
        {
            throw new RuntimeException();
        }
        finally
        {
            return;
        }
    }
}

it's weird at the 1st sight that program runs smoothly without displaying RuntimeException, but that's default behavior of finally block
HTH
[ February 09, 2003: Message edited by: Aaron Anders ]

[Sridhar Srikanthan]

Aaron,
Now I know what you mean....i was thinking on different lines. After seeing your code sample, I now understand what you meant. Probably, it was a misunderstanding on my part....
Thanks and congrats again for a wonderful score
Sri