การสร้างอินสแตนซ์วัตถุ C ++

ฉันเป็นโปรแกรมเมอร์ C ที่พยายามเข้าใจ C ++ บทช่วยสอนจำนวนมากแสดงให้เห็นถึงการสร้างอินสแตนซ์อ็อบเจ็กต์โดยใช้ข้อมูลโค้ดเช่น:

Dog* sparky = new Dog();

ซึ่งหมายความว่าในภายหลังคุณจะทำ:

delete sparky;

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

Dog sparky;

และปล่อยให้ผู้ทำลายถูกเรียกเมื่อประกายไฟออกไปนอกขอบเขต?

ขอบคุณ!

ในทางตรงกันข้ามคุณควรชอบการจัดสรรสแต็กเสมอเท่าที่ตามหลักทั่วไปคุณไม่ควรมีใหม่ / ลบในรหัสผู้ใช้ของคุณ

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

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

ชื่อที่พบบ่อยที่สุดสำหรับสำนวนนี้คือRAII

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

แบบฝึกหัดจำนวนมากแสดงให้เห็นถึงการสร้างอินสแตนซ์อ็อบเจ็กต์โดยใช้ข้อมูลโค้ดเช่น ...

ดังนั้นสิ่งที่คุณค้นพบก็คือบทช่วยสอนส่วนใหญ่ดูด ;) บทช่วยสอนส่วนใหญ่จะสอนวิธีปฏิบัติ C ++ ที่ไม่ดีให้กับคุณรวมถึงการเรียกใหม่ / ลบเพื่อสร้างตัวแปรเมื่อไม่จำเป็นและทำให้คุณมีเวลาติดตามตลอดอายุการใช้งานของการจัดสรรของคุณ

แม้ว่าการมีสิ่งต่างๆในสแต็กอาจเป็นข้อดีในแง่ของการจัดสรรและการพ้นอัตโนมัติ แต่ก็มีข้อเสียอยู่บ้าง

1. คุณอาจไม่ต้องการจัดสรรวัตถุขนาดใหญ่บน Stack

2. ส่งแบบไดนามิก! พิจารณารหัสนี้:

#include <iostream>

class A {
public:
  virtual void f();
  virtual ~A() {}
};

class B : public A {
public:
  virtual void f();
};

void A::f() {cout << "A";}
void B::f() {cout << "B";}

int main(void) {
  A *a = new B();
  a->f();
  delete a;
  return 0;
}

สิ่งนี้จะพิมพ์ "B" มาดูกันว่าจะเกิดอะไรขึ้นเมื่อใช้ Stack:

int main(void) {
  A a = B();
  a.f();
  return 0;
}

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

บางสิ่งอาจเกิดขึ้นโดยไม่ได้ตั้งใจโดยเฉพาะอย่างยิ่งเมื่อคุณยังใหม่กับ C ++ ใน C คุณมีพอยน์เตอร์ของคุณนั่นแหล่ะ คุณรู้วิธีใช้และพวกเขาก็ทำเช่นเดียวกันเสมอ ใน C ++ ไม่เป็นเช่นนั้น ลองนึกดูว่าจะเกิดอะไรขึ้นเมื่อคุณใช้ในตัวอย่างนี้เป็นอาร์กิวเมนต์สำหรับวิธีการสิ่งต่าง ๆ จะซับซ้อนมากขึ้นและมันสร้างความแตกต่างอย่างมากหากaเป็นประเภทAหรือA*หรือแม้กระทั่งA&(call-by-reference) การผสมผสานหลายอย่างเป็นไปได้และพวกเขาทั้งหมดมีพฤติกรรมที่แตกต่างกัน

เหตุผลในการใช้ตัวชี้จะเหมือนกันทุกประการกับเหตุผลที่ต้องใช้ตัวชี้ใน C ที่จัดสรรด้วย malloc: ถ้าคุณต้องการให้วัตถุของคุณอยู่ได้นานกว่าตัวแปรของคุณ!

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

ฉันเคยเห็นรูปแบบการต่อต้านนี้จากผู้ที่ไม่ค่อยได้รับ & ที่อยู่ของผู้ให้บริการ หากพวกเขาต้องการเรียกใช้ฟังก์ชันด้วยตัวชี้พวกเขาจะจัดสรรบนฮีปเสมอเพื่อให้ได้ตัวชี้

void FeedTheDog(Dog* hungryDog);

Dog* badDog = new Dog;
FeedTheDog(badDog);
delete badDog;

Dog goodDog;
FeedTheDog(&goodDog);

ถือว่าฮีปเป็นอสังหาริมทรัพย์ที่สำคัญมากและใช้อย่างรอบคอบ กฎพื้นฐานทั่วไปคือการใช้ stack เมื่อใดก็ตามที่เป็นไปได้และใช้ heap เมื่อใดก็ตามที่ไม่มีวิธีอื่น ด้วยการจัดสรรวัตถุบนสแต็กคุณจะได้รับประโยชน์มากมายเช่น:

(1) คุณไม่จำเป็นต้องกังวลเกี่ยวกับการคลายสแต็กในกรณีที่มีข้อยกเว้น

(2) คุณไม่จำเป็นต้องกังวลเกี่ยวกับการกระจายตัวของหน่วยความจำที่เกิดจากการจัดสรรพื้นที่มากเกินความจำเป็นโดยตัวจัดการฮีปของคุณ

เหตุผลเดียวที่ฉันกังวลคือตอนนี้ Dog ได้รับการจัดสรรให้อยู่ในสแต็กแทนที่จะเป็นฮีป ดังนั้นหาก Dog มีขนาดเมกะไบต์คุณอาจมีปัญหา

หากคุณจำเป็นต้องไปเส้นทางใหม่ / ลบโปรดระวังข้อยกเว้น และด้วยเหตุนี้คุณจึงควรใช้ auto_ptr หรือ boost smart pointer ประเภทหนึ่งเพื่อจัดการอายุการใช้งานของวัตถุ

ไม่มีเหตุผลที่จะใหม่ (บนฮีป) เมื่อคุณสามารถจัดสรรบนสแต็กได้ (เว้นแต่ด้วยเหตุผลบางประการที่คุณมีสแต็กขนาดเล็กและต้องการใช้ฮีป

คุณอาจต้องการพิจารณาใช้ shared_ptr (หรือตัวแปรตัวใดตัวหนึ่ง) จากไลบรารีมาตรฐานหากคุณต้องการจัดสรรบนฮีป ซึ่งจะจัดการลบให้คุณเมื่อการอ้างอิงถึง shared_ptr หมดไปจากการมีอยู่แล้ว

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

ฉันมีปัญหาเดียวกันใน Visual Studio คุณต้องใช้:

yourClass-> classMethod ();

ค่อนข้างมากกว่า:

yourClass.classMethod ();