Pratik bir durumda kullandığınız en karmaşık veri yapısı nedir? [kapalı]

Bu sorudaki mikrop, sektördeki birkaç geliştirici ile yaptığım bir tartışmadan geldi.

Birçok yerde proje yöneticilerinin karmaşık veri yapıları konusunda ihtiyatlı oldukları ve genellikle standart kütüphane / paketlerden çıkan her şeyde ısrar ettikleri ortaya çıkıyor. Genel fikir, performans ciddi şekilde engellenmedikçe halihazırda mevcut olanların bir kombinasyonunu kullanmak gibi görünüyor. Bu, kod tabanını basit tutmaya yardımcı olur, bu da diplomatik olmayanlar için "yüksek yıpranmaya sahibiz ve işe aldığımız yeni olanlar o kadar iyi olmayabilir" anlamına gelir.

Bu yüzden CS junkies için çiçek filtresi veya atlama listeleri veya yayvan ağaçları yok. İşte soru (tekrar): Ofiste yaptığınız veya kullandığınız en karmaşık veri yapısı nedir?

Gerçek dünya yazılımlarının ne kadar iyi / sofistike olduğunu anlamaya yardımcı olur.

Arama için atlama listelerini kullandınız. Çalıştığım yerde standart bir uygulama var ve herkes bunu kullanmaya teşvik ediliyor. Patricia, IP adreslerini verimli bir şekilde saklamak ve almak için kullanmıştır. Yine uygulama zaten mevcuttu.

Ben Java geliştiricisiyim. Java Collection Framework ,% 90 veri yapısı problemlerimi çözebilir, diğer% 10 çaba gerektirir. Uzmanlar tarafından yazılan sofistike standart lib'i gerçekten anlarsanız, çoğu durumda yardımcı olduklarını göreceksiniz.

Karmaşık veri yapılarının gerçek dünyada bakımı zordur. Kodu karıştırmaktan kaçınmak için, bir problemi daha küçük olanlara bölerim. Her küçük problem Java Collection Framework ile çözülebilir . Belki de çözüm en akıllısı değildir (daha fazla bellek ve daha yavaş gerekir), ancak çalışır ve bakımı kolaydır. Bu değiş tokuş.

Karmaşık veri yapısı yazmam gerekiyorsa ders kitabını alacağım :)

İşte kullandığım en karmaşık veri yapısı üç katıydı. Ancak, bu yirmi yıl önceydi.

Endüstriyel yazılım geliştirmeyle ilgili sorun, endüstriyel programcıların çoğunun bilgisayar bilimi (CompSci) mezunları olmamasıdır; bu nedenle ortalama CompSci derecesinin aldığı tekniklerin ekmek ve tereyağı programcılarının bakımı için çok zor olduğu düşünülmektedir.

Sektördeki genel CompSci bilgisinin eksikliği ciddi bir sorundur. Örneğin, tanıştığım yazılım geliştiricilerinin sayısını (a! = 5 && b! = 3) ve a == 5 || b == 3 mantıksal olarak eşdeğerdir. DeMorgan Teoreminin nasıl uygulanacağını bilen herkes, bu ifadelerin mantıksal olarak eşdeğer olduğunu anlayabilir. CompSci üyesi olmayan mezunların çoğu DeMorgan Teoremini hiç duymamıştır. Herhangi bir önemli kod tabanı araştırılırsa, negatif mantıksal alt ifadeleri reddeden ifadelerin birçok örneği bulunur. Negatif negatif mantıksal alt ifadeler içeren kodun okunabilirliği, bu ifadelerin negatif olmayan biçimlerine dönüştürülmesiyle neredeyse her zaman geliştirilir.

Bir keresinde, profil oluşturmanın mevcut yığının bir darboğaz olduğunu gösterdiği olaya dayalı bir simülasyon için bir takvim kuyruğu (O (1) öncelik kuyruğu) yazdım.

Ayrıca, yaklaşık 80000 eyaletli sonlu durum makinesi içeren bir ürün de piyasaya sürdüm - en az söylemek gerekirse, bunu üretmek için kod biraz zordu.

Uzun, uzun, önce, bir galakside ... Knuth'un "arkadaş arabelleklerini" montajcıda bir RTOS'da kullanan bir ekip üzerinde çalıştı.

Ayrıca, 1024 x 1024 dünyası için 256 nesil Conway'in Hayat Oyunu.

Gerçekten çok özel bir şey kullanmadım, sıfırdan iki katına çıkmış bir liste olurdu .

Çok heyecan verici değil, başka yapılar kullandım. Ama sorunuz sıfırdan söyledi.

Genel finansal veri listelerini içeren bir karma ağaç - sormayın bile. Bazen keşke kovboy olsaydım. Ah, yıldızların altındaki basit yaşam ...

Sudoku çözücü için Dancing Links Algoritması için sıfırdan Dairesel Çift Bağlantılı Liste yapısı yazmak zorunda kaldım . Bir Rubik küpü tasarlamak gibiydi. Tüm yapı temel olarak bir liste listesiydi - her bir düğüm diğer dörtünü işaret ediyordu.

Bir keresinde özel bir önbellek için ağırlıklı bir yol uzunluğu ağacı kullandım . Bu eğlenceliydi. Ayrıca malloc()değiştirme için kendi yığın yönetimi rutinleri yazdı , ancak birçok insan bunu yaptı.

Bir düşünce verdikten sonra, sıfırdan yaptığım en "karmaşık" veri yapısı, çift bağlantılı listelere dayanan bir elemanlar ağını modellemek. Ancak yıllar önce sistem düzeyinde programlama yapıyordum.

Bugünlerde neredeyse hiç fantezi veri yapıları oluşturmuyorum. Çoğu, bir tabloya ne koyduğunuza karar verdiğiniz veritabanında gerçekleşir, belki de önceden hesaplanmamış bir değer, belki de gereksiz aramalardan kaçınmak için hızlı erişim için bazı ilgili kayıtların kimliği.

Şahsen eldeki görevin araçları tanımladığı şey. Kullanılmıyorsa neden bazı egzotik veri yapılarından faydalanmaya çalışıyoruz? Ve pratik uygulamalı programlamanın çoğunda söyleyebilirsem, muhtemelen tekerleği yeniden keşfetmeye gerek yoktur.

Öncelik kuyruğu geçerli mi? Bu yazdığım neredeyse her gerçek zamanlı uygulamada ortaya çıkıyor. Sadece son zamanlarda standart Java kitaplığının bir parçası oldu (Java 1.5).

Bunun dışında, gerçekten bir kütüphaneden çıkamamamı istediğim karmaşık bir şey düşünemiyorum. Bunun beni durdurmasına izin vermem, ama kütüphanelerin dahil etmesi için neden çok egzotik bir veri yapısına ihtiyaç duyduğumu sorgularım. Bir trie veya çiçek filtresi veya mevcut bir açık kaynak uygulamasını kendim yazmaya çalışmadan önce kesinlikle ararım.

Genel olarak, müdürünüze, kütüphane sürümü olmayacak kadar özel bir veri yapısı oluşturma ve sürdürme maliyetinin, bundan elde edilen herhangi bir performans avantajından daha ağır basması muhtemel olduğunu kabul ediyorum. Profilleme yoluyla, düz kütüphane yapılarının, devam etmenize ve onları süslü bir şeyle optimize etmenize izin vermeden önce önemli bir performans cezasına neden olduğunu göstermenizi istiyorum. Çünkü genel bir kural olarak, işlemci döngülerini satın almak mühendislik döngülerinden daha ucuzdur.