C++ nhớ bảng chức năng ảo tốn

Question

xem xét:

class A 
{ 
    public: 
     virtual void update() = 0; 
} 

class B : public A 
{ 
    public: 
     void update() { /* stuff goes in here... */ } 

    private: 
     double a, b, c; 
} 

class C { 
    // Same kind of thing as B, but with different update function/data members 
} 

Tôi bây giờ thực hiện:

A * array = new A[1000]; 
array[0] = new B(); 
array[1] = new C(); 
//etc., etc. 

Nếu tôi gọi sizeof(B), kích thước trở lại là kích thước theo yêu cầu của 3 thành viên tăng gấp đôi, cộng với một số chi phí cần thiết cho bảng con trỏ hàm ảo. Bây giờ, trở lại mã của tôi, nó chỉ ra rằng 'sizeof (myclass)' là 32; có nghĩa là, tôi đang sử dụng 24 byte cho các thành viên dữ liệu của tôi, và 8 byte cho bảng chức năng ảo (4 chức năng ảo). Câu hỏi của tôi là: có cách nào tôi có thể sắp xếp hợp lý điều này không? Chương trình của tôi cuối cùng sẽ sử dụng rất nhiều bộ nhớ, và tôi không thích âm thanh 25% của nó được ăn bởi các con trỏ hàm ảo.

Answer 1

Thông thường, mọi trường hợp của một lớp có ít nhất một hàm ảo sẽ có thêm một con trỏ được lưu trữ với các thành viên dữ liệu rõ ràng của nó.

Không có cách nào làm tròn điều này, nhưng hãy nhớ rằng (một lần nữa) mỗi bảng chức năng ảo được chia sẻ giữa tất cả các phiên bản của lớp, vì vậy không có phí tuyệt vời để có nhiều chức năng ảo hoặc thừa kế thừa trả "thuế vptr" (chi phí nhỏ của con trỏ vtable).

Đối với các lớp học lớn hơn, chi phí sẽ trở nên nhỏ hơn nhiều so với phần trăm.

Nếu bạn muốn chức năng hoạt động giống như chức năng ảo, bạn sẽ phải trả tiền theo cách nào đó. Trên thực tế sử dụng các chức năng ảo gốc cũng có thể là tùy chọn rẻ nhất.

Answer 2

Bảng v là cho mỗi lớp chứ không phải cho mỗi đối tượng. Mỗi đối tượng chỉ chứa một con trỏ vào bảng v. Vì vậy, chi phí cho mỗi trường hợp là sizeof(pointer) (thường là 4 hoặc 8 byte). Không quan trọng bạn có bao nhiêu hàm ảo cho kích thước của đối tượng lớp. Xem xét điều này, tôi nghĩ bạn không nên lo lắng quá nhiều về nó.

Answer 3

Bạn có hai tùy chọn.

1) Đừng lo lắng về điều đó.

2) Không sử dụng các chức năng ảo. Tuy nhiên, không sử dụng các chức năng ảo chỉ có thể di chuyển kích thước vào mã của bạn, vì mã của bạn trở nên phức tạp hơn.

Answer 4

Chi phí không gian của vtable là một con trỏ (căn chỉnh modulo). Bản thân bảng không được đặt vào mỗi thể hiện của lớp.

Answer 5

Nếu bạn biết tất cả các loại dẫn xuất và chức năng cập nhật tương ứng của chúng, bạn có thể lưu trữ kiểu dẫn xuất trong A và thực hiện gửi thủ công cho phương thức cập nhật.

Tuy nhiên, như những người khác đang chỉ ra, bạn thực sự không trả tiền nhiều cho vtable, và sự cân bằng là mã phức tạp (và tùy thuộc vào sự liên kết, bạn có thể không tiết kiệm bộ nhớ nào cả!). Ngoài ra, nếu bất kỳ thành viên dữ liệu nào của bạn có một destructor, thì bạn cũng phải lo lắng về việc gửi đi thủ công destructor.

Nếu bạn vẫn muốn đi tuyến đường này, nó có thể trông như thế này:

class A; 
void dispatch_update(A &); 

class A 
{ 
public: 
    A(char derived_type) 
     : m_derived_type(derived_type) 
    {} 
    void update() 
    { 
     dispatch_update(*this); 
    } 
    friend void dispatch_update(A &); 
private: 
    char m_derived_type; 
}; 

class B : public A 
{ 
public: 
    B() 
     : A('B') 
    {} 
    void update() { /* stuff goes in here... */ } 

private: 
    double a, b, c; 
}; 

void dispatch_update(A &a) 
{ 
    switch (a.m_derived_type) 
    { 
    case 'B': 
     static_cast<B &> (a).update(); 
     break; 
    // ... 
    } 
} 

