Выложены презентации и документы с BoostCon09
Выложены документы и презентации с конференции BoostCon09, которая прошла вначале мая.
Основные темы докладов - новый C++0x, многопоточное программирование и конечно же примеры использования библиотеки Boost.
Советую обратить внимание и не пропустить доклады Multithreaded C++0x: The Dawn of a New Standard и Keynote: Iterators Must Go от Andrei Alexandrescu.
Ну и остальные доклады тоже на высоте.
вот обсуждение второго доклада с точки зрения ФП
Странный пост
Мне фичи предлагаемого range понравились. Просто и удобно.
пост странный только с точки зрения людей не особо знакомых с функциональными языками
в С++ сейчас тянут слишком много всего, от чего язык проще не становится…
C этим я согласен - язык проще не становится. Не спроектирован он для таких вещей.
стоит отметить, что всеми наворотами, которые придуманы в последние годы, будут пользоваться очень мало людей (имхо), кроме самых простых конечно.
я сам вижу по разным проектам, и знакомый недавно жаловался, что народ достаточно простые шаблоны не использует, не говоря уже о полноценном MPL, который позволяет построить свой язык (который дает прирост производительности, например), но мало кто в нем может разобраться
По поводу MPL. Если бы типы обьявлялись не так:
typdef
typename std::vector::const_iterator
my_iterator;
а, например, так:
$my_iterator = std::vector::const_iterator;
= вместо typedef, $ вместо typename
то метапрограммирование мало чем отличалось бы от обычного.
Да блин, мало того, что шаблоны не используют - многие до сих пор на C пишут! Жесть же. 2009 год на дворе.
Только сегодня на C эмулировали ссылки прозрачно - ну нафиг эту старину.
оно в boost’е уже давно есть, только производительность очень низкая
Так вроде уже давно все посмотрели и обсудили?
Я только добрался
Всего-то меньше пары недель прошло
что бы перейти на полноценный range надо полностью отказаться от итераторов. Недавно в boost принята RangeEx, но это всего лишь обертка вокруг итераторов.
Вот какие проблемы.
Например мы имеем begin, end, filter1, filter2 тогда:
filter1_begin = (begin + end + filter)
filter1_end = (begin + end + filter)
filter2_begin = (filter1_begin + filter1_end + filter2)
filter2_end = (filter1_begin + filter1_end + filter2)
или
filter2_begin = ((begin + end + filter)+ (begin + end + filter)+ filter2)
filter2_end = ((begin + end + filter)+ (begin + end + filter)+ filter2)
т.е. размер filter1 range будет как минимум 24 байта, вместо 12. А теперь представьте размер итератора с 32 фильтрами, для такого итератора не хватит оперативной памяти.
В случае с range мы имеем: range, filter1, filter2:
filter1_range = range + filter1
filter2_range = filter1_range + filter2 = (range + filter1) + filter2;
Ни какого оверхеда!
Жду полноценных ренжей.
Оверхед не так критичен во многих случаях. Но да, всегда лучше иметь альтернативу для критических для памяти приложений. Но опять же - кто будет использовать STL в критических для памяти местах?
>Но опять же - кто будет использовать STL в критических для памяти местах?
а почему нет? STL - это набор интерфейсов, и они никак не связаны с памятью, производительностью. Вот например boost.array, кудаж эффективнее? А на вид обычный STL контейнер. Если вас не устраивает эффективность какой-то конкретной реализации STL, то никто не мешает выбрать другую,переписать те места, которые вас не устраивают. Сейчас в boost контейнеров - на любой вкус и цвет.
Речь идет не о STL, а о концепции итератор, а он везде.
Надо проитерировать файлы в директории - итератор, обойти вершины графа - итератор, пробежаться по базе данных - итератор. И всегда надо таскаться с парой [begin, end).
В общем как-то не комфортно себя чувствуешь, когда знаешь что есть более простое, понятное, лучшее решение.
Любой контейнер STL добавляет хотя бы 4 байта оверхед на указатель. boost.array не смотрел, но если он resizeable, то тоже должен иметь оверхед хотя бы 4 байта, а скорее 8, т.к. еще размер нужен. Отсюда уже небольшие затраты памяти. Плюс итераторы, да.
Так что если уж память СИЛЬНО критична, то нечего вообще ими пользоваться.
Но все же в 99.9% случаев нет таких критических ограничений.
Он не resizable. Поэтому тогда, когда нужен ресайз, используется вектор, когда не нужен - используется array.