javascript_use strict

本文介绍了JavaScript中的严格模式,包括如何启用严格模式以及它所带来的变化。文章详细解释了在严格模式下,JavaScript对于语法错误和一些特定操作的不同处理方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

JavaScript语法支持严格模式:”use strict”

如果给JavaScript代码标志为“严格模式”,则其中运行的所有代码都必然是严格模式下的。
其一:如果在语法检测时发现语法问题,则整个代码块失效,并导致一个语法异常。
其二:如果在运行期出现了违反严格模式的代码,则抛出执行异常。

注:经过测试IE6,7,8,9均不支持严格模式。

JavaScript代码“严格模式”使用方法:
严格模式需要使用字符串序列:

 


"use strict"

 

在如下位置加入可以开启相应代码块中的严格模式:
1.必须在全局代码的开始处加入。
2.在eval代码开始处加入。
3.在函数声明代码开始处加入。
4.在new Function()所传入的body参数块开始加入。

例1:

 


var num =012;alert(num);

 

在非严格模式下,可以使用0(零)开头前缀声明8进制。显示10。

但是在严格模式下,会产生错误。

 

"use strict";

var num =012;

alert(num);

 

测试结果:
IE6,7,8,9均显示10。
FF报错:octal literals and octal escape sequences are deprecated
Chrome报错:Uncaught SyntaxError: Octal literals are not allowed in strict mode.
Opera报错:Syntax error at line 3 while loading: Invalid character var num = 012;

如果使用严格模式,除了0(零)开头前缀8进制以外还有:
1.在代码中不能使用一些扩展的保留字:
implements,interface,let,package,private,public,static,yield
2.with语句也不能使用。
3.不能声明或重写eval和arguments两个标识符。
4.不能用delete 删除显式声明的标识符,名称或具名函数。

