Здравствуйте, WolfHound, Вы писали:
WH>исправляться надо...надеюсь еще не позно...
Вот давайте только не будем доказывать друг другу, что разработка алгоритмов (не интерфейсов) идёт одинакого на С++ вообще. А вот разработка интерфейса, для тестирования алгоритма гораздо быстрее выполняется именно на Билдере, т.к. не нагружается программист особенностями визуализации. Или я не прав? Или вы можете в VC сделать ПрогрессБар, прижатый к низу окна, тремя кликами мыши?
Ваша программа работает корректно? Один звонок и я всё исправлю!
Здравствуйте, Багер, Вы писали:
Б>Вот давайте только не будем доказывать друг другу, что разработка алгоритмов (не интерфейсов) идёт одинакого на С++ вообще. А вот разработка интерфейса, для тестирования алгоритма гораздо быстрее выполняется именно на Билдере, т.к. не нагружается программист особенностями визуализации. Или я не прав? Или вы можете в VC сделать ПрогрессБар, прижатый к низу окна, тремя кликами мыши?
Я это сделаю на C#.
... << RSDN@Home 1.0 beta 2 Enya — Anywhere Is>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Багер, Вы писали:
Б>Да, однако, мне явно не показалось, что Микрософт стал стремиться к повторению интерфейсного удобства Билдера.
Хм а что есть в BCB6 чего нет в VS.NET?
А вот обратный список:
Solution Explorer — У бормано жалкое кривое подобие View unit зовут.
Class view — У бормано жалкое кривое подобие Class explorer зовут.
Debuger — У борманов дебильный, ни чего не показывает и постоянно падает.
Autos — Может плохо искал но его у борманов я не видел.
Locals — У борманов дебильный, ни чего толком не показывает.
Watch — У борманов дебильный, ни чего толком не показывает.
Auto complite — тоже дурной.
Hints — Мло того что они тормозят они еще и выглядят так что лучше бы их небыло.
А про то что их библиотеки написаны так что хочеться громко материься, компилер тормозной, код генерит хреновый, и сама среда постоянно кидает AV я вобще молчу.
ЗЫ Скорей всего я еще чтото забыл.
... << RSDN@Home 1.0 beta 2 Enya — I May Not Awaken>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
Б>>Да, однако, мне явно не показалось, что Микрософт стал стремиться к повторению интерфейсного удобства Билдера.
WH>Хм а что есть в BCB6 чего нет в VS.NET? WH>А вот обратный список: <...>
Предлагаю вам продолжить обсуждение достоинств и недостатков BCB и VC++ где-нибудь в другом форуме.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, ingie, Вы писали:
I>Здравствуйте, Багер, Вы писали:
Б>>Вот бинарное дерево, автобалансируемое — это да, но вот есть ли реализация его в STL? I>Нет. Для этого есть boost, и со временем оно там скорее всего появится.
как нет? а как же map, set — они сделаны на основе red-black tree.
I>
Serge.
Hасколько проще была бы жизнь, если бы она была в исходниках.
Здравствуйте, Sergeem, Вы писали:
S>как нет? а как же map, set — они сделаны на основе red-black tree.
А что это за основа — красно-чёрное дерево?
Можно попросить Вас привести пример кода с добавлением нового элемента в дерево, либо Мап, либо Сет — на Ваш выбор.
WolfHound, Билдер 6 посмотрите — половина того что Вы написали уже полгода, как неактуально ))
Павел Кузнецов, какой форум можно выбрать для "горячих" споров в стиле этого?
Ваша программа работает корректно? Один звонок и я всё исправлю!
Здравствуйте, Sergeem, Вы писали:
S>как нет? а как же map, set — они сделаны на основе red-black tree.
Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
Здравствуйте, ingie, Вы писали:
S>>как нет? а как же map, set — они сделаны на основе red-black tree. I>Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
С другой стороны — а какая ценность у балансируемого бинарного дерева самого по себе?
Это инструмент, в частности, для создания упорядоченного контейнера.
Таковым является std::set и все его производные/аналоги (std::map, std::multi*** и т.д.)
Здравствуйте, Кодт, Вы писали:
I>>Согласен. rb-tree есть в каждой реализации STL. Беда в том, что они не стандартизированы.
Ну "беда" — это громко сказано...
К>С другой стороны — а какая ценность у балансируемого бинарного дерева самого по себе? К>Это инструмент, в частности, для создания упорядоченного контейнера. К>Таковым является std::set и все его производные/аналоги (std::map, std::multi*** и т.д.)
Верно, инструмент, но вся STL по большому счету — они и есть...
Ну так что мешает стандартизировать инструмент? Если бы и к этому были требования, то, я уверен, разница между различными реализациями STL еще сильнее сократилась бы.
К>Какие еще применения балансируемого дерева?
Дерево, — не важно какое, — это уже сама по себе интересная идиома, начиная с того, что существующие итераторы с точки зрения логики не имеют ничего общего с теми методами доступа которые могут быть у дерева. Я легко представляю себе реализацию, ну например, XML-парсера, c использованием дерева, а вот map — для этого, на мой взгляд не очень подходит. Короче, в окружающем мире дофига иерархических структур, почему бы не отобразить их прямо в таком виде на машинную память и не использовать интуитивные операции доступа? Да взять хотя бы MIB в SNMP, за пять минут программируется устройство с такой базой на деревьях... А с множествами? Если честно, то я предпочел бы видеть в STL именно деревья, а не все эти multi*... boost с этой точки зрения радует, там взялись сразу за графы...
<<RSDN@Home 1.0 beta 2 >>
Re: Что такое "STL контейнеры"? И чем они полезны?
Здравствуйте, ingie, Вы писали:
I>Дерево, — не важно какое, — это уже сама по себе интересная идиома, начиная с того, что существующие итераторы с точки зрения логики не имеют ничего общего с теми методами доступа которые могут быть у дерева. Я легко представляю себе реализацию, ну например, XML-парсера, c использованием дерева, а вот map — для этого, на мой взгляд не очень подходит. Короче, в окружающем мире дофига иерархических структур, почему бы не отобразить их прямо в таком виде на машинную память и не использовать интуитивные операции доступа? Да взять хотя бы MIB в SNMP, за пять минут программируется устройство с такой базой на деревьях... А с множествами? Если честно, то я предпочел бы видеть в STL именно деревья, а не все эти multi*... boost с этой точки зрения радует, там взялись сразу за графы...
Так ведь дерево вообще, а не красно-черное сбалансированное двоичное...
Структура узла может варьироваться: фиксированное количество ветвей (двоичное дерево), произвольное...
И правила доступа к дереву отличаются от контейнеров... и зависят от смысла этой структуры.
Например, в дереве двоичного поиска — один вид упорядочивания (левая ветвь — узел — правая ветвь), а в пирамиде и б-дереве — другой (узел — первая ветвь — вторая ветвь... и ветвей может быть много). Пирамида вообще эффективно реализуется на векторе.
Поэтому, наверное, лучше изготовить/найти библиотеку структур и алгоритмов для той или иной задачи, чем валить все в STL.
Здравствуйте, Кодт, Вы писали:
К>Так ведь дерево вообще, а не красно-черное сбалансированное двоичное...
Ну это конечно, изначально именно они имелись ввиду, это потом кто-то про rb вставил...
Согдасен. Правда обидно за дерево, все есть в STL а его нет...
Перекуём баги на фичи!
