Mengapa tanda bintang sebelum nama variabel, bukan setelah tipe?


187

Mengapa sebagian besar variabel pemrogram nama C seperti ini:

int *myVariable;

daripada seperti ini:

int* myVariable;

Keduanya valid. Sepertinya saya bahwa tanda bintang adalah bagian dari jenisnya, bukan bagian dari nama variabel. Adakah yang bisa menjelaskan logika ini?


1
Gaya kedua tampaknya lebih intuitif secara umum, tetapi yang pertama adalah cara untuk menghindari jenis bug yang terkait dalam kode. Jika Anda benar-benar terikat dengan gaya yang terakhir, Anda selalu bisa mengikuti typedefs, tetapi itu akan menambah kompleksitas yang tidak perlu, IMHO.
Cloud

Jawaban:


251

Mereka sama persis. Namun, dalam

int *myVariable, myVariable2;

Tampaknya jelas bahwa myVariable memiliki tipe int * , sedangkan myVariable2 memiliki tipe int . Di

int* myVariable, myVariable2;

mungkin tampak jelas bahwa keduanya bertipe int * , tetapi itu tidak benar karena myVariable2memiliki tipe int .

Oleh karena itu, gaya pemrograman pertama lebih intuitif.


135
mungkin tapi saya tidak akan mencampur dan mencocokkan jenis dalam satu deklarasi.
BobbyShaftoe

15
@ BobbyShaftoe Setuju. Bahkan setelah membaca setiap argumen di sini, saya bertahan int* someVaruntuk proyek pribadi. Itu lebih masuk akal.
Alyssa Haroldsen

30
@Kupiakos Itu hanya lebih masuk akal sampai Anda mempelajari sintaks deklarasi C berdasarkan "deklarasi ikuti penggunaan". Deklarasi menggunakan sintaks yang sama persis seperti yang dilakukan oleh variabel yang diketik sama. Ketika Anda mendeklarasikan array int, itu tidak terlihat seperti: int[10] x. Ini bukan sintaks C. Tata bahasanya secara eksplisit diuraikan sebagai:, int (*x)dan bukan sebagai (int *) x, sehingga menempatkan tanda bintang di sebelah kiri hanya menyesatkan dan didasarkan pada kesalahpahaman sintaksis deklarasi C.
Peaker

8
Koreksi: karena itu, Anda tidak boleh mendeklarasikan lebih dari satu variabel pada satu baris. Secara umum, Anda tidak boleh memotivasi gaya pengkodean tertentu berdasarkan pada gaya pengkodean lain yang tidak terkait, buruk, dan berbahaya.
Lundin

6
Inilah sebabnya saya tetap berpegang pada satu variabel per deklarasi pointer. Sama sekali tidak ada kebingungan jika Anda melakukannya int* myVariable; int myVariable2;.
Patrick Roberts

122

Jika Anda melihatnya dengan cara lain, *myVariableadalah tipe int, yang masuk akal.


6
Ini adalah penjelasan favorit saya, dan bekerja dengan baik karena ini menjelaskan quirks deklarasi C secara umum - bahkan sintaks pointer fungsi menjijikkan dan keriput.
Benjamin Pollack

12
Agak rapi, karena Anda bisa membayangkan tidak ada jenis pointer yang sebenarnya. Hanya ada variabel yang, ketika direferensikan atau didereferensi dengan tepat, memberi Anda salah satu tipe primitif.
biozinc

1
Sebenarnya, '* myVariable' mungkin bertipe NULL. Untuk membuat keadaan menjadi lebih buruk itu bisa saja lokasi memori memori acak.
qonf

4
qonf: NULL bukan tipe. myVariablebisa NULL, dalam hal ini *myVariablemenyebabkan kesalahan segmentasi, tetapi tidak ada tipe NULL.
Daniel Roethlisberger

28
Poin ini bisa menyesatkan dalam konteks seperti itu:, int x = 5; int *pointer = &x;karena itu menyarankan kita mengatur int *pointerke beberapa nilai, bukan nilai pointeritu sendiri.
rafalcieslak

40

Karena * pada baris itu mengikat lebih dekat ke variabel daripada ke tipe:

int* varA, varB; // This is misleading

Seperti yang ditunjukkan @Lundin di bawah ini, const menambahkan lebih banyak lagi kehalusan untuk dipikirkan. Anda dapat sepenuhnya menghindarinya dengan mendeklarasikan satu variabel per baris, yang tidak pernah ambigu:

int* varA;
int varB;

