We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
Of everyone here, my approach was far the closest to yours.
I messed up a few times, at first I was writing more code than I needed given that the definition of the XRML data is guaranteed to have zero syntax errors, that was an interesting side trip and I found some new C++11 stuff that is nice but would have killed me on any timed test in the world.
Then I stripped things down. I'm all about regexes, and have used them for many years, but I agree that this problem totally gave no hint that they were part of what they were looking for.
People seem to say that everywhere except some embedded systems and game consoles they are now part of modern C++, meaning at least 0x11 -- that is nice and something that is important to remember for the future, but I still support plenty of code that doesn't have that available. In the future, we will all solve C++ parsing issues in regex for 15 minutes. Some of us are already there.
The other mistakes I made were good practice for newbie or rustie mistakes (someone who hasn't used C++ heavily for something like this for a while) -- I got bit in the ass by mixing << and getline() and choking on a newline -- COUGH!! -- *
There are so many, many, many choices for actually doing parsing, and of course the number of times you are writing something from scratch is absolutely dwarfed by the times it is appropriate to just link in an appropriate library that you know well and get on with it, but I guess going forward Perl-style regex is always one of them.
While using the STL algorithms often isn't the best choice for such parsing, I wanted practice in that anyway, because you use the same approach for all kinds of things that aren't parsing or even strings, so I'm happy with that approach.
This is an interesting problem, I probably also don't think it is moderate difficulty, the fact that there are so many radically different approaches to it with their own advantages and disadvantages seems to validate that.
Most correct answers to moderate problems would tend to look pretty similar I think, while the challenging ones are expected to have a million different valid solutions that differ radically.
-- this documents my choice of the term "rustie" to describe developers or users who make what appear to be "newbie" mistakes that they would not have made before they got out of shape. It also applies to mistakes one will make once again if they go too long without practice, unless they have great memory.
Cookie support is required to access HackerRank
Seems like cookies are disabled on this browser, please enable them to open this website
Attribute Parser
You are viewing a single comment's thread. Return to all comments →
Of everyone here, my approach was far the closest to yours.
I messed up a few times, at first I was writing more code than I needed given that the definition of the XRML data is guaranteed to have zero syntax errors, that was an interesting side trip and I found some new C++11 stuff that is nice but would have killed me on any timed test in the world.
Then I stripped things down. I'm all about regexes, and have used them for many years, but I agree that this problem totally gave no hint that they were part of what they were looking for.
People seem to say that everywhere except some embedded systems and game consoles they are now part of modern C++, meaning at least 0x11 -- that is nice and something that is important to remember for the future, but I still support plenty of code that doesn't have that available. In the future, we will all solve C++ parsing issues in regex for 15 minutes. Some of us are already there.
The other mistakes I made were good practice for newbie or rustie mistakes (someone who hasn't used C++ heavily for something like this for a while) -- I got bit in the ass by mixing << and getline() and choking on a newline -- COUGH!! -- *
There are so many, many, many choices for actually doing parsing, and of course the number of times you are writing something from scratch is absolutely dwarfed by the times it is appropriate to just link in an appropriate library that you know well and get on with it, but I guess going forward Perl-style regex is always one of them.
While using the STL algorithms often isn't the best choice for such parsing, I wanted practice in that anyway, because you use the same approach for all kinds of things that aren't parsing or even strings, so I'm happy with that approach.
This is an interesting problem, I probably also don't think it is moderate difficulty, the fact that there are so many radically different approaches to it with their own advantages and disadvantages seems to validate that.
Most correct answers to moderate problems would tend to look pretty similar I think, while the challenging ones are expected to have a million different valid solutions that differ radically.