Golang, Swift своим вполне себе успехом показывают, что много куда — было бы желание. И если Swift насаждается Apple как монополистом платформы, то Гофер хорошо выстрелил без такого "допинга". Любой успех начинается с малого. А если думать в терминах "куда же мы от Х", то так и будем ещё лет 10-20 с перераздутым стандартом, убогими iostreams и зета-функцией Римана.
P.S: Эх, где был нынешний bindgen и tokio два года назад...
А вот сейчас вы спорите не с тем человеком :) Ваш изначальный посыл был, что смарт-указатели решают эту проблему. Я вам отвечал, что есть целый пласт ситуаций, где не могут — поскольку отношение заимствования не может быть выражено в системе типов С++, но само заимствование присутствует повсеместно.
По моему опыту, данная проблема не может быть решена в компайл-тайме в рамках правил С++. Из-за того, что копирование, а не перемещение, первично, такой "трекинг" нельзя добавить в компилятор, не ломая всё.
Проблема в том, что в общем случае вы не знаете, куда потом денется &s.
Естественно, что на простых примерах всё очевидно. Менее простой пример (тоже искусственный, конечно) — инвалидация итераторов:
std::vector<Foo> foos;
std::vector<Bar> bars;
auto const& first = foos.first();
for (auto const& bar: bars)
{
if(asFoo(bar) != first)
foos.push_back(asFoo(bar));
}
Ещё один пример (опять же псевдокод):
for(auto& item: range(returnVector()) | filter(userPredicate))
{
// Here, item's would point to nowhere, since initial container of returnVector is already dead
}
В общем, проблема "висящих ссылок" кажется мелкой, но вездесущей. Когда идёшь по набитому тараканами подвалу, сложно не наступить ни на одного.
Я кстати не говорил, что предложенное решение хорошее. И таки оверхед у него будет поболе чем у shared_ptr.
А как вы предлагаете передавать объекты не "с потрохами"? Ссылки, из-за своей недвижимой природы, тоже не всегда подходят.
На самом деле, проблема более фундаментальна, чем просто подсчёт ссылок на обекты в куче. Умные указатели в реальном коде решат часть ваших проблем — но далеко не все, и далеко не все решённые проблемы будут из числа самых коварных.
Другими словами, у вас в качестве базовой операции выступает reduce, а также целая обвязка вокруг неё. Чем такой подход лучше простого поэлементного прохода по коллекции как базовой операции? Какие случаи можно (или значительно проще) записать на трансдьюсерах, но нельзя (значительно сложнее) на итераторах? Пока что я вижу, что трансдьюсеры:
требуют нетривиальную логику во вспомогательном коде
требуют более нетривиальной работы с пробросом состояния в рекурсивной манере
применяются к коллекциям точно также через обёртки
Или весь вопрос исключительно в получении функционального иммутабельного ленивого аналога итераторов без ленивых коллекций?
Я честно говоря так и не понял, чем это лучше Iterable, который гораздо понятней и для реализации поддержки в коллекции, и для построения полностью ленивых трансформаций поверх такой ленивой последовательности — в т.ч. reduce.
Это позволит отправить JavaScript на то место, для которого он и задумывался — анимировать снежинки и связывать компоненты на странице. Языки со статической типизацией начинают доминировать после определённого объёма проекта — динамику сложно анализировать и рефакторить.
Спасибо, я в принципе в курсе. По поводу рейнджей я наверное по инерции ною. Один чёрт во многие проекты их можно втянуть только как стороннюю библиотеку.
Я-то задачу решил — использовав обычный мэп. Я про то, что код нынешних реализаций STL крайне тяжело читать. Что является проблемой, когда надо выяснить подробности такого вот implementation-defined behavior. Которым пестрит половина стандарта.
Golang, Swift своим вполне себе успехом показывают, что много куда — было бы желание. И если Swift насаждается Apple как монополистом платформы, то Гофер хорошо выстрелил без такого "допинга". Любой успех начинается с малого. А если думать в терминах "куда же мы от Х", то так и будем ещё лет 10-20 с перераздутым стандартом, убогими iostreams и зета-функцией Римана.
P.S: Эх, где был нынешний bindgen и tokio два года назад...
А вот сейчас вы спорите не с тем человеком :) Ваш изначальный посыл был, что смарт-указатели решают эту проблему. Я вам отвечал, что есть целый пласт ситуаций, где не могут — поскольку отношение заимствования не может быть выражено в системе типов С++, но само заимствование присутствует повсеместно.
По моему опыту, данная проблема не может быть решена в компайл-тайме в рамках правил С++. Из-за того, что копирование, а не перемещение, первично, такой "трекинг" нельзя добавить в компилятор, не ломая всё.
Проблема в том, что в общем случае вы не знаете, куда потом денется
&s.Естественно, что на простых примерах всё очевидно. Менее простой пример (тоже искусственный, конечно) — инвалидация итераторов:
Ещё один пример (опять же псевдокод):
В общем, проблема "висящих ссылок" кажется мелкой, но вездесущей. Когда идёшь по набитому тараканами подвалу, сложно не наступить ни на одного.
На самом деле, проблема более фундаментальна, чем просто подсчёт ссылок на обекты в куче. Умные указатели в реальном коде решат часть ваших проблем — но далеко не все, и далеко не все решённые проблемы будут из числа самых коварных.
Сходу могу вспомнить 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. Которым пестрит половина стандарта.