Recently, I participated in Codeforces Round 873 (Div. 2). I was doing well, and in the last 5 minutes of the contest I solved problem D1, putting me at rank 200 and with CM performance. I was happy with myself until this happened:
I saw that I got TLE on test case 13 and quickly realized what happened. I chose to use Java in this round, and I had somehow fallen in another one of Java's traps. Now, I've decided to compile a comprehensive list of these pitfalls so no one can FST to them again. (Hopefully after you see this you'll be convinced to just use C++.)
1. Array sorting
2. String concatenation
3. Input/output
4. Comparing objects
5. Stacks
In conclusion, you should just use C++, because this is just too much stuff to remember. With C++, none of these are even issues.
If you have any more Java pitfalls, feel free to comment about them!
In conclusion, you should just use C++, because this is just too much stuff to remember. With C++, none of these are even issues.
Java is good enough to get you a decent rank. There are quite a number of red coders who use Java.
If you use a programming language without understanding what you are doing, then you will obviously run into this sort of problems. C++ has its pitfalls too.
For example in C++:
for(int i = 0; i < n; i++) c = c + a;
can potentially be much slower thanfor(int i = 0; i < n; i++) c += a;
where
c
anda
are strings.But then again, C++ is indeed faster than Java given that you use both languages correctly. But don't think that you can get away with slipshod understanding by using a faster programming language.
I agree that C++ has issues too, but in general, it has fewer issues, and the main ones (I/O, unordered_map) are really easy to fix. Therefore, it's less likely that you'll FST or get hacked with a C++ submission. On the other hand, it's really easy to fall into "black magic death traps" in Java that you didn't even know existed, especially considering most problems are made by C++ coders.
Java is definitely good enough to get you a decent rank though (see SecondThread) and if you'd like to use Java then by all means go ahead.
Thanks for the helpful blog.
Because of small stack size in java , many times DFS gives runtime error Is there any solution for it other than using BFS?
for point 4 , instead of using equals , converting to int from integer than using == is much cleaner.
Setting stack size in Java
It worked , Thanks a lot
Could you explain what this is and why that problem is occurring? I'm still a little confused about what the runtime error is, and why stack size has anything to do with this. This is probably due to my ignorance of Java docs, so any explanation would be appreciated!
Actually DFS uses recursion and recursion uses stack and there is a size limit of stack , so when the recursion goes deep the stack requires more memory , so by default it less and we can change it.
e.g
This Problem.
This gives run time error and this passes after adjusting the stack size by adding this line
new Thread(null, new Main(), "whatever", 1<<27).start();
oh, I see now thanks for the explanation. Your comment on longs was separate from your comment on stack size. I thought something about stack size was affecting the ==s operator on longs
If the reference is compared, then shouldn't a==b have the same problem as c==d. why does one return true but the other return false? a, b, c, d are all Integers aren't they?
there is some random java bullshit about numbers below 128 and numbers above iirc, maybe i remember the wrong border though
Oh. Considering all these things, do ppl even like java? It seems very alien to me as a programming language lol.
above 128 , for Integers == doesn't works
thanks for rectifying :) updated
Java has something weird they do with small enough Integer values called auto-boxing.
Auto-boxing is the idea of automatically converting a primitive (e.g.
int
) and its corresponding wrapper (e.g.Integer
).Basically, $$$a$$$ and $$$b$$$ will both point to the same reference as they're small enough in absolute value ($$$-128 \le a,b \le 127$$$ if I remember correctly), whereas $$$c$$$ and $$$d$$$ are big enough that they'll be equal in value (
c.equals(d)
istrue
) but not in reference (c == d
isfalse
).I see. Im guessing they store all the number from [-128, 127] in memory and then create a reference to it when creating the variable?
as a non-java coder, I am asking myself... why TF doesn't Java offer an easy way to compare two numbers (using
=
or==
or whatever) and instead you must use the ugly.equals()
?Integer
is a pointer in Java. The value type isint
.==
has been already defined on all pointers as comparingobject id
(kind of memory address), andInteger
doesn't want to break this.If you use
int
(it's a more common case), you use==
. But however, you will be unable to assignnull
to the variable since it's not a pointer.null
is important for collections in Java, since the value may not be always present. For example.1.arrays.solution-3 , how does that work?
Same as randomized quick sort algorithm.
For 5, you can use Dequeue also. It has the same complexity as of ArrayList.
As you mentioned in the solution, all of the problems you mentioned with JJava can be bypassed effortlessly. Don't motivate people to leave Java. C++ also has issues like initializing randomly for primitive data type arrays. Java uses default values for them (0 for int[] and false for boolean[]).
Also, Java does not provide Segmentation fault, which I like about Java.