Làm thế nào tôi có thể nhận được địa chỉ của một đối tượng một cách đáng tin cậy khi toán tử & bị quá tải?

Hãy xem xét chương trình sau:

struct ghost
{
    // ghosts like to pretend that they don't exist
    ghost* operator&() const volatile { return 0; }
};

int main()
{
    ghost clyde;
    ghost* clydes_address = &clyde; // darn; that's not clyde's address :'( 
}

Làm thế nào để tôi có được clydeđịa chỉ?

Tôi đang tìm kiếm một giải pháp sẽ hoạt động tốt như nhau cho tất cả các loại đối tượng. Một giải pháp C ++ 03 sẽ rất tuyệt, nhưng tôi cũng quan tâm đến các giải pháp C ++ 11. Nếu có thể, hãy tránh mọi hành vi cụ thể thực hiện.

Tôi biết std::addressofmẫu khuôn hàm của C ++ 11 , nhưng không quan tâm đến việc sử dụng nó ở đây: Tôi muốn hiểu cách người triển khai Thư viện Chuẩn có thể triển khai mẫu hàm này.

Cập nhật: trong C ++ 11, người ta có thể sử dụng std::addressofthay vì boost::addressof.

Trước tiên chúng ta hãy sao chép mã từ Boost, trừ đi trình biên dịch hoạt động xung quanh các bit:

template<class T>
struct addr_impl_ref
{
  T & v_;

  inline addr_impl_ref( T & v ): v_( v ) {}
  inline operator T& () const { return v_; }

private:
  addr_impl_ref & operator=(const addr_impl_ref &);
};

