Mengapa C ++ tidak dapat mengadopsi pendekatan D untuk implementasi konsepnya?


19

Seperti yang Anda ketahui, konsep , pendekatan C ++ untuk membatasi tipe yang mungkin untuk argumen templat telah gagal dimasukkan dalam C ++ 11.

Saya belajar bahwa bahasa pemrograman D 2.0 memiliki fitur serupa untuk pemrograman generiknya. Solusinya menurut saya cukup elegan & sederhana.

Jadi pertanyaan saya adalah mengapa C ++ tidak dapat menggunakan pendekatan yang serupa .

  • Tujuan konsep C ++ mungkin lebih besar dari apa yang disediakan oleh implementasi D?
  • Atau warisan C ++ mencegahnya mengadopsi pendekatan seperti itu?
  • Atau yang lainnya?

Terima kasih atas jawaban anda

ps Untuk melihat beberapa contoh kekuatan pemrograman generik D, lihat ini: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534


2
Pertanyaan ini seharusnya dimigrasikan ke programmer. (Saya memilih itu, tetapi 3 suara untuk "tidak konstruktif").
iammilind

3
Saya pikir pertanyaannya mungkin tidak ditulis dengan cara yang paling konstruktif, tetapi ada nilai di dalamnya. Saya akan senang seseorang menjelaskan bagaimana D mengelola konsep, dan dapat membandingkannya dengan dua pendekatan utama yang komite C ++ mengambil konsep sebelum mereka memutuskan untuk menunda fitur sama sekali ... Jika ini akan ditutup, maka harus di paling tidak dipindahkan ke programmer
David Rodríguez - dribeas

2
@ David: Saya memilih untuk membuka kembali (dan kemudian mungkin, itu dapat dipindahkan ke situs programmer)
Nawaz

1
Setuju dengan David. Saya tidak melihat alasan untuk mengatakan sebelumnya "tidak konstruktif" sebelum ada orang yang mencoba membangun sesuatu. dengan 0 jawaban, "konstruktivitas" adalah 0/0 karenanya tidak dapat ditentukan.
Emilio Garavaglia

1
@ jj1: Bisakah Anda memberikan penjelasan singkat tentang pendekatan D bagi kita yang tidak tahu bahasa?
David Rodríguez - dribeas

Jawaban:


9

Standar C ++ adalah dokumen normatif, yang menetapkan aturan yang akan tetap (kebanyakan tidak terpengaruh) dalam dokumen masa depan. Karena itu panitia telah mengambil pendekatan yang sangat hati-hati sehubungan dengan pembaruannya.

Penambahan ke perpustakaan standar agak mudah. Sejumlah perpustakaan sudah ada di Boost sejak lama: sudah terbukti berhasil.

Namun, penambahan konsep inti dalam bahasa jauh lebih sulit untuk dicoba, karena pertama-tama membutuhkan modifikasi kompiler. Fitur C ++ 03 (ekspor template) telah ditentukan tanpa dukungan kompiler ... hasilnya mengerikan. Para pelaksana frontend compiler EDG melaporkannya sebagai tugas besar (beberapa tahun kerja) untuk keuntungan yang sangat sedikit. Tidak ada kompiler lain yang pernah mencoba mengimplementasikannya. Ini bukan situasi yang nyaman.

Fitur suka constexpratau static_assertmudah (dan sudah ditiru oleh perpustakaan). Lambdas cukup dipahami dan diimplementasikan dalam berbagai bahasa lain, sudah ada penelitian yang luas, jadi itu terutama masalah sintaksis.

Di sisi lain Konsep dinilai terlalu baru dan belum dicoba . Mereka hampir tidak ditentukan dalam waktu, tidak ada bukti konsep ... dan dengan demikian mereka ditolak, daripada menunggu mereka (atau membuat kesalahan).

Kenapa tidak mengikuti D? Tidak ada yang mengatakan bahwa itu tidak akan terjadi. Komite telah mendorong orang untuk memikirkan kembali dari awal, tanpa tenggat waktu yang mendesak, dan untuk mencoba memasukkan mereka dalam kompiler untuk melihat bagaimana mereka berinteraksi dengan fitur-fitur lain dalam bahasa. Ada pertanyaan khusus tentang pemisahan Konsep dan Peta Konsep: haruskah mereka digabungkan menjadi satu atau tidak?

FYI: Saat ini ada cabang Clang yang didedikasikan untuk eksperimen ini, dipimpin oleh Larisse Voufo dari universitas Indiana.


Komentar kecil: kata kunci ekspor sebenarnya adalah fitur c ++ 98 (standardisasi asli). Corrigendum 2003 membahas terutama fitur perpustakaan.
ex0du5

@ ex0du5: Benar, '03 adalah revisi kecil dari Standar C ++ 98, yang sebagian besar menyangkut koreksi.
Matthieu M.

3