Keseimbangan antara kode yang jelas dan kode yang ringkas sulit dipukul - selusin baris yang berlebihan int a;juga tidak bagus. Namun, saya default ke satu deklarasi per baris dan khawatir tentang menggabungkan kode nanti.


2
Nah, contoh pertama yang menyesatkan di mata saya adalah kesalahan desain. Jika saya bisa, saya akan menghapus deklarasi seperti itu dari C seluruhnya, dan membuatnya jadi keduanya bertipe int *.
Adam Bajger

1
"the * mengikat lebih dekat ke variabel daripada ke tipe" Ini adalah argumen yang naif. Pertimbangkan int *const a, b;. Di mana * "mengikat"? Tipe ais int* const, jadi bagaimana Anda bisa mengatakan bahwa * milik variabel ketika itu adalah bagian dari tipe itu sendiri?
Lundin

1
Khusus untuk pertanyaan, atau mencakup semua kasus: pilih satu. Saya akan membuat catatan, tapi ini argumen bagus untuk saran terakhir saya: satu deklarasi per baris mengurangi peluang untuk mengacaukannya.
ojrac

36

Sesuatu yang belum pernah disebutkan di sini sejauh ini adalah tanda bintang ini sebenarnya adalah " operator dereferensi " di C.

*a = 10;

Baris di atas bukan berarti saya ingin menetapkan 10ke a, itu berarti saya ingin menetapkan 10apa pun lokasi memori apoin ke. Dan saya belum pernah melihat orang menulis

* a = 10;

apakah kamu Jadi operator dereference hampir selalu ditulis tanpa spasi. Ini mungkin untuk membedakannya dari perkalian yang terputus di beberapa baris:

x = a * b * c * d
  * e * f * g;

Ini *eakan menyesatkan, bukan?

Oke, sekarang apa arti sebenarnya dari baris berikut:

int *a;

Kebanyakan orang akan mengatakan:

Ini berarti bahwa aadalah penunjuk ke intnilai.

Ini secara teknis benar, kebanyakan orang suka melihat / membacanya seperti itu dan itu adalah cara bagaimana standar C modern akan mendefinisikannya (perhatikan bahwa bahasa C sendiri mendahului semua standar ANSI dan ISO). Tapi itu bukan satu-satunya cara untuk melihatnya. Anda juga dapat membaca baris ini sebagai berikut:

Nilai dereferensi adari tipe int.

Jadi sebenarnya tanda bintang dalam deklarasi ini juga dapat dilihat sebagai operator dereference, yang juga menjelaskan penempatannya. Dan itu aadalah pointer tidak benar-benar dideklarasikan sama sekali, itu tersirat oleh fakta, bahwa satu-satunya hal yang Anda benar-benar dapat dereferensi adalah pointer.

Standar C hanya mendefinisikan dua arti bagi *operator:

  • operator tipuan
  • operator perkalian

Dan tipuan hanya satu makna tunggal, tidak ada makna tambahan untuk mendeklarasikan pointer, hanya ada tipuan, yang dilakukan oleh operasi dereference, ia melakukan akses tidak langsung, demikian juga dalam pernyataan seperti int *a;ini adalah akses tidak langsung ( *berarti akses tidak langsung) dan dengan demikian pernyataan kedua di atas jauh lebih dekat dengan standar daripada yang pertama.


6
Terima kasih telah menyelamatkan saya dari menulis jawaban lain di sini. BTW Saya biasanya membaca int a, *b, (*c)();sebagai sesuatu seperti "menyatakan objek-objek berikut sebagai int: objek a, objek menunjuk ke b, dan objek kembali dari fungsi yang ditunjukkan oleh c".
Antti Haapala

1
The *dalam int *a;tidak operator, dan tidak dereferencing a(yang bahkan tidak didefinisikan belum)
MM

1
@ MM Sebutkan nomor halaman dan baris dari setiap standar ISO C di mana standar ini mengatakan bahwa tanda bintang bisa menjadi sesuatu yang lain daripada perkalian atau tipuan. Ini hanya menunjukkan "deklarasi pointer" dengan contoh, itu tidak mendefinisikan arti ketiga untuk asterisk (dan itu tidak mendefinisikan arti, yang tidak akan menjadi operator). Oh, aku tidak mengklaim apa pun "didefinisikan", kau mengarangnya. Atau seperti yang dikatakan topi Jonathan Leffler, dalam standar C, * selalu "tata bahasa", itu bukan bagian dari penentu-deklarasi yang terdaftar (jadi itu bukan bagian dari deklarasi, sehingga harus menjadi operator)
Mecki

