Job Interview, Did I Mess Up?
in [C++]
|
From: Thomas Richter on 2 Mar 2010 16:04 Walter Bright schrieb: > A minor nit, the code computes the length of str twice (once with > strlen, once with strncpy). I generally calc the length of all the > strings at the beginning, and use memcpy(). > > I eschew strncpy because I can never remember if the terminating 0 is > included in the 'n' or not. Unfortunately, it is not. Which makes strncpy pretty useless. So long, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel T. on 2 Mar 2010 16:03 Walter Bright <newshound1(a)digitalmars.com> wrote: > Daniel T. wrote: > > > // Answer 3 > > // The interviewer told me that 'min' wasn't standard (which I know is > > // wrong) and asked what I would use in place of it. I told him I would > > // use the ternary operator "?:". > > // He also asked why I new'ed the output instead of changing 'str', > > // I showed him that some of the examples provided with the question > > // showed input strings that were too small to hold the result. The > > // question didn't explicitly say that I should modify 'str', but he > > // thought I should have inferred that from the lack of const in the > > // signature. > > char* copy(char* str, int n) > > { > > char* result = new char[n + 1]; > > memset(result, ' ', n); > > result[n] = 0; > > strncpy(result, str, min(strlen(str), static_cast<size_t>(n))); > > return result; > > } > > A minor nit, the code computes the length of str twice (once with > strlen, once with strncpy). I generally calc the length of all the > strings at the beginning, and use memcpy(). > > I eschew strncpy because I can never remember if the terminating 0 is > included in the 'n' or not. Once I was told that I was supposed to modify the input string, I came up with this implementation: char* copy(char* str, int n) { const int len = strlen(str); if (len < n) memset(str + len, ' ', n - len); str[n] = 0; return str; } A cleaner implementation to be sure, but I have no way to make sure that the memory block that str points to is big enough to hold the result and that makes me very nervous. I simply don't write code that way. Not that the potential leak is any better. The only good solutions I can think of would require a different declaration. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Thomas Richter on 2 Mar 2010 16:04 Juan Pedro Bolivar Puente schrieb: > In any case, if you really care that much about about performance, here > is a just for fun new implementation for very picky boys ;) > > bool f (char a, char b) > { > const char d = a - b; > if (a >= 'a') { > if (b < 'a') > return d <= 'a' - 'A'; > return d < 0; > } > if (b >= 'a') > return d < 'A' - 'a'; > return d < 0; > } A pretty bad solution. If a company works a lot in the international market, it is a *no go* solution. You know, there's more than ASCII. (-; > Or if you prefer in a more obfuscated fashion: > > bool fn (char a, char b) > { > const char d = a - b; > return a>='a' ? b<'a' ? d<='a'-'A' : d<0 : b>='a' ? d<'A'-'a' : d<0; > } Same problem as above, just even less readable. Such code shouldn't go into a production system. Greetings, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Juan Pedro Bolivar Puente on 2 Mar 2010 20:10 > A pretty bad solution. If a company works a lot in the international > market, it is a *no go* solution. You know, there's more than ASCII. (-; > The support for non-ascii characters was a whole in the specification of the problem. Still... >> Or if you prefer in a more obfuscated fashion: >> >> bool fn (char a, char b) >> { >> const char d = a - b; >> return a>='a' ? b<'a' ? d<='a'-'A' : d<0 : b>='a' ? d<'A'-'a' : d<0; >> } > > Same problem as above, just even less readable. Such code shouldn't go > into a production system. > I agree with your complaints. I wouldn't commit it into production code ;) My point was that Daniel's solution was right and Balog's one did not provide much improvement --maybe I misunderstood that performance was his motivation to add the lo_a and lob_b variables. This code was just a game. JP -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Juan Pedro Bolivar Puente on 2 Mar 2010 20:11
> > I am pretty dogmatic about the single exit principle. I've had too many > times when I was trying to find some hard to track bug in someone else's > code only to learn that it had to do with some early return or continue > that bypassed a critical piece of code. > Yes, while I am not against it in small cases, I also agree on the single exit point principle at 99%. >> In any case, if you really care that much about about performance, here >> is a just for fun new implementation for very picky boys ;) >> [Code Snippet...] > > I'm not so worried about performance except in the later stages of a > project. I'm more worried about reducing cyclomatic complexity. My > function only has two possible paths, where the above has four. > I did not mean that you where too worried about performance; I just thought that if performance was the motivation behind Balog's move on adding the lo_a and lo_b variables, one could still play "the performer". I agree on that early optimization is the root to most evil and that one should strive for clean, simple, bugfree code first. Don't take my code snippet too seriously, I would have written almost the same as you if I were asked. And as someonelse pointed out, my "solution" works worse for non-ascii charsets --while still, none of the other solutions work with Unicode charsets neither. JP -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |