C ++ neden D'nin konsept uygulaması için yaklaşımını benimseyemiyor?


19

Birçoğunuzun bildiği gibi, kavramlar , C ++ 'ın bir şablon argümanı için olası türleri sınırlama yaklaşımı C ++ 11'e dahil edilemedi.

D programlama dili 2.0'ın genel programlama için benzer bir özelliğe sahip olduğunu öğrendim. Çözümü bana oldukça zarif ve basit görünüyor.

Benim sorum C ++ benzer bir yaklaşım kullanamıyor neden .

  • C ++ konseptinin amacı D'nin uygulamasından daha büyük olabilir mi?
  • Yoksa C ++ 'ın mirası böyle bir yaklaşımı benimsemesini engeller mi?
  • Veya herhangi biri?

Cevaplarınız için teşekkürler.

ps D'nin genel programlama gücünden bazı örnekler görmek için lütfen şu adrese bakın: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534


2
Bu sorunun programcılara taşınması gerekirdi. (Buna oy verdim, ancak 3 oy "yapıcı değil" idi).
iammilind

3
Sorunun en yapıcı şekilde yazılmayabileceğini, ama bunun üzerinde bir değer olduğunu düşünüyorum. D'nin kavramları nasıl yönettiğini açıklayan birini sevmek isterim ve C ++ komitesinin kavramları tamamen ertelemeye karar vermeden önce kavramları üstlendiği iki ana yaklaşımla karşılaştırabilirim ... Bu, kapatılacaksa, en az programcılara taşınacak
David Rodríguez - dribeas

2
@David: Yeniden açmaya oy verdim (ve belki de programcılar sitesine taşınabilir)
Nawaz

1
David ile aynı fikirde. Kimsenin bir şey inşa etmeyi denemesinden önce, önleyici olarak "yapıcı olmayan" demek için hiçbir neden göremiyorum. 0 cevap ile "yapıcılık" 0/0 dolayısı ile belirsizdir.
Emilio Garavaglia

1
@ jj1: D'nin dili bilmeyenlere yaklaşımı hakkında kısa bir açıklama yapabilir misiniz?
David Rodríguez - dribeas

Yanıtlar:


9

C ++ Standardı, gelecekteki belgelerde kalacak (çoğunlukla etkilenmeyecek) kurallar belirleyen normatif bir belgedir. Bu nedenle komite güncellemeleri konusunda çok temkinli bir yaklaşım benimsemiştir.

Standart kütüphaneye eklemeler biraz kolaydı. Birçok kütüphane uzun zamandır Boost'taydı: çalıştıkları kanıtlandı.

Bununla birlikte, dilde temel kavramlara eklemelerin denenmesi çok daha zordur, çünkü öncelikle bir derleyiciyi değiştirmeyi gerektirir. Derleyici desteği olmadan bir C ++ 03 özelliği (şablonların dışa aktarılması) belirtilmişti ... sonuç korkunçtu. EDG derleyici ön ucunun uygulayıcıları, çok az kazanç için büyük bir görev (birkaç yıl) olarak bildirdiler. Başka hiçbir derleyici bunu uygulamaya çalışmadı. Rahat bir durum değil.

Özellikler gibi constexprveya static_assertkolay (ve zaten kütüphaneler tarafından taklit). Lambdalar, diğer birçok dilde oldukça iyi anlaşılmış ve uygulanmış, zaten kapsamlı araştırmalar yapıldı, bu yüzden esas olarak sözdizimi meselesiydi.

Öte yandan Kavramlar çok yeni ve denenmemiş olarak değerlendirildi . Zamanla zar zor tanımlandılar, kavram kanıtı yoktu ... ve böylece onları beklemek (veya bir hata yapmak) yerine reddedildiler.

Neden D'yi takip etmiyorsun? Yapmayacağına dair hiçbir söz yok. Komite, insanları son başvuru tarihi olmadan sıfırdan yeniden düşünmeye ve dildeki diğer özelliklerle nasıl etkileşime girdiklerini görmek için onları bir derleyiciye dahil etmeye çalışmalarını teşvik etti. Kavramların ve Kavram Haritalarının ayrılması sorusu özellikle vardır: bunlar tek olarak mı paketlenmeli mi?

FYI: Şu anda Indiana Üniversitesi'nden Larisse Voufo liderliğindeki bu denemeye adanmış bir Clang şubesi var.


Küçük yorum: export anahtar sözcüğü aslında bir c ++ 98 özelliğidir (orijinal standartlaştırma). 2003 toplantısında öncelikli olarak kütüphane özellikleri ele alındı.
ex0du5

@ ex0du5: Doğru, '03, çoğunlukla düzeltmelerle ilgili olan C ++ 98 Standardının küçük bir düzeltmesidir.
Matthieu M.13

3

