ฉันจะปิดเสียงเตือนเกี่ยวกับตัวแปรที่ไม่ได้ใช้ได้อย่างไร

ฉันมีแอพพลิเคชั่นข้ามแพลตฟอร์มและในบางฟังก์ชั่นของฉันไม่ได้ใช้ค่าทั้งหมดที่ส่งไปยังฟังก์ชั่น ดังนั้นฉันจึงได้รับคำเตือนจาก GCC บอกฉันว่ามีตัวแปรที่ไม่ได้ใช้

อะไรจะเป็นวิธีที่ดีที่สุดในการเขียนโปรแกรมเตือน

#ifdef รอบฟังก์ชั่นหรือไม่

#ifdef _MSC_VER
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal qrLeft, qreal qrTop, qreal qrWidth, qreal qrHeight)
#else
void ProcessOps::sendToExternalApp(QString sAppName, QString sImagePath, qreal /*qrLeft*/, qreal /*qrTop*/, qreal /*qrWidth*/, qreal /*qrHeight*/)
#endif
{

มันน่าเกลียดมาก แต่ดูเหมือนว่าวิธีที่คอมไพเลอร์จะชอบ

หรือฉันจะกำหนดศูนย์ให้กับตัวแปรที่ส่วนท้ายของฟังก์ชั่น? (ซึ่งฉันเกลียดเพราะมันเปลี่ยนแปลงบางสิ่งบางอย่างในโฟลว์ของโปรแกรมเพื่อปิดเสียงเตือนคอมไพเลอร์)

มีวิธีที่ถูกต้องหรือไม่?

คุณสามารถใส่มันใน(void)var;นิพจน์ (ไม่ทำอะไรเลย) เพื่อให้คอมไพเลอร์เห็นว่ามันถูกใช้ นี่คือพกพาระหว่างคอมไพเลอร์

เช่น

void foo(int param1, int param2)
{
    (void)param2;
    bar(param1);
}

หรือ,

#define UNUSED(expr) do { (void)(expr); } while (0)
...

void foo(int param1, int param2)
{
    UNUSED(param2);
    bar(param1);
}

ใน GCC และ Clang คุณสามารถใช้__attribute__((unused))คำสั่ง preprocessor เพื่อให้บรรลุเป้าหมายของคุณ
ตัวอย่างเช่น:

int foo (__attribute__((unused)) int bar) {
   return 0;
}

ตอนนี้ C ++ 17 จะให้[[maybe_unused]]คุณสมบัติ

http://en.cppreference.com/w/cpp/language/attributes

ค่อนข้างดีและมาตรฐาน

โซลูชันปัจจุบันของคุณดีที่สุด - แสดงความคิดเห็นชื่อพารามิเตอร์หากคุณไม่ได้ใช้ สิ่งนี้ใช้ได้กับคอมไพเลอร์ทั้งหมดดังนั้นคุณไม่จำเป็นต้องใช้ตัวประมวลผลล่วงหน้าเพื่อทำมันเป็นพิเศษสำหรับ GCC

การอัปเดต C ++ 17

ใน C ++ 17 เราได้รับคุณลักษณะ[[บางที _unused]]ซึ่งครอบคลุมใน[dcl.attr.unused]

attribute-token บางที _unused บ่งชี้ว่าชื่อหรือเอนทิตีอาจไม่ได้ใช้อย่างตั้งใจ มันจะปรากฏขึ้นมากที่สุดครั้งหนึ่งในแต่ละรายการแอตทริบิวต์และไม่มีแอตทริบิวต์ข้อโต้แย้งจะอยู่ ...

ตัวอย่าง:

 [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                        [[maybe_unused]] bool thing2) {
  [[maybe_unused]] bool b = thing1 && thing2;
    assert(b);
 }

การใช้งานไม่ควรเตือนว่าไม่ได้ใช้ b ไม่ว่าจะมีการกำหนด NDEBUG หรือไม่ก็ตาม - ตัวอย่าง]

สำหรับตัวอย่างต่อไปนี้:

int foo ( int bar) {
    bool unused_bool ;
    return 0;
}

