Kapan Anda menggunakan kata kunci "ini"? [Tutup]


249

Saya ingin tahu tentang bagaimana orang lain menggunakan kata kunci ini . Saya cenderung menggunakannya dalam konstruktor, tetapi saya juga dapat menggunakannya di seluruh kelas dalam metode lain. Beberapa contoh:

Dalam konstruktor:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

Di tempat lain

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

2
Saya menemukan contoh yang baik ketika Anda benar-benar membutuhkan this MSDN. Silakan ikuti tautan ini ... ;-)
Matt

12
Jika Anda harus memahami dan mengoptimalkan atau menulis ulang orang lain, sebagian besar kode yang ditulis dengan buruk Anda akan senang memiliki thisatau kualifikasi lainnya sehingga dari tampilan sederhana Anda tahu ruang lingkup variabel (Terutama kualifikasi kelas yang dihapus untuk konstanta (paket yang sama atau hierarki) atau super/ basekualifikasi). Dan menggunakan sintaks yang biasa digunakan _foosepertinya tidak elegan untuk saya sendiri. Menekan _intellisense lebih memakan waktu daripada masuk this. Dan mengapa repot-repot sama sekali! Dengan fungsi pemformatan eclipse auto-save tidak perlu _jika Anda lupa kualifikasi.
djmj

Setelah membaca jawaban dan komentar di bawah ini, serta membaca dokumentasi MSDN: docs.microsoft.com/en-us/previous-versions/visualstudio/… pada kata kunci ini yang belum diperbarui dalam 6 tahun, saya akan menyarankan untuk tidak pernah menggunakan kata kunci ini . Tidak ada gunanya. Jangan membuat parameter dengan nama yang sama, itu membingungkan dan bodoh. Kenapa kamu ingin melakukan itu? Juga, jangan melewatkan contoh dalam menggunakan ini , itu juga membingungkan dan bodoh.
Yusha

Jawaban:


218

Ada beberapa penggunaan kata kunci ini di C #.

  1. Untuk memenuhi syarat anggota yang disembunyikan dengan nama yang mirip
  2. Untuk memiliki objek lulus sendiri sebagai parameter ke metode lain
  3. Untuk memiliki objek mengembalikan dirinya dari suatu metode
  4. Untuk mendeklarasikan pengindeks
  5. Untuk mendeklarasikan metode ekstensi
  6. Untuk melewatkan parameter antara konstruktor
  7. Untuk menetapkan kembali nilai jenis (struct) nilai secara internal .
  8. Untuk memanggil metode ekstensi pada instance saat ini
  9. Untuk melemparkan sendiri ke tipe lain
  10. Untuk rantai konstruktor didefinisikan di kelas yang sama

Anda dapat menghindari penggunaan pertama dengan tidak memiliki variabel anggota dan lokal dengan nama yang sama dalam cakupan, misalnya dengan mengikuti konvensi penamaan umum dan menggunakan properti (case Pascal) alih-alih bidang (case unta) untuk menghindari bertabrakan dengan variabel lokal (juga unta kasus). Dalam C # 3.0 bidang dapat dikonversi ke properti dengan mudah dengan menggunakan properti yang diimplementasikan otomatis .


49
8. Untuk memanggil metode ekstensi pada instance saat ini ( this.Foo();akan bekerja, tetapi Foo()tidak akan)
Marc Gravell

4
Juga untuk melemparkan dirinya sendiri ke tipe lain, misalnya metode yang diterapkan secara eksplisit akan dipanggil seperti ((ICollection<T>)this).Add(bla).
nawfal

4
Untuk rantai konstruksi ke konstruktor lain yang didefinisikan dalam tipe yang sama. public ClassName(...) : this(...).
Lasse V. Karlsen