Answer 6

Có bao nhiêu trường hợp của lớp A có nguồn gốc từ sao bạn mong đợi? Bạn mong đợi bao nhiêu lớp học có nguồn gốc A khác biệt?

Lưu ý rằng ngay cả với hàng triệu trường hợp, chúng tôi đang nói về tổng cộng 32MB. Lên đến 10 triệu, không đổ mồ hôi nó.

Thông thường, bạn cần thêm một con trỏ cho mỗi trường hợp, (nếu bạn đang chạy trên nền tảng 32 bit, 4 byte cuối cùng là do căn chỉnh). Mỗi lớp tiêu thụ thêm (Number of virtual functions * sizeof(virtual function pointer) + fixed size) byte cho VMT của nó.

Lưu ý rằng, xem xét căn chỉnh cho đôi, thậm chí một byte đơn là định danh loại sẽ làm tăng kích thước phần tử mảng lên 32. Vì vậy, giải pháp của Stjepan Rajko hữu ích trong một số trường hợp, nhưng không phải trong của bạn.

Ngoài ra, đừng quên chi phí của một vùng chung cho rất nhiều đối tượng nhỏ. Bạn có thể có 8 byte khác cho mỗi đối tượng. Với trình quản lý heap tùy chỉnh - chẳng hạn như đối tượng/kích thước cụ thể pool allocator - bạn có thể tiết kiệm nhiều hơn tại đây và sử dụng giải pháp chuẩn.

Answer 7

Bạn đang thêm một con trỏ vào vtable cho mỗi đối tượng - nếu bạn thêm một số hàm ảo mới, kích thước của từng đối tượng sẽ không tăng. Lưu ý rằng ngay cả khi bạn đang ở trên nền tảng 32 bit, nơi con trỏ là 4 byte, bạn sẽ thấy kích thước của đối tượng tăng lên 8 có thể do yêu cầu căn chỉnh tổng thể của cấu trúc (ví dụ: bạn nhận được 4 byte của padding).

Vì vậy, ngay cả khi bạn đã tạo lớp không ảo, việc thêm một thành viên char đơn lẻ có thể sẽ thêm 8 byte đầy đủ vào kích thước của từng đối tượng.

Tôi nghĩ rằng cách duy nhất bạn sẽ có thể giảm kích thước của bạn đối tượng sẽ được:

• làm cho họ không ảo (? Bạn có thực sự cần hành vi đa hình)
• sử dụng thay vì tăng gấp đôi cho một hoặc nhiều thành viên dữ liệu nếu bạn không cần độ chính xác
• nếu bạn có khả năng thấy nhiều đối tượng có cùng giá trị cho thành viên dữ liệu, bạn có thể tiết kiệm dung lượng bộ nhớ đối với một số phức tạp trong việc quản lý các đối tượng bằng cách sử dụng Flyweight design pattern

Answer 8

Không phải là câu trả lời cho câu hỏi trực tiếp, mà còn xem xét thứ tự khai báo của các thành viên dữ liệu có thể tăng hoặc giảm mức tiêu thụ bộ nhớ thực của bạn cho mỗi đối tượng lớp. Điều này là do hầu hết các trình biên dịch không thể (đọc: không) tối ưu hóa thứ tự mà các thành viên lớp được đặt ra trong bộ nhớ để giảm phân mảnh nội bộ do các tai ương liên kết.

Answer 9

Nếu bạn sắp có hàng triệu thứ này và bộ nhớ là mối quan tâm nghiêm trọng đối với bạn, thì có thể bạn không nên làm cho chúng trở thành đối tượng. Chỉ cần khai báo chúng như một cấu trúc hoặc một mảng gồm 3 đôi (hoặc bất kỳ thứ gì), và đặt các hàm để thao tác dữ liệu ở một nơi khác.

Nếu bạn thực sự cần những hành vi đa hình, có lẽ bạn không thể giành chiến thắng, kể từ khi loại thông tin bạn muốn có để lưu trữ trong cấu trúc của bạn sẽ kết thúc chiếm một lượng tương tự của không gian ...

Is có khả năng bạn sẽ có nhiều nhóm đối tượng cùng loại? Trong trường hợp đó, bạn có thể đặt các loại thông tin một cấp "lên" từ cá nhân "A" lớp ...

Cái gì như:

class A_collection 
{ 
    public: 
     virtual void update() = 0; 
} 

class B_collection : public A_collection 
{ 
    public: 
     void update() { /* stuff goes in here... */ } 

    private: 
     vector<double[3]> points; 
} 