ทั้งเสียงดังกราวและ gcc สร้างการวินิจฉัยโดยใช้-Wall -Wextraสำหรับทั้งแถบและunused_bool ( ดูแบบสด )

ในขณะที่เพิ่ม[[บางทีอาจใช้]]ปิดการวินิจฉัย:

int foo ([[maybe_unused]] int bar) {
    [[maybe_unused]] bool unused_bool ;
    return 0;
}

เห็นมันมีชีวิตอยู่

ก่อน C ++ 17

ใน C ++ 11 รูปแบบทางเลือกของUNUSEDมาโครอาจเกิดขึ้นได้โดยใช้การแสดงออกแลมบ์ดา ( ผ่าน Ben Deane ) ด้วยการจับตัวแปรที่ไม่ได้ใช้:

#define UNUSED(x) [&x]{}()

การร้องขอนิพจน์แลมบ์ดาในทันทีควรได้รับการปรับให้เหมาะสมตามตัวอย่างต่อไปนี้:

int foo (int bar) {
    UNUSED(bar) ;
    return 0;
}

เราเห็นได้ในgodboltว่าการโทรได้รับการปรับให้เหมาะที่สุด

foo(int):
xorl    %eax, %eax
ret

วิธีที่สะอาดยิ่งขึ้นคือการแสดงความคิดเห็นชื่อตัวแปร:

int main(int /* argc */, char const** /* argv */) {
  return 0;
}

เพื่อนร่วมงานเพิ่งชี้ให้ฉันเห็นมาโครตัวน้อยตัวนี้ที่นี่

เพื่อความสะดวกฉันจะรวมมาโครด้านล่าง

#ifdef UNUSED
#elif defined(__GNUC__) 
# define UNUSED(x) UNUSED_ ## x __attribute__((unused)) 
#elif defined(__LCLINT__) 
# define UNUSED(x) /*@unused@*/ x 
#else 
# define UNUSED(x) x 
#endif

void dcc_mon_siginfo_handler(int UNUSED(whatsig))

GCCไม่ได้ตั้งค่าสถานะคำเตือนเหล่านี้ตามค่าเริ่มต้น คำเตือนนี้ต้องถูกเปิดใช้งานอย่างชัดเจนโดยการส่ง-Wunused-parameterไปยังคอมไพเลอร์หรือโดยปริยายโดยการส่งผ่าน-Wall -Wextra(หรืออาจเป็นการรวมกันของธงอื่น ๆ )

คำเตือนพารามิเตอร์ที่ไม่ได้ใช้สามารถถูกยับยั้งได้โดยส่งผ่าน-Wno-unused-parameterไปยังคอมไพเลอร์ แต่โปรดทราบว่าการปิดใช้งานแฟล็กนี้ต้องมาหลังจากการเปิดใช้งานแฟล็กที่เป็นไปได้ใด ๆ สำหรับคำเตือนนี้ในบรรทัดคำสั่งคอมไพเลอร์

วิธีแบบไร้แมโครและแบบพกพาเพื่อประกาศพารามิเตอร์อย่างน้อยหนึ่งพารามิเตอร์โดยไม่ได้ใช้:

template <typename... Args> inline void unused(Args&&...) {}

int main(int argc, char* argv[])
{
    unused(argc, argv);
    return 0;
}

การใช้คำสั่ง preprocessor ถือเป็นความชั่วร้ายเกือบตลอดเวลา เป็นการดีที่คุณต้องการหลีกเลี่ยงพวกเขาเช่นศัตรู โปรดจำไว้ว่าการทำให้คอมไพเลอร์เข้าใจว่าโค้ดของคุณนั้นง่ายทำให้ผู้เขียนโปรแกรมคนอื่นเข้าใจโค้ดของคุณได้ยากขึ้น มีหลายสิบกรณีเช่นนี้และทำให้ยากที่จะอ่านด้วยตัวคุณเองในภายหลังหรือเพื่อคนอื่นในตอนนี้

