完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
德赢Vwin官网
论坛
3526
|
在MCC生成的代码中，在FVR.H中，我看到，在StuttTyManger-H中，我看到，领先的下划线是怎么回事？有些文件有，有些没有。到目前为止，CuffTyManger-Mealth.h，PixMaultMealth.h和MCC.h没有它们，而所有其他文件都有领先的下划线。
以上来自于百度翻译 以下为原文 In the code generated by MCC say in fvr.h I see, #ifndef _FVR_H #define _FVR_H In interrupt_manager.h I see, #ifndef INTERRUPT_MANAGER_H #define INTERRUPT_MANAGER_H What is going on with the leading underscores? Some files have 'em, some do not. So far, interrupt_manager.h, pin_manager.h and mcc.h do not have them while all the rest of the files do have the leading underscore. 
0
|
|
相关推荐
8个回答
|
|
|
|
|
|
|
|
|
我猜不同的人写的代码，没有一个编码标准，或没有遵循。
以上来自于百度翻译 以下为原文 I'm guessing different people wrote the code and there isn't a coding standard, or it wasn't followed. |
|
|
|
|
|
是的，虽然用户通常不鼓励使用领先的下划线，但在“包含警卫”中，他们总是存在于微软C包含文件中。只是一种习惯，可以这么说
以上来自于百度翻译 以下为原文 Yeah, though users are usually discouraged from using a leading underscore, in "include guards" they were always there in Microsoft C include files. Just a habit, so to say |
|
|
|
|
|
对于包含后卫，我也遇到了一种带有前导加后跟下划线的风格（＝＝& gt；yfvrthHi）。意图不是与“通常”定义的冲突（如果你通常不使用领先的下划线，那么完美）。
以上来自于百度翻译 以下为原文 For include guards I also encountered a style with a leading plus a trailing underscore (==> _FVR_H_). The intention is not to collide with "usual" #defines (perfect if you're usually not using leading underscores). |
|
|
|
|
|
嗨，领先的下划线是一种尝试避免命名冲突的方法，也就是为了避免相同的符号被用于不同目的的问题。该约定是“系统库”使用宏符号的领先下划线，因此应用程序代码和应用程序库代码应该使用MACR。o不从下划线开始的符号。MCC生成的代码是否应被视为“系统代码”或“应用程序代码”，可能会引起争论，但代码生成的MCC与预期使用的编译器一起测试，因此编译器所使用的符号之间存在任何冲突，MCC使用的符号应该已经解决了。设备支持头文件，使用带有用于寄存器位和字段的宏符号的领先下划线的符号，但是SFR寄存器名没有下划线，因此SFR寄存器名在没有领先下划线的情况下保留了许多保留名称。这些都是大写的名字，除了PIC32 MIPS系统协处理器CP0中的几个寄存器，但是这些寄存器无论如何都不能被C代码直接访问。迈西尔
以上来自于百度翻译 以下为原文 Hi, The leading underscore is a way to try to avoid naming conflicts, that is to avoid problems by the same symbol beeing used for different purposes. The convention is that 'system libraries' use a leading underscore for macro symbols, so application code and application libraries code should use macro symbols that do not start with underscore. Whether code generated by MCC should be regarded as 'system' code, or 'application' code, may be open to debate, but code generated MCC is tested together with the compiler that is expected to be used, so any conflict between symbols used by the compiler, and symbols used by MCC should have been solved already. Device support header files, use symbols with a leading underscore for macro symbols for register bits and fields, but SFR register names have no underscore, so SFR register names make a lot of reserved names without a leading underscore. These are mostly all uppercase names, except a few registers in PIC32 MIPS system coprocessor, CP0, but those registers cannot be accessed directly by C code anyway. Mysil |
|
|
|
|
|
谢谢你，Mysil。我想从我的新手角度来看，我会努力使所有文件都能保持一致。看起来最好的做法是在两端不要使用下划线。
以上来自于百度翻译 以下为原文 Thank you Mysil. I guess from my newbie viewpoint I'll just try to make it consistent across all my files. It looks as though a best practice might be to not use the underscores at either end. |
|
|
|
|
|
从{下划线}{下划线}或{下划线}{大写}开始的标识符被保留以供实现者使用。用户保证所有非保留的标识符都可以在自己的代码中使用。我们是Implementer，你是用户。在我们提供的源代码中出现了棘手的问题，这可能是由你修改的。在我的卑微（哈！）MPLAX生成的头文件骨架，当你告诉它在你的项目中创建一个新的头文件时，你要填写的是用户代码，因此它们的包含保护不应该有领先的下划线；由MCC等产生的“驱动”，被用来作为IS，实现。R代码及其包含的警卫应该有领先的下划线；任何与上面不匹配的是bug，你应该记录一个支持TIKETE来修复它。
以上来自于百度翻译 以下为原文 Identifiers beginning with {underscore}{underscore} or {underscore}{uppercase} are reserved for use by the Implementer. The User is guaranteed that all non-reserved identifiers are available for use in their own code. We are the Implementer, you are the User. The tricky bit arises in source code that we supply that is perhaps intended to be modified by you. In My Humble (hah!) Opinion,
|
|
|
|
|
|
请注意，当使用“文件/新文件”创建一个新的.h文件时，它不会自动使用下划线。因此，在这种方式下，它通常被MLP、MysIL和其他人在这个线程中推荐。
以上来自于百度翻译 以下为原文 Just a note to say that when creating a new .h file using "File/New File" it does not automatically use underscores. So in this way it works as has been generally recommended by mlp, mysil and others in this thread. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5237 浏览 9 评论
2027 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3202 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
772浏览 1评论
662浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
590浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
672浏览 0评论
572浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
评论
淘帖
1186
