Oberon space
General Category => Общий раздел => Тема начата: Илья Ермаков от Февраль 21, 2012, 07:49:59 am
-
Споров про (не)удобство обобщённых стандартных библиотек было много..
Всё-таки хотелось бы распросить уважаемых коллег:
а как часто и в каких задачах они вообще используют такие "типовые" алгоритмы, как сортировка, двоичный поиск и им подобные?
"До кучи" интересно, какие типы контейнеров применяете и как часто.
Но про алгоритмы более интересно. Потому что контейнеры общего характера реализовываются и без обобщённого программирования. А вот алгоритмы уже очень трудно представить.
(Потому что мне трудно представить класс практических задач, где та же сортировка бы встречалась на каждом шагу. В системщине - редко, в прикладухе её делает либо СУБД, либо уже GUI-компоненты...)
-
Что подразумевается под обобщенкой? Параметрический полиморфизм?
-
а как часто и в каких задачах они вообще используют такие "типовые" алгоритмы, как сортировка, двоичный поиск и им подобные?
Пишу на C#. Обощённые алгоритмы почти не использую. Несколько раз понадобилась сортировка (для встроенного в программу профилировщика), тогда я быстренько написал её сам. Двоичный поиск никогда не был нужен. Иногда использую generic типы в контейнерах (хэштаблицах), но только для значений, не для ключей, ключи конкретные ибо обобщённо делать поиск по generic ключу неэффективно получается (для каждого конкретного типа ключа поиск можно реализовать более эффективно чем обобщённо для всех сразу).
-
Delphi. Сплошь и рядом нужны ассоциативные массивы и списки, а соответственно и сортировка на уровне быстрой. Обобщённые контейнеры, хранящие объекты-обёртки над реальными данными слишком затратны. В текущих реализациях использую ручное указание, владеет ли контейнер элементами и являются ли элементы объектами. INTEGER<>POINTER взаимоконвертируются друг в друга.
-
C#. Сортировка периодически встречается, в этом случае используется LINQ. Исключений не припомню.
Двоичный поиск забыл когда использовал (но такое было).
-
Споров про (не)удобство обобщённых стандартных библиотек было много..
Всё-таки хотелось бы распросить уважаемых коллег:
а как часто и в каких задачах они вообще используют такие "типовые" алгоритмы, как сортировка, двоичный поиск и им подобные?
Довольно часто. Ну не каждый день, потому что вообще большая часть моего времени - это сопровождение. Но если взять написания "нового" кода - то довольно часто. Кроме того, не следует забывать еще более типовые for_each/find/map - на каждый день :)
"До кучи" интересно, какие типы контейнеров применяете и как часто.
std::vector как универсальный динамический массив - вне конкуренции. Ну и map (ассоциативный), конечно. Хотя если взять последний месяц - то были и set и stack и queue и deque.
(Потому что мне трудно представить класс практических задач, где та же сортировка бы встречалась на каждом шагу. В системщине - редко, в прикладухе её делает либо СУБД, либо уже GUI-компоненты...)
Кстати, с сортировкой и СУБД все не так однозначно. Есть такой шаблон, что если СУБД, то она должна и сортировать. Но не всегда. Очень даже часто проще/быстрее/правильнее делать сортировку в прикладном коде.
-
Ну, поскольку никто так и не уточнил что подразумевается под "обобщенными" алгоритмами, буду считать что это параметрический полиморфизм времени компиляции в C++.
Споров про (не)удобство обобщённых стандартных библиотек было много..
Всё-таки хотелось бы распросить уважаемых коллег:
а как часто и в каких задачах они вообще используют такие "типовые" алгоритмы, как сортировка, двоичный поиск и им подобные? "До кучи" интересно, какие типы контейнеров применяете и как часто.
Если пишу на C++ - то использую всякие там std::map (часто), std::vector (этот вообще постоянно), std::list (реже), std::string ( :-) ), std::auto_ptr. Ну и алгоритмы с ними связанные. Всякое там std::sort, std::find и так далее. Используеся постоянно (примерно как встроенные типы данных в иных языках).
При написании своего кода обычно правило - использовать полиморфизм времени компиляции везде кроме мест где реально требуется полиморфизм времени исполнения, и кроме мест где это код делает слишком запутанным (к сожалению в плюсы так и не ввели концепты). То есть, если следовать моему же определению обобщенки (а другого тут не давали), то у меня по большей части код на плюсах обобщенный.
Если пишу что-то на haskell (правда давненько не писал), то там вообще ВСЕ обобщенное. Та же функция map, fold(l/r) и так далее. Как там жить без обобщенки - слабо понятно.
Если пишу что-то на чистых сях, то обычно обобщенки нет, но периодически имитирую макросами :-) Это же относится к ObjC.
Когда пишу на яве Ну а что про яву сказать? Там обобщенки нет вообще (опять же см. определение), и даже макросов нет. Так что ява в пролете.
Но про алгоритмы более интересно. Потому что контейнеры общего характера реализовываются и без обобщённого программирования. А вот алгоритмы уже очень трудно представить.
Вот поэтому я и просил уточнить определение обобщенки без этого я не вижу в сказаном смысла :-) Если считать обобщенкой то что я вначале этого поста определил, то не вижу проблем для реализации алгоритмов общего характера без использования этого механизма.
(Потому что мне трудно представить класс практических задач, где та же сортировка бы встречалась на каждом шагу. В системщине - редко, в прикладухе её делает либо СУБД, либо уже GUI-компоненты...)
А если ты сам пишешь эту самую СУБД и GUI-компоненты? ;-) Последнее - я писал. Точнее писал, как модно нынче выражаться, gui-framework. Кроме того, даже если gui "фреймворк" уже написан другими, то обычно это ж все равно конструктор. Какой-нибудь список (в гуи) выведет элементы ровно в таком порядке в котором ты их отсортируешь.
-
Вопрос о выборе тех или иных средств зависит от цели, которая должна быть достигнута. Как известно, цель может оправдывать средства, а может и... не оправдывать. Если цель написать небольшую (учебную, например) программу, то желательно использовать "стандартные" средства языка/среды разработки/ОС. Срок жизни таких программ, как правило, невелик и сопоставим со сроком жизни средств, которые используются. Если же речь идёт о создании большой системы/программного комплекса, то предпочтительнее подход с минимальным использованием "стандартных" средств, поскольку не исключено, что срок их жизни окажется короче не только срока жизни продукта, но... даже срока его создания. Для примера, что было бы с теми продуктами, которые созданы на Delphi, если бы эта среда разработки не была своевременно перекуплена, если бы в неё внесли критические изменения?..
Удобство... При создании небольшой программы можно не обращать внимания на незначительные неудобства использования "стандартных" средств (понятно же, что "тиражная" одежда редко хорошо сидит на фигуре конкретного человека), но если проект большой, то "маленькие" неудобства могут перерасти в большие проблемы. И здесь правильным будет решение о том, чтобы совсем отказаться от тех "стандартных" элементов, которые создают проблемы, написав вместо них свои элементы (алгоритмы, библиотеки, шаблоны, компоненты...). С учётом того, что было сказано ранее, такой проект можно развивать и сопровождать дольше и с большими удобствами.
Эффективность... Применение "стандартных" библиотек даёт "стандартную" эффективность, которой... может оказаться недостаточно (в критических участках). Для примера стандартная подпрограмма/шаблон сортировки максимально дистанцирована от типа и порядка сортируемых данных, это обеспечивает ей широкое применение. И в простых случаях её производительности достаточно, но... для специфических данных (а, собственно, все реальные данные имеют некоторую специфику) "рукописная" сортировка может оказаться значительно эффективнее. Трудно ли написать свою сортировку (точнее сказать, свою разновидность сортировки)?.. Сортировка в среднем записывается в 20-30 строк... бинарный поиск в 5-10 строк.. Зная алгоритмы, их сильные и слабые стороны... толковому разработчику не потребуется много времени, чтобы написать свою разновидность алгоритмов, нацеленную на эффективную обработку специфических данных. И далее с учётом п.2 и п.1...
Не следует истолковывать мои слова, как призыв к переписыванию "стандартных" алгоритмов. Думать надо, прежде всего, о цели, а средства подбирать в зависимости от неё.
-
Вопрос о выборе тех или иных средств зависит от цели, которая должна быть достигнута. Как известно, цель может оправдывать средства, а может и... не оправдывать. Если цель написать небольшую (учебную, например) программу, то желательно использовать "стандартные" средства языка/среды разработки/ОС.
Как раз в учебных целях полезно изобретать велосипеды. В промышленном коде - только когда такая необходимость оправдана.
Срок жизни таких программ, как правило, невелик и сопоставим со сроком жизни средств, которые используются. Если же речь идёт о создании большой системы/программного комплекса, то предпочтительнее подход с минимальным использованием "стандартных" средств, поскольку не исключено, что срок их жизни окажется короче не только срока жизни продукта, но... даже срока его создания.
С таким подходом - вам прямая дорога в оберон :) Делаем железку, делаем компилятор и вперед... На самом деле нет ничего страшного в смене стандартных средств - ну будет у вас часть продукта собираться древнючей дельфей, для действительно большой системы - не проблема. Ну, конечно, на заведомо однодневки ставить не стоит (я бы вот на дельфи и не поставил, борланд загибаться давно начал ;)
Удобство... При создании небольшой программы можно не обращать внимания на незначительные неудобства использования "стандартных" средств (понятно же, что "тиражная" одежда редко хорошо сидит на фигуре конкретного человека), но если проект большой, то "маленькие" неудобства могут перерасти в большие проблемы. И здесь правильным будет решение о том, чтобы совсем отказаться от тех "стандартных" элементов, которые создают проблемы, написав вместо них свои элементы (алгоритмы, библиотеки, шаблоны, компоненты...). С учётом того, что было сказано ранее, такой проект можно развивать и сопровождать дольше и с большими удобствами.
В идеале :) На практике квалификация создателей велосипедов оказывается ниже уровня создателей стандартных средств. Конечно они с этим никогда не согласятся, но это так :) Я уже не говорю про мелочи типа вовлечения новых людей в проект.
Эффективность... Применение "стандартных" библиотек даёт "стандартную" эффективность, которой... может оказаться недостаточно (в критических участках). Для примера стандартная подпрограмма/шаблон сортировки максимально дистанцирована от типа и порядка сортируемых данных, это обеспечивает ей широкое применение. И в простых случаях её производительности достаточно, но... для специфических данных (а, собственно, все реальные данные имеют некоторую специфику) "рукописная" сортировка может оказаться значительно эффективнее. Трудно ли написать свою сортировку (точнее сказать, свою разновидность сортировки)?.. Сортировка в среднем записывается в 20-30 строк... бинарный поиск в 5-10 строк.. Зная алгоритмы, их сильные и слабые стороны... толковому разработчику не потребуется много времени, чтобы написать свою разновидность алгоритмов, нацеленную на эффективную обработку специфических данных. И далее с учётом п.2 и п.1...
Ну вот я как раз сейчас занимаюсь оптимизацией (по скорости) некоторых мест в нашем продукте. Ни одной сортировки не пришлось переписать :) Вот выкинуть совсем сортировку и переписать алгоритм так, чтоб работало без сортировки - пришлось :) Короче, ни одного велосипеда еще не написал по ходу этой оптимизационной деятельности. Все сводится к анализу существующего кода (вот уж когда хочется, чтоб все было написано стандартно и просто), потом выкидывается/переписывается код типа "из пустого в порожнее". Кода становится меньше, работает быстрее. Местами, конечно, код становится несколько витиеватый и не такой прямолинейный - ставится коммент типа "заоптимизировано".
-
for_each/find/map std::vector set и stack и queue и deque.
Осталось не понятным пишешь ли ты сам новые шаблонные алгоритмы или же всегда всё только из готовых-стандартных шаблонных кубиков собираешь?
-
Ну вот я как раз сейчас занимаюсь оптимизацией (по скорости)
Кстати, ни из одного стандартного контейнера нельзя удалить произвольный элемент за О(1) просто потому, что сначала его нужно в нём найти. Контейнеры из которых удаление элементов невозможно в принципе могут быть реализованы эффективнее контейноров из которых удаление элементов в принципе возможно. Ну и так далее. Так что, в моём понимании, оптимизация, если конечно это не просто чистка от говнокода, подразумевает неизбежный отказ от универсальных стандартных шаблонных кубиков.
-
Кстати, ни из одного стандартного контейнера нельзя удалить произвольный элемент за О(1) просто потому, что сначала егоquote] Не понял - пусть мы имеем массив ссылок на существующие простые обьекты(например, записи -куда уж стандартней) - разве нельзя из него удалить элемент за О(1)?
-
Не понял - пусть мы имеем массив ссылок на существующие простые обьекты(например, записи -куда уж стандартней) - разве нельзя из него удалить элемент за О(1)?
-
Вопрос о выборе тех или иных средств зависит от цели, которая должна быть достигнута. Как известно, цель может оправдывать средства, а может и... не оправдывать. Если цель написать небольшую (учебную, например) программу, то желательно использовать "стандартные" средства языка/среды разработки/ОС.
Как раз в учебных целях полезно изобретать велосипеды. В промышленном коде - только когда такая необходимость оправдана.
Изобретать велосипеды вообще полезно... Хорошая тренировка мышления, как такового.
Срок жизни таких программ, как правило, невелик и сопоставим со сроком жизни средств, которые используются. Если же речь идёт о создании большой системы/программного комплекса, то предпочтительнее подход с минимальным использованием "стандартных" средств, поскольку не исключено, что срок их жизни окажется короче не только срока жизни продукта, но... даже срока его создания.
С таким подходом - вам прямая дорога в оберон :) Делаем железку, делаем компилятор и вперед...
Проект оберона, по-моему мнению... самый неудачный. Для железки более удачной идеей может стать кросс-ассемблер.
На самом деле нет ничего страшного в смене стандартных средств - ну будет у вас часть продукта собираться древнючей дельфей, для действительно большой системы - не проблема. Ну, конечно, на заведомо однодневки ставить не стоит (я бы вот на дельфи и не поставил, борланд загибаться давно начал ;)
Видимо, у нас немного разные представления о средствах, видимо цели/задачи не очень похожи... Для меня смена средства (даже переход на новую версию) связана с проблемами. Пересобрать проект под новыми средствами может оказаться сравнимо с полным переписыванием, поскольку этого нет... а это не поддерживается... вместо того, есть вот это, а оно несовместимо с тем-то... и т.д. и т.п. Если речь об отдельных частностях, то с этим можно смириться, а если о ключевых моментах?..
Борланд был приличной командой, пока там был Филип Канн (Philip Kahn)... Он был не только основателем, но и душой фирмы.
Удобство... При создании небольшой программы можно не обращать внимания на незначительные неудобства использования "стандартных" средств (понятно же, что "тиражная" одежда редко хорошо сидит на фигуре конкретного человека), но если проект большой, то "маленькие" неудобства могут перерасти в большие проблемы. И здесь правильным будет решение о том, чтобы совсем отказаться от тех "стандартных" элементов, которые создают проблемы, написав вместо них свои элементы (алгоритмы, библиотеки, шаблоны, компоненты...). С учётом того, что было сказано ранее, такой проект можно развивать и сопровождать дольше и с большими удобствами.
В идеале :) На практике квалификация создателей велосипедов оказывается ниже уровня создателей стандартных средств. Конечно они с этим никогда не согласятся, но это так :) Я уже не говорю про мелочи типа вовлечения новых людей в проект.
Так оно... но для того и существуют... "старшие товарищи". И хороший проект не должен сразу писаться в виде "чистовика", пару первых версий надо готовить для "её величества" корзины... А к третьей версии либо появляется опыт, либо исчезает... программист.
Эффективность... Применение "стандартных" библиотек даёт "стандартную" эффективность, которой... может оказаться недостаточно (в критических участках). Для примера стандартная подпрограмма/шаблон сортировки максимально дистанцирована от типа и порядка сортируемых данных, это обеспечивает ей широкое применение. И в простых случаях её производительности достаточно, но... для специфических данных (а, собственно, все реальные данные имеют некоторую специфику) "рукописная" сортировка может оказаться значительно эффективнее. Трудно ли написать свою сортировку (точнее сказать, свою разновидность сортировки)?.. Сортировка в среднем записывается в 20-30 строк... бинарный поиск в 5-10 строк.. Зная алгоритмы, их сильные и слабые стороны... толковому разработчику не потребуется много времени, чтобы написать свою разновидность алгоритмов, нацеленную на эффективную обработку специфических данных. И далее с учётом п.2 и п.1...
Ну вот я как раз сейчас занимаюсь оптимизацией (по скорости) некоторых мест в нашем продукте. Ни одной сортировки не пришлось переписать :) Вот выкинуть совсем сортировку и переписать алгоритм так, чтоб работало без сортировки - пришлось :) Короче, ни одного велосипеда еще не написал по ходу этой оптимизационной деятельности. Все сводится к анализу существующего кода (вот уж когда хочется, чтоб все было написано стандартно и просто), потом выкидывается/переписывается код типа "из пустого в порожнее". Кода становится меньше, работает быстрее. Местами, конечно, код становится несколько витиеватый и не такой прямолинейный - ставится коммент типа "заоптимизировано".
У каждого свои задачи и свои взгляды на них, и свои методы их решения... Повторю, что с моей точки зрения, "изобретение велосипедов" - полезное занятие... Пока не изобретёшь несколько "велосипедов"... вообще ничего путнего не изобретёшь.
-
Велосипеды рулят. Рулят в том плане, что пока велосипед свой не построишь, так до конца и не поймешь как устроен велосипед стандартный, промышленный. Но при этом обычно выгодней ездить таки на промышленных велосипедах :-)
-
На мой взгляд , эта (велосипедная) тема высосана из пальца- в 99 процентах речь идет об оценке чей -то деятельности (и чаще всего со стороны). Я к чему это говорю - я не знаю лично ни одного человека (из тех , чья деятельность оценивалась подобным образом) который СОЗНАТЕЛЬНО занимался бы "изобретением велосипедов" (ВСЕ они имели ДРУГИЕ цели).
-
... я не знаю лично ни одного человека (из тех , чья деятельность оценивалась подобным образом) который СОЗНАТЕЛЬНО занимался бы "изобретением велосипедов" (ВСЕ они имели ДРУГИЕ цели).
Теперь можете уверено говорить, что... знаете такого человека, хоть и заочно... (я имею ввиду себя... люблю это занятие... "изобретение велосипедов"). :)
-
Теперь можете уверено говорить, что... знаете такого человека, хоть и заочно... (я имею ввиду себя... люблю это занятие... "изобретение велосипедов"). :)
Не думаю ;), впрочем, раз так - то так.
-
Осталось не понятным пишешь ли ты сам новые шаблонные алгоритмы или же всегда всё только из готовых-стандартных шаблонных кубиков собираешь?
Стандартное. Нестандартное редко оформляется как шаблон - потому что оно специализированное и используется в конкретном месте.
-
Ну вот я как раз сейчас занимаюсь оптимизацией (по скорости)
Кстати, ни из одного стандартного контейнера нельзя удалить произвольный элемент за О(1) просто потому, что сначала его нужно в нём найти.
Обычно на руках есть итератор, если речь о стандартной библиотеке С++. Кроме того, в boost есть всякие интрузивные списки - там не нужен итератор.
Контейнеры из которых удаление элементов невозможно в принципе могут быть реализованы эффективнее контейноров из которых удаление элементов в принципе возможно. Ну и так далее. Так что, в моём понимании, оптимизация, если конечно это не просто чистка от говнокода, подразумевает неизбежный отказ от универсальных стандартных шаблонных кубиков.
Не обязательно сразу говнокод. Код может быть как раз нормальный и читабельный. Но не самый эффективный. Самый распространенный пример для С++ - это контейнер копируемых структур против контейнера указателей. С указателями возни/ошибок больше, но работать оно может быстрее в определенных случаях.
-
Не понял - пусть мы имеем массив ссылок на существующие простые обьекты(например, записи -куда уж стандартней) - разве нельзя из него удалить элемент за О(1)?
Нельзя. Сначала надо найти индекс элемента в этом массиве. Обычно на руках есть итератор, если речь о стандартной библиотеке С++.
Обычно указатель на объект лежит сразу в нескольких совершенно разных контейнерах и перед удалением объекта надо удалить указатели на него из всех них. Кроме того, в boost есть всякие интрузивные списки - там не нужен итератор.
Хм... Интересно. Надо будет посмотреть. А случай с несколькими контейнерами как-то разруливается множественным наследованием? Стандартное. Нестандартное редко оформляется как шаблон - потому что оно специализированное и используется в конкретном месте.
Считаю это ключевым моментом. Если программисты сами свои шаблонные алгоритмы не пишут, а используют лишь стандартные, то шаблоны в языке получается что и не так уж и нужны, ведь стандартные шаблоны могут быть реализованы на уровне компилятора, ведь на то они и стандартные. Например, почти во всех языках на уровне компилятора поддерживается такой шаблонный контейнер как массив.
-
Обычно на руках есть итератор, если речь о стандартной библиотеке С++.
Обычно указатель на объект лежит сразу в нескольких совершенно разных контейнерах и перед удалением объекта надо удалить указатели на него из всех них.
Это у вас в шарпах такое обычно :) А у нас, как я уже говорил - в контейнерах лежат не указатели, а полноценные объекты. Ну если нужен полиморфизм - то смартпоинтеры :) Держать одно и тоже в разных контейнерах, а потом синхронизировать - похоже на какую-то вашу специфику. Хотя иногда такое нужно. В случаях, когда явная синхронизация по удалению не очень удобна я обычно пользуюсь таким подходом: кладу в контейнер слабую ссылку, которая автоматически протухает при удалении объекта. В какой-то удобный момент дохлые ссылки вычищаются из контейнера.
Хм... Интересно. Надо будет посмотреть. А случай с несколькими контейнерами как-то разруливается множественным наследованием?
Случай с несколькими контейнерами никак не разруливается. Разруливается эффективный доступ без итераторов и меньше фрагментируется память.
Считаю это ключевым моментом. Если программисты сами свои шаблонные алгоритмы не пишут, а используют лишь стандартные, то шаблоны в языке получается что и не так уж и нужны, ведь стандартные шаблоны могут быть реализованы на уровне компилятора, ведь на то они и стандартные. Например, почти во всех языках на уровне компилятора поддерживается такой шаблонный контейнер как массив.
Я не говорил, что совсем не пишу свои алгоритмы ;) Просто они пишутся один раз и надолго. Тот же find/for_each/map у нас используются не стандартные. Это легковесная обертка над стандартными алгоритмами, которая умеет работать с диапазонами итераторов.
-
Не понял - пусть мы имеем массив ссылок на существующие простые обьекты(например, записи -куда уж стандартней) - разве нельзя из него удалить элемент за О(1)?
Нельзя. Сначала надо найти индекс элемента в этом массиве.
Понял, мы говорим про разные вещи - лично я стою на позиции - если мы говорим об ОПРЕДЕЛЕННОМ элементе массива - то он вполне задается названием массива и индексом - у вас точка зрения нестандартная (вы говорите про НЕОПРЕДЕЛЕННЫЙ элемент содержащийся в массиве и задаваемый некоторым уникальным набором значений атрибутов).
-
Это у вас в шарпах такое обычно :)
А при чём тут C#? Мы пишем телефонную станцию. Указатель на объект-звонок лежит в большой хэштаблице всех звонков, в большом списке всех звонков, в списке звонков терминала с которого он пришёл или в списке звонков терминала на который он ушёл, в списке звонков медиаконференции, а так же в списке звонков с определённого так называемого ендпоинта. Указатель на объект-телефон лежит в большом списке всех телефонов, в хэштаблице по registrationId, в хэштаблице по uri, в хэштаблице по registration cookie, в хэштаблице по ip-адресу и порту, в хэштаблице по просто ip-адресу. Чтобы удалить звонок (телефон) за О(1) в самом объекте звонка (телефона) есть указатели на другие звонки (телефоны) навроде prev, next. Получается такая большая но простая структура данных, добавление и удаление звонка (телефона) в которую осуществляется за O(1).
-
Это у вас в шарпах такое обычно :)
А при чём тут C#? Мы пишем телефонную станцию. Указатель на объект-звонок лежит в большой хэштаблице всех звонков, в большом списке всех звонков, в списке звонков терминала с которого он пришёл или в списке звонков терминала на который он ушёл, в списке звонков медиаконференции, а так же в списке звонков с определённого так называемого ендпоинта. Указатель на объект-телефон лежит в большом списке всех телефонов, в хэштаблице по registrationId, в хэштаблице по uri, в хэштаблице по registration cookie, в хэштаблице по ip-адресу и порту, в хэштаблице по просто ip-адресу. Чтобы удалить звонок (телефон) за О(1) в самом объекте звонка (телефона) есть указатели на другие звонки (телефоны) навроде prev, next. Получается такая большая но простая структура данных, добавление и удаление звонка (телефона) в которую осуществляется за O(1).
Очень похоже вот на это: http://www.boost.org/doc/libs/1_48_0/libs/multi_index/doc/tutorial/index.html
-
Борланд был приличной командой, пока там был Филип Канн (Philip Kahn)... Он был не только основателем, но и душой фирмы.
Хм... Дай угадаю когда он ушел... Сразу после релиза 1-го дебилдера? :) У меня подыхание борланда ассоциируется с тем временем. Борланд слил свой С++ и покатился :)
-
Борланд был приличной командой, пока там был Филип Канн (Philip Kahn)... Он был не только основателем, но и душой фирмы.
Хм... Дай угадаю когда он ушел... Сразу после релиза 1-го дебилдера? :) У меня подыхание борланда ассоциируется с тем временем. Борланд слил свой С++ и покатился :)
А вот и нет - на 2 года раньше... :) :) :) (нафиг гадать - проще посмотреть).
-
Хм... Дай угадаю когда он ушел... Сразу после релиза 1-го дебилдера? :) У меня подыхание борланда ассоциируется с тем временем. Борланд слил свой С++ и покатился :)
А вот и нет - на 2 года раньше... :) :) :) (нафиг гадать - проще посмотреть).
А я хотел угадать ;) Ну что ж, значит его имя не запятнано даже 1-м дебилдером :)
-
Хм... Дай угадаю когда он ушел... Сразу после релиза 1-го дебилдера? :) У меня подыхание борланда ассоциируется с тем временем. Борланд слил свой С++ и покатился :)
А вот и нет - на 2 года раньше... :) :) :) (нафиг гадать - проще посмотреть).
А я хотел угадать ;) Ну что ж, значит его имя не запятнано даже 1-м дебилдером :)
:) Неплохо , хотя я бы ответил так.... "Ох ошибся , он ушел когда руководство ТОЛЬКО РЕШИЛО создавать билдер" :)
-
Хм... Дай угадаю когда он ушел... Сразу после релиза 1-го дебилдера? :) У меня подыхание борланда ассоциируется с тем временем. Борланд слил свой С++ и покатился :)
А вот и нет - на 2 года раньше... :) :) :) (нафиг гадать - проще посмотреть).
А я хотел угадать ;) Ну что ж, значит его имя не запятнано даже 1-м дебилдером :)
:) Неплохо , хотя я бы ответил так.... "Ох ошибся , он ушел когда руководство ТОЛЬКО РЕШИЛО создавать билдер" :)
А какая разница... до или после?.. C++ был вторичным продуктом Borland, вышедшем после успеха TurboPascal (хороший компилятор, первая IDE, позже в BorlandPascal расширитель DOS). Я не отношусь к поклонникам C++ и на C++ Builder не писал... но во времена Delphi Филип Канн уже не работал в Borland.
-
А какая разница... до или после?.. C++ был вторичным продуктом Borland, вышедшем после успеха TurboPascal (хороший компилятор, первая IDE, позже в BorlandPascal расширитель DOS). Я не отношусь к поклонникам C++ и на C++ Builder не писал... но во времена Delphi Филип Канн уже не работал в Borland.
1.В сообщении я посмеялся на пренебрежением Vlada по отношению к Билдеру
2. Он ушел в 1995 - а значит к первой делфи имел непосредственное отношение
-
А какая разница... до или после?.. C++ был вторичным продуктом Borland, вышедшем после успеха TurboPascal (хороший компилятор, первая IDE, позже в BorlandPascal расширитель DOS). Я не отношусь к поклонникам C++ и на C++ Builder не писал... но во времена Delphi Филип Канн уже не работал в Borland.
2. Он ушел в 1995 - а значит к первой делфи имел непосредственное отношение
Да, Вы правы. Прошу прощения...
-
Вот собрал себе gcc 4.7, там есть искаропки компилятор Go. (справедливости ради, он там есть начиная с 4.6). Немного с Go поигрался соответственно. И таки разочарован. Там нет типобезопасных контейнеров и способов из сделать. Вот например как работаем с вектором.
import "container/vector"
type mytype struct {
a, b int
}
func main() {
v := new(vector.Vector)
v.Push(mytype{1, 2})
value := v.Pop().(mytype)
}
Как говорится, welcome back to java 1.4.
Причем в стандартной либе контейнеров подобного рода несколько штук.
Это к вопросу о нужности "обобщенки".
-
Там нет типобезопасных контейнеров...
А массивы есть?
-
Там нет типобезопасных контейнеров...
А массивы есть?
В самом языке есть массивы (array) (http://golang.org/doc/go_spec.html#Array_types) и словари (map) (http://golang.org/doc/go_spec.html#Map_types). Это все естественно типобезопасно.