วิธีหนึ่งอาจจะรวมพารามิเตอร์ของคุณเข้ากับคลาสอาร์กิวเมนต์บางประเภท จากนั้นคุณสามารถใช้ชุดย่อยของตัวแปร (เทียบเท่ากับการกำหนด 0 ของคุณจริงๆ) หรือมีความเชี่ยวชาญที่แตกต่างกันของคลาสอาร์กิวเมนต์นั้นสำหรับแต่ละแพลตฟอร์ม อย่างไรก็ตามสิ่งนี้อาจไม่คุ้มค่าคุณต้องวิเคราะห์ว่าเหมาะสมหรือไม่

หากคุณสามารถอ่านเทมเพลตที่เป็นไปไม่ได้คุณอาจพบเคล็ดลับขั้นสูงในหนังสือ "เจ๋ง C ++" หากคนที่อ่านรหัสของคุณสามารถได้รับชุดทักษะของพวกเขาที่จะครอบคลุมสิ่งที่บ้าสอนในหนังสือเล่มนั้นแล้วคุณจะมีรหัสที่สวยงามซึ่งสามารถอ่านได้ง่าย คอมไพเลอร์จะตระหนักดีถึงสิ่งที่คุณกำลังทำอยู่ (แทนที่จะซ่อนทุกอย่างด้วยการประมวลผลล่วงหน้า)

ก่อนปิดคำเตือนจะถูกสร้างขึ้นโดยนิยามตัวแปรในไฟล์ต้นฉบับไม่ใช่ไฟล์ส่วนหัว ส่วนหัวสามารถคงอยู่ที่เก่าแก่และควรเนื่องจากคุณอาจใช้บางอย่างเช่น doxygen เพื่อสร้างเอกสารประกอบ API

ฉันจะสมมติว่าคุณมีการใช้งานที่แตกต่างอย่างสิ้นเชิงในไฟล์ต้นฉบับ ในกรณีเหล่านี้คุณสามารถแสดงความคิดเห็นพารามิเตอร์ที่ละเมิดหรือเพียงแค่เขียนพารามิเตอร์

ตัวอย่าง:

func(int a, int b)
{
    b;
    foo(a);
}

สิ่งนี้อาจดูเป็นความลับดังนั้นให้นิยามมาโครเช่น UNUSED วิธีที่ MFC ทำคือ:

#ifdef _DEBUG
#define UNUSED(x)
#else
#define UNUSED(x) x
#endif

เช่นนี้คุณเห็นคำเตือนว่ายังอยู่ในการสร้างข้อบกพร่องอาจเป็นประโยชน์

ไม่ปลอดภัยที่จะใส่เครื่องหมายชื่อพารามิเตอร์ทุกครั้งหรือไม่ หากไม่ใช่คุณสามารถทำสิ่งที่ชอบ

#ifdef _MSC_VER
# define P_(n) n
#else
# define P_(n)
#endif

void ProcessOps::sendToExternalApp(
    QString sAppName, QString sImagePath,
    qreal P_(qrLeft), qreal P_(qrTop), qreal P_(qrWidth), qreal P_(qrHeight))

มันน่าเกลียดน้อยกว่านิดหน่อย

ฉันได้เห็นสิ่งนี้แทนที่จะเป็น(void)param2วิธีปิดปากเตือน:

void foo(int param1, int param2)
{
    std::ignore = param2;
    bar(param1);
}

ดูเหมือนว่าจะมีการเพิ่มใน C ++ 11

ใช้UNREFERENCED_PARAMETER(p)งานได้ ฉันรู้ว่ามันถูกกำหนดไว้ใน WinNT.h สำหรับระบบ Windows และสามารถกำหนดได้อย่างง่ายดายสำหรับ gcc เช่นกัน (หากยังไม่มีมัน)

UNREFERENCED PARAMETER(p) ถูกกำหนดให้เป็น

#define UNREFERENCED_PARAMETER(P)          (P)

ใน WinNT.h

ใช้การตั้งค่าสถานะของคอมไพเลอร์เช่นตั้งค่าสถานะสำหรับ GCC: -Wno-unused-variable

คุณสามารถใช้__unusedเพื่อบอกคอมไพเลอร์ว่าอาจไม่ใช้ตัวแปร