1
@ Dan itu tidak akan memengaruhi kinerja pada saat dijalankan. Dengan asumsi tidak ada ambiguitas, output kompiler adalah sama terlepas dari apakah Anda menulis, misalnya this.someField = someValueatau someField = someValue. Ini bisa memengaruhi kinerja kompiler, karena kompiler akan mem-parsing kode sumber secara berbeda, tetapi perbedaan pasti akan diabaikan.
phoog

7
Anda dapat menghindari masalah pertama dengan mengakses bidang melalui properti hanya jika Anda mematuhi konvensi gaya di mana properti tidak dapat memiliki nama yang sama dengan parameter. Kebetulan konvensi gaya C # yang lazim memenuhi persyaratan itu. Namun, tidak semua C # ditulis di bawah konvensi itu. Tidak ada yang melekat pada properti per se yang akan membuat thiskata kunci tidak perlu; parameter konstruktor yang dipanggil xakan menyembunyikan anggota yang disebut xapakah anggota itu bidang, properti, atau peristiwa, dalam hal ini.
phoog

246

Saya tidak bermaksud ini terdengar aneh, tapi itu tidak masalah.

Serius.

Lihatlah hal-hal yang penting: proyek Anda, kode Anda, pekerjaan Anda, kehidupan pribadi Anda. Tak satu pun dari mereka akan memiliki kesuksesan mereka bergantung pada apakah Anda menggunakan kata kunci "ini" atau tidak untuk memenuhi syarat akses ke bidang. Kata kunci ini tidak akan membantu Anda mengirim tepat waktu. Itu tidak akan mengurangi bug, itu tidak akan memiliki efek yang berarti pada kualitas kode atau pemeliharaan. Itu tidak akan membuat Anda mendapatkan kenaikan gaji, atau memungkinkan Anda untuk menghabiskan lebih sedikit waktu di kantor.

Ini benar-benar hanya masalah gaya. Jika Anda suka "ini", maka gunakan. Jika tidak, maka jangan. Jika Anda membutuhkannya untuk mendapatkan semantik yang benar maka gunakanlah. Yang benar adalah, setiap programmer memiliki gaya pemrograman yang unik. Gaya itu mencerminkan gagasan programmer tertentu tentang seperti apa "kode yang paling menyenangkan secara estetika" seharusnya. Menurut definisi, setiap programmer lain yang membaca kode Anda akan memiliki gaya pemrograman yang berbeda. Itu berarti akan selalu ada sesuatu yang Anda lakukan yang tidak disukai orang lain, atau akan dilakukan secara berbeda. Pada titik tertentu seseorang akan membaca kode Anda dan menggerutu tentang sesuatu.

Saya tidak akan khawatir. Saya hanya akan memastikan kodenya senyaman mungkin sesuai dengan selera Anda. Jika Anda bertanya kepada 10 programmer bagaimana memformat kode, Anda akan mendapatkan sekitar 15 pendapat berbeda. Hal yang lebih baik untuk difokuskan adalah bagaimana kode diperhitungkan. Apakah hal-hal itu disarikan dengan benar? Apakah saya memilih nama yang bermakna untuk sesuatu? Apakah ada banyak duplikasi kode? Apakah ada cara saya bisa menyederhanakan hal-hal? Saya rasa, melakukan hal-hal itu akan memiliki dampak positif terbesar pada proyek Anda, kode Anda, pekerjaan Anda, dan kehidupan Anda. Secara kebetulan, itu mungkin juga akan menyebabkan orang lain menggerutu sedikit. Jika kode Anda berfungsi, mudah dibaca, dan difaktorkan dengan baik, orang lain tidak akan meneliti bagaimana Anda menginisialisasi bidang. Dia hanya akan menggunakan kode Anda, takjub akan kebesaran itu,


35
Kata thiskunci bermakna secara semantik. Lihat komentar @ JasonBunting di bawah ini. Anda mengacaukan penggunaan gaya yang berlebihan thisdengan tujuan sebenarnya. Komentar Anda bukan hanya sembrono, itu salah!
Dan Barowy

12
Jika Anda mendapat kesempatan, Anda mungkin ingin membaca kembali jawaban saya. Saya berbicara tentang menggunakannya dalam kasus-kasus di mana perlu untuk semantik yang benar. Anda mungkin juga ingin melihat pertanyaan asal. Ini menunjukkan penggunaan dalam contoh di mana tidak semantik diperlukan. Jadi, saya tidak yakin apa yang saya katakan itu "salah". Jawaban saya tentu tidak sembrono.
Scott Wisniewski

9
Apakah Anda tahu bagaimana jawaban Anda bagi saya? Yang tersirat saya baca, "Bagaimana Anda berani mengajukan pertanyaan seperti ini?" - Itu benar-benar tidak konstruktif menurut saya. Tidak ada yang tahu segalanya - inilah sebabnya kami memiliki Stackoverflow: Untuk membantu orang lain dan mendapatkan bantuan. Beberapa topik Anda tahu, ada yang tahu yang lain. Saling membantu, jangan bertengkar satu sama lain. Tolong dipikirkan.
Matt

9
Saya tidak bermaksud terdengar gila, tetapi ini adalah salah satu jawaban terburuk sejauh ini. Saya tidak melihat bagaimana membandingkan ini dengan pekerjaan atau kehidupan pribadi Anda bermanfaat. Hanya karena beberapa hal kurang penting daripada yang lain tidak berarti bahwa mereka tidak penting . Memiliki gaya pemrograman yang konsisten bukanlah hal yang tidak penting (baca buku tentang keterbacaan kode / pemeliharaan pilihan Anda).
aioobe

4
Saya pikir Anda mungkin salah mengerti maksud saya. Bukannya "memiliki gaya yang konsisten" itu buruk. Saya tidak mengatakan apa-apa tentang efek itu. Itu adalah pertanyaan op "haruskah panduan gaya saya mengamanatkan 'ini.' sebagai awalan untuk semua akses bidang? " sewenang-wenang dan berubah-ubah.
Scott Wisniewski

96

Saya hanya menggunakannya ketika benar-benar diperlukan, yaitu, ketika variabel lain membayangi yang lain. Seperti di sini:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Atau seperti yang ditunjukkan oleh Ryan Fox, ketika Anda perlu memberikan ini sebagai parameter. (Variabel lokal memiliki prioritas di atas variabel anggota)


6
Dalam hal ini mengapa tidak hanya memberikan nama yang berbeda untuk variabel input konstruktor?
wz366

54

Secara pribadi, saya mencoba untuk selalu menggunakan ini ketika merujuk ke variabel anggota. Ini membantu memperjelas kode dan membuatnya lebih mudah dibaca. Bahkan jika tidak ada ambiguitas, seseorang membaca kode saya untuk pertama kalinya tidak tahu itu, tetapi jika mereka melihat ini digunakan secara konsisten, mereka akan tahu apakah mereka sedang melihat variabel anggota atau tidak.


9
tetapi jika Anda lupa menggunakannya kapan-kapan, mereka akan menjadi bingung
berselancar

2
@surfen yang dapat dihindari dengan pemeriksaan gaya tambahan, misalnya di Jawa Anda dapat menggunakan Checkstyle dan menjalankannya setelah membangun penuh (dan dalam bahasa iteratif / OO populer akan ada alat serupa)
Maarten Bodewes

5
@Surfen seolah-olah Anda lupa dalam kasus-kasus yang ambigu. Saya dapat mematahkan argumen apa pun dengan mengatakan "tetapi jika Anda lupa ...".
Askolein

6
Kebanyakan orang sepertinya tidak pernah membaca, mengoptimalkan, atau menulis ulang kode orang lain! Kualifikasi adalah penghemat waktu dan motivasi! Tanpa kualifikasi sihirnya seperti jika Anda melihat garis kode sewenang-wenang. Jadi Anda membuang-buang waktu hanya checkin dari mana variabel-variabel ini berasal.
djmj