1
@MM 6.7.6.1 hanya menunjukkan deklarasi dengan contoh, persis seperti saya katakan, itu tidak memberikan arti untuk *(itu hanya memberikan makna terhadap total ekspresi, tidak ke *dalam ekspresi!). Dikatakan bahwa "int a;" mendeklarasikan pointer, yang ia lakukan, tidak pernah mengklaim sebaliknya, tetapi tanpa makna yang diberikan *, membacanya sebagai * nilai dereferenced dari aint masih benar-benar valid, karena itu memiliki arti faktual yang sama. Tidak ada, benar-benar tidak ada yang tertulis dalam 6.7.6.1 yang akan bertentangan dengan pernyataan itu.
Mecki

2
Tidak ada "ekspresi total". int *a;adalah deklarasi, bukan ekspresi. atidak direferensikan oleh int *a;. abahkan belum ada pada saat *ini sedang diproses. Apakah Anda menganggapnya int *a = NULL;sebagai bug karena referensi nol?
MM

17

Aku akan pergi mengambil risiko di sini dan mengatakan bahwa ada jawaban langsung untuk pertanyaan ini , baik untuk deklarasi variabel dan untuk parameter dan kembali jenis, yaitu bahwa tanda bintang harus pergi di sebelah nama: int *myVariable;. Untuk menghargai mengapa, lihat bagaimana Anda mendeklarasikan jenis simbol lain di C:

int my_function(int arg); untuk suatu fungsi;

float my_array[3] untuk sebuah array.

Pola umum, yang disebut sebagai deklarasi follow use , adalah bahwa jenis simbol dibagi menjadi bagian sebelum nama, dan bagian-bagian di sekitar nama, dan bagian-bagian ini di sekitar nama meniru sintaks yang akan Anda gunakan untuk mendapatkan nilai jenis di sebelah kiri:

int a_return_value = my_function(729);

float an_element = my_array[2];

dan: int copy_of_value = *myVariable;.

C ++ melempar kunci pas dalam karya dengan referensi, karena sintaks pada titik di mana Anda menggunakan referensi identik dengan jenis nilai, sehingga Anda bisa berpendapat bahwa C ++ mengambil pendekatan yang berbeda untuk C. Di sisi lain, C ++ tetap sama perilaku C dalam kasus pointer, jadi referensi benar-benar berdiri sebagai yang aneh dalam hal ini.


12

Itu hanya masalah preferensi.

Ketika Anda membaca kode, membedakan antara variabel dan pointer lebih mudah dalam kasus kedua, tetapi hal itu dapat menyebabkan kebingungan ketika Anda meletakkan kedua variabel dan pointer dari tipe umum dalam satu baris (yang seringkali tidak disarankan oleh pedoman proyek, karena mengurangi keterbacaan).

Saya lebih suka mendeklarasikan pointer dengan tanda yang sesuai di sebelah ketikkan nama, misalnya

int* pMyPointer;

3
Pertanyaannya adalah tentang C, di mana tidak ada referensi.
Antti Haapala

Terima kasih telah menunjukkan itu, meskipun pertanyaannya bukan tentang petunjuk atau referensi, tetapi tentang pemformatan kode, pada dasarnya.
macbirdie

8

Seorang guru yang hebat pernah berkata, "Baca jalan kompiler, Anda harus."

http://www.drdobbs.com/conversationsa-midsummer-nights-madness/184403835

Memang ini pada topik penempatan const, tetapi aturan yang sama berlaku di sini.

Kompiler membacanya sebagai:

int (*a);

tidak seperti:

(int*) a;

Jika Anda terbiasa menempatkan bintang di sebelah variabel, itu akan membuat deklarasi Anda lebih mudah dibaca. Itu juga menghindari merusak pemandangan seperti:

int* a[10];

- Edit -

Untuk menjelaskan dengan tepat apa yang saya maksud ketika saya mengatakan itu diuraikan sebagai int (*a), itu berarti yang *mengikat lebih erat adaripada yang dilakukannya int, dalam banyak cara yang dalam ekspresi 4 + 3 * 7 3mengikat lebih erat 7daripada yang dilakukannya 4karena prioritas lebih tinggi dari *.

Dengan permintaan maaf untuk seni ascii, sinopsis AST untuk penguraian int *aterlihat kurang lebih seperti ini:

      Declaration
      /         \
     /           \