class C_collection { /* Same kind of thing as B_collection, but with different update function/data members */ 

Answer 10

Với tất cả các câu trả lời rằng đã ở đây, tôi nghĩ rằng Tôi phải điên rồ, nhưng điều này có vẻ đúng với tôi vì vậy tôi đăng nó dù sao đi nữa.Khi tôi lần đầu tiên nhìn thấy ví dụ mã của bạn, tôi nghĩ bạn đã cắt các trường hợp của B và C, nhưng sau đó tôi nhìn gần hơn một chút. Tôi bây giờ hợp lý chắc chắn ví dụ của bạn sẽ không biên dịch ở tất cả, nhưng tôi không có một trình biên dịch trên hộp này để kiểm tra.

A * array = new A[1000]; 
array[0] = new B(); 
array[1] = new C(); 

Với tôi, điều này có vẻ như dòng đầu tiên phân bổ một mảng 1000 A. Hai dòng tiếp theo hoạt động trên các phần tử thứ nhất và thứ hai của mảng đó, tương ứng, là các cá thể của A, không trỏ đến A. Do đó bạn không thể gán một con trỏ tới A cho các phần tử đó (và new B() trả về một con trỏ như vậy). Các loại không giống nhau, do đó nó sẽ không thành công tại thời gian biên dịch (trừ khi A có một toán tử gán phải mất A*, trong trường hợp này nó sẽ làm bất cứ điều gì bạn đã nói nó làm).

Vì vậy, tôi hoàn toàn có cơ sở không? Tôi mong muốn tìm ra những gì tôi đã bỏ lỡ.

Answer 11

Di chuyển ra khỏi vấn đề không của con trỏ vtable trong đối tượng của bạn:

Mã của bạn có vấn đề khác:

A * array = new A[1000]; 
array[0] = new B(); 
array[1] = new C(); 

Vấn đề bạn đang gặp phải là vấn đề cắt.
Bạn không thể đặt đối tượng của lớp B vào khoảng trống được đặt trước cho đối tượng của lớp A.
Bạn sẽ chỉ cắt phần B (hoặc C) của đối tượng sạch sẽ để lại bạn chỉ với phần A.

Điều bạn muốn làm. Có một mảng của một con trỏ để nó giữ mỗi mục bằng con trỏ.

A** array = new A*[1000]; 
array[0] = new B(); 
array[1] = new C(); 

Bây giờ bạn có một vấn đề khác về sự hủy diệt. Được. Điều này có thể đi vào cho các lứa tuổi.
ngắn câu trả lời sử dụng boost: ptr_vector <>

boost:ptr_vector<A> array(1000); 
array[0] = new B(); 
array[1] = new C(); 

Never allocte mảng như vậy, trừ khi bạn phải (nó quá Java Giống như là hữu ích).

Answer 12

Như những người khác đã nói, trong một cách tiếp cận phổ biến thực hiện phổ biến, một khi một lớp trở nên đa hình, mỗi cá thể phát triển bởi kích thước của một con trỏ dữ liệu thông thường. Không quan trọng bạn có bao nhiêu chức năng ảo trong lớp của mình. Trên nền tảng 64 bit, kích thước sẽ tăng 8 byte. Nếu bạn quan sát sự tăng trưởng 8 byte trên nền tảng 32-bit, nó có thể gây ra bởi đệm được thêm vào con trỏ 4 byte để căn chỉnh (nếu lớp của bạn có yêu cầu căn chỉnh 8 byte).

Ngoài ra, có thể cần lưu ý rằng thừa kế ảo có thể đưa thêm con trỏ dữ liệu vào các phiên bản lớp (con trỏ cơ sở ảo). Tôi chỉ quen thuộc với một vài triển khai và trong ít nhất một số con trỏ cơ sở ảo giống như số lượng cơ sở ảo trong lớp, có nghĩa là thừa kế ảo có thể thêm nhiều con trỏ dữ liệu nội bộ vào mỗi cá thể.

Answer 13

Nếu bạn thực sự muốn lưu bộ nhớ của con trỏ bảng ảo trong từng đối tượng thì bạn có thể triển khai mã theo kiểu C ...

Ví dụ:

struct Point2D { 
int x,y; 
}; 

struct Point3D { 
int x,y,z; 
}; 

void Draw2D(void *pThis) 
{ 
    Point2D *p = (Point2D *) pThis; 
    //do something 
} 

void Draw3D(void *pThis) 
{ 
    Point3D *p = (Point3D *) pThis; 
//do something 
} 

int main() 
{ 

    typedef void (*pDrawFunct[2])(void *); 

    pDrawFunct p; 
    Point2D pt2D; 
    Point3D pt3D; 

    p[0] = &Draw2D; 
    p[1] = &Draw3D;  

    p[0](&pt2D); //it will call Draw2D function 
    p[1](&pt3D); //it will call Draw3D function 
    return 0; 
}