数学表达式的递归分解顺序和日常的顺序是完全相反的。一方面，原本的高级运算符要后进行拆分，另一方面，原本的从左到右的运算顺序使得拆分运算符时要从最右侧进行拆分。
要解析一个带有括号的长表达式并没有想象中那么容易
我对括号处理的理解有问题，识别括号时，不是两侧有括号+括号匹配就代表正确
按照讲义提供的逻辑，最外层要有一层能包住完整式子的才是有效的外层括号.
比如这样的一个表达式：((839*(928/((((972)))))-505)-((((666)))-(746*796/723*408-((713))))+365)
第一步肯定是去掉外层括号，然后按照+把前面和365切开。但是，下一步就有问题了：
(839*(928/((((972)))))-505) - ((((666)))-(746*796/723*408-((713)))) 这一部分，看起来，两侧有括号，而且括号左右匹配，那应该继续返回true，去掉最外层再继续？实际上不行，因为最外层的括号并不是包裹整个式子的。去掉多余括号，变成(839*(928/972)-505) - (666-(746*796/723*408-713))。可以看到这个式子其实已经没有最外层括号了，所以应该返回的是false，按照中间的减号拆分。
第二个遇到的问题是：代码里全程都使用的是uint32，但这样存在一个问题，就是在计算除法时，假如被除数和除数里有一个是负数（按人的理解），在uint里会被强制转换为正数，导致计算出问题，所以如果想全程保持uint，那么除法这里就需要把两个数先强转int型再计算。
举例：(((261))-826*(739)*(480-((789+863)))/(542)/((991))) 在计算到-715405208 /542 这一步时就出现了问题。正确结果是-1319935,但是计算成了6604358。原本的被除数被理解成了一个超大的uint，导致计算结果是一个正数（int环境）。这显然有问题。为了保险起见，我又测试了一下乘法，似乎不存在这个问题。在DIV的case里强转int后，问题解决了。
那么问题来了，一定要全程使用uint32吗？此外，负数可以用类似的方法处理吗？我感觉uint和int在机器中的处理这一块可能还需要再多看看。 除此之外，我还发现了之前写代码的一个错误思路： 对于一个有bool* 参数的函数，比如 func(bool *success)，在外层函数调用func时，正确做法是bool success=false; 调用func时传入&success。 但我却一直在外层声明bool *success=false; 然后调用func(success); 这个点纠结了我一段时间。在外层直接定义*success=false，false会被理解为0.success又是一个指针，这就会导致我实际上声明了一个指向0x00000000的指针，这明显是错的。 标签：外层,false,success,int,ysyx,括号,数学,func,表达式 From： https://www.cnblogs.com/namezhyp/p/18222465