Declaration-      Init-
Secifiers       Declarator-
    |             List
    |               |
    |              ...
  "int"             |
                Declarator
                /       \
               /        ...
           Pointer        \
              |        Identifier
              |            |
             "*"           |
                          "a"

Seperti yang ditunjukkan dengan jelas, *ikat lebih erat ke asejak leluhur mereka bersama Declarator, sementara Anda harus pergi jauh-jauh ke atas pohon Declarationuntuk menemukan leluhur bersama yang melibatkan int.


Tidak, kompiler paling pasti membaca jenisnya sebagai (int*) a.
Lundin

@Lundin Ini adalah kesalahpahaman besar yang dimiliki sebagian besar programmer C ++ modern. Mengurai deklarasi variabel berjalan seperti ini. Langkah 1. Baca token pertama, yang menjadi "tipe dasar" dari deklarasi. intpada kasus ini. Langkah 2. Baca deklarasi, termasuk dekorasi jenis apa pun. *apada kasus ini. Langkah 3 Baca karakter berikutnya. Jika koma, konsumsilah dan kembali ke langkah 2. Jika titik koma berhenti. Jika ada yang lain melemparkan kesalahan sintaksis. ...
dgnuff

@Lundin ... Jika parser membacanya seperti yang Anda sarankan, maka kita akan bisa menulis int* a, b;dan mendapatkan sepasang petunjuk. Maksud saya membuat adalah bahwa *mengikat ke variabel dan diuraikan dengan itu, bukan dengan tipe untuk membentuk "tipe dasar" dari deklarasi. Itu juga bagian dari alasan bahwa typedef diperkenalkan untuk memungkinkan typedef int *iptr; iptr a, b;membuat beberapa petunjuk. Dengan menggunakan typedef Anda dapat mengikat *ke int.
dgnuff

1
... Tentu saja, kompiler "menggabungkan" jenis dasar dari Declaration-Specifierdengan "dekorasi" di Declaratoruntuk sampai pada jenis akhir untuk setiap variabel. Namun itu tidak "bergerak" dekorasi untuk specifier Deklarasi jika tidak int a[10], b;akan menghasilkan hasil yang benar-benar konyol, itu mem-parsing int *a, b[10];sebagai int *a , b[10] ;. Tidak ada cara lain untuk menggambarkannya yang masuk akal.
dgnuff

1
Ya, bagian penting di sini bukanlah sintaks atau urutan penguraian kompiler, tetapi tipe int*apada akhirnya dibaca oleh kompiler sebagai: " amemiliki tipe int*". Itulah yang saya maksud dengan komentar asli saya.
Lundin

3

Karena itu lebih masuk akal ketika Anda memiliki deklarasi seperti:

int *a, *b;

5
Ini secara harfiah adalah contoh dari mengemis pertanyaan. Tidak, itu tidak masuk akal seperti itu. "int * a, b" bisa membuat keduanya menjadi petunjuk.
MichaelGG

1
@MichaelGG Anda punya ekor yang mengibas-ngibaskan anjing di sana. Tentu K&R bisa menentukan yang int* a, b;membuat bpointer ke int. Tetapi mereka tidak melakukannya. Dan dengan alasan yang bagus. Di bawah sistem yang diusulkan Anda apa jenis bdalam deklarasi berikut: int* a[10], b;?
dgnuff

2

Untuk mendeklarasikan banyak pointer dalam satu baris, saya lebih suka int* a, * b;yang secara lebih intuitif mendeklarasikan "a" sebagai pointer ke integer, dan tidak mencampur gaya ketika juga mendeklarasikan "b." Seperti yang dikatakan seseorang, saya tidak akan mendeklarasikan dua tipe berbeda dalam pernyataan yang sama.


2

Orang yang lebih suka int* x;mencoba memaksakan kode mereka ke dunia fiksi di mana jenisnya ada di sebelah kiri dan pengenal (nama) ada di sebelah kanan.

Saya katakan "fiksi" karena:

Dalam C dan C ++, dalam kasus umum, pengenal yang dideklarasikan dikelilingi oleh informasi tipe.

