Neden tüm <algorithm> işlevleri konteynerleri değil, yalnızca aralıklarını kullanıyor?

Birçok yararlı fonksiyon vardır <algorithm>, fakat hepsi "sekans" larda çalışır - yinelemeler Örneğin, eğer bir konteynırım varsa ve std::accumulateüzerine koştuğumda yazmam gerekir

std::vector<int> myContainer = ...;
int sum = std::accumulate(myContainer.begin(), myContainer.end(), 0);

Yapmayı düşündüğüm tek şey:

int sum = std::accumulate(myContainer, 0);

Bu benim gözlerimde biraz daha okunaklı ve net.

Şimdi sadece bir kabın bazı bölümlerinde çalışmak isteyebileceğiniz durumların olabileceğini görebiliyorum, bu yüzden aralıkların geçilmesi seçeneğinin olması kesinlikle yararlı . Ama en azından deneyimime göre, bu nadir görülen özel bir durum. Genelde bütün konteynerlerde çalışmak isterim.

Bir konteyneri alan ve çağıran begin()ve end()üzerine bir sarmalayıcı işlevi yazmak kolaydır , ancak bu kolaylık işlevleri standart kitaplığa dahil edilmez.

Bu STL tasarım seçiminin nedenini bilmek istiyorum.

... aralıkların geçme seçeneğine sahip olmak kesinlikle faydalıdır. Ama en azından deneyimime göre, bu nadir görülen özel bir durum. Genelde bütün konteynerlerde çalışmak isterim

Deneyiminizde nadir görülen özel bir durum olabilir , ancak gerçekte tüm konteyner özel durumdur ve keyfi aralık genel durumdur.

Geçerli kapsayıcıyı kullanarak tüm konteyner durumunu uygulayabileceğinizi zaten farkettiniz , ancak görüşmeyi yapamazsınız.

Bu yüzden, kütüphane yazarı öndeki iki arayüzü uygulamak veya hala tüm vakaları kapsayan birini uygulamak arasında bir seçeneğe sahipti.

Konteynır alan ve çağrıları başlatan () ve end () üzerine sarılmış bir sarmalayıcı işlevi yazmak kolaydır, ancak bu kolaylık işlevleri standart kitaplığa dahil edilmez

Doğru, özellikle de serbest fonksiyonlar std::beginve std::endşimdi dahil edilmiştir.

Öyleyse, kütüphanenin kolaylık aşırı yüklemesini sağladığını varsayalım:

template <typename Container>
void sort(Container &c) {
  sort(begin(c), end(c));
}

Şimdi aynı zamanda bir karşılaştırma işlevini alan eşdeğer aşırı yükü sağlaması gerekiyor ve diğer tüm algoritmalar için eşdeğerleri sağlamamız gerekiyor.

Ama en azından tam bir konteynerde çalışmak istediğimiz her vakayı ele aldık, değil mi? Pek iyi değil. Düşünmek

std::for_each(c.rbegin(), c.rend(), foo);

Kaplarda geriye doğru işlem yapmak istiyorsak , mevcut algoritma başına başka bir yönteme (veya bir çift yönteme) ihtiyacımız var.

Dolayısıyla, menzil temelli yaklaşım basit anlamda daha geneldir:

• bütün konteyner versiyonunun yapabileceği her şeyi yapabilir
• Tüm konteyner yaklaşımı, hala daha az güçlü olmakla birlikte, gereken aşırı yük sayısını iki katına çıkarır veya üçe katlar.
• Menzil tabanlı algoritmalar da kompoze edilebilir (iterator adaptörlerini istifleyebilir veya zincirleyebilirsiniz, ancak bu daha yaygın olarak fonksiyonel dillerde ve Python'da yapılır).

Elbette, STL'nin standart hale getirilmesinin zaten çok fazla uğraştığı ve bunun yaygın bir şekilde kullanılmadan önce uygun ambalajlarla şişirilmesi, sınırlı bir komite zamanının büyük bir kullanımı olmazdı. Eğer ilgileniyorsanız, Stepanov & Lee'nin teknik raporunu burada bulabilirsiniz.

Yorumlarda belirtildiği gibi, Boost.Range , standartta değişiklik gerektirmeden daha yeni bir yaklaşım sunar.

Bu konuda Herb Sutter'ın bir makalesi olduğu ortaya çıktı. Temel olarak, sorun aşırı yük belirsizliğidir. Aşağıdakiler göz önüne alındığında:

template<typename Iter>
void sort( Iter, Iter ); // 1

template<typename Iter, typename Pred>
void sort( Iter, Iter, Pred ); // 2

Ve aşağıdakileri ekleyerek:

template<typename Container>
void sort( Container& ); // 3

template<typename Container, typename Pred>
void sort( Container&, Pred ); // 4

Ayırt etmek 4ve 1doğru şekilde zorlaştırır .

Önerilen fakat sonuçta C ++ 0x'e dahil olmayan kavramlar bunu çözmüş olacaktı ve onu kullanarak atlatmak da mümkün enable_if. Algoritmaların bazıları için hiç sorun değil. Ama buna karşı karar verdiler.

Şimdi burada tüm yorumları ve cevapları okuduktan sonra, rangenesnelerin en iyi çözüm olacağını düşünüyorum . Sanırım bir göz atacağım Boost.Range.

Temel olarak eski bir karar. Yineleyici kavramı işaretçiler üzerinde modellenmiştir, ancak kaplar diziler üzerinde modellenmemiştir. Ayrıca, dizilerin geçmesi zor olduğu için (genelde uzunluk için bir tip olmayan şablon parametresine ihtiyaç duyar), genellikle bir işlev yalnızca işaretçilere sahiptir.

Ama evet, görüş açıklarında karar yanlış. Ya begin/endda begin/length; ' dan ya da ; Şimdi _nbunun yerine çoklu ek algoritmalarımız var .

Bunları eklemek size hiçbir güç kazandırmayacak (zaten tüm konteyneri arayarak .begin()ve .end()kendiniz arayarak yapabilirsiniz), ve tedarikçiler tarafından kütüphanelere eklenmiş, test edilmiş, bakımı yapılmış, kütüphaneye uygun şekilde belirtilmesi gereken bir şey daha ekleyecektir. vs vs.

Kısacası, muhtemelen orada değil çünkü tüm konteyner kullanıcılarını bir ekstra fonksiyon çağrısı parametresi yazmaktan korumak için fazladan bir dizi şablon tutmaya değmez.

Şimdilik, http://en.wikipedia.org/wiki/C++11#Range-based_for_loop için güzel bir alternatif std::for_each. Dikkat edin, açık bir yineleyici yok:

int a[5] = {1, 2, 3, 4, 5};
for (auto &i: a) { i *= 2; }

( Https://stackoverflow.com/a/694534/2097284 tarafından ilham alındı .)