secondary programming language (graduation req.)

Pages: 12
I thought we were talking about crappy code in general.
closed account (3hM2Nwbp)
I thought we were talking about existing C++ programmers migrating to Java. :\
Picking Java is easier when you don't have previous exposure to C++. E.g. if you don't know C++, you won't get such a stupid idea to use Java finalizers as a replacement for C++ destructors.
I'd say things like this qualify:
1
2
3
4
5
switch (integer) {
case 0: return 0;
case 1: return 1;
// etc.
}



This made me wonder... does this code qualify as stupid as well:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
bool isRightSeparator(char c)
{ switch(c)
  { case ' ':
    case '\n':
    case ':':
    case ',':
    case ';':
    case '+':
    case '*':
    case '^':
    case '=':
    case '_':
    case '/':
    case '-':
    case '`':
    case '[':
    case '&':
    case '\\':
    case '}':
    case '{':
    case '~':
    case '$':
    case ']':
    case '(':
    case ')':
      return true;
    default:
      return false;
  }
}
closed account (1yR4jE8b)
I don't think so. A little verbose looking, but it's obvious what's going on in that snippet.
@tition,
No, it's not stupid, the problem with the code I posted is that the switch isn't doing anything that return integer; doesn't do already. Like darkestfright said, it's just a little verbose. I would've done it like this:
1
2
3
4
bool isRightSeparator(char c) {
        static std::string string = "\n:,;+*^=_/-`[&\\}{~$]()";
        return (string.find(c) != std::string::npos);
}

Yours would probably be faster, though, since there'd be no loop or function call overhead. The compiler would just create a jump table or something.
Wow, talk about a blast from the past. In seventh and eighth grades for me we had computer courses that had us learn BASIC. That was 15 or 16 years ago for me (sometimes being 30 I feel old hearing these kids learning younger than I did).
@chrisname: this relates to a recent topic you posted - and my example was my actual parsing code. To be honest I am kinda relieved to not get a total dissing from you guys.

How do you separate words in your lexer?
[Edit:] I use left and right separators: for example, 12x is separated as "1", "2", "x".
However, x12 is parsed as the single string "x12".
In my terminology, digits are left separators, but not right separators.
[Edit:] Sorry for ignoring the OP's original topic.
Last edited on
@tition,
I haven't done very much with it yet. On my maths evaluator, though, the string "12x" would become "12" and "x". Digits together are assumed to be part of a single number. "x12" would be "x" and "12". All my lexer does is copy tokens in the order it finds them and say what they are. The evaluator will make sense of them later I might change the lexer to convert infix notation ("a + b") into prefix notation ("+ a b"), though, because it's a lot easier to evaluate prefix notation).
The evaluator will make sense of them later I might change the lexer to convert infix notation ("a + b") into prefix notation ("+ a b") though, because it's a lot easier to evaluate prefix notation


Please don't! Doing it the mathematically readable way is far superior, and not difficult at all.

I mean, if we have to adjust our way of expression to computers (rather than have computers adjust to us), then we might as well do all the work ourselves, and not use computers altogether!
Last edited on
Please don't! Doing it the mathematically readable way is far superior, and not difficult at all.


Reading prefix/postfix isn't very hard, and if the lexer is doing it behind the scenes, it doesnt matter. Prefix/postfix is easier for a computer anyway
@tition,
I don't mean to have the users input prefix notation (which, I might remind you, is how LISP works: (define (add a b) (+ a b)) (that might be wrong, I haven't done much LISP programming)). I mean to convert it into prefix notation after it's inputted. I had a simple maths evaluator in Python which converted infix into prefix and then parsed the prefix notation, and it was far easier to parse.
If you can make an expression tree for whatever the user puts in, then all it takes is corresponding traversal of the tree you made. Not sure if this would be any easier to program though.
Topic archived. No new replies allowed.
Pages: 12