пачему упыри из МелкоСофта не включили в generics деревья???
в вопросе кроется ответ. потому что упыри.
А все сразу им было влом прогать, надо же и для сторонних программеров работы оставить хоть немножко =)
Потому что деревьев немножко слишком дохуя разных.Я не в теме, но такой вопрос - хеш там есть? Его ведь тоже много разных.
хеш там есть? Его ведь тоже много разных.virtual int Object.GetHashCode есть. Потому что они справедливо рассудили, что интового хеша будет достаточно любому(с при этом появляется возможность писать HashTable базируясь на этой виртуальной функции (и ещё Object.Equals а реализацию можно сделать практически любую.
Какая может быть польза от генерика "дерево" — я не понимаю. Чтобы что-нибудь куда-нибудь передать, лучше использовать ICollection (которая внутри может быть деревом, естественно). Методы "добавить/найти/удалить элемент" в этом генерике реализовать нельзя, а кроме них ничего интересного в дереве-то и нет. Вот, структуру можно реализовать, типа ссылки, но тогда будет жутко неэффективной реализация бинарных деревьев (потому что вместо двух потомков будет массив потомков да и остальным деревьям дофига дополнительной инфы придётся хранить отдельно.
очень сложно представить класс дерево, которое покрывает широкий класс задач.
именно поэтому дерева и нет в стандартной либе.
во-вторых, какое ещё дерево, кроме бинарного нужно в стандартной библиотеке классов?
мне кажется для мелких данных сгодится любая хрень, а для не мелких уже лучше использовать какую-нить БД
> какое ещё дерево, кроме бинарного нужно в стандартной библиотеке классов?
Расскажи, как ты будешь иерархическую структуру каталогов и файлов в файловой системе упихивать в бинарное дерево =)
Расскажи, как ты будешь иерархическую структуру каталогов и файлов в файловой системе упихивать в бинарное дерево =)Очень просто.
Флудербля!
Элементарно, Уотсон.
---
А еще лучше сто орудий на километр фронта.
Оставить комментарий
Alexander08