3
Saya tahu ini adalah posting yang sangat lama, tetapi tidak bisa membantu tetapi mengomentari ironi dari jawaban ini (yang kebetulan saya setujui). Dalam Jihad melawan Notasi Hungaria yang jahat, siapa pun yang berani memberi awalan variabel anggota mereka dengan "m_" dengan cepat dicuri karena variabel anggota yang berbeda tidak berguna atau diperlukan.
Michael J.

38

Saya menggunakannya setiap kali saya merujuk ke variabel instan, bahkan jika saya tidak perlu. Saya pikir itu membuat kode lebih jelas.


Saya ingin membedakan variabel kelas sebanyak yang saya bisa, jadi kode lebih jelas. Saya biasa menggunakan awalan m_ (variabel anggota) misalnya private string m_name. Sekarang saya hanya menggunakan ini misalnya jika saya memiliki Test kelas {private string a; public someMethod () {this.a = "foo"; }}
broadband

36

Saya tidak percaya semua orang yang mengatakan menggunakannya selalu adalah "praktik terbaik" dan semacamnya.

Gunakan "ini" ketika ada ambiguitas, seperti dalam contoh Corey atau ketika Anda harus melewatkan objek sebagai parameter, seperti dalam contoh Ryan . Tidak ada alasan untuk menggunakannya sebaliknya karena dapat menyelesaikan variabel berdasarkan rantai lingkup harus cukup jelas sehingga variabel yang memenuhi syarat dengannya tidak perlu.

EDIT: Dokumentasi C # tentang "ini" menunjukkan satu penggunaan lagi, selain dua yang saya sebutkan, untuk kata kunci "ini" - untuk mendeklarasikan pengindeks

EDIT: @Juan: Huh, saya tidak melihat adanya ketidakkonsistenan dalam pernyataan saya - ada 3 contoh ketika saya akan menggunakan kata kunci "ini" (seperti yang didokumentasikan dalam dokumentasi C #), dan itu adalah saat ketika Anda benar - benar membutuhkannya . Menempel "ini" di depan variabel dalam konstruktor ketika tidak ada bayangan yang terjadi hanyalah buang-buang tombol dan buang waktu saya ketika membacanya, itu tidak memberikan manfaat.


21
@ JasonBunting : Anda tidak dapat melakukan sesuatu kadang-kadang dan tidak beberapa orang lain ... itu membingungkan ... Saya harap saya tidak pernah bekerja di Anda kode Anda tidak dapat selalu berasumsi bahwa orang yang membaca kode Anda di masa depan akan mengerti apa yang Anda menulis, Anda harus sejelas mungkin, dan salah satu cara untuk mencapainya adalah konsisten
juan

@ juan, 10 tahun kemudian. Anda masih berpikir menggunakan "ini" adalah praktik yang baik? :)
Scott Adams

2
@ScottAdams Saya masih percaya pada konsistensi dan kejelasan, ya
juan

Bagaimana dengan menentukan ruang lingkup suatu variabel (apakah itu variabel lokal atau variabel anggota) hanya dengan melihatnya? Bukankah 'ini' dibenarkan untuk tujuan ini? Atau Anda bermaksud mengatakan bahwa jika kita menulis metode yang lebih kecil itu akan cukup mudah untuk memahami ruang lingkup variabel?
BornToCode

27

Saya menggunakannya kapan pun StyleCop menyuruh saya. StyleCop harus ditaati. Oh ya.


1
Dan ReSharper memberitahuku untuk tidak menggunakannya. Agak membingungkan ketika saya menggunakan kedua StyleCop dan ReSharper pada saat yang sama :) Tapi saya condong ke Coreys jawaban di atas, untuk menggunakan kata kunci 'ini' hanya ketika benar-benar diperlukan.
Gunnar

@ Gunnar, ada opsi untuk menonaktifkan "redundant" yang berlebihan ini. dalam R #
Winger Sendon

@EmperorAiman ​​- Ya, saya tahu. Maksud saya adalah bahwa kedua alat pemformatan populer secara default, menyarankan dua hal yang berbeda dan itu bisa membingungkan. "Menjadi atau tidak menjadi ..." :)
Gunnar

11

Kapan saja Anda membutuhkan referensi ke objek saat ini.

Satu skenario yang sangat berguna adalah ketika objek Anda memanggil suatu fungsi dan ingin memasukkan dirinya ke dalamnya.

Contoh:

void onChange()
{
    screen.draw(this);
}

7

Saya cenderung menggunakannya di mana-mana juga, hanya untuk memastikan bahwa itu adalah jelas bahwa itu adalah anggota contoh yang kita hadapi.


5

Saya menggunakannya di mana saja mungkin ada ambiguitas (jelas). Tidak hanya kompiler ambiguitas (itu akan diperlukan dalam kasus itu), tetapi juga ambiguitas bagi seseorang yang melihat kode.


5

Penggunaan lain yang agak jarang untuk kata kunci ini adalah ketika Anda harus meminta implementasi antarmuka eksplisit dari dalam kelas implementasi. Inilah contoh yang dibuat-buat:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

4

Inilah saat saya menggunakannya:

  • Mengakses Metode Pribadi dari dalam kelas (untuk membedakan)
  • Melewati objek saat ini ke metode lain (atau sebagai objek pengirim, jika terjadi peristiwa)
  • Saat membuat metode ekstensi: D

Saya tidak menggunakan ini untuk bidang pribadi karena saya awali nama variabel bidang pribadi dengan garis bawah (_).


4

[C ++]

Saya setuju dengan brigade "gunakan saat Anda harus". Menghias kode yang tidak perlu dengan ini bukanlah ide yang bagus karena kompiler tidak akan memperingatkan Anda ketika Anda lupa melakukannya. Ini menimbulkan potensi kebingungan bagi orang-orang yang mengharapkan hal ini selalu ada, yaitu mereka harus memikirkannya .

Jadi, kapan Anda akan menggunakannya? Saya baru saja melihat-lihat beberapa kode acak dan menemukan contoh-contoh ini (saya tidak menilai apakah ini hal yang baik untuk dilakukan atau tidak):

  • Melewati "diri sendiri" ke suatu fungsi.
  • Menetapkan "diri sendiri" ke pointer atau sesuatu seperti itu.
  • Casting, yaitu casting atas / bawah (aman atau tidak), mengusir ketegaran, dll.
  • Compiler disambiguasi diberlakukan.

3

Anda harus selalu menggunakannya, saya menggunakannya untuk membedakan bidang dan parameter pribadi (karena konvensi penamaan kami menyatakan bahwa kami tidak menggunakan awalan untuk nama anggota dan parameter (dan mereka didasarkan pada informasi yang ditemukan di internet, jadi saya menganggap bahwa praktek terbaik))


3

Saya menggunakannya ketika, dalam fungsi yang menerima referensi ke objek dengan tipe yang sama, saya ingin membuatnya dengan sangat jelas objek yang saya maksud, di mana.

Sebagai contoh

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(vs)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

Sepintas yang dimaksud AABB right()? The thismenambahkan sedikit clarifier a.


3

Dalam Jakub Šturc menjawab, # 5 tentang meneruskan data antar kontraktor mungkin bisa menggunakan sedikit penjelasan. Ini dalam konstruktor kelebihan beban dan merupakan kasus di mana penggunaan thisadalah wajib. Dalam contoh berikut ini kita dapat memanggil konstruktor parameter dari konstruktor tanpa parameter dengan parameter default.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

Saya menemukan ini sebagai fitur yang sangat berguna pada kesempatan tertentu.


2

Saya terbiasa menggunakannya secara bebas di Visual C ++ karena melakukan hal itu akan memicu IntelliSense saya menekan tombol '>', dan saya malas. (dan rentan terhadap kesalahan ketik)

