project euler problem 083 path sum: four ways

The problem is not hard to solve once I realized that this is a standard problem for Dijkstra's algorithm. I used priority_queue in STL to solve this problem and succeeded. Everything looks great and I immediately started working on the next problem.

But I did not think it over. I read the related sections about the Dijkstra in CLRS.
One paragraph is focused on a function called decreaseKey. The weird thing is that there is no such functionality in STL and CLRS has no code snippet for it. So I just ignored it! 

My experience with later-on project euler problems was awful when I can recognize that it is a Dijkstra problem, but with STL, my code ran extremely slow and required huge amount of memory! The root cause is simply that I do not have a function to fulfill the functionality of decreaseKey!

I reviewed this problem for one time two years ago, but I did not review the problem carefully and missed another learning opportunity!

The projecteuler+ on this problem also requires an efficient implementation of Dijkstra.

Learning is of top priority and the number of problem solved is not that important!

project euler 054

Poker Hands

This problem is easy but a little bit boring. And it is not really hard to get the correct answer.  One thing that I found in hackerrank.com is that my code give the wrong answer on a special straight or straight flush like
"1H 2H 3H 4H 5H     2H 3H 4H 5H 6H". The second hand is larger that the first hand.