🚀 go-pugleaf

>> Może twoim zdaniem powinny one mieć wszystkie te same metody, wszystkie
>> te same zależności, wszystkie te same wymagania, a nawet jeszcze niech
>> mają taką samą implementację. Wtedy będą spójne. A nie, cholera, będą
>> miały inne nazwy.
> 
> Nonsens. Zgubiłeś problem.
> Operacje robiące to samo mają mieć interfejs taki sam. A nie mają.
> 
> Dlaczego map::iterator iteruje po parach a vector::iterator nie --
> przecież oba są zbiornikami danych do których można się odwoływac po
> kluczu -- w przypadku vectora kluczem jest indeks, w mapie obiekt
> dowolnej porównowywalnego i przypisywalnego typu. Mapa powinna mieć dwa
> iteratory -- jeden po wartościach i *inny* po kluczach (tylko stały).
> Zbiór zaś powinien mieć tylko stały iterator -- po kluczach. Nie stały
> interator w zbiorze to jest w ogóle kompletna porażka.
> 

Jeśli dobrze rozumiem std::map i std::set to jest tam niejasne założenie 
korzystania z drzewa(choćby brak możliwości określenia jednoznacznego 
hashu takiego że (a == b) => (hash(a) == hash(b)) - gdzie == oznacza 
przeciążony operator). Chociaż są niestandardowe implementacje 
'std::hash_map'.

Jeśli zrobić iteracje tylko po kluczach i wartościach to uzyskujemy czas 
dostępu logarytmiczny (bo musimy go jeszcze raz wyszukać) jeśli mamy klucz 
a nie mamy pary (tzn. trzeba wyszukać).

Dlatego w Javie mamy metody Map<K, V>:
Set<Map.Entry<K, V>> entrySet(); //Tak jak w C++
Set<K> keySet();
Collection<V> values();

Jeśli zdefinjujesz wszystkie trzy std::map odstawałby - posiadaniem 6 
iteratorów zamiast 2. I tak źle. Mapy na tyle odstają od innych kolekcji, 
że w Javie nie są kolekcją.


>> [ciach]

Co do wyjątków w Javie to ostatnio piszę kod podobny do tego:
public class MojaKlasa extends AbstractList<Costam> {
	//...
	public Costam get(int index) {
		try {
			//...
		} catch(IOException ex) {
			Logger.log(Level.SERVE, null, ex);
			throw new RuntimeException(ex);
		}
	}
	//...
}

Nie mogę po prostu oznaczyć metody get jako wyrzucającej IOException bo 
interfejs tego wyjątku nie wyszczególnia. 

>>>Pobaw się trochę z sygnałami na systemie bez NPTL a poitem z NPTL :)
>> 
>>>Albo choćby taki "szczegół" jak get_pid() :)
>> 
>> Ano to ja wiem, że implementacja LinuxThreads jest niezgodna z POSIX.
>> Ale szczęściem nie mam dziś nigdzie w użyciu systemu z jądrem sprzed
>> 2.6.
> 
> Ty nie, ale się trafia.
> 

Można to uznać za błąd naprawiony? Bo wytykanie błędów implementacji 
poprzedniej głęzi nie ma sensu (i tak tego nie zmienią bo już zmienili i 
naprawili).

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)