Я кстати не говорил, что предложенное решение хорошее. И таки оверхед у него будет поболе чем у shared_ptr.
А как вы предлагаете передавать объекты не "с потрохами"? Ссылки, из-за своей недвижимой природы, тоже не всегда подходят.
На самом деле, проблема более фундаментальна, чем просто подсчёт ссылок на обекты в куче. Умные указатели в реальном коде решат часть ваших проблем — но далеко не все, и далеко не все решённые проблемы будут из числа самых коварных.
Другими словами, у вас в качестве базовой операции выступает reduce, а также целая обвязка вокруг неё. Чем такой подход лучше простого поэлементного прохода по коллекции как базовой операции? Какие случаи можно (или значительно проще) записать на трансдьюсерах, но нельзя (значительно сложнее) на итераторах? Пока что я вижу, что трансдьюсеры:
требуют нетривиальную логику во вспомогательном коде
требуют более нетривиальной работы с пробросом состояния в рекурсивной манере
применяются к коллекциям точно также через обёртки
Или весь вопрос исключительно в получении функционального иммутабельного ленивого аналога итераторов без ленивых коллекций?
Я честно говоря так и не понял, чем это лучше Iterable, который гораздо понятней и для реализации поддержки в коллекции, и для построения полностью ленивых трансформаций поверх такой ленивой последовательности — в т.ч. reduce.
Это позволит отправить JavaScript на то место, для которого он и задумывался — анимировать снежинки и связывать компоненты на странице. Языки со статической типизацией начинают доминировать после определённого объёма проекта — динамику сложно анализировать и рефакторить.
Спасибо, я в принципе в курсе. По поводу рейнджей я наверное по инерции ною. Один чёрт во многие проекты их можно втянуть только как стороннюю библиотеку.
Я-то задачу решил — использовав обычный мэп. Я про то, что код нынешних реализаций STL крайне тяжело читать. Что является проблемой, когда надо выяснить подробности такого вот implementation-defined behavior. Которым пестрит половина стандарта.
Насколько я помню, был большой спор про UFCS — возможность вызывать свободные функции как методы классов, но передавая инстанс первым аргументом. Как с этим дела?
Мне, к примеру, пришёл в голову такой вариант:
a |> f(b, c)
// превращается в
f(a, b, c)
т.е. через отдельный оператор. Хотя их, наверное, и так хватает.
(1) Я тихонько надеялся, что хотя бы о необходимости прототипа начинают задумываться. Впорчем, это отдельная тема для разговора.
(2) Вопрос в том, что даже фулл-тайм я не смогу написать прототипы для всего, что может войти в стандарт, для одного компилятора.
(3) Ключевое словосочетание "поддерживающих концепты". Последний раз, когда я интересовался вопросом, такое было только в отдельной экспериментальной ветке GCC. Нв других "столпах индустрии", насколько я знаю, состояние на нуле.
С модулями, концептами, рейнджами 3 и другими вкусностями всё ясно — их не будет минимум до С++20, а то и дольше. Хотелось бы узнать что-нибудь по другим фундаментальным вопросам
Опакечивание. Какой-то более-менее стандартный формат описания пакета. Для начала пусть без центрального репозитория — хотя бы как в Go возможность просто стянуть репозиторий, который будет собран по своим правилам и подключен к сборке моего проекта. Без попыток вручную скрестить CMake, MSBuild, GNU Make, Autotools, BJam etc.
Chosen nightly compiler. GCC может концепты, MSVC может модули, CLang может что-то ещё нужное (не помню). Попробовать это всё в связке нельзя по понятным причинам.
Если такая большая проблема добавить ranges v3, есть ли шанс в обозримом будущем получить хотя бы набор iterator adaptors? Втащить Boost не всегда есть возможность.
Я понимаю что в (1) и (2) требую слишком многого. Хотя нет — С++ единственный из мейнстрима, где нет конкретно (1) и катастрофический разброд касательно (2).
На самом деле, проблема более фундаментальна, чем просто подсчёт ссылок на обекты в куче. Умные указатели в реальном коде решат часть ваших проблем — но далеко не все, и далеко не все решённые проблемы будут из числа самых коварных.
Сходу могу вспомнить 2 фактора
Нет. Они предназначены для общего владения одним объектом из нескольких мест. Но проблему "утёкшего" временного указателя не решают.
Другими словами, у вас в качестве базовой операции выступает reduce, а также целая обвязка вокруг неё. Чем такой подход лучше простого поэлементного прохода по коллекции как базовой операции? Какие случаи можно (или значительно проще) записать на трансдьюсерах, но нельзя (значительно сложнее) на итераторах? Пока что я вижу, что трансдьюсеры:
Или весь вопрос исключительно в получении функционального иммутабельного ленивого аналога итераторов без ленивых коллекций?
Я честно говоря так и не понял, чем это лучше Iterable, который гораздо понятней и для реализации поддержки в коллекции, и для построения полностью ленивых трансформаций поверх такой ленивой последовательности — в т.ч. reduce.
Это позволит отправить JavaScript на то место, для которого он и задумывался — анимировать снежинки и связывать компоненты на странице. Языки со статической типизацией начинают доминировать после определённого объёма проекта — динамику сложно анализировать и рефакторить.
EDIT: не туда, отвечал на https://geektimes.ru/post/287342/#comment_9967202
Тогда они выбрали не тот язык.
Глядя на текущий код реализации, вы действительно хотите это знать?
Всё бы хорошо, но 2014-10-04...
Эмм… они проклянут фичу, которая вместо листинга ошибки инстанцирования на несколько экранов покажет
type X does not satisfy concept Y at file.cpp:42?Спасибо, был не в курсе. К сожалению, честно купленной копии стандарта не имею. А cppreference.com в разделе про unordered_map об этом молчит.
Спасибо, я в принципе в курсе. По поводу рейнджей я наверное по инерции ною. Один чёрт во многие проекты их можно втянуть только как стороннюю библиотеку.
Дайте пожалуйста ссылку на место в документации, где сказано про поддержку incomplete types в различных контейнерах.
Я-то задачу решил — использовав обычный мэп. Я про то, что код нынешних реализаций STL крайне тяжело читать. Что является проблемой, когда надо выяснить подробности такого вот implementation-defined behavior. Которым пестрит половина стандарта.
Насколько я помню, был большой спор про UFCS — возможность вызывать свободные функции как методы классов, но передавая инстанс первым аргументом. Как с этим дела?
Мне, к примеру, пришёл в голову такой вариант:
т.е. через отдельный оператор. Хотя их, наверное, и так хватает.
(1) Я тихонько надеялся, что хотя бы о необходимости прототипа начинают задумываться. Впорчем, это отдельная тема для разговора.
(2) Вопрос в том, что даже фулл-тайм я не смогу написать прототипы для всего, что может войти в стандарт, для одного компилятора.
(3) Ключевое словосочетание "поддерживающих концепты". Последний раз, когда я интересовался вопросом, такое было только в отдельной экспериментальной ветке GCC. Нв других "столпах индустрии", насколько я знаю, состояние на нуле.
С модулями, концептами, рейнджами 3 и другими вкусностями всё ясно — их не будет минимум до С++20, а то и дольше. Хотелось бы узнать что-нибудь по другим фундаментальным вопросам
Я понимаю что в (1) и (2) требую слишком многого. Хотя нет — С++ единственный из мейнстрима, где нет конкретно (1) и катастрофический разброд касательно (2).