Tại sao một T * có thể được thông qua trong đăng ký, nhưng unique_ptr <T> không thể?

Tôi đang xem cuộc nói chuyện của Chandler Carruth trong CppCon 2019:

Không có Tóm tắt chi phí bằng không

trong đó, anh ta đưa ra ví dụ về việc anh ta đã ngạc nhiên như thế nào về việc bạn phải chịu bao nhiêu chi phí bằng cách sử dụng một cái std::unique_ptr<int>trên int*; đoạn đó bắt đầu vào thời điểm 17:25.

Bạn có thể xem kết quả biên dịch của cặp đoạn trích mẫu của anh ấy (godbolt.org) - để chứng kiến ​​rằng, thực sự, có vẻ như trình biên dịch không sẵn sàng vượt qua giá trị unique_ptr - mà thực tế ở dòng dưới cùng là chỉ là một địa chỉ - bên trong một thanh ghi, chỉ trong bộ nhớ thẳng.

Một trong những điểm mà ông Carruth đưa ra vào khoảng 27:00 là C ++ ABI yêu cầu các tham số theo giá trị (một số nhưng không phải tất cả; có lẽ - các loại không nguyên thủy? Các loại không tầm thường?) Được truyền vào bộ nhớ thay vì trong một đăng ký.

Những câu hỏi của tôi:

1. Đây thực sự là một yêu cầu ABI trên một số nền tảng? (mà?) Hoặc có thể đó chỉ là một số bi quan trong một số tình huống nhất định?
2. Tại sao ABI lại như vậy? Đó là, nếu các trường của struct / class phù hợp với các thanh ghi, hoặc thậm chí là một thanh ghi duy nhất - tại sao chúng ta không thể vượt qua nó trong thanh ghi đó?
3. Ủy ban tiêu chuẩn C ++ đã thảo luận về điểm này trong những năm gần đây hay chưa?

PS - Vì vậy, không để lại câu hỏi này không có mã:

Con trỏ đơn giản:

void bar(int* ptr) noexcept;
void baz(int* ptr) noexcept;

void foo(int* ptr) noexcept {
    if (*ptr > 42) {
        bar(ptr); 
        *ptr = 42; 
    }
    baz(ptr);
}

Con trỏ duy nhất:

using std::unique_ptr;
void bar(int* ptr) noexcept;
void baz(unique_ptr<int> ptr) noexcept;

void foo(unique_ptr<int> ptr) noexcept {
    if (*ptr > 42) { 
        bar(ptr.get());
        *ptr = 42; 
    }
    baz(std::move(ptr));
}

1. Đây thực sự là một yêu cầu ABI, hoặc có thể nó chỉ là một sự bi quan trong một số tình huống nhất định?

Một ví dụ là Giao diện nhị phân ứng dụng System64 Bổ sung bộ xử lý kiến ​​trúc AMD64 . ABI này dành cho CPU tương thích 64 bit x86 (kiến trúc Linux x86_64). Nó được theo dõi trên Solaris, Linux, FreeBSD, macOS, Hệ thống con Windows cho Linux:

Nếu một đối tượng C ++ có hàm tạo sao chép không tầm thường hoặc hàm hủy không tầm thường, thì nó được truyền bằng tham chiếu vô hình (đối tượng được thay thế trong danh sách tham số bằng một con trỏ có lớp INTEGER).

Một đối tượng với hàm tạo sao chép không tầm thường hoặc hàm hủy không tầm thường không thể được truyền bằng giá trị vì các đối tượng đó phải có địa chỉ được xác định rõ. Các vấn đề tương tự được áp dụng khi trả về một đối tượng từ một hàm.

Lưu ý, chỉ có thể sử dụng 2 thanh ghi mục đích chung để truyền 1 đối tượng với hàm tạo sao chép tầm thường và hàm hủy tầm thường, tức là chỉ các giá trị của các đối tượng sizeofkhông lớn hơn 16 có thể được truyền vào các thanh ghi. Xem các quy ước gọi của Agner Fog để biết cách xử lý chi tiết các quy ước gọi, đặc biệt là §7.1 Các đối tượng chuyển và trả lại. Có các quy ước gọi riêng để chuyển các loại SIMD trong các thanh ghi.

Có các ABI khác nhau cho các kiến ​​trúc CPU khác.

2. Tại sao ABI lại như vậy? Đó là, nếu các trường của struct / class phù hợp với các thanh ghi, hoặc thậm chí là một thanh ghi duy nhất - tại sao chúng ta không thể vượt qua nó trong thanh ghi đó?

