ฉันสามารถใช้ if (ตัวชี้) แทน if (ตัวชี้! = NULL) หรือไม่

การตรวจสอบตัวชี้ไม่ปลอดภัยNULLโดยการเขียนเพียงอย่างเดียวif(pointer)หรือฉันต้องใช้อย่างปลอดภัยif(pointer != NULL)หรือไม่?

คุณสามารถ; ตัวชี้โมฆะจะถูกแปลงเป็นบูลีนโดยปริยายในขณะที่พอยน์เตอร์ที่ไม่ใช่นัลถูกแปลงเป็นจริง จากมาตรฐาน C ++ 11 ส่วนในBoolean Conversions:

prvalue ของเลขคณิตนับ unscoped ตัวชี้หรือตัวชี้ไปยังประเภทสมาชิกสามารถแปลงเป็น prvalue boolของประเภท ค่าศูนย์ค่าตัวชี้โมฆะหรือค่าตัวชี้โมฆะสมาชิกถูกแปลงเป็น false; ค่าอื่น ๆ true จะถูกแปลงเป็น prvalue ชนิด std::nullptr_t สามารถแปลงเป็น prvalue ชนิด bool ; false คุ้มค่าที่เกิดขึ้นคือ

ใช่คุณทำได้

• ตัวชี้โมฆะถูกแปลงเป็นเท็จโดยปริยาย
• ตัวชี้ที่ไม่ใช่ null ถูกแปลงเป็นจริง

นี่เป็นส่วนหนึ่งของการแปลงมาตรฐาน C ++ ซึ่งอยู่ในมาตราการแปลงบูลีน :

§ 4.12 การแปลงบูลีน

prvalue ของเลขคณิตการแจงนับที่ไม่ จำกัด ขอบเขตตัวชี้หรือตัวชี้เป็นชนิดสมาชิกสามารถแปลงเป็น prvalue ของบูลประเภท ค่าศูนย์ค่าตัวชี้โมฆะหรือค่าตัวชี้โมฆะสมาชิกถูกแปลงเป็นเท็จ ค่าอื่นใดจะถูกแปลงเป็นจริง prvalue ของ type std :: nullptr_t สามารถแปลงเป็น prvalue ของ type bool; ค่าผลลัพธ์เป็นเท็จ

ใช่คุณสามารถ. ที่จริงแล้วฉันชอบที่จะใช้if(pointer)เพราะมันง่ายกว่าในการอ่านและเขียนเมื่อคุณชินกับมันแล้ว

นอกจากนี้ยังทราบว่า C ++ 11 แนะนำซึ่งเป็นที่ต้องการมากกว่าnullptrNULL

ตอบคำถามแล้ว แต่ฉันต้องการเพิ่มคะแนน

ฉันจะชอบif(pointer)มากกว่าif(pointer != NULL)และif(!pointer)แทนที่จะเป็นif(pointer == NULL):

• มันง่ายเล็ก

• โอกาสน้อยที่จะเขียนรหัสรถสมมติว่าถ้าผมสะกดผู้ประกอบการตรวจสอบความเท่าเทียมกัน==กับ=
if(pointer == NULL)สามารถสะกดผิดดังนั้นผมจะหลีกเลี่ยงมันที่ดีที่สุดคือเพียงif(pointer = NULL) _{(ฉันยังแนะนำเงื่อนไขบางอย่างของโยดาในคำตอบเดียวแต่นั่นเป็นเรื่องที่ต่างออกไป)}if(pointer)
  

• ในทำนองเดียวกันสำหรับwhile (node != NULL && node->data == key)ฉันฉันจะเขียนwhile (node && node->data == key)ที่ชัดเจนมากขึ้นสำหรับฉัน (แสดงว่าใช้ไฟฟ้าลัดวงจร)

• (อาจเป็นเหตุผลที่โง่เง่า) เนื่องจาก NULL เป็นแมโครถ้าสมมติว่าหนึ่งนิยามใหม่โดยไม่ได้ตั้งใจกับค่าอื่น ๆ

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

ใช่คุณสามารถ. ความสามารถในการเปรียบเทียบค่ากับศูนย์โดยนัยได้รับการสืบทอดมาจาก C และมีอยู่ใน C ++ ทุกเวอร์ชัน คุณยังสามารถใช้if (!pointer)เพื่อตรวจสอบพอยน์เตอร์สำหรับ NULL

กรณีการใช้งานที่เกี่ยวข้องสำหรับพอยน์เตอร์พอยน์เตอร์คือ

