Hans Beck�rus

Greenhorn
+ Follow
since Aug 23, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Hans Beck�rus

See Topic

I got a good answer on my question there.
[ September 25, 2006: Message edited by: Hans Beck�rus ]
Ok well, I believe an "empty" string is just a \0 in memory with
a reference to it.
If find() returns true on an empty string means it must have
evaluated/included also the \0 as a valid source in its logic.
So empty strings (\0) are handled as a special case.

Thanks for the link!
That really explains it all!

[ September 25, 2006: Message edited by: Hans Beck�rus ]
[ September 25, 2006: Message edited by: Hans Beck�rus ]
Ok, so then my assumption that find() actually
includes the terminating null character in its logic is correct?
That was not what I would have expected from a find()
implementation. A regex on an empty string (only a \0)
I would have assumed returned 'false' since it has nothing to
compare against! Tricky, really tricky! I would certainly
have failed this question on the exam

Thanks.
I think we are aligned in our studies
I just posted the same question!
It is very confusing I agree. Hope someone can explain
the logic behind this output.

Maybe it is the terminating null character that matches the "*"?
In memory the string "ab34df" is actually represented as
"ab34df\0", so index 6 is the terminating null character which would
match the "0 or more" expression. But that I think is a very questionable
implementation of find() if this assumption is correct that find()
includes the \0 and returns 'true' for it.
[ September 25, 2006: Message edited by: Hans Beck�rus ]
No, I wanted to use *, the problem is not undertstanding patterns
themselves, it is the output of the code that confuses me.
As said, this post is obsolete, it was comitted before I managed
to finish it I made another post with the same title.
Please check that for my "real" question.
Sorry by browser comitted the post before it was complete,
can you check my new post?
I have some issues understanding the logic implemented by the find()/start() methods in class Matcher .



I would have guessed that this code produced the output:
0123445
But it actually gives:
01234456
The last '6' is my concern here, why does it return the
extra '6' in the end? For any output to be printed find()
must return true, how can it return true for a value of
start() being 6? It is outside the pattern string range?
I have some issues understanding the logic implemented by the find()/start() methods in class Matcher .

From K&B:
"If you serialize a collection or an array, every element must be serializable! A single non-serializable element will cause serialization to fail. Note also that while the collection interface are not serializable, the concrete collection classes in the Java API are."

What confuses me a little is the last sentence. Should it be interpreted
as if I inherit, and/or implement, a class/interface that is not serializable, it is still OK to have elements of that class in e.g. an
array and serialize that array, knowing off course that any inherited
members will not be part of the serialization process?
The rules for non-serializable superclasses thus applies also to interfaces
that I implement, though interfaces have no member variables and falls out of the serialization process by design.
I think I know the answer but I just want to double-check to make absolutely sure.
I think the answer is simply that if at any point in the code you find an
error (compile-time or run-time) it obsoletes all other possible
choices that may have applied if the code _did_ compile or execute
properly. Look at it as a prerequisite, for any given question, that the code must compile and execute. It is part of your exam to primarily discover any problems in the code, secondly analyse the result of
program logic! That is my interpretation of what is said in K&B, and
also my conclusion after going through a lot of the self-test questions.
But then, I have not taken the exam myself yet so if my statement
is wrong I hope someone that did will correct me
As said before try needs either a catch a finally or both.
What really do you want to accomplish? Why not do a try w/ an
empty finally body. Or have I totally misunderstood your
question?

It is common when you are moving to Java from C or C++ where "," should not present in end. But in java, it is optional. You may give it or not.



Ok, true, I come from the C++ world but still I believe its strange
for Java to allow the extra ','. Why? It is only confusing and makes
you think what other "obscure" syntax does Java allow. I can not really
see the point why to allow it. I answered this question incorrectly since
this case was not really mentioned in the K&B chapter before the self-tests.
If I am to know all kinds of strange combinations allowed it would have been nice with e.g. an exam watch covering this case.

Thanks for your time.
...
int[][] x = {{1,2,}, {1,2}};

I answered that this will fail to compile but it does not!
However, this will fail:

int[][] x = {{1,2,,}, {1,2}};

So what is the rationale behind this?
Why allow the superfluous ',' in the first place?
I was very suprised to see that it does compile.

Example was taken from the self tests in K&B 1.5, "Assignments".
You are right. That is a possible scenario.
The compiler would be able to catch this if it was within the same
source file, but otherwise would fail. Better to have the same
behavour in both cases instead of mixing the two!
Thanks guys. That did the trick.
Now it is all crystal clear!