- (void)myMethod:(__unused NSObject *)theObject    
{
    // there will be no warning about `theObject`, because you wrote `__unused`

    __unused int theInt = 0;
    // there will be no warning, but you are still able to use `theInt` in the future
}

ใน C ++ 11 นี่คือโซลูชันที่ฉันใช้:

template<typename... Ts> inline void Unreferenced(Ts&&...) {}

int Foo(int bar) 
{
    Unreferenced(bar);
    return 0;
}

int Foo2(int bar1, int bar2) 
{
    Unreferenced(bar1, bar2);
    return 0;
}

ตรวจสอบแล้วว่าเป็นแบบพกพา (อย่างน้อยใน msvc ที่ทันสมัยเสียงดังกราวและ gcc) และไม่สร้างรหัสพิเศษเมื่อเปิดใช้งานการปรับให้เหมาะสม ไม่มีการเพิ่มประสิทธิภาพการเรียกใช้ฟังก์ชันพิเศษจะดำเนินการและการอ้างอิงไปยังพารามิเตอร์จะถูกคัดลอกไปยังสแต็ก แต่ไม่มีมาโครที่เกี่ยวข้อง

หากรหัสพิเศษเป็นปัญหาคุณสามารถใช้การประกาศนี้แทน:

(decltype(Unreferenced(bar1, bar2)))0;

แต่ ณ จุดนั้นมาโครสามารถอ่านได้ง่ายขึ้น:

#define UNREFERENCED(...) { (decltype(Unreferenced(__VA_ARGS__)))0; }

ใช้งานได้ดี แต่ต้องใช้C ++ 11

template <typename ...Args>
void unused(Args&& ...args)
{
  (void)(sizeof...(args));
}

ฉันพบว่าคำตอบที่นำเสนอส่วนใหญ่ทำงานสำหรับตัวแปรที่ไม่ได้ใช้งานในพื้นที่เท่านั้นและจะทำให้เกิดข้อผิดพลาดในการรวบรวมสำหรับตัวแปรโกลบอลแบบคงที่ที่ไม่ได้ใช้

แมโครอื่นจำเป็นต้องระงับการเตือนตัวแปรโกลบอลแบบคงที่ที่ไม่ได้ใช้

template <typename T>
const T* UNUSED_VARIABLE(const T& dummy) { 
    return &dummy;
}
#define UNUSED_GLOBAL_VARIABLE(x) namespace {\
    const auto dummy = UNUSED_VARIABLE(x);\
}

static int a = 0;
UNUSED_GLOBAL_VARIABLE(a);

int main ()
{
    int b = 3;
    UNUSED_VARIABLE(b);
    return 0;
}

ใช้งานได้เนื่องจากไม่มีการเตือนสำหรับตัวแปรโกลบอลที่ไม่คงที่ในเนมสเปซที่ไม่ระบุชื่อ

ต้องใช้ C ++ 11

 g++  -Wall -O3  -std=c++11 test.cpp

ฮ่า ๆ! ฉันไม่คิดว่าจะมีคำถามอีกข้อใน SO ที่เปิดเผยคนนอกศาสนาที่ได้รับความเสียหายจากความโกลาหลที่ดีกว่านี้!

ด้วยความเคารพจากทุก C ++ 17 มีแนวทางที่ชัดเจนในc ++ แนวทางหลัก AFAIR ย้อนกลับไปในปี 2009 ตัวเลือกนี้มีให้ใช้เช่นเดียวกับวันนี้ และถ้าใครบางคนบอกว่ามันถือเป็นข้อผิดพลาดใน Doxygen ก็มีข้อผิดพลาดใน Doxygen

ฉันไม่เห็นปัญหาของคุณเกี่ยวกับคำเตือน จัดทำเอกสารไว้ในส่วนหัวของวิธีการ / ฟังก์ชั่นที่คอมไพเลอร์ xy จะออกคำเตือน (ถูกต้อง) ที่นี่ แต่ตัวแปรเหล่านี้จำเป็นสำหรับแพลตฟอร์ม z

คำเตือนถูกต้องไม่จำเป็นต้องปิด ไม่ได้ทำให้โปรแกรมใช้ไม่ได้ - แต่ควรมีเอกสารว่ามีเหตุผล