template<class T>
struct addressof_impl
{
  static inline T * f( T & v, long ) {
    return reinterpret_cast<T*>(
        &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
  }

  static inline T * f( T * v, int ) { return v; }
};

template<class T>
T * addressof( T & v ) {
  return addressof_impl<T>::f( addr_impl_ref<T>( v ), 0 );
}

Điều gì xảy ra nếu chúng ta vượt qua một tham chiếu đến chức năng ?

Lưu ý: addressofkhông thể được sử dụng với một con trỏ để hoạt động

Trong C ++ nếu void func();được khai báo, thì functham chiếu đến một hàm không có đối số và không trả về kết quả. Tham chiếu này đến một chức năng có thể được chuyển đổi một cách tầm thường thành một con trỏ thành chức năng - từ @Konstantin: Theo 13.3.3.2 cả hai T &và T *không thể phân biệt cho các chức năng. Cái đầu tiên là một chuyển đổi Nhận dạng và cái thứ hai là chuyển đổi Hàm-Con trỏ cả hai đều có thứ hạng "Kết hợp chính xác" (13.3.3.1.1 bảng 9).

Các tham chiếu đến chức năng đi qua addr_impl_ref, có một sự nhập nhằng trong việc giải quyết tình trạng quá tải cho các lựa chọn f, được giải quyết nhờ vào lập luận giả 0, mà là một intđầu tiên và có thể được đề bạt lên một long(chuyển đổi Integral).

Vì vậy, chúng tôi chỉ đơn giản trả về con trỏ.

Điều gì xảy ra nếu chúng ta vượt qua một loại với toán tử chuyển đổi?

Nếu toán tử chuyển đổi mang lại một giá trị T*thì chúng ta có một sự mơ hồ: đối với f(T&,long)Khuyến mãi tích hợp là bắt buộc đối với đối số thứ hai trong khi đối f(T*,int)với toán tử chuyển đổi được gọi vào lần đầu tiên (nhờ @litb)

Đó là khi addr_impl_refbắt đầu. Tiêu chuẩn C ++ bắt buộc một chuỗi chuyển đổi có thể chứa tối đa một chuyển đổi do người dùng xác định. Bằng cách gói loại addr_impl_refvà buộc sử dụng trình tự chuyển đổi, chúng tôi "vô hiệu hóa" bất kỳ toán tử chuyển đổi nào mà loại đi kèm.

Do đó, f(T&,long)quá tải được chọn (và Khuyến mãi tích hợp được thực hiện).

Điều gì xảy ra cho bất kỳ loại khác?

Do đó, f(T&,long)quá tải được chọn, vì có loại không khớp với T*tham số.

Lưu ý: từ các nhận xét trong tệp liên quan đến khả năng tương thích Borland, các mảng không phân rã thành các con trỏ, nhưng được chuyển qua tham chiếu.

Điều gì xảy ra trong tình trạng quá tải này?

Chúng tôi muốn tránh áp dụng operator&cho các loại, vì nó có thể đã bị quá tải.

Tiêu chuẩn đảm bảo reinterpret_castcó thể được sử dụng cho công việc này (xem câu trả lời của @Matteo Italia: 5.2.10 / 10).

Boost thêm một số niceties với constvà volatilevòng loại để tránh cảnh báo trình biên dịch (và sử dụng đúng cách const_castđể loại bỏ chúng).

• Truyền T&tớichar const volatile&
• Tách constvàvolatile
• Áp dụng &toán tử để lấy địa chỉ
• Quay trở lại một T*

Các const/ volatiletung hứng là một chút ma thuật đen, nhưng nó đơn giản hóa công việc (hơn là cung cấp 4 quá tải). Lưu ý rằng kể từ khi Tlà không đủ tiêu chuẩn, nếu chúng ta vượt qua một ghost const&, sau đó T*là ghost const*, do đó vòng loại đã không thực sự bị mất.

EDIT: quá tải con trỏ được sử dụng cho con trỏ đến các chức năng, tôi đã sửa đổi phần giải thích ở trên. Tôi vẫn không hiểu tại sao nó lại cần thiết .

Đầu ra ideone sau đây tổng hợp điều này, phần nào.

Sử dụng std::addressof.

Bạn có thể nghĩ về nó như làm những điều sau hậu trường:

1. Giải thích lại đối tượng như một tài liệu tham khảo
2. Lấy địa chỉ đó (sẽ không gọi quá tải)
3. Truyền con trỏ trở lại một con trỏ của loại của bạn.

Các triển khai hiện có (bao gồm Boost.Addressof) thực hiện chính xác điều đó, chỉ cần chăm sóc thêm constvà volatileđủ điều kiện.

Thủ thuật đằng sau boost::addressofvà việc thực hiện được cung cấp bởi @Luc Danton dựa vào sự kỳ diệu của reinterpret_cast; tiêu chuẩn nêu rõ tại §5.2.10 10

Một biểu thức giá trị của kiểu T1có thể được chuyển thành kiểu tham chiếu kiểu thành hình chữ nhật T2nếu một biểu thức của kiểu con trỏ kiểu thành thành con trỏ T1có thể được chuyển đổi rõ ràng thành kiểu con trỏ kiểu hình thành con trỏ T2bằng cách sử dụng a reinterpret_cast. Đó là, một tham chiếu cast reinterpret_cast<T&>(x)có tác dụng tương tự như chuyển đổi *reinterpret_cast<T*>(&x)với các toán tử tích hợp &và *toán tử. Kết quả là một giá trị tham chiếu đến cùng một đối tượng như giá trị nguồn, nhưng với một loại khác.

Bây giờ, điều này cho phép chúng ta chuyển đổi một tham chiếu đối tượng tùy ý thành một char &(với trình độ cv nếu tham chiếu đủ điều kiện cv), bởi vì bất kỳ con trỏ nào cũng có thể được chuyển đổi thành (có thể đủ điều kiện cv) char *. Bây giờ chúng ta có một char &, toán tử quá tải trên đối tượng không còn phù hợp nữa và chúng ta có thể lấy địa chỉ với &toán tử dựng sẵn .

Việc triển khai tăng cường thêm một vài bước để làm việc với các đối tượng đủ điều kiện cv: bước đầu tiên reinterpret_castđược thực hiện const volatile char &, nếu không, một char &diễn viên đơn giản sẽ không hoạt động constvà / hoặc volatiletham chiếu ( reinterpret_castkhông thể xóa const). Sau đó, constvà volatileđược xóa cùng với const_cast, địa chỉ được lấy &và cuối cùng reinterpet_castlà loại "chính xác" được thực hiện.

Điều const_castcần thiết là loại bỏ const/ volatilecó thể đã được thêm vào các tham chiếu không phải là hằng số / dễ bay hơi, nhưng nó không "làm hại" những gì const/ volatiletham chiếu ở vị trí đầu tiên, bởi vì trận chung kết reinterpret_castsẽ bổ sung lại tiêu chuẩn cv nếu nó là ở nơi đầu tiên ( reinterpret_castkhông thể loại bỏ constnhưng có thể thêm nó).

Đối với phần còn lại của mã trong addressof.hpp, có vẻ như hầu hết là dành cho cách giải quyết. Các static inline T * f( T * v, int )dường như là cần thiết chỉ dành cho các trình biên dịch Borland, nhưng sự hiện diện của nó giới thiệu sự cần thiết addr_impl_ref, nếu không loại con trỏ sẽ được đánh bắt bởi tình trạng quá tải thứ hai này.

Chỉnh sửa : các tình trạng quá tải khác nhau có chức năng khác nhau, xem @Matthieu M. câu trả lời tuyệt vời .

Chà, tôi cũng không còn chắc về điều này nữa; Tôi nên điều tra thêm về mã đó, nhưng bây giờ tôi đang nấu bữa tối :), tôi sẽ xem xét nó sau.

Tôi đã thấy một triển khai thực hiện addressofđiều này:

char* start = &reinterpret_cast<char&>(clyde);
ghost* pointer_to_clyde = reinterpret_cast<ghost*>(start);

Đừng hỏi tôi làm thế nào để tuân thủ điều này!

Hãy xem boost :: addressof và cách thực hiện.