Sao chép hàm tạo và = toán tử quá tải trong C ++: một hàm phổ biến có thể thực hiện được không?

Kể từ một phương thức tạo bản sao

MyClass(const MyClass&);

và một = toán tử quá tải

MyClass& operator = (const MyClass&);

có khá nhiều mã giống nhau, cùng một tham số và chỉ khác nhau về kết quả trả về, liệu có thể có một hàm chung cho cả hai để sử dụng không?

Đúng. Có hai lựa chọn phổ biến. Một - điều thường không được khuyến khích - là gọi operator=từ hàm tạo bản sao một cách rõ ràng:

MyClass(const MyClass& other)
{
    operator=(other);
}

Tuy nhiên, cung cấp một sản phẩm tốt operator=là một thách thức khi phải đối mặt với tình trạng cũ và các vấn đề phát sinh từ việc tự phân công. Ngoài ra, tất cả các thành viên và cơ sở được khởi tạo mặc định trước ngay cả khi chúng được chỉ định từ other. Điều này thậm chí có thể không hợp lệ cho tất cả các thành viên và cơ sở và ngay cả khi nó hợp lệ thì nó thừa về mặt ngữ nghĩa và có thể đắt tiền.

Một giải pháp ngày càng phổ biến là thực hiện operator=bằng cách sử dụng phương thức sao chép và phương thức hoán đổi.

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

hoặc thậm chí:

MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

Một swaphàm thường đơn giản để viết vì nó chỉ hoán đổi quyền sở hữu của các bên trong và không phải xóa trạng thái hiện có hoặc phân bổ tài nguyên mới.

Ưu điểm của thành ngữ sao chép và hoán đổi là nó tự động an toàn và - miễn là hoạt động hoán đổi là không cần thiết - cũng rất an toàn ngoại lệ.

Để đảm bảo an toàn ngoại lệ mạnh mẽ, một toán tử gán tài nguyên viết tay 'thường phải cấp phát một bản sao của tài nguyên mới trước khi hủy phân bổ tài nguyên cũ của người được chuyển nhượng để nếu có ngoại lệ xảy ra, phân bổ tài nguyên mới, trạng thái cũ vẫn có thể được trả về . Tất cả điều này đều miễn phí với tính năng sao chép và trao đổi nhưng thường phức tạp hơn và do đó dễ xảy ra lỗi, phải làm lại từ đầu.

Một điều cần cẩn thận là đảm bảo rằng phương thức hoán đổi là một phương thức hoán đổi thực sự, chứ không phải là phương thức mặc định std::swapsử dụng chính hàm tạo bản sao và toán tử gán.

Thông thường một thành viên swapđược sử dụng. std::swaphoạt động và được đảm bảo 'không ném' với tất cả các kiểu cơ bản và kiểu con trỏ. Hầu hết các con trỏ thông minh cũng có thể được hoán đổi với một đảm bảo không ném.

Hàm tạo bản sao thực hiện khởi tạo lần đầu các đối tượng từng là bộ nhớ thô. Toán tử gán, OTOH, ghi đè các giá trị hiện có bằng các giá trị mới. Thường xuyên hơn không bao giờ, điều này liên quan đến việc loại bỏ các tài nguyên cũ (ví dụ: bộ nhớ) và phân bổ tài nguyên mới.

Nếu có sự giống nhau giữa cả hai, đó là toán tử gán thực hiện hủy và xây dựng bản sao. Một số nhà phát triển đã từng thực sự triển khai phân công bằng cách phá hủy tại chỗ, sau đó là xây dựng bản sao theo vị trí. Tuy nhiên, đây là một ý tưởng rất tồi. (Điều gì sẽ xảy ra nếu đây là toán tử gán của một lớp cơ sở được gọi trong khi gán một lớp dẫn xuất?)

Những gì thường được coi là thành ngữ kinh điển ngày nay đang được sử dụng swapnhư Charles đã đề xuất:

MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

Điều này sử dụng sao chép-xây dựng (lưu ý rằng otherđược sao chép) và phá hủy (nó bị hủy ở cuối hàm) - và nó cũng sử dụng chúng theo đúng thứ tự: xây dựng (có thể thất bại) trước khi phá hủy (không được thất bại).

Có điều gì đó làm tôi khó chịu:

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

Đầu tiên, đọc từ "hoán đổi" khi tâm trí tôi đang nghĩ "bản sao" làm tôi khó chịu. Ngoài ra, tôi đặt câu hỏi về mục tiêu của thủ thuật lạ mắt này. Có, bất kỳ ngoại lệ nào trong việc xây dựng các tài nguyên mới (được sao chép) sẽ xảy ra trước khi hoán đổi, đây có vẻ như là một cách an toàn để đảm bảo tất cả dữ liệu mới được lấp đầy trước khi đưa nó vào hoạt động.

Tốt rồi. Vì vậy, những gì về ngoại lệ xảy ra sau khi hoán đổi? (khi tài nguyên cũ bị hủy khi đối tượng tạm thời vượt ra khỏi phạm vi) Từ quan điểm của người sử dụng phép gán, hoạt động đã thất bại, ngoại trừ nó đã không. Nó có một tác dụng phụ rất lớn: bản sao đã thực sự xảy ra. Nó chỉ là một số tài nguyên dọn dẹp không thành công. Trạng thái của đối tượng đích đã được thay đổi mặc dù hoạt động từ bên ngoài có vẻ như đã thất bại.

Vì vậy, tôi đề xuất thay vì "hoán đổi" để thực hiện một "chuyển giao" tự nhiên hơn:

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    transfer(tmp);
    return *this;
}

Vẫn còn việc xây dựng đối tượng tạm thời, nhưng hành động ngay lập tức tiếp theo là giải phóng tất cả tài nguyên hiện tại của đích trước khi di chuyển (và NULLing để chúng không bị giải phóng hai lần) tài nguyên của nguồn tới nó.

Thay vì {cấu tạo, di chuyển, hủy bỏ}, tôi đề xuất {cấu trúc, hủy, di chuyển}. Động thái, là hành động nguy hiểm nhất, là hành động được thực hiện cuối cùng sau khi mọi việc khác đã được giải quyết.

Có, phá hủy không thành công là một vấn đề trong cả hai chương trình. Dữ liệu bị hỏng (được sao chép khi bạn không nghĩ là có) hoặc bị mất (được giải phóng khi bạn không nghĩ là có). Mất tốt hơn là bị hỏng. Không có dữ liệu nào tốt hơn dữ liệu xấu.

Chuyển khoản thay vì hoán đổi. Đó là gợi ý của tôi anyway.