Đây là một chi tiết triển khai, nhưng khi một ngoại lệ được xử lý, trong quá trình giải nén ngăn xếp, các đối tượng có thời gian lưu trữ tự động bị phá hủy phải có địa chỉ liên quan đến khung ngăn xếp chức năng vì các thanh ghi đã bị chặn bởi thời gian đó. Mã giải nén ngăn xếp cần địa chỉ của các đối tượng để gọi các hàm hủy của chúng nhưng các đối tượng trong các thanh ghi không có địa chỉ.

Về mặt giáo dục, các tàu khu trục hoạt động trên các đối tượng :

Một đối tượng chiếm một vùng lưu trữ trong thời kỳ xây dựng ([class.cdtor]), trong suốt vòng đời của nó và trong thời kỳ hủy diệt.

và một đối tượng không thể tồn tại trong C ++ nếu không có bộ nhớ địa chỉ nào được phân bổ cho nó vì danh tính của đối tượng là địa chỉ của nó .

Khi cần một địa chỉ của một đối tượng với hàm tạo sao chép tầm thường trong các thanh ghi, trình biên dịch chỉ có thể lưu trữ đối tượng vào bộ nhớ và lấy địa chỉ. Nếu hàm tạo sao chép là không tầm thường, mặt khác, trình biên dịch không thể lưu trữ nó vào bộ nhớ, nó cần gọi hàm tạo sao chép để tham chiếu và do đó yêu cầu địa chỉ của đối tượng trong các thanh ghi. Quy ước gọi có lẽ không thể phụ thuộc vào việc hàm tạo sao chép có được đặt trong callee hay không.

Một cách khác để suy nghĩ về điều này, là đối với các loại có thể sao chép tầm thường, trình biên dịch sẽ chuyển giá trị của một đối tượng trong các thanh ghi, từ đó một đối tượng có thể được phục hồi bằng các bộ nhớ đơn giản nếu cần thiết. Ví dụ:

void f(long*);
void g(long a) { f(&a); }

trên x86_64 với System V ABI biên dịch thành:

g(long):                             // Argument a is in rdi.
        push    rax                  // Align stack, faster sub rsp, 8.
        mov     qword ptr [rsp], rdi // Store the value of a in rdi into the stack to create an object.
        mov     rdi, rsp             // Load the address of the object on the stack into rdi.
        call    f(long*)             // Call f with the address in rdi.
        pop     rax                  // Faster add rsp, 8.
        ret                          // The destructor of the stack object is trivial, no code to emit.

Trong bài nói chuyện kích thích tư duy của mình, Chandler Carruth đã đề cập rằng một sự thay đổi ABI phá vỡ có thể là cần thiết (trong số những thứ khác) để thực hiện động thái phá hoại có thể cải thiện mọi thứ. IMO, thay đổi ABI có thể không phá vỡ nếu các chức năng sử dụng ABI mới chọn tham gia rõ ràng để có một liên kết khác mới, ví dụ: khai báo chúng trongextern "C++20" {} khối (có thể, trong một không gian tên nội tuyến mới để di chuyển các API hiện có). Vì vậy, chỉ có mã được biên dịch theo các khai báo hàm mới với liên kết mới có thể sử dụng ABI mới.

Lưu ý rằng ABI không áp dụng khi hàm được gọi đã được nội tuyến. Cũng như với việc tạo mã thời gian liên kết, trình biên dịch có thể các hàm nội tuyến được xác định trong các đơn vị dịch thuật khác hoặc sử dụng các quy ước gọi tùy chỉnh.

Với ABI thông thường, hàm hủy không tầm thường -> không thể vượt qua trong các thanh ghi

_{(Một minh họa về một điểm trong câu trả lời của @ MaximEgorushkin bằng cách sử dụng ví dụ của @ harold trong một nhận xét; được sửa theo nhận xét của @ Yakk.)}

Nếu bạn biên dịch:

struct Foo { int bar; };
Foo test(Foo byval) { return byval; }

bạn lấy:

test(Foo):
        mov     eax, edi
        ret

tức là Foođối tượng được truyền testvào một thanh ghi ( edi) và cũng được trả về trong một thanh ghi ( eax).

Khi hàm hủy không tầm thường (như std::unique_ptr ví dụ về OP) - ABI thông thường yêu cầu vị trí trên ngăn xếp. Điều này đúng ngay cả khi hàm hủy hoàn toàn không sử dụng địa chỉ của đối tượng.

