這是因?yàn)?,程序設(shè)計(jì)里如果遇到configMAX_PRIORITIES < 1的情況,可能會(huì)導(dǎo)致更嚴(yán)重的錯(cuò)誤。
所以這種在預(yù)編譯階段攔截了這個(gè)錯(cuò)誤,是很有作用的2. FreeRTOS中的運(yùn)行時(shí)狀態(tài)獲取函數(shù),必須依賴(lài)于configUSE_TRACE_FACILITY的定義
void vTaskGetRunTimeStats( char *pcWriteBuffer )
{
TaskStatus_t *pxTaskStatusArray;
UBaseType_t uxArraySize, x;
uint32_t ulTotalTime, ulStatsAsPercentage;
{
}
因?yàn)?,這個(gè)函數(shù)很依賴(lài)其他其他的函數(shù)實(shí)現(xiàn)或者資源定義,那么這個(gè)configUSE_TRACE_FACILITY管理了這些
3. 版本檢查,如果你設(shè)計(jì)一個(gè)比較通用的功能,可以用到很多項(xiàng)目中去,為了方便管理和迭代更新,就要對(duì)這個(gè)功能模塊做版本定義。那么不同版本之間就存在差異,可能存在不兼容的情況,此時(shí)就可以用預(yù)編譯指令做這種兼容的檢查
通過(guò)預(yù)編譯指令來(lái)檢查錯(cuò)誤是很有限的,因?yàn)轭A(yù)編譯指令能檢查的是立即數(shù)和一些邏輯關(guān)系。于是,我們還要考慮編譯階段的錯(cuò)誤檢查,即對(duì)在編譯階段產(chǎn)生的結(jié)果做檢查。例如,unsigned long或者void*的長(zhǎng)度檢查即sizeof(unsignedlong)或sizeof(void*)的值,就必須在編譯階段由于unsigned long和void*的長(zhǎng)度在不同芯片架構(gòu)上可能存在差異,如果你的程序依賴(lài)這個(gè)類(lèi)型的長(zhǎng)度,那必須要檢查其長(zhǎng)度是否為你設(shè)計(jì)的那樣。像這種#if sizeof(unsigned long) == 4是不正確的做法,因?yàn)轭A(yù)編譯無(wú)法計(jì)算sizeof(unsigned long)那么有沒(méi)有一種情況能確保sizeof(unsigned long)的值是4才不出錯(cuò)呢?也許你會(huì)想到一個(gè)叫assert的東西,例如FreeRTOS里面定義的
既可以這樣使用configASSERT(sizeof(unsigned long) == 4),如果sizeof(unsignedlong) == 4,那么程序是“靜悄悄”的,當(dāng)做啥事都沒(méi)發(fā)生,但是如果sizeof(unsigned long) == 8,那么程序就會(huì)進(jìn)入for( ;; );無(wú)法自拔。但是這種做法是運(yùn)行階段的,必須要在程序已經(jīng)集成好并讓其在實(shí)際環(huán)境中運(yùn)行才能發(fā)現(xiàn)這種錯(cuò)誤,排查起來(lái)成本還是有點(diǎn)高。那么有沒(méi)有一種辦法可以讓其扼殺在編譯階段呢?答案是有的,像C++11和C11就支持這種assert了,名叫STATIC_ASSERT,需要包含頭文件assert.h。但是,如果我還沒(méi)用到C11,也想用這種STATIC_ASSERT呢,有沒(méi)有辦法自己實(shí)現(xiàn)一個(gè)?答案也是可以的,需要想個(gè)竅門(mén),例如從數(shù)組的長(zhǎng)度入手。像int arr[1];這種定義是沒(méi)有問(wèn)題的,但int arr[-1];卻是會(huì)引起編譯器報(bào)錯(cuò)的,我們就可以基于這種東西做文章了,即將數(shù)組長(zhǎng)度換成檢查條件COND,即如果COND為T(mén)RUE就不報(bào)錯(cuò),為FALSE就報(bào)錯(cuò)通過(guò)一頓反復(fù)嘗試,搞成這樣或許就可以了
int arr[(!!(COND))*2-1];
這里(!!(COND))*2-1沒(méi)有一個(gè)符號(hào)是多余的,簡(jiǎn)單解釋下:1.(COND),這里加了一層括號(hào),防止COND是個(gè)比較復(fù)雜的表達(dá)式,可能引發(fā)未知的優(yōu)先級(jí)問(wèn)題;2.(!!(COND)),這里有兩個(gè)感嘆號(hào),即邏輯取反再取反。也許你會(huì)覺(jué)得有點(diǎn)奇怪,!!TRUE不就是TURE嗎,!!FALSE也是FALSE啊,雙層取反是不是有點(diǎn)多余。那你就要認(rèn)真思考下TRUE和FALSE的定義了,C語(yǔ)言中的FALSE是0,而非0是TRUE,這個(gè)非0就有很多發(fā)揮空間了,例如整數(shù)100,也是TRUE,但是!!100就會(huì)變成1,這里的(!!(COND))就是讓其結(jié)果變成0或者1,而不是其他數(shù)。3.通過(guò)2的解釋?zhuān)秃苋菀桌斫?/span>(!!(COND))*2-1這可以保證這個(gè)結(jié)果是1或者-1,而不存在其他數(shù)值。因?yàn)椋覀兊哪康囊氖?span style="font-family:'Microsoft YaHei';letter-spacing:.578px;background-color:rgb(214,214,214);">int arr[1];或者int arr[-1];即可。
定義一個(gè)數(shù)組用在程序中間好像用起來(lái)沒(méi)那么友好,可以換成
typedef int arr[(!!(COND))*2-1];
為了還能看到多一點(diǎn)點(diǎn)錯(cuò)誤信息,還可以將其定義成宏,并帶多一個(gè)參數(shù),這就成了這樣
##MSG[(!!(COND))*2-1] defineSTATIC_ASSERT(COND,MSG)typedefchar static_assertion_
在這個(gè)基礎(chǔ)上再搞定其他的,就可以這樣了
// token pasting madness:
接著,判斷sizeof(unsigned long) 是否為4,就可以這樣
STATIC_ASSERT(sizeof(unsignedlong)==4,unsigned_long_size_is_not_4_error);
-
C語(yǔ)言
+關(guān)注
關(guān)注
183文章
7634瀏覽量
143880 -
C++
+關(guān)注
關(guān)注
22文章
2120瀏覽量
76446 -
編譯
+關(guān)注
關(guān)注
0文章
682瀏覽量
34766
原文標(biāo)題:C語(yǔ)言開(kāi)發(fā)如何將錯(cuò)誤扼殺在編譯階段
文章出處:【微信號(hào):embedded_sw,微信公眾號(hào):嵌入式軟件實(shí)戰(zhàn)派】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
幾款C語(yǔ)言編譯器推薦
C語(yǔ)言的編譯鏈接過(guò)程

Rust語(yǔ)言中錯(cuò)誤處理的機(jī)制
如何將高級(jí)C語(yǔ)言編譯成機(jī)器碼
C語(yǔ)言編譯過(guò)程中的錯(cuò)誤分析
C語(yǔ)言編程時(shí)常犯的18種錯(cuò)誤
如何將C源代碼從MPLAB C18編譯器移植到MPLAB XC8C編譯器的詳細(xì)概述

C語(yǔ)言編譯器中有哪些錯(cuò)誤信息詳細(xì)中英文對(duì)比

C語(yǔ)言里extern "C" 是什么意思?
解析C語(yǔ)言編譯過(guò)程中所做的工作

VScode編譯器如何配置C/C++編譯環(huán)境
c語(yǔ)言代碼錯(cuò)誤怎么找
為什么C語(yǔ)言要進(jìn)行編譯

評(píng)論