81–84 of 84 posts
This C++ coder seems to have a habit of writing unecessary constructor argument lists. The example works if we change it to:
*x = new X[100];
This is undefined behavior. According to the C++ standard, there is no way to reason about what this does. Anything can happen with this code. Once you have undefined behavior, you lose the ability to reason about your entire program. Thus, this program does not solve the problem. It demonstrates a lack of knowledge about undefined behavior in C++. Rating: Absolutely would never hire this candidate.
Earlier quoted context omitted.
A bug-free one (nonexistent). :) In seriousness, the interview is supposed to give a taste of how the candidate thinks and codes in general. If they start using every obscure language feature under the sun, I am not too sure they got the idea.
Do you seriously believe, that someone who can write stuff like this can’t write ordinary code?
Maybe they work well on their own, or maybe their solutions collapse when given a problem of a complexity greater than the leetcode problems.
Earlier quoted context omitted.
If someone wrote that in an interview I'd be keen to get them to explain to me exactly how it works... my C++ being a bit rusty (I mean old).
Explanation: 1. There are no data members inside X, in this case the size of the structure is 1 byte. 2. main() does nothing. 3. *x = new X[100]() - this requests a new array of 100 elements of type X, at a stage before main() is called. 4. The new[] operator is overloaded in the class, this operator must return the address for the requested array. It returns the address of the empty string object plus 1. 5. For each…
But maybe it is not UB because it is not calculated explicitly by the program, hard to tell