Do đó, ngay cả trong trường hợp cực đoan của hàm hủy không làm gì, nếu bạn biên dịch:

struct Foo2 {
    int bar;
    ~Foo2() {  }
};

Foo2 test(Foo2 byval) { return byval; }

bạn lấy:

test(Foo2):
        mov     edx, DWORD PTR [rsi]
        mov     rax, rdi
        mov     DWORD PTR [rdi], edx
        ret

với tải và lưu trữ vô dụng.

Đây thực sự là một yêu cầu ABI trên một số nền tảng? (mà?) Hoặc có thể đó chỉ là một số bi quan trong một số tình huống nhất định?

Nếu một cái gì đó có thể nhìn thấy ở bộ phận đơn vị khiếu nại thì nó được định nghĩa ngầm hay rõ ràng nó trở thành một phần của ABI.

Tại sao ABI lại như vậy?

Vấn đề cơ bản là các thanh ghi được lưu và khôi phục mọi lúc khi bạn di chuyển xuống và lên ngăn xếp cuộc gọi. Vì vậy, nó không thực tế để có một tham chiếu hoặc con trỏ đến chúng.

Nội tuyến và tối ưu hóa kết quả từ nó là tốt khi nó xảy ra, nhưng một nhà thiết kế ABI không thể dựa vào nó xảy ra. Họ phải thiết kế ABI giả sử trường hợp xấu nhất. Tôi không nghĩ các lập trình viên sẽ rất hài lòng với trình biên dịch mà ABI thay đổi tùy thuộc vào mức độ tối ưu hóa.

Một loại có thể sao chép tầm thường có thể được thông qua trong các thanh ghi vì hoạt động sao chép logic có thể được chia thành hai phần. Các tham số được sao chép vào các thanh ghi được sử dụng để truyền tham số cho người gọi và sau đó sao chép vào biến cục bộ bằng callee. Cho dù biến cục bộ có vị trí bộ nhớ hay không thì đó chỉ là mối quan tâm của callee.

Một loại trong đó một công cụ sao chép hoặc di chuyển phải được sử dụng mặt khác không thể có hoạt động sao chép được phân tách theo cách này, vì vậy nó phải được truyền vào bộ nhớ.

Ủy ban tiêu chuẩn C ++ đã thảo luận về điểm này trong những năm gần đây hay chưa?

Tôi không biết nếu các cơ quan tiêu chuẩn đã xem xét điều này.

Giải pháp rõ ràng với tôi là thêm các động thái phá hoại thích hợp (chứ không phải là ngôi nhà nửa chừng hiện tại của "trạng thái hợp lệ nhưng không xác định") vào ngôn ngữ, sau đó giới thiệu một cách để gắn cờ một loại như cho phép "di chuyển phá hoại tầm thường "Ngay cả khi nó không cho phép các bản sao tầm thường.

