 Do you have time to publicly laugh at your Lexar? Of course I do. Let's look at your Lexar tests. I think it's worth investing in making your tests a lot shorter, because there's a lot of repeated pattern here. So test string, start. You can merge these lines into one by just saying start equals, oh, I see. This is not const. Do you intend to modify? Is it supposed to be not const? I understand start as the iterator, but why is this not const? Make this const char. If you make this const char, one, you'll never modify it, because the compiler will tell you, oops, you're modifying it. So if you get the parentheses wrong, it'll catch you. But the main reason you would use const char is to make this nicer. You would be able to say const char, pointer, start equals, and then just put the string literal. So you don't need an SCD string in the middle. So you'd cut out one line in your tests. If I make it constant, it can't increment it. You can, because you're making the char const. You're not making the pointer const. You can make the pointer const, and then this won't work, but you can make the char const, and then all your code will work, because the character, you're not modifying any of the characters, you're only modifying the pointer to point to something else. Yeah, it's confusing, but C++ gives you that choice. And you get token.first, I don't know what that means. Then you cast two ints. Wait a minute. This probably casts it to an int, and then you cast it out of an int into a whatever. It don't look good. So get token, cast, cast, cast, cast, get what? Make this function return token instead of an ints. Then you don't need all these casts here, and you don't need all the casts in your test. Then you don't need to break this up into four lines. So you save the line there. So then your test is only three lines. So what is this thing supposed to do? It's quite a bit past what I know, you'd love to understand. This is reading in some program in the EGB lane. So you might have a two plus two times y times banano, two plus 42 times banano. So when you call get token with this string, it'll tell you, hey, there's a number two. And it's an integer, or maybe an integer two. And then you call it again, and it says, hey, there's a plus. And then you say, do it again, and it tells you there's a 42, which is an integer. You ask for it again, it gives you a star. They ask for again, it's like, oh, it's an identifier, which is a banana. And then you ask for it again, and then you get end of file. So the purpose of the get token function is to split this into all these pieces so that other parts can do some other processing on it. Probably just parsing. This process is called lexing, lexical analysis. And check if there are duplicate depth of points. Okay. What the heck is this, huh? And then you catch it, and then you return red value. What the heck is going on here? Just say return i here on 153 and get rid of the try catch nonsense. Same here. This could be just return red value. Also, this braces in the wrong spot. This should be over here. So string to int, if it finds a decimal at the very beginning, it returns zero. And then if it's successful, there's no decimal point, it also returns zero. So that doesn't seem right. I'm guessing you don't have a test for dot 42 or something. I would add a test for dot 42 because I think that's gonna treat it as an int. I don't know what the number would be, but why is there a comment saying numbers? Get rid of that comment. Go away. Last char. What is this last char stuff for? What do you use that for? Isn't that just star iterator? I don't know why you're storing it there. See, all these stores, they're just bothering me. You keep writing when you don't need to write anything. Why don't you start iterator? That seems more natural to me. If I have my performance head on, which I usually do, or like my don't waste time hat, I wouldn't append into a string. I would instead figure out how long the identifier is and then do a bulk copy. That's how I would do it. What if you hit the end of the string? If I do hash, ABC, end of string, you're gonna hit the null byte and then you're gonna keep going after the null byte until you find a new line. So that's gonna read out a bounce of your string. You need to check for null as well. And I wouldn't return an undefined token if you see a comment. What I would do is go to the beginning of this. I would go to here or whatever and like skip white space after the comments and then parse the next token. I don't think it makes sense to have an undefined token for comments. Overall seems like a decent structure for a lexer. Personally, I don't like using if chains for lexers. I would use a giant switch. Well, this is special, white space is special, but I'd make an outer switch for these ifs. One issue with that is you need to write out all the cases for characters. I had to write out all the letters. I should probably make this more compact. Well, so that sucks, but for the most part it's fine. Want to improve your coding skills? Coming out at twitch.tv slash dragger. I give free code reviews and lessons every weekday.