2011 standardı için, C ++ kavramları üzerinde çalışılan şeydi ve nihayetinde bu standarttan çıkarıldılar, çünkü "yeterince pişirilmedi". Onları bir sonraki standarda dönüştürmelerine neden olabilecek C ++ konseptleri üzerinde çalışmalar devam etmektedir. Bununla birlikte, bazı kişiler D'nin şablon kısıtlamalarına benzer bir sonraki standart için bir teklif üzerinde çalışacaktır. Bunun olup olmayacağı hala görülüyor. Bildiğim kadarıyla, 2011 standardı için böyle bir teklif yoktu, bu yüzden onun değerine bakılmaksızın bu standarda girme şansı yoktu, ancak bir sonraki standarda ne yapacak veya olmayacak tamamen bilinmiyor. bu noktada.

D ++ 'ın şablon kısıtlamalarına benzer bir şeyin C ++ için uygulanamamasının önemli bir nedeninin farkında değilim, ancak C ++' nın derleme zamanında ne yapabileceği konusunda daha sınırlı olduğu göz önüne alındığında, bunların (D gibi şeyler giriş constexprkesinlikle yardımcı olsa da ).

Gerçekten, kısa cevabın D'nin şablon kısıtlamalarına benzer bir şeyin C ++ 'da olmamasının teknik bir nedeni olmadığını düşünüyorum.

Soru, böyle bir teklifin bir sonraki standart için yapılıp yapılmayacağı ve benzer teklifler ile nasıl karşılaştırılacağıdır (örn. Kavramlarla ilgili teklifler). Kabul edilebilir bir teklif yapılabileceğini varsayarsak, kavramlara veya D'nin şablon kısıtlamalarına benzer bir şeyin onu bir sonraki standarda dönüştürmesini beklerim, çünkü bunun için çok fazla istek vardır. Soru, herkesin yeterince sağlam ve kabul edilebilir "yeterince pişirilmiş" bir teklif bulup bulamayacağıdır.


2

D'nin şablon kısıtlamalarını mı kastediyorsunuz?

Bildiğim kadarıyla, C ++ kavramları boost :: concept adına önerilmişti. Burada sorun, C ++ 03 için yazılmış bir kütüphane olmasıdır. C ++ 11, belirli şeylerin farklı bir şekilde uygulanmasına izin veren başka sözdizimi yeteneklerine sahiptir (bu nedenle, yeni sözdiziminin avantajlarını kullanarak kendini yeniden yazabilirsiniz).

Standart komite kavramları bıraktı çünkü bunları belirtmek çok uzun sürecekti (c ++ 11 onayını tekrar ertelemek). Muhtemelen bir sonraki C ++ sürümüne geçecekler.

Bu arada, D sözdizimi C ++ 'dan farklıdır ve D'nin kendisi derleme zamanında bazı ifade değerlendirme yeteneklerini korur C ++ bazı eski kodları kırmadan her zaman sahip olamaz (D dozunun olmadığı, daha kısa bir geçmişe sahip olması). C ++ şimdi static_assertve costexprderleme zamanı değerlendirme yeteneklerini geliştirmek için izin verir. Gelecekte de benzer bir seviyeye ulaşacaktır.


2

İşte Herb Sutter ile bir KG, 15 dakika işaretindeki kavramlardan bahsediyor.

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

Eğer isterseniz, bir tane daha: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Şimdi sorunuza gelince. Neden D versiyonu değil? Neden kullanıyorsunuz? C ++ çok karmaşık ve istikrarlı bir dildir. Her özelliğin son derece dikkatli bir şekilde seçilmesi gerekir, çünkü genellikle on yıllar boyunca desteklenmesi gerekir. İlk C ++ standardına bakar ve düzeltmeleri takip ederseniz, kullanımdan kaldırılmış bazı özellikler vardır, ancak bunların hala desteklenmesi gerekir. Bu yüzden konseptleri% 100 C ++ 'a uyacak şekilde tasarlamak mantıklıdır.

Neden C ++ 0x'e dahil edilmedi. Çünkü çok büyüktü. Teklif 100 sayfa uzunluğundaydı ve uygulanması çok zordu. Bu özelliğin standarda dahil oluncaya kadar olgunlaşması için daha fazla zamana ihtiyaç olduğuna karar verildi.


2

Oldukça basit bir şekilde, C ++, D'den çok daha fazla tarihi bir bagaj cehennemine sahiptir. ve beklendiği gibi. D'nin bu sorunu yok.


Belki de sadece yanlış ifade ettiniz, ancak sorun eski kod değil, sorun yeni bir dilde onlarca yıldır mevcut olacak ve desteklenmesi gerekecek. Bu, her yeni özelliğin çok dikkatli seçilmesi gerektiği anlamına gelir.
13'te Let_Me_Be

@Let_Me_Be: Doğru, sorun eski kodda, şimdi kavramları atarsak on yıl çizgimiz olacak.
David Thornley
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.