nhưng một giải pháp như vậy sẽ yêu cầu phá vỡ ABI của mã hiện tại để triển khai cho các loại hiện có, điều này có thể mang lại một chút kháng cự (mặc dù ABI bị phá vỡ do các phiên bản tiêu chuẩn C ++ mới không phải là chưa từng có, ví dụ như thay đổi chuỗi std :: trong C ++ 11 dẫn đến phá vỡ ABI ..

Đầu tiên chúng ta cần quay trở lại ý nghĩa của việc vượt qua giá trị và tham chiếu.

Đối với các ngôn ngữ như Java và SML, việc truyền theo giá trị rất đơn giản (và không có thông qua tham chiếu), giống như sao chép một giá trị biến, vì tất cả các biến chỉ là vô hướng và có bản sao ngữ nghĩa: chúng là những gì được coi là số học gõ vào C ++ hoặc "tài liệu tham khảo" (con trỏ với tên và cú pháp khác nhau).

Trong C, chúng ta có các kiểu vô hướng và người dùng xác định:

• Vô hướng có một giá trị số hoặc trừu tượng (con trỏ không phải là số, chúng có giá trị trừu tượng) được sao chép.
• Các loại tổng hợp có tất cả các thành viên có thể khởi tạo được sao chép:
  • đối với các loại sản phẩm (mảng và cấu trúc): theo cách đệ quy, tất cả các thành viên của cấu trúc và thành phần của mảng được sao chép (cú pháp hàm C không thể truyền trực tiếp mảng theo giá trị, chỉ mảng thành viên của cấu trúc, nhưng đó là chi tiết ).
  • đối với các loại tổng (công đoàn): giá trị của "thành viên tích cực" được giữ nguyên; rõ ràng, thành viên của bản sao thành viên không theo thứ tự vì không phải tất cả các thành viên có thể được khởi tạo.

Trong C ++, các kiểu do người dùng xác định có thể có ngữ nghĩa sao chép do người dùng xác định, cho phép lập trình thực sự "hướng đối tượng" với các đối tượng có quyền sở hữu tài nguyên của họ và các hoạt động "sao chép sâu". Trong trường hợp như vậy, một hoạt động sao chép thực sự là một cuộc gọi đến một chức năng gần như có thể thực hiện các hoạt động tùy ý.

Đối với các cấu trúc C được biên dịch là C ++, "sao chép" vẫn được định nghĩa là gọi hoạt động sao chép do người dùng định nghĩa (hàm tạo hoặc toán tử gán), được trình biên dịch ngầm tạo. Điều đó có nghĩa là ngữ nghĩa của chương trình tập hợp con chung C / C ++ khác nhau ở C và C ++: trong C, toàn bộ loại tổng hợp được sao chép, trong C ++, một hàm sao chép được tạo ngầm được gọi để sao chép từng thành viên; kết quả cuối cùng là trong cả hai trường hợp, mỗi thành viên được sao chép.

(Tôi nghĩ có một ngoại lệ, khi một cấu trúc bên trong một liên minh được sao chép.)

Vì vậy, đối với một loại lớp, cách duy nhất (bên ngoài các bản sao hợp nhất) để tạo một thể hiện mới là thông qua một hàm tạo (ngay cả đối với những người có trình biên dịch tạo trình biên dịch tầm thường).

Bạn không thể lấy địa chỉ của một giá trị thông qua toán tử đơn nguyên &nhưng điều đó không có nghĩa là không có đối tượng giá trị; và một đối tượng, theo định nghĩa, có một địa chỉ ; và địa chỉ đó thậm chí được biểu thị bằng một cấu trúc cú pháp: một đối tượng của kiểu lớp chỉ có thể được tạo bởi một hàm tạo và nó có một thiscon trỏ; nhưng đối với các loại tầm thường, không có hàm tạo bằng văn bản người dùng nên không có chỗ để đặt thischo đến sau khi bản sao được tạo và đặt tên.

Đối với kiểu vô hướng, giá trị của một đối tượng là giá trị của đối tượng, giá trị toán học thuần túy được lưu trữ vào đối tượng.

Đối với một loại lớp, khái niệm duy nhất về giá trị của đối tượng là một bản sao khác của đối tượng, chỉ có thể được tạo bởi một hàm tạo sao chép, một hàm thực (mặc dù đối với các loại tầm thường có chức năng rất đặc biệt, đôi khi chúng có thể là được tạo mà không gọi hàm tạo). Điều đó có nghĩa là giá trị của đối tượng là kết quả của sự thay đổi trạng thái chương trình toàn cầu bằng cách thực thi . Nó không truy cập toán học.

Vì vậy, vượt qua giá trị thực sự không phải là một điều: nó vượt qua cuộc gọi của nhà xây dựng sao chép , điều này ít đẹp hơn. Hàm tạo sao chép dự kiến ​​sẽ thực hiện thao tác "sao chép" hợp lý theo ngữ nghĩa thích hợp của loại đối tượng, tôn trọng các bất biến bên trong của nó (là các thuộc tính người dùng trừu tượng, không phải thuộc tính C ++ nội tại).

Truyền theo giá trị của một đối tượng lớp có nghĩa là:

• tạo một ví dụ khác
• sau đó làm cho hàm được gọi hành động trong trường hợp đó.

Lưu ý rằng vấn đề không liên quan đến việc bản sao có phải là một đối tượng có địa chỉ hay không: tất cả các tham số chức năng là đối tượng và có địa chỉ (ở cấp ngữ nghĩa ngôn ngữ).

Vấn đề là liệu:

• bản sao là một đối tượng mới được khởi tạo với giá trị toán học thuần túy (giá trị thuần thực) của đối tượng ban đầu, như với vô hướng;
• hoặc bản sao là giá trị của đối tượng gốc , như với các lớp.

Trong trường hợp của loại lớp tầm thường, bạn vẫn có thể xác định thành viên của bản sao thành viên của bản gốc, do đó bạn có thể xác định giá trị thuần của bản gốc vì tính tầm thường của các hoạt động sao chép (hàm tạo sao chép và gán). Không phải như vậy với các chức năng người dùng đặc biệt tùy ý: một giá trị của bản gốc phải là một bản sao được xây dựng.

Các đối tượng lớp phải được xây dựng bởi người gọi; một hàm tạo chính thức có một thiscon trỏ nhưng chủ nghĩa hình thức không liên quan ở đây: tất cả các đối tượng chính thức có một địa chỉ nhưng chỉ những đối tượng thực sự sử dụng địa chỉ của chúng theo cách không thuần túy cục bộ (không giống như *&i = 1;sử dụng địa chỉ thuần túy địa phương) cần phải được xác định rõ Địa chỉ.

Một đối tượng phải hoàn toàn bằng cách chuyển qua địa chỉ nếu nó phải xuất hiện một địa chỉ trong cả hai hàm được biên dịch riêng biệt này:

void callee(int &i) {
  something(&i);
}

void caller() {
  int i;
  callee(i);
  something(&i);
}

Ở đây ngay cả khi something(address)là một hàm thuần túy hoặc macro hoặc bất cứ thứ gì (như printf("%p",arg)) không thể lưu trữ địa chỉ hoặc liên lạc với thực thể khác, chúng tôi có yêu cầu chuyển qua địa chỉ vì địa chỉ phải được xác định rõ cho một đối tượng duy nhất intcó duy nhất danh tính.

Chúng tôi không biết nếu một chức năng bên ngoài sẽ "thuần túy" về mặt địa chỉ được truyền cho nó.

Ở đây, tiềm năng sử dụng thực sự của địa chỉ trong một hàm tạo không phải là tầm thường hoặc hàm hủy ở phía người gọi có lẽ là lý do để lấy tuyến đường an toàn, đơn giản và cung cấp cho đối tượng một danh tính trong người gọi và chuyển địa chỉ của nó, vì nó tạo ra chắc chắn rằng bất kỳ việc sử dụng không tầm thường của địa chỉ của nó trong hàm tạo, sau khi xây dựng và trong hàm hủy là nhất quán : thisphải xuất hiện giống nhau trên sự tồn tại của đối tượng.

Một hàm tạo hoặc hàm hủy không tầm thường như bất kỳ hàm nào khác có thể sử dụng thiscon trỏ theo cách đòi hỏi tính nhất quán đối với giá trị của nó mặc dù một số đối tượng có nội dung không tầm thường có thể không:

struct file_handler { // don't use that class!
    file_handler () { this->fileno = -1; }
    file_handler (int f) { this->fileno = f; }
    file_handler (const file_handler& rhs) {
        if (this->fileno != -1)
            this->fileno = dup(rhs.fileno);
        else
            this->fileno = -1;
    }
    ~file_handler () {
        if (this->fileno != -1)
            close(this->fileno); 
    }
    file_handler &operator= (const file_handler& rhs);
};

Lưu ý rằng trong trường hợp đó, mặc dù sử dụng rõ ràng một con trỏ (cú pháp rõ ràng this->), danh tính đối tượng là không liên quan: trình biên dịch cũng có thể sử dụng sao chép từng bit đối tượng xung quanh để di chuyển nó và thực hiện "sao chép elision". Điều này dựa trên mức độ "tinh khiết" của việc sử dụng các thischức năng thành viên đặc biệt (địa chỉ không thoát).

Nhưng độ tinh khiết không phải là một thuộc tính có sẵn ở cấp khai báo tiêu chuẩn (phần mở rộng trình biên dịch tồn tại thêm mô tả độ tinh khiết vào khai báo hàm không nội tuyến), vì vậy bạn không thể xác định ABI dựa trên độ tinh khiết của mã có thể không có (mã có thể hoặc có thể không phải là nội tuyến và có sẵn để phân tích).

Độ tinh khiết được đo là "chắc chắn tinh khiết" hoặc "không tinh khiết hoặc không rõ". Điểm chung, hoặc giới hạn trên của ngữ nghĩa (thực tế tối đa), hoặc LCM (Least Common bội) là "không xác định". Vì vậy, ABI giải quyết trên chưa biết.

Tóm lược:

• Một số cấu trúc yêu cầu trình biên dịch xác định danh tính đối tượng.
• ABI được định nghĩa theo thuật ngữ của các lớp chương trình và không phải là trường hợp cụ thể có thể được tối ưu hóa.

Công việc có thể trong tương lai:

Chú thích độ tinh khiết có đủ hữu ích để được khái quát hóa và tiêu chuẩn hóa không?