Untuk standar 2011, konsep C ++ adalah apa yang sedang dikerjakan, dan mereka akhirnya dikeluarkan dari standar itu, karena mereka tidak "cukup matang." Pekerjaan berlanjut pada konsep-konsep C ++ yang dapat menyebabkan mereka membuatnya menjadi standar berikutnya. Namun, bisa jadi beberapa orang akan mengerjakan proposal untuk standar berikutnya yang mirip dengan batasan template D. Apakah itu terjadi atau tidak, masih harus dilihat. Sejauh yang saya tahu, tidak ada proposal seperti itu untuk standar 2011, jadi tidak ada kesempatan untuk membuatnya menjadi standar itu terlepas dari kelebihannya, tetapi apa yang akan atau tidak membuatnya menjadi standar berikutnya sama sekali tidak diketahui. pada saat ini.

Saya tidak mengetahui alasan utama mengapa sesuatu yang mirip dengan batasan template D tidak dapat diimplementasikan untuk C ++, meskipun mengingat bahwa C ++ umumnya lebih terbatas pada apa yang dapat dilakukan pada waktu kompilasi, mungkin akan lebih sulit untuk membuatnya bekerja dengan baik. baik seperti yang mereka lakukan di D (meskipun pengenalan hal-hal seperti constexprpasti membantu).

Jadi sungguh, saya pikir jawaban singkatnya adalah bahwa tidak ada alasan teknis mengapa sesuatu yang mirip dengan batasan template D tidak bisa ada di C ++.

Pertanyaannya adalah apakah proposal seperti itu akan dibuat untuk standar berikutnya dan bagaimana itu akan dibandingkan dengan proposal serupa yang dibuat (misal proposal yang berkaitan dengan konsep). Dengan asumsi bahwa proposal yang dapat diterima dapat dibuat, saya sepenuhnya berharap bahwa sesuatu yang mirip dengan konsep atau batasan template D akan membuatnya menjadi standar berikutnya hanya karena ada banyak keinginan untuk itu. Pertanyaannya adalah apakah ada yang bisa membuat proposal yang cukup solid dan "cukup matang" untuk bisa diterima.


2

Maksud Anda kendala template D?

Sejauh yang saya tahu, konsep C ++ telah diusulkan atas nama boost :: concept. Masalahnya, di sini, adalah boost adalah pustaka yang ditulis untuk C ++ 03. C ++ 11 memiliki kemampuan sintaksis lain yang memungkinkan untuk mengimplementasikan hal-hal tertentu dengan cara yang berbeda yang memungkinkan C ++ 03 (karenanya, boost itu sendiri dapat ditulis ulang dengan mengambil keuntungan dari sintaks baru).

Komite standar menjatuhkan konsep karena akan terlalu lama untuk menentukannya (sehingga menunda lagi persetujuan c ++ 11). Mereka mungkin akan masuk dalam rilis C ++ berikutnya.

Sementara itu, sintaks D berbeda dari C ++ dan D sendiri mempertahankan beberapa kemampuan evaluasi ekspresi pada waktu kompilasi C ++ tidak selalu dapat tanpa melanggar beberapa kode lama (sesuatu yang D miliki, memiliki sejarah yang lebih singkat). C ++ sendiri sekarang memiliki static_assertdan costexpr, yang memungkinkan untuk meningkatkan kemampuan evaluasi waktu kompilasi. Mungkin di masa depan akan mencapai level yang sama.


2

Berikut ini adalah QA dengan Herb Sutter, ia berbicara tentang konsep pada tanda 15 menit.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

Jika Anda suka itu, ini adalah satu lagi: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Sekarang untuk pertanyaan Anda. Kenapa bukan versi D? Nah mengapa menggunakannya? C ++ adalah bahasa yang sangat kompleks dan stabil. Setiap fitur perlu dipilih dengan sangat hati-hati, karena biasanya harus didukung selama beberapa dekade. Jika Anda melihat standar C ++ pertama dan mengikuti revisi, ada beberapa fitur yang sudah usang, tetapi bahkan mereka harus tetap didukung. Jadi masuk akal untuk merancang konsep hingga 100% sesuai dengan C ++.

Adapun mengapa itu tidak termasuk dalam C ++ 0x. Ya karena itu sangat besar. Proposal itu 100 halaman panjang dan sangat sulit untuk diterapkan. Diputuskan bahwa fitur ini perlu lebih banyak waktu untuk menjadi dewasa hingga dimasukkan ke dalam standar.


2

Sederhananya, C ++ memiliki muatan sejarah yang jauh lebih banyak daripada D. Akan lebih mudah untuk menerapkan banyak hal yang mengerikan jika bukan karena fakta bahwa C ++ memiliki sejumlah besar kode historis yang harus terus bekerja dengan benar dan seperti yang diharapkan. D tidak memiliki masalah ini.


Mungkin Anda salah mengartikannya, tetapi masalahnya bukan kode warisan, masalahnya adalah bahwa fitur baru apa pun akan hadir dalam bahasa ini selama beberapa dekade dan harus didukung. Itu berarti setiap fitur baru harus dipilih dengan sangat hati-hati.
Let_Me_Be

@Let_Me_Be: Benar, masalahnya ada dalam kode warisan kita akan memiliki sepuluh tahun ke depan jika kita membuang konsep sekarang.
David Thornley
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.