|
|
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Сергей Ильич К сожалению, я не сталкивался с задачами где негарантированное константное время хоть как-то по перформансу опережало гарантированное логарифмическое. Может быть, в этом мой пробел. Практически, можно регулировать производительность хеша, коэффициентом загрузки. При малом количестве промахов можно довести отклик до константы. Правда это удобно для хешей которые не растут. В случае роста, реорганизация потребует гораздо большего времени чем расширение Б-дерева или Пирамиды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 15:42 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Petro123...Вот поэтому дельфист первым делом ищет готовые решения, а С++ник пишет все сам. Такой вот Коде Реюзе получается. Washington Irving Абсолютно согласен.[/quot] И я подпишусь. Именно так все и обстоит. А беда вся из-за бедности стандартной библиотеки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 23:19 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
mayton Сергей Ильич К сожалению, я не сталкивался с задачами где негарантированное константное время хоть как-то по перформансу опережало гарантированное логарифмическое. Может быть, в этом мой пробел. Практически, можно регулировать производительность хеша, коэффициентом загрузки. При малом количестве промахов можно довести отклик до константы. Правда это удобно для хешей которые не растут. В случае роста, реорганизация потребует гораздо большего времени чем расширение Б-дерева или Пирамиды. Время доступа к элементу хэш-таблицы в теории не зависит от N, т.е. практически константа. Правда это статистически и при условии, что хэш-функция хорошая. Поэтому это - самый быстрый из способов поиска, но он требует большого объема памяти и требователен к хэш-функции, которая не может быть универсальной и хорошей одновременно. Но логарифмического бинарного поиска она всяко "круче", но не всегда , естественно. На счет переполнения - не согласен, способов обработки переполнения много, и не все они требуют какого-то времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 23:34 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Сергей Ильич Yossarian ПОТОМУ ЧТО ГОТОВЫЕ РЕШЕНИЯ - КОШМАРНЫЙ ОТСТОЙ И ГОЛОВНАЯ БОЛЬ. Дык Вы заказчику отдаете инсталлятор с бинарью или же заставляете его все это собирать? Можно вместо ассоциативных массивов использовать наследник от std::vector< std::pair<KeyType,ValueType> > который при вставке его сортирует по ключу. А искать - бинарным поиском. Работать будет быстрее хеш-массива и фрагментировать кучу поменьше. Дык, Сергей Ильич, давайте не будем обсуждать мои взаимоотношения с заказчиком и конкретные технические решения, сделанные при решении конкретной задачи. Вы ведь не будете утверждать что хеш-массивы вообще не нужны ? Да и дело не в хеш-массивах, а в общей ублюдочности большинства С++ных библиотек. Ни шаблоны не спасают, ни стандарт в 1000 страниц. Так что данное Ваше возражение = null and void. Сергей Ильич Кроме того, в дельфе хешей тоже нет. И из-за отсутствия шаблонов полный аналог сделать нельзя. Опаньки! С каких пор наличие шаблонов стало необходимым для реализации хешей ? Что ж бедные программисты НА ЧИСТОМ С не знали об этом ? Бред. Сергей Ильич Я, напимер, никаких велоспедов не изобретаю и не пишу тривиальных вещй сам. Не то чтобы я фанат С++ (скорее наоборот), но в C++ я имею те средства которые мне нужны. Оттого что средний дегенерат не понимает зачем нужно множественное наследование, функционал который оно дает нужен и при его отсутствии надо искать обходные пути. (Ну дегенератами других ругать у нас все здоровы.) Про множественное наследование мне это опять же непонятно. Я не знаю задач, которые невозможно было бы решить без множественного наследования, так же я не знаю задач, которые нельзя было бы решить без GOTO. По мне так множественное наследование - это бантик. С ним бывает красивше, но и без него жить можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 12:49 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
YossarianПо мне так множественное наследование - это бантик. С ним бывает красивше, но и без него жить можно. Можно, но недолго и мучительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 13:02 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
MasterZiv YossarianПо мне так множественное наследование - это бантик. С ним бывает красивше, но и без него жить можно. Можно, но недолго и мучительно. Нееее... наоборот. С множественным наследованием жить тяжко. А без него очень просто и легко. Вообще, считаю множественное наследование злом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 18:45 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Ты просто не умеешь его готовить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 00:17 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
MasterZivТы просто не умеешь его готовить... Поддерживаю :) Абстрактные классы + множественное наследование - те же интерфейсы в Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 10:12 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
gardenman MasterZivТы просто не умеешь его готовить... Поддерживаю :) Абстрактные классы + множественное наследование - те же интерфейсы в Java. нифига себе! А если так? Абстрактные классы + множественное наследование - те же интерфейсы в Delphi . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 14:26 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
YossarianВы ведь не будете утверждать что хеш-массивы вообще не нужны ? Да и дело не в хеш-массивах, а в общей ублюдочности большинства С++ных библиотек. Ни шаблоны не спасают, ни стандарт в 1000 страниц. Так что данное Ваше возражение = null and void. Проекты собираю nmake'ом чтобы иметь возможность их пересобрать где угодно. Положить буст и прочую ботву в поддиректории проекта и настроить mak файл чтобы он цеплял все что нужно. В Джаве использую Ант для сборки. По той же причине - чтобы не надо было обучать заказчика настраивать среду. Yossarian Сергей Ильич Кроме того, в дельфе хешей тоже нет. И из-за отсутствия шаблонов полный аналог сделать нельзя. Опаньки! С каких пор наличие шаблонов стало необходимым для реализации хешей ? Что ж бедные программисты НА ЧИСТОМ С не знали об этом ? Бред. Сам дурак. На чистом C нельзя сделать полный аналог std::hash_map по той причине, что структура данных там будет другой. Для того чтобы размещать в хеше данные любого типа их надо будет размещать в куче и пользоваться void* указателями на ключ и на ассоциированное значение. При имении шаблонов значения ключей и ассоциированные значения можно размещать прямо в узле, уменьшая расход на доп. указатели и фрагментацию памяти. Кроме того, хранимые ключи и значения не надо ни от чего наследовать (от TCollectionItem например). При работе с std::hash_map не происходят виртуальные вызовы и проч. полиморфные вещи. Эстеты еще оценят type safety данного контейнера. Yossarian Сергей Ильич Оттого что средний дегенерат не понимает зачем нужно множественное наследование, функционал который оно дает нужен и при его отсутствии надо искать обходные пути. (Ну дегенератами других ругать у нас все здоровы.) Про множественное наследование мне это опять же непонятно. Я не знаю задач, которые невозможно было бы решить без множественного наследования, так же я не знаю задач, которые нельзя было бы решить без GOTO. По мне так множественное наследование - это бантик. С ним бывает красивше, но и без него жить можно. Если класс содержит в себе несколько разных алгоритмов, то лучше его разбить на поведения и вынести их в базовые классы. Аггрегирование тут будет работать через жопу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 17:16 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Сергей ИльичСам дурак. На чистом C нельзя сделать полный аналог std::hash_map по той причине, что структура данных там будет другой. Для того чтобы размещать в хеше данные любого типа их надо будет размещать в куче и пользоваться void* указателями на ключ и на ассоциированное значение. При имении шаблонов значения ключей и ассоциированные значения можно размещать прямо в узле, уменьшая расход на доп. указатели и фрагментацию памяти. Кроме того, хранимые ключи и значения не надо ни от чего наследовать (от TCollectionItem например). При работе с std::hash_map не происходят виртуальные вызовы и проч. полиморфные вещи. Эстеты еще оценят type safety данного контейнера. О господи.... Поверь старому любителю процедурных языков - хеш-карты делаются на С с легкостью необычайной. Всяческие темплейты и классы только усложняют исходный код. И работают оно в итоге медленнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 18:02 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
то, что шаблоны усложняют код - это ну очень сильно сказано.... Если б я писал без шаблонов... мои исходники были бы раз в 10 длиннее... если не в сто! а уж копался бы я в этом дерьме.. до пенсии... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 18:43 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Товарищи! Не все велосипеды еще построены!... За работу, товарищи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 18:44 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
White Owl Сергей ИльичСам дурак. На чистом C нельзя сделать полный аналог std::hash_map по той причине, что структура данных там будет другой. О господи.... Поверь старому любителю процедурных языков - хеш-карты делаются на С с легкостью необычайной. Всяческие темплейты и классы только усложняют исходный код. И работают оно в итоге медленнее. Процедурные языки - это недоделанные объектно-ориентированные языки. Программисту нужны контексты вполнения функций, области видимости, зависимость реализации функции от контекста, повторное использование готового кода. Без этого программу которая сложнее "Hello world" написать невозможно. Если этого функционала на уровне языка нет, то его придется эмулипровать. Как все это реализуется в C? Контексты (объекты) реализуются так - пишется структура. А потом пишутся функции, которые принимают указатель на эту структуру первым параметром. Та информация которая лежит в структуре - это контекст. То есть классы все равно есть в любой нетривиальной программе на C, но указатель this передается явно, а не неявно. Области видимости... Для в каждой нетривиальной программы на С у каждой функции делается префикс, чтобы избежать конфлика имен. То есть вместо ClassName::method пишем ClassNameMethod. Если не эстеты то смириться с этим можно. Дальше начинается мудизм. Зависимость реализации функции от контекста можно сделать с помошью enum и оператора switch. Можно в контекст внести указатель на функцию, но этот указатель надо где-то заполнить. Чаще всего это делается в "конструкторе" , где используется тот же switch с метками. Или же надо сделать несколько "конструкторов", генерящих разные контексты. В первом случае пользовантелю кода расширить модуль чтобы добавить в него новые фичи невозможно, во втором - можно через хак, то есть тоже почти невозможно. Все это приводило к появлению запутанных и совершенно неподдерживаемых программ. Чтобы от этого уйти, появилось ООП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2005, 21:06 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
>Сам дурак >Процедурные языки - это недоделанные объектно-ориентированные языки Я думаю на этой оптимистической ноте можно закончить обсуждение. Washington Irving ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2005, 12:04 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Сергей ИльичПроцедурные языки - это недоделанные объектно-ориентированные языки. Хорошо сказал :) Принцип реализации сложных структур в процедурном языке ты понимаешь, молодец. А вот то, что ты считаешь его настолько сложным - это у тебя просто недостаток опыта. Проверять, чувствую, ты не будешь, но тогда просто поверь что написать всю эту очень-страшную-систему на процедурном языке так же легко как и на объектном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2005, 18:58 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
... тем более, что люди так и делали много-много лет до появления ОО языков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2005, 21:20 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
MasterZiv... тем более, что люди так и делали много-много лет до появления ОО языков. а еще, много-много лет люди жрали мясо сырым до появления в их быту огня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2005, 22:25 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Интересно, а нафига ООП вообще нужно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2005, 23:02 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
Ну вот... начали с велосипедов, а закончили провокациями. По сабжу. Лично для меня ООП - всего лишь очередная техника программирования и отнюдь не идеология. Я могу писать эффективный код на процедурном ЯП но зачем рвать ж.... если для ускорения процесса разработки создан роскошный инструментаций, который в сокращает количество кода на 10-20% (для больших систем). Уж поверьте моему опыту. Программер ленив по определению, и если есть возможность чего-то не написать - будьте уверены - не напишет. А вы говорите - зачем дескать нужно.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 09:39 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
mayton Ну а как тут без провокаций :) Некоторые предыдущие заявления настолько ...э необычны, что очень хочется у афтаров спросить об их видении назначения ООП. Еще повеселило про шаблоны - дескать и код усложняют, да еще и медленнее все работает! Также интересное заявление о легкой эмуляции generic'ов в структурном C... В общем топик безусловно интересный :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 14:06 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
White Owl авторна процедурном языке так же легко как и на объектном. А если место процедурного языка поставить а) ассемблер б) машину Тьюринга г) вычислимые функции ... ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 14:08 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
funikovyuri ... Ага. Вы на статистику посмотрите. Нас уже 1000 человек прочитало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 14:09 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
mayton Ну а что - зато отвлекаем внимание от темы всех времен и народов Чем отличается union от enum ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 14:17 |
|
||
|
Философия велосипедостроения.
|
|||
|---|---|---|---|
|
#18+
funikovyuriНу а что - зато отвлекаем внимание от темы всех времен и народов ... неееее.. енто мелко.... вот тут круче... BSWAP всего за 3988 циклов ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 15:57 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=33312369&tid=2032631]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 427ms |

| 0 / 0 |