<think>我们正在处理一个预处理器错误,错误信息是:`error: missing binary operator before token`,具体出现在检查`EIGEN_COMP_MINGW`和`EIGEN_GNUC_STRICT_LESS_THAN`的条件中。这个错误通常发生在预处理器条件表达式中,当表达式不符合C/C++预处理器的语法要求时。 根据引用[2][3][4]中的信息,这种错误通常是由于预处理器无法识别某个宏或表达式导致的。特别是在条件编译指令(如`#if`)中,如果表达式包含未定义的宏或者使用了C++11才支持的特性(如`__has_attribute`)而编译器不支持,就会报错。 具体到我们的错误:`if EIGEN_COMP_MINGW && EIGEN_GNUC_STRICT_LESS_THAN 6 0 0`,这里的问题可能是`EIGEN_GNUC_STRICT_LESS_THAN`这个宏的用法不正确。在Eigen库中,`EIGEN_GNUC_STRICT_LESS_THAN`是一个用于检查GCC版本的宏,其定义类似于: ```c #define EIGEN_GNUC_STRICT_LESS_THAN(x,y,z) (__GNUC__ < x || (__GNUC__ == x && (__GNUC_MINOR__ < y || (__GNUC_MINOR__ == y && __GNUC_PATCHLEVEL__ < z)))) ``` 但是,在`#if`指令中,预处理器只能处理整数常量表达式,并且要求表达式是有效的。如果`EIGEN_GNUC_STRICT_LESS_THAN`被定义为上述形式,那么它不能在`#if`中使用,因为`#if`中不能使用`||`和`&&`等逻辑运算符(预处理器条件表达式有特定的语法,只能使用基本的整数运算和已定义的宏)。 实际上,在Eigen库中,通常使用`EIGEN_GNUC_AT_LEAST`和`EIGEN_GNUC_AT_MOST`等宏,并且这些宏被设计为可以在`#if`中使用。那么,为什么会出现这个错误呢? 查看Eigen的源代码(以Eigen 3.3.9为例),在`Macros.h`中,`EIGEN_GNUC_STRICT_LESS_THAN`的定义如下: ```c #define EIGEN_GNUC_STRICT_LESS_THAN(x,y,z) ((__GNUC__*10000+__GNUC_MINOR__*100+__GNUC_PATCHLEVEL__) < (x*10000+y*100+z)) ``` 这样,它就可以在`#if`中使用了,因为整个表达式是一个整数常量表达式。 因此,错误可能的原因有: 1. 编译器不是GCC,但代码尝试使用GCC的版本宏(`__GNUC__`等)。 2. 在定义`EIGEN_GNUC_STRICT_LESS_THAN`之前就使用了它,导致预处理器将其视为未定义。 3. 在`#if`中使用了错误的语法,比如`EIGEN_GNUC_STRICT_LESS_THAN`后面跟着三个参数(6,0,0)但宏定义只接受三个参数,而错误信息中却写成了`EIGEN_GNUC_STRICT_LESS_THAN 6 0 0`(没有括号和逗号)。 根据错误信息中的写法:`EIGEN_GNUC_STRICT_LESS_THAN 6 0 0`,这显然是不正确的宏调用。正确的调用应该是: ```c EIGEN_GNUC_STRICT_LESS_THAN(6,0,0) ``` 所以,问题可能出在Eigen库的某个头文件中,或者用户代码中,错误地写成了空格分隔而不是用括号和逗号。 但是,用户提到错误发生在Eigen库的编译中,所以可能是Eigen库内部的代码。我们检查Eigen的版本,因为不同版本的宏定义可能不同。 在Eigen 3.3.9中,我们可以在`Macros.h`中找到如下代码: ```c #if defined(__GNUC__) && (__GNUC__ <= 4) #define EIGEN_GNUC_AT_LEAST(x,y,z) 0 #else #define EIGEN_GNUC_AT_LEAST(x,y,z) (__GNUC__>x || (__GNUC__==x && (__GNUC_MINOR__>y || (__GNUC_MINOR__==y && __GNUC_PATCHLEVEL__>=z)))) #endif ``` 注意,这个`EIGEN_GNUC_AT_LEAST`不能在`#if`中使用,因为它使用了逻辑运算符。但是,在Eigen的后续版本(如3.4)中,已经改进了宏的定义。 实际上,在Eigen的代码库中,我们发现在`Eigen/src/Core/util/Macros.h`中,对于GCC版本检查的宏有两种:一种用于`#if`,一种用于普通条件。而`EIGEN_GNUC_STRICT_LESS_THAN`在Eigen的代码中并没有直接出现,可能是用户代码或第三方库中的宏。 因此,我们需要确定这个宏是从哪里来的。 **解决方案:** 1. **检查代码中的宏定义:** 确保在条件编译指令中使用的宏已经正确定义,并且语法正确。特别是检查`EIGEN_GNUC_STRICT_LESS_THAN`是否被定义为一个可以在`#if`中使用的整数常量表达式。 2. **更新Eigen库:** 如果使用的是较旧的Eigen版本,尝试更新到最新版本,因为新版本可能已经修复了这个问题。 3. **检查编译器兼容性:** 确保使用的编译器是GCC,并且版本符合要求。如果使用的是MinGW,确保其GCC版本足够新(至少5.0以上)。 4. **修改有问题的宏:** 如果无法更新Eigen,可以尝试修改Eigen的宏定义,将其改为可以在`#if`中使用的形式,即使用整数运算。例如,将`EIGEN_GNUC_STRICT_LESS_THAN`定义为: ```c #define EIGEN_GNUC_STRICT_LESS_THAN(x,y,z) ( (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) < (x * 10000 + y * 100 + z) ) ``` 注意:这个宏在非GCC编译器上会出错,所以应该只在GCC上使用。 5. **在条件判断前确保宏已定义:** 如果宏`EIGEN_COMP_MINGW`或`EIGEN_GNUC_STRICT_LESS_THAN`未定义,预处理器会将其视为0,但可能导致条件表达式不符合语法。因此,在条件判断前,确保这些宏已经定义,或者使用`defined()`操作符。 例如,将: ```c #if EIGEN_COMP_MINGW && EIGEN_GNUC_STRICT_LESS_THAN(6,0,0) ``` 改为: ```c #if defined(EIGEN_COMP_MINGW) && EIGEN_COMP_MINGW && defined(EIGEN_GNUC_STRICT_LESS_THAN) && EIGEN_GNUC_STRICT_LESS_THAN(6,0,0) ``` 但这样写很冗长,而且`EIGEN_GNUC_STRICT_LESS_THAN`本身可能没有定义成可以独立检查的条件。 实际上,更好的做法是确保宏在未定义时不会参与运算。在Eigen库中,通常会在定义这些宏之前先给一个默认值,比如: ```c #ifndef EIGEN_COMP_MINGW #define EIGEN_COMP_MINGW 0 #endif ``` 6. **参考引用[4]中的解决方案:** 该引用提到一个类似错误的解决方法是更新软件版本(将host-m4更新到1.4.19)。因此,如果错误是由于Eigen库的某个已知问题导致的,可以尝试更新Eigen库。 **总结:** 错误`missing binary operator before token`通常是由于预处理器条件表达式中存在语法错误。具体到这个问题,很可能是`EIGEN_GNUC_STRICT_LESS_THAN`宏的调用方式不正确(缺少括号和逗号)或者该宏没有被正确定义。建议检查并修正宏的调用方式,确保使用括号和逗号传递参数,即`EIGEN_GNUC_STRICT_LESS_THAN(6,0,0)`。同时,确保宏定义是有效的预处理器表达式。 如果问题仍然存在,尝试更新Eigen库到最新版本,或者根据上述建议修改宏定义。 §§相关问题§§ 1. 如何正确定义一个可以在预处理器条件中使用的宏? 2. 在C/C++中,预处理器条件表达式有哪些限制? 3. 如何检查GCC编译器的版本?</think>### 错误分析:`error: missing binary operator before token` 该错误发生在预处理器条件编译阶段,具体与 Eigen 库的宏定义 `EIGEN_COMP_MINGW` 和 `EIGEN_GNUC_STRICT_LESS_THAN` 相关。核心问题是 **预处理器无法识别宏表达式中的语法结构**,常见原因如下: 1. **宏未定义或语法错误** 当 `EIGEN_COMP_MINGW` 或 `EIGEN_GNUC_STRICT_LESS_THAN` 未正确定义时,预处理器会将其视为无效 token(类似未声明的变量)。在 `#if` 指令中直接使用未定义的宏会导致语法错误。 2. **编译器兼容性问题** `EIGEN_GNUC_STRICT_LESS_THAN` 依赖 GCC 版本号(如 `6.0.0`),但预处理器要求版本比较必须转换为整数表达式。例如: ```c // 错误写法(缺少括号和运算符) #if EIGEN_COMP_MINGW && EIGEN_GNUC_STRICT_LESS_THAN 6 0 0 // 正确写法(需明确比较逻辑) #if defined(EIGEN_COMP_MINGW) && EIGEN_COMP_MINGW && \ (__GNUC__ < 6 || (__GNUC__ == 6 && __GNUC_MINOR__ < 0)) ``` 3. **头文件顺序问题** Eigen 库的宏定义可能未被正确初始化。若在包含 `<Eigen/Core>` 前定义了某些平台宏(如 `__MINGW32__`),可能导致内部宏状态不一致[^1]。 --- ### 解决方案 #### 方法 1:更新 Eigen 库 升级到最新版 Eigen(3.4+),该问题可能已被修复: ```bash git clone https://gitlab.com/libeigen/eigen.git cd eigen && git checkout tags/3.4.0 ``` #### 方法 2:手动修复宏定义 在包含 Eigen 头文件前添加以下代码: ```c // 确保 MingW 宏被正确定义 #if defined(__MINGW32__) && !defined(EIGEN_COMP_MINGW) #define EIGEN_COMP_MINGW 1 #endif // 显式定义版本比较宏 #ifndef EIGEN_GNUC_STRICT_LESS_THAN #define EIGEN_GNUC_STRICT_LESS_THAN(x,y,z) \ (__GNUC__ < x || (__GNUC__ == x && (__GNUC_MINOR__ < y || \ (__GNUC_MINOR__ == y && __GNUC_PATCHLEVEL__ < z)))) #endif // 然后包含 Eigen #include <Eigen/Core> ``` #### 方法 3:检查编译器兼容性 确认 GCC 版本符合 Eigen 要求(≥ 4.8): ```bash gcc --version # 若版本过低,需升级 ``` #### 方法 4:简化条件编译(临时方案) 若仅需绕过错误,可注释或简化报错代码段(不推荐长期使用): ```c // 原始报错代码 // #if EIGEN_COMP_MINGW && EIGEN_GNUC_STRICT_LESS_THAN(6,0,0) // 修改为(假设满足条件) #if 0 // 直接禁用条件块 ``` --- ### 根本原因 此错误本质是预处理器无法解析复杂的逻辑表达式。引用[4]指出,类似问题在动态栈大小配置(如 `SIGSTKSZ`)更新时也会触发,需确保库文件与编译器规范兼容[^4]。对于 Eigen,建议优先升级库版本或显式定义缺失宏。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值