Itu mungkin terdengar gila, tetapi Anda tahu itu benar. Berikut ini beberapa contohnya:

  • int main(int argc, char *argv[])berarti " mainadalah fungsi yang membawa intdan array pointer ke chardan mengembalikan sebuah int." Dengan kata lain, sebagian besar tipe informasi ada di sebelah kanan. Beberapa orang berpikir deklarasi fungsi tidak masuk hitungan karena itu entah bagaimana "istimewa." OK, mari kita coba variabel.

  • void (*fn)(int)berarti fnadalah penunjuk ke fungsi yang mengambil intdan tidak mengembalikan apa pun.

  • int a[10]mendeklarasikan 'a' sebagai array 10 intdetik.

  • pixel bitmap[height][width].

  • Jelas, saya sudah memilih contoh ceri yang memiliki banyak jenis info di sebelah kanan untuk menyampaikan maksud saya. Ada banyak deklarasi di mana sebagian besar - jika tidak semua - dari jenis di sebelah kiri, seperti struct { int x; int y; } center.

Sintaksis deklarasi ini tumbuh dari keinginan K&R untuk mendeklarasikan penggunaannya. Membaca deklarasi sederhana adalah intuitif, dan membaca yang lebih kompleks dapat dikuasai dengan mempelajari aturan kanan-kiri-kanan (kadang-kadang disebut aturan spiral atau hanya aturan kanan-kiri).

C cukup sederhana sehingga banyak programmer C merangkul gaya ini dan menulis deklarasi sederhana sebagai int *p.

Dalam C ++, sintaks mendapat sedikit lebih kompleks (dengan kelas, referensi, templat, kelas enum), dan, sebagai reaksi terhadap kerumitan itu, Anda akan melihat lebih banyak upaya memisahkan jenis dari pengenal dalam banyak deklarasi. Dengan kata lain, Anda mungkin melihat lebih banyak int* pdeklarasi gaya jika Anda melihat petak besar kode C ++.

Dalam bahasa apa pun, Anda selalu dapat memiliki tipe di sisi kiri deklarasi variabel dengan (1) tidak pernah mendeklarasikan beberapa variabel dalam pernyataan yang sama, dan (2) memanfaatkan typedefs (atau alias deklarasi, yang, ironisnya, menempatkan alias pengidentifikasi di sebelah kiri jenis). Sebagai contoh:

typedef int array_of_10_ints[10];
array_of_10_ints a;

Pertanyaan kecil, mengapa tidak dapat membatalkan (* fn) (int) berarti "fn adalah fungsi yang menerima int, dan mengembalikan (void *)?
Soham Dongargaonkar

1
@ a3y3: Karena tanda kurung (*fn)tetap mempertahankan pointer yang terkait dengan fnbukan tipe kembali.
Adrian McCarthy

Mengerti. Saya pikir ini cukup penting untuk ditambahkan dalam jawaban Anda, saya akan menyarankan edit segera.
Soham Dongargaonkar

1
Saya pikir itu mengacaukan jawabannya tanpa menambahkan banyak nilai. Ini hanyalah sintaks bahasa. Kebanyakan orang bertanya mengapa sintaksis seperti ini mungkin sudah tahu aturannya. Siapa pun yang bingung mengenai hal ini dapat melihat klarifikasi dalam komentar ini.
Adrian McCarthy

1

Saya sudah menjawab pertanyaan serupa di CP, dan, karena tidak ada yang menyebutkan itu, juga di sini saya harus menunjukkan bahwa C adalah bahasa format bebas , gaya apa pun yang Anda pilih ok sementara parser dapat membedakan masing-masing token. Kekhasan ini C menyebabkan jenis yang sangat khusus kontes yang disebut kontes kebingungan C .


1

Banyak argumen dalam topik ini sangat subjektif dan argumen tentang "bintang mengikat nama variabel" adalah naif. Berikut beberapa argumen yang bukan hanya pendapat:


Kualifikasi jenis pointer yang terlupakan

Secara formal, "bintang" tidak termasuk dalam jenis atau nama variabel, itu adalah bagian dari item gramatikal bernama pointer . Sintaks C formal (ISO 9899: 2018) adalah:

(6.7) deklarasi:
deklarasi-penentu init-declarator-list opt ;

Di mana declaration-specifiers berisi tipe (dan penyimpanan), dan init-declarator-list berisi pointer dan nama variabel. Yang kami lihat jika kami membedah sintaksis daftar deklarator ini lebih lanjut:

(6.7.6) deklarator:
pointer opt direct-declarator
...
(6.7.6) pointer:
* type-qualifier-list opt
* tipe-kualifikasi-list opt pointer

Di mana deklarator adalah seluruh deklarasi, deklarator langsung adalah pengenal (nama variabel), dan sebuah pointer adalah bintang yang diikuti oleh daftar kualifikasi jenis opsional yang dimiliki oleh pointer itu sendiri.