• การเปลี่ยนเส้นทางไปยังบางสิ่งเช่นโหนดต้นไม้ที่ลึกกว่าซึ่งอาจไม่มีอยู่หรือยังไม่ได้เชื่อมโยง นั่นเป็นสิ่งที่คุณควรห่อหุ้มไว้อย่างใกล้ชิดในชั้นเรียนเฉพาะเพื่อให้การอ่านหรือความรัดกุมไม่เป็นปัญหามากนักที่นี่

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

  Derived* derived_ptr = dynamic_cast<Derived*>(base_ptr);
  if(derived_ptr != nullptr) { ... }

  (หรือดีกว่าauto derived_ptr = ...) ตอนนี้สิ่งนี้ไม่ดีเพราะมันปล่อยให้ตัวชี้ที่ได้รับ (อาจไม่ถูกต้องเช่นว่าง) อยู่นอกifขอบเขตของบล็อกความปลอดภัย สิ่งนี้ไม่จำเป็นเนื่องจาก C ++ ช่วยให้คุณสามารถแนะนำตัวแปรแบบบูลที่สามารถแปลงได้ภายในif-condition :

  if(auto derived_ptr = dynamic_cast<Derived*>(base_ptr)) { ... }

  ซึ่งไม่เพียง แต่สั้นและปลอดภัยเท่านั้น แต่ยังมีความชัดเจนมากขึ้นด้วย: เมื่อคุณตรวจสอบ null ในเงื่อนไข if-if ที่แยกต่างหากผู้อ่านสงสัยว่า "ตกลงดังนั้นderived_ptrจะต้องไม่เป็นโมฆะที่นี่ ... ทำไมจะเป็นเช่นนั้น มันจะว่างเปล่า " ในขณะที่รุ่นหนึ่งบรรทัดพูดชัดถ้อยชัดคำมาก "ถ้าคุณสามารถโยนได้อย่างปลอดภัยbase_ptrไปDerived*แล้วใช้งานได้ ..."

  การทำงานแบบเดียวกันเช่นเดียวกับการดำเนินการที่ล้มเหลวอื่น ๆ ที่ส่งกลับตัวชี้ถึงแม้ว่าโดยทั่วไปแล้ว IMO คุณควรหลีกเลี่ยงสิ่งนี้: ควรใช้บางอย่างเช่นboost::optional"คอนเทนเนอร์" เพื่อผลลัพธ์ของการดำเนินการที่อาจล้มเหลวแทนที่จะเป็นพอยน์เตอร์

ดังนั้นถ้ากรณีที่ใช้หลักสำหรับตัวชี้ null ควรจะเขียนในรูปแบบของนัยหล่อสไตล์ผมว่ามันเป็นเรื่องดีสำหรับเหตุผลที่สอดคล้องไปเสมอใช้รูปแบบนี้คือผมจะสนับสนุนให้มากกว่าif(ptr)if(ptr!=nullptr)

ฉันกลัวฉันจะต้องจบลงด้วยการอ้างอิงที่: if(auto bla = ...)ไวยากรณ์เป็นจริงเพียงประมาณยุ่งยากเล็กน้อยไปที่จริงวิธีการแก้ปัญหาดังกล่าว: จับคู่รูปแบบ ทำไมคุณต้องบังคับการกระทำบางอย่าง (เช่นการชี้ตัวชี้) แล้วพิจารณาว่าอาจมีความล้มเหลว ... ฉันหมายถึงมันไร้สาระใช่มั้ย มันเหมือนกับว่าคุณมีอาหารและต้องการทำซุป คุณมอบมันให้กับผู้ช่วยของคุณพร้อมกับภารกิจในการสกัดน้ำผลไม้หากมันเป็นผักที่อ่อนนุ่ม คุณไม่ได้ดูมันก่อน เมื่อคุณมีมันฝรั่งคุณยังมอบมันให้กับผู้ช่วยของคุณ แต่พวกมันตบหน้ามันด้วยโน้ตล้มเหลว Ah, การเขียนโปรแกรมที่จำเป็น!

ดีกว่ามาก: ลองพิจารณาทุกกรณีที่คุณพบ จากนั้นปฏิบัติตาม Haskell:

makeSoupOf :: Foodstuff -> Liquid
makeSoupOf p@(Potato{..}) = mash (boil p) <> water
makeSoupOf vegetable
 | isSoft vegetable  = squeeze vegetable <> salt
makeSoupOf stuff  = boil (throwIn (water<>salt) stuff)

Haskell ยังมีเครื่องมือพิเศษสำหรับเมื่อมีความเป็นไปได้ที่ร้ายแรงของความล้มเหลว (เช่นเดียวกับสิ่งอื่น ๆ ทั้งหมด): monads แต่นี่ไม่ใช่สถานที่สำหรับอธิบาย

^{⟨ / advert⟩}

ใช่แน่นอน! ในความเป็นจริงการเขียนถ้า (ตัวชี้) เป็นวิธีที่สะดวกกว่าในการเขียนมากกว่า (ตัวชี้! = NULL) เพราะ: 1. ง่ายต่อการดีบัก 2. ง่ายต่อการเข้าใจ 3. ถ้าตั้งใจค่า NULL จะถูกกำหนด จากนั้นรหัสก็จะไม่ผิดพลาด

ใช่. ในความเป็นจริงคุณควร หากคุณสงสัยว่ามันสร้างความผิดพลาดในการแบ่งเซ็กเมนต์หรือไม่

ในขณะที่คนอื่นตอบแล้วดีพวกเขาทั้งคู่จะใช้แทนกันได้

pointer != NULLกระนั้นก็มูลค่าการกล่าวขวัญว่าอาจมีกรณีที่คุณอาจต้องการที่จะใช้คำสั่งอย่างชัดเจนคือ

ดูเพิ่มเติมที่https://stackoverflow.com/a/60891279/2463963

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

ฉันคิดว่าเป็นกฎง่ายๆหากการแสดงออกของคุณสามารถเขียนใหม่เป็น

const bool local_predicate = *if-expression*;
if (local_predicate) ...

ดังกล่าวที่จะทำให้คำเตือนไม่มีแล้วที่ควรจะเป็นรูปแบบที่ต้องการสำหรับถ้าแสดงออก (ฉันรู้ว่าฉันได้รับคำเตือนเมื่อฉันกำหนด C BOOL( #define BOOL int) เก่าแก่C ++ boolให้ชี้อย่างเดียว)

"ปลอดภัยหรือไม่ .. " เป็นคำถามเกี่ยวกับมาตรฐานภาษาและรหัสที่สร้างขึ้น

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