Tapi saya terus menggunakannya, karena saya merasa berguna untuk melihat bahwa saya memanggil fungsi anggota daripada fungsi global.


1

Saya cenderung menggarisbawahi bidang dengan _ jadi tidak benar-benar perlu menggunakan ini. Lagi pula, R # cenderung untuk menolak mereka ...


1

Saya cukup banyak hanya menggunakan ini ketika referensi jenis properti dari dalam jenis yang sama. Seperti yang disebutkan pengguna lain, saya juga menggarisbawahi bidang lokal sehingga mereka terlihat tanpa perlu ini .


1

Saya menggunakannya hanya bila diperlukan, kecuali untuk operasi simetris yang karena polimorfisme argumen tunggal harus dimasukkan ke dalam metode satu sisi:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

1

[C ++]

ini digunakan dalam operator penugasan di mana sebagian besar waktu Anda harus memeriksa dan mencegah hal-hal aneh (tidak disengaja, berbahaya, atau hanya buang-buang waktu untuk program) seperti:

A a;
a = a;

Operator penugasan Anda akan ditulis:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

1

this pada kompiler C ++

Compiler C ++ akan mencari simbol secara diam-diam jika tidak segera menemukannya. Terkadang, sebagian besar waktu, itu baik:

  • menggunakan metode kelas ibu jika Anda tidak kelebihannya di kelas anak.
  • mempromosikan nilai suatu tipe ke tipe lain

Tetapi kadang-kadang, Anda hanya tidak ingin kompiler menebak. Anda ingin kompiler mengambil simbol yang benar dan bukan yang lain.

Bagi saya , saat-saat itu adalah ketika, dalam suatu metode, saya ingin mengakses metode anggota atau variabel anggota. Aku hanya tidak ingin beberapa simbol acak dijemput hanya karena saya menulis printfbukan print. this->printftidak akan dikompilasi.

Intinya adalah bahwa, dengan C legacy libraries (§), kode legacy ditulis bertahun-tahun yang lalu (§§), atau apa pun yang bisa terjadi dalam bahasa di mana copy / paste adalah fitur usang tetapi masih aktif, kadang-kadang, memberitahu kompiler untuk tidak bermain kecerdasan adalah ide bagus.

Inilah alasan saya menggunakan this.

(§) itu masih semacam misteri bagi saya, tapi sekarang saya bertanya-tanya apakah fakta Anda menyertakan tajuk <windows.h> di sumber Anda, adalah alasan semua simbol perpustakaan C warisan akan mencemari namespace global Anda

(§§) menyadari bahwa "Anda harus menyertakan tajuk, tetapi dengan memasukkan tajuk ini akan merusak kode Anda karena menggunakan beberapa makro bodoh dengan nama generik" adalah salah satu momen roulette Rusia dalam kehidupan seorang pembuat kode.


1

'ini.' membantu menemukan anggota di kelas 'ini' dengan banyak anggota (biasanya karena rantai warisan yang dalam).

Memukul CTRL + Space tidak membantu dengan ini, karena juga termasuk tipe; dimana-seperti 'ini.' termasuk anggota SAJA.

Saya biasanya menghapusnya setelah saya mendapatkan apa yang saya inginkan: tetapi ini hanya gaya saya menerobos.

Dalam hal gaya, jika Anda seorang penjaga sendirian - Anda memutuskan; jika Anda bekerja untuk perusahaan tetap pada kebijakan perusahaan (lihat hal-hal dalam kendali sumber dan lihat apa yang dilakukan orang lain). Dalam hal menggunakannya untuk memenuhi syarat anggota, tidak ada yang benar atau salah. Satu-satunya hal yang salah adalah inkonsistensi - itu adalah aturan gaya emas. Biarkan nit-picking yang lain. Luangkan waktu Anda merenungkan masalah pengkodean nyata - dan jelas pengkodean - sebagai gantinya.