Apa yang membuat berbagai argumen gaya tentang "bintang milik variabel" tidak konsisten, adalah bahwa mereka telah melupakan kualifikasi jenis penunjuk ini. int* const x,int *const x atau int*const x?

Pertimbangkan int *const a, b;, apa saja jenis adanb ? Tidak begitu jelas bahwa "bintang milik variabel" lebih lama lagi. Sebaliknya, orang akan mulai merenungkan di mana constmilik.

Anda pasti dapat membuat argumen suara bahwa bintang tersebut termasuk dalam kualifikasi jenis pointer, tetapi tidak lebih dari itu.

Daftar kualifikasi tipe untuk pointer dapat menyebabkan masalah bagi mereka yang menggunakan int *astyle. Mereka yang menggunakan pointer di dalam typedef(yang seharusnya tidak, praktik yang sangat buruk!) Dan berpikir "bintang milik nama variabel" cenderung menulis bug yang sangat halus ini:

    /*** bad code, don't do this ***/
    typedef int *bad_idea_t; 
    ...
    void func (const bad_idea_t *foo);

Ini mengkompilasi dengan bersih. Sekarang Anda mungkin berpikir kode itu dibuat const benar. Tidak begitu! Kode ini secara tidak sengaja adalah kebenaran const palsu.

Jenis foosebenarnya int*const*- pointer paling luar dibuat hanya-baca, bukan data yang runcing. Jadi di dalam fungsi ini bisa kita lakukan**foo = n; dan itu akan mengubah nilai variabel di pemanggil.

Ini karena dalam ekspresi const bad_idea_t *foo, *itu bukan milik nama variabel di sini! Dalam kode semu, deklarasi parameter ini harus dibaca sebagai const (bad_idea_t *) foodan tidak seperti (const bad_idea_t) *foo. Bintang milik tipe pointer tersembunyi dalam kasus ini - jenisnya adalah pointer dan pointer yang memenuhi syarat ditulis sebagai *const.

Tetapi kemudian akar masalah dalam contoh di atas adalah praktik menyembunyikan pointer di belakang a typedefdan bukan *style.


Mengenai deklarasi beberapa variabel dalam satu baris

Mendeklarasikan banyak variabel pada satu baris secara luas diakui sebagai praktik buruk 1) . CERT-C merangkumnya dengan baik sebagai:

DCL04-C. Jangan mendeklarasikan lebih dari satu variabel per deklarasi

Hanya membaca bahasa Inggris, maka akal sehat setuju bahwa sebuah deklarasi harus satu deklarasi.

Dan tidak masalah apakah variabelnya pointer atau tidak. Mendeklarasikan setiap variabel pada satu baris membuat kode lebih jelas di hampir setiap kasus.

Jadi argumen tentang programmer bingung int* a, badalah buruk. Akar masalahnya adalah penggunaan beberapa deklarator, bukan penempatan *. Terlepas dari gaya, Anda harus menulis ini sebagai gantinya:

    int* a; // or int *a
    int b;

Argumen lain yang masuk akal tetapi subyektif adalah bahwa mengingat int* atipe atanpa pertanyaanint* maka bintang tersebut termasuk dalam jenis kualifikasi.

Tetapi pada dasarnya kesimpulan saya adalah bahwa banyak argumen yang diposting di sini hanya subyektif dan naif. Anda tidak dapat benar-benar membuat argumen yang valid untuk gaya mana pun - itu benar-benar masalah preferensi pribadi subjektif.


1) CERT-C DCL04-C .


Agak mengherankan, jika Anda membaca artikel yang saya tautkan, ada bagian singkat tentang topik typedef int *bad_idea_t; void func(const bad_idea_t bar); Seperti yang diajarkan nabi besar Dan Saks "Jika Anda selalu menempatkan constsejauh sejauh yang Anda bisa, tanpa mengubah makna semantik" ini sepenuhnya berhenti menjadi masalah. Itu juga membuat constdeklarasi Anda lebih konsisten untuk dibaca. "Segala sesuatu di sebelah kanan kata const adalah apa yang const, segala yang di sebelah kiri adalah tipenya." Ini akan berlaku untuk semua const dalam deklarasi. Cobalah denganint const * * const x;
dgnuff

-1

Mempertimbangkan

int *x = new int();

Ini tidak diterjemahkan ke

int *x;
*x = new int();

Ini sebenarnya diterjemahkan menjadi

int *x;
x = new int();

Ini membuat int *xnotasi agak tidak konsisten.


newadalah operator C ++. Pertanyaannya ditandai "C" dan bukan "C ++".
Sapphire_Brick
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.