1

Saya menggunakannya setiap kali saya bisa. Saya percaya itu membuat kode lebih mudah dibaca, dan kode lebih mudah dibaca sama dengan lebih sedikit bug dan lebih mudah dirawat.


1

Ketika Anda banyak pengembang yang bekerja pada basis kode yang sama, Anda memerlukan beberapa panduan / aturan kode. Di tempat saya bekerja, kami memutuskan untuk menggunakan 'ini' di bidang, properti, dan acara.

Bagi saya itu masuk akal untuk melakukannya seperti ini, itu membuat kode lebih mudah dibaca ketika Anda membedakan antara variabel kelas dan variabel metode.


0

Tergantung pada standar pengkodean yang sedang saya kerjakan. Jika kita menggunakan _ untuk menunjukkan variabel instan maka "ini" menjadi redundan. Jika kita tidak menggunakan _ maka saya cenderung menggunakan ini untuk menunjukkan variabel instan.


0

Saya menggunakannya untuk memanggil Intellisense seperti JohnMcG , tapi saya akan kembali dan menghapus "ini->" ketika saya selesai. Saya mengikuti konvensi Microsoft tentang awalan variabel anggota dengan "m_", jadi meninggalkannya sebagai dokumentasi hanya akan menjadi berlebihan.


0

1 - idiom penyetel Java umum:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - Saat memanggil fungsi dengan objek ini sebagai parameter

notifier.addListener(this);

0

Ada satu penggunaan yang belum disebutkan dalam C ++, dan itu bukan untuk merujuk ke objek sendiri atau mendisambiguasikan anggota dari variabel yang diterima.

Anda bisa menggunakan thisuntuk mengonversi nama yang tidak tergantung menjadi nama yang bergantung argumen di dalam kelas templat yang mewarisi dari templat lain.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

Template dikompilasi dengan mekanisme dua pass. Selama pass pertama, hanya nama-nama non-argumen yang dependen yang diselesaikan dan diperiksa, sementara nama-nama dependen hanya diperiksa untuk koherensi, tanpa benar-benar menggantikan argumen templat.

Pada langkah itu, tanpa benar-benar mengganti tipe, kompiler hampir tidak memiliki informasi tentang apa yang base<T>bisa (perhatikan bahwa spesialisasi template dasar dapat mengubahnya menjadi tipe yang sama sekali berbeda, bahkan tipe yang tidak terdefinisi), jadi ia hanya berasumsi bahwa itu adalah tipe . Pada tahap ini panggilan non-dependen fyang tampaknya wajar bagi programmer adalah simbol yang harus ditemukan oleh kompiler sebagai anggota derivedatau dalam melampirkan ruang nama - yang tidak terjadi dalam contoh - dan itu akan mengeluh.

Solusinya adalah mengubah nama yang tidak tergantung fmenjadi nama yang tergantung. Hal ini dapat dilakukan dalam beberapa cara, dengan secara eksplisit menyatakan jenis di mana ia diterapkan (- base<T>::fmenambahkan base<T>simbol membuat ketergantungan Tdan kompilator hanya akan menganggap bahwa itu akan ada dan menunda pemeriksaan aktual untuk lintasan kedua, setelah substitusi argumen.

Cara kedua, jauh lebih penyortir jika Anda mewarisi dari template yang memiliki lebih dari satu argumen, atau nama panjang, hanya menambahkan this->sebelum simbol. Sebagai kelas templat yang Anda laksanakan tergantung pada argumen (diturunkan dari base<T>) this->adalah bergantung pada argumen, dan kami mendapatkan hasil yang sama: this->fdicentang di babak kedua, setelah penggantian parameter templat.


-2

Anda tidak boleh menggunakan "ini" kecuali Anda benar-benar harus.

ADA hukuman yang terkait dengan verbositas yang tidak perlu. Anda harus mengusahakan kode yang tepat asalkan diperlukan, dan tidak lagi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.