Язык D - действительно красота и эффективность в одном флаконе - Философия программирования

Здравствуйте, Cyberax, Вы писали:

C>С чего бы контейнеры будут на стеке?? По факту, единственной оптимизацией в D по сравнению с Java является использование структур. Какие-либо сложные данные через них передавать нельзя — оверхед на копирование всё съедает.

А ссылки (константные/обычные) кто-то отменял? )

Ну и оверхед на сами данные в Java не стоит забывать. К примеру в D вся инстроспекция времени компиляции и т.п. Т.е. по этим параметрам D ближе именно к C/C++.

_>>Ну например вот такое http://rsdn.ru/forum/flame.comp/5159524.1 бывало.
C>Совершенно нерепрезентабельно, тест на скорость обращения к массивам.

Ну там не только скорость обращения к массивам, но да, действительно тест узкоспециализированный, как и указано в заголовке.

C>И это всё делает всю эту механику чуть менее, чем бесполезной. В Rust система типов гарантирует сегментированность данных между процессами, что делает возможным приватные мусоросборщики для задач, например. В D это невозможно, так как shared/immutable являются лишь хинтами и легко текут.

Ээээ, ну так не надо путать "отсутствие защиты" и "возможность пробить защиту". Это совершенно разные вещи. По умолчанию всё работает надёжно. Плюс для экспертов дана возможность обхода всех защит — типа можете заниматься этой чёрной магией на свой страх и риск. Это подход напрямую из C++, где тоже всё довольно строго, но при этом всегда есть путь обхода. Лично мне такой подход очень даже нравится.

_>>И модификатор immutable и индификатор shared являются транзитивными.
C>И как это отвечает на мой вопрос?

D. Mon уже ответил подробнее.

Здравствуйте, _NN_, Вы писали:

_NN>Например ненужность ужасного оператора ?: .
_NN>Обычный — if-else может быть выражением.

О, кстати, вот этот вот if else в Питоне весьма раздражает после привычки к ?:. Хотя это всё наверное дело вкуса.

Здравствуйте, Sinclair, Вы писали:

S>На самом деле — всё ещё интереснее. В этом коде x(), у(), и z() могут быть синхронными и асинхронными — по вкусу.
S>То есть я могу написать что-то типа requestStockQuotes().updateChart().alert('Done!')

Синхронность/асинхронность — это вообще не принципиально, как мы недавно выяснили в соседних темах. Вопрос лишь в построение цепочки. Это можно делать:
— в динамике (через указатели на функции) — элементарно реализуется
— в статике (с помощью МП, в Boost'e полно примеров) — уже чуть сложнее, но эффективнее и надёжнее
— с помощью сопрограмм — цепочки строятся вообще без усилий, но требуется создание некой минимальной инфраструктуры.

S>А можно показать эти "обычные способы" в студию? Ну, то есть чтобы я мог написать аналог на C++, при этом updateChart() — асинхронная, библиотечная; alert() — синхронная, библиотечная, а requestStockQuotes — это асинхронная, самописанная.

Да все серьёзные ООП оконные библиотеки по сути реализуют нечто подобное внутри себя.

S>Какой ещё инлайнинг в асинхронных вызовах?

Какая разница какой там вызов, если все вызываемые функции определены на момент компиляции? Именно за счёт инлайнинга тот же Boost.Spirit настолько летает. А там тоже строится некая цепочка исполнения и обычно посложнее, чем в коде выше. Правда по умолчанию он у нас синхронный, но мы уже видели насколько легко это исправляется. Причём это без переписывания кода. А если поставить цель изначально написать асинхронный Boost.Spirit, то можно такого наворотить... )))

_>>С помощью МП можно подобное записать в статике, так что всё заинлайнится.
S>Интересно было бы посмотреть. В JS это всё делается путём добавления ссылки на библиотеку.

Если есть готовая библиотека, то это в любом языке так делается.

А про пример см. предыдущий абзац.

Здравствуйте, alex_public, Вы писали:

S>>На самом деле — всё ещё интереснее. В этом коде x(), у(), и z() могут быть синхронными и асинхронными — по вкусу.
S>>То есть я могу написать что-то типа requestStockQuotes().updateChart().alert('Done!')

_>Синхронность/асинхронность — это вообще не принципиально, как мы недавно выяснили в соседних темах. Вопрос лишь в построение цепочки. Это можно делать:
_>- в динамике (через указатели на функции) — элементарно реализуется

точнее, эмулируется, поскольку нет некоторых нужных механизмов, которые я упоминал.

_>- в статике (с помощью МП, в Boost'e полно примеров) — уже чуть сложнее, но эффективнее и надёжнее

Ткни пальцем, где такое в бусте. Вот есть x(), он асинхронный, сигнатура у него содержит колбек. А надо вызвать так, как будто колбека нет и как будто это синхронный, а у возвращаемого значения, того что мвместо колбека, надо вызвать синхронный y() а него вызвать асинхронный z().

_>- с помощью сопрограмм — цепочки строятся вообще без усилий, но требуется создание некой минимальной инфраструктуры.

С помощью сопрограмм тебе надо как то ухитриться модифицировать поведение функции. Для простоты давай предположим, что доступа к коду асинхронной функции у тебя нет есть только её сигнатура. То есть, тебе надо намолотить кучку кода — взять да переписать.

S>>А можно показать эти "обычные способы" в студию? Ну, то есть чтобы я мог написать аналог на C++, при этом updateChart() — асинхронная, библиотечная; alert() — синхронная, библиотечная, а requestStockQuotes — это асинхронная, самописанная.

_>Да все серьёзные ООП оконные библиотеки по сути реализуют нечто подобное внутри себя.

Точнее ни одна из самых известных этого не делает.

S>>Какой ещё инлайнинг в асинхронных вызовах?

_>Какая разница какой там вызов, если все вызываемые функции определены на момент компиляции? Именно за счёт инлайнинга тот же Boost.Spirit настолько летает. А там тоже строится некая цепочка исполнения и обычно посложнее, чем в коде выше.

Руками-руками-руками-руками.

Неинтересно.

Вобщем нужен код.

В джаваскрипте скажем есть асинхронная функция

function x(succeed, error){ ... }

возвращает в succeed объект, у которого есть function y() {...} который возвращает объект у которого есть асинхронный function z(succeed, error);

все что нужно, это просто вызвать один единственный библиотечный метод:

var result = async().x().y().z();

Этот метод делает лифтинг по всей цепочке и всё работает само.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, _NN_, Вы писали:

_NN>>Например ненужность ужасного оператора ?: .
_NN>>Обычный — if-else может быть выражением.

_>О, кстати, вот этот вот if else в Питоне весьма раздражает после привычки к ?:. Хотя это всё наверное дело вкуса.

В питоне это немного другое.
Там синтаксис слегка непривычен: <then> if <cond> else <other> .
Но это потому как оригинальный if else ничего не возвращает.
Если бы он был изначально выражением, ничего вводить нового бы не пришлось.

Написать такое нельзя:

a = if True:
      1
    else:
      2

И из-за этого можно создавать переменные изнутри, хотя это конечно обход, а не решение.

if True:
  a = 1
else:
  a = 2

print(a)

Здравствуйте, Ikemefula, Вы писали:

I>Ткни пальцем, где такое в бусте. Вот есть x(), он асинхронный, сигнатура у него содержит колбек. А надо вызвать так, как будто колбека нет и как будто это синхронный, а у возвращаемого значения, того что мвместо колбека, надо вызвать синхронный y() а него вызвать асинхронный z().

Речь про организацию цепочек, а не про синхронность/асинхронность — с ней мы вроде как уже давно разобрались. А пример цепочки — ну вот тот же Boost.Spirit. Но не только он. В Boost'е вообще довольно много подобных техник встречается, без какого-то специального выделения этого нюанса. Я уже молчу про банальную реализацию продолжения в классе future (boost.thread), которая напрямую занимается такими вещами.

I>С помощью сопрограмм тебе надо как то ухитриться модифицировать поведение функции. Для простоты давай предположим, что доступа к коду асинхронной функции у тебя нет есть только её сигнатура. То есть, тебе надо намолотить кучку кода — взять да переписать.

Ээээ что? )

>>Какая разница какой там вызов, если все вызываемые функции определены на момент компиляции? Именно за счёт инлайнинга тот же Boost.Spirit настолько летает. А там тоже строится некая цепочка исполнения и обычно посложнее, чем в коде выше.
I>Руками-руками-руками-руками.
I>Неинтересно.

Ээээ а что у нас в Spirit'е руками? Вроде как задаёшь цепочку простейшим образом, а потом просто запускаешь. Где у нас там руками?

I>Вобщем нужен код.
I>...
I>Этот метод делает лифтинг по всей цепочке и всё работает само.

И? )

Здравствуйте, alex_public, Вы писали:

C>>С чего бы контейнеры будут на стеке?? По факту, единственной оптимизацией в D по сравнению с Java является использование структур. Какие-либо сложные данные через них передавать нельзя — оверхед на копирование всё съедает.
_>А ссылки (константные/обычные) кто-то отменял? )
И прямо всё будет в виде ссылок? Не верю. В том же vibe.d оно в виде объектов почти всё. Ну и как обычно — это небезопасно.

_>Ну и оверхед на сами данные в Java не стоит забывать. К примеру в D вся инстроспекция времени компиляции и т.п. Т.е. по этим параметрам D ближе именно к C/C++.
В Java интроспекция нужна, только если хочется.

C>>И это всё делает всю эту механику чуть менее, чем бесполезной. В Rust система типов гарантирует сегментированность данных между процессами, что делает возможным приватные мусоросборщики для задач, например. В D это невозможно, так как shared/immutable являются лишь хинтами и легко текут.
_>Ээээ, ну так не надо путать "отсутствие защиты" и "возможность пробить защиту". Это совершенно разные вещи. По умолчанию всё работает надёжно.
По умолчанию C и C++ работают полностью надёжно. Получается, что в D нет совершенно никаких жёстких гарантий.

_>Плюс для экспертов дана возможность обхода всех защит — типа можете заниматься этой чёрной магией на свой страх и риск.
Я уже привёл сценарий, когда всё ломается абсолютно штатными средствами. Наверняка есть и другие подобные.

Здравствуйте, alex_public, Вы писали:

_NN>>Например ненужность ужасного оператора ?: .
_NN>>Обычный — if-else может быть выражением.
_>О, кстати, вот этот вот if else в Питоне весьма раздражает после привычки к ?:. Хотя это всё наверное дело вкуса.
А мне как раз очень нравится — и читается естественно: "12 if something else 14". Как дополнительный плюс, границы выражения более понятны.

Здравствуйте, Cyberax, Вы писали:

C>И прямо всё будет в виде ссылок? Не верю. В том же vibe.d оно в виде объектов почти всё. Ну и как обычно — это небезопасно.

Ну так в C++ это вполне стандартная практика и как раз вполне безопасно. В D все подобные возможности так же имеются, так что при желание можно сохранить тот же стиль. А можно и другие пробовать...

C>В Java интроспекция нужна, только если хочется.

Эээ ты серьёзно считаешь, что java будет отжирать ровно столько же памяти, сколько C++/D при одинаковом коде?

C>По умолчанию C и C++ работают полностью надёжно. Получается, что в D нет совершенно никаких жёстких гарантий.

В D ровно тот же уровень гарантии (хотя разнообразия побольше), что и в C++.

C>Я уже привёл сценарий, когда всё ломается абсолютно штатными средствами. Наверняка есть и другие подобные.

Я же вроде чётко написал выше, что cast(immutable) — это совсем не штатное средство, а классическая чёрная магия, которую надо применять очень осторожно. Точно так же как и скажем reinterpret_cast в C++.

Здравствуйте, alex_public, Вы писали:

C>>И прямо всё будет в виде ссылок? Не верю. В том же vibe.d оно в виде объектов почти всё. Ну и как обычно — это небезопасно.
_>Ну так в C++ это вполне стандартная практика и как раз вполне безопасно. В D все подобные возможности так же имеются, так что при желание можно сохранить тот же стиль. А можно и другие пробовать...
В С++ это приводит к тому, что многопоточный код в стиле Erlang'а почти никто не пишет.

C>>В Java интроспекция нужна, только если хочется.
_>Эээ ты серьёзно считаешь, что java будет отжирать ровно столько же памяти, сколько C++/D при одинаковом коде?
По сравнению с D — да. При правильных настройках. Обычно в Java предпочитают использовать большой размер кучи сразу, из-за чего кажется, что она сжирает кучу памяти зря.

C>>По умолчанию C и C++ работают полностью надёжно. Получается, что в D нет совершенно никаких жёстких гарантий.
_>В D ровно тот же уровень гарантии (хотя разнообразия побольше), что и в C++.
Ну то есть, совершенно никакого.

C>>Я уже привёл сценарий, когда всё ломается абсолютно штатными средствами. Наверняка есть и другие подобные.
_>Я же вроде чётко написал выше, что cast(immutable) — это совсем не штатное средство, а классическая чёрная магия, которую надо применять очень осторожно. Точно так же как и скажем reinterpret_cast в C++.
Вот тут пример вообще без кастов: http://rsdn.ru/forum/philosophy/5559913?tree=tree

Причина всё та же — immutable в D сделан топорно. В частности, нет контролируемой возможности его снять.

Здравствуйте, alex_public, Вы писали:

_>Речь про организацию цепочек, а не про синхронность/асинхронность — с ней мы вроде как уже давно разобрались. А пример цепочки — ну вот тот же Boost.Spirit. Но не только он. В Boost'е вообще довольно много подобных техник встречается, без какого-то специального выделения этого нюанса. Я уже молчу про банальную реализацию продолжения в классе future (boost.thread), которая напрямую занимается такими вещами.

ля-ля-ля. Была конкретная задача и снова как дошло дело до решения, у тебя общие слова.

Вещи про которые мы говорим в бусте отсутствуют. Нет там никаких способов превратить апи с одной сигнатурой в другую, смотри сам
http://braddock.com/~braddock/future/

I>>С помощью сопрограмм тебе надо как то ухитриться модифицировать поведение функции. Для простоты давай предположим, что доступа к коду асинхронной функции у тебя нет есть только её сигнатура. То есть, тебе надо намолотить кучку кода — взять да переписать.

_>Ээээ что? )

Да-да. Фраза "Ээээ что? )" в прошлые месяцы появлялась именно там, где тебе нечего было сказать Для простоты представим, что у функция такая

void getDocument(Callback<Document> cnt, Callback<Error> errCnt);

а вызвать её надо так, как будто она максимально близко похожа на свой синхронный вариант:

Document getDocument() throws Error;

Ну например

Promise<Document> getDocument();

Валяй, показывай чудеса метапрограммирования — одной строчкой подключил либу и всё палит само. Ручное написание всех сортов врапперов и тд оставь детям. Короче, покажи, наконец "тривиально реализуется обычными способами".

I>>Неинтересно.

_>Ээээ а что у нас в Spirit'е руками? Вроде как задаёшь цепочку простейшим образом, а потом просто запускаешь. Где у нас там руками?

См выше. От тебя нужно показать чудеса метапрограммирования.

I>>Этот метод делает лифтинг по всей цепочке и всё работает само.

_>И? )

Ты утверждал, "для реализации подобного метапрограммирование не требуется. Это тривиально реализуется обычными способами"

Похоже, как дошло дело до "обычных способов", так в ход сразу пошли "И? )", "Ээээ что? )", "в бусте всё есть" и тд

Здравствуйте, alex_public, Вы писали:

_>Я же вроде чётко написал выше, что cast(immutable) — это совсем не штатное средство, а классическая чёрная магия, которую надо применять очень осторожно. Точно так же как и скажем reinterpret_cast в C++.
Кстати, меня смущает такой момент, что в С++ разные виды кастов и случайно сделать не то, что надо сложнее, чем с одним кастом. На практике в D с этим не возникает проблем?

Здравствуйте, alex_public, Вы писали:

_>Синхронность/асинхронность — это вообще не принципиально, как мы недавно выяснили в соседних темах.
О, а можно ссылки на эти темы?
А то я только что наткнулся на .whenAll, .then и прочие примитивы, популярные в JS-фреймворках, и до сих пор под впечатлением.
Чтобы наколбасить хоть что-то подобное на С++ у меня тупо не хватит квалификации.

_>Да все серьёзные ООП оконные библиотеки по сути реализуют нечто подобное внутри себя.
Впервые об этом слышу. Вся "асинхронность" в известных мне "серъёзных ООП оконных библиотеках" сводится к аналогам postThreadMessage.

S>>Какой ещё инлайнинг в асинхронных вызовах?
_>Какая разница какой там вызов, если все вызываемые функции определены на момент компиляции?
Эмм... Я, наверное, тупой. Но я совершенно себе не представляю, что и куда можно заинлайнить в случае, когда две "функции" вызываются одновременно. Ну, то есть под капотом там, понятное дело, что-то вроде queueUserWorkItem, а ниже — или пул потоков, или кооперативная многозадачность, или IOCP — по вкусу.

Именно за счёт инлайнинга тот же Boost.Spirit настолько летает. А там тоже строится некая цепочка исполнения и обычно посложнее, чем в коде выше. Правда по умолчанию он у нас синхронный, но мы уже видели насколько легко это исправляется.
А, это вы наверное сейчас про переписывание активного кода в реактивный. Ну, может быть это и можно свернуть в асинхронный код; хотя по моему опыту это ещё немножно сложнее.

_>Если есть готовая библиотека, то это в любом языке так делается.

А про пример см. предыдущий абзац.
Ну, то есть нету ничего опять. Только обещания написать "если поставить целью".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, alex_public, Вы писали:

_>>Синхронность/асинхронность — это вообще не принципиально, как мы недавно выяснили в соседних темах.
S>О, а можно ссылки на эти темы?

Это та самая тема, которая началась ажно в начале декабря и тянется до сих пор. Он имеет ввиду преобразование энергичного в ленивый код при помощи stackfull короутин. Типа, подменил ты stream, на тот, который унутре будет переключать короутины, так сразу getLine() станет асинхронной и консольное приложение вдруг превратится из жабы в прынца

S>А то я только что наткнулся на .whenAll, .then и прочие примитивы, популярные в JS-фреймворках, и до сих пор под впечатлением.
S>Чтобы наколбасить хоть что-то подобное на С++ у меня тупо не хватит квалификации.

js он однопоточный, отсюда простая либа промисов это пару килобайт кода. Но вообще промисы пишет наверное каждый второй

Если интересно такое, то вот, наиболее полная либа https://github.com/petkaantonov/bluebird.git, здесь даже есть реализация навроде async/await для Harmony, через евойный yield

Здравствуйте, Cyberax, Вы писали:

C>В С++ это приводит к тому, что многопоточный код в стиле Erlang'а почти никто не пишет.

Хм, я очень часто использую разные вариации на тему модели акторов. И кстати даже работа через всякие ссылки/указатели совсем не противоречит этой модели — достаточно установить определённые правила игры. В варианте со встроенной реализацией этой модели (как в Эрланге или в D) эти правила просто ещё и жёстко контролируются компилятором.

C>По сравнению с D — да. При правильных настройках. Обычно в Java предпочитают использовать большой размер кучи сразу, из-за чего кажется, что она сжирает кучу памяти зря.

Нет, речь не о преаллокации, а о количестве выделяемой памяти в расчёте на 1 байт реальных данных. У java там всё довольно печально. Вот например помнится были такие https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf измерения...

Что касается D, то они полностью используют выделение памяти в стиле C++ (хотя бы уже потому, что в D полноценно реализована арифметика указателей, со всеми вытекающими последствиями), даже если и используется GC.

C>Вот тут пример вообще без кастов: http://rsdn.ru/forum/philosophy/5559913?tree=tree

Хы, ну это да, модный баг с конструктором)

C>Причина всё та же — immutable в D сделан топорно. В частности, нет контролируемой возможности его снять.

Снимать immutable — это вообще выглядит ненормально. Я ещё понимаю снятие shared...

Здравствуйте, alex_public, Вы писали:

_>Нет, речь не о преаллокации, а о количестве выделяемой памяти в расчёте на 1 байт реальных данных. У java там всё довольно печально. Вот например помнится были такие https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf измерения...
Что значит памяти на 1 байт? Заголовок объектов в Java — это нынче 16 байт. Если объект большой, то это непринципиально.

У Boehm GC оверхед 8 байт. Чуть меньше, но уже не принципиально.

_>Что касается D, то они полностью используют выделение памяти в стиле C++ (хотя бы уже потому, что в D полноценно реализована арифметика указателей, со всеми вытекающими последствиями), даже если и используется GC.
D без GC никому не нужен.

C>>Причина всё та же — immutable в D сделан топорно. В частности, нет контролируемой возможности его снять.
_>Снимать immutable — это вообще выглядит ненормально. Я ещё понимаю снятие shared...
Точнее, наоборот — нет возможности сделать граф объектов и после этого работать с ним как с immutable. В Rust — именно это гениальный штрих.

Здравствуйте, Ikemefula, Вы писали:

I>ля-ля-ля. Была конкретная задача и снова как дошло дело до решения, у тебя общие слова.

Я могу без проблем накидать велосипед на коленке, решающий ту твою задачку в динамике (указатели на функции и т.п.). Если посидеть дольше (уже лень), то можно накидать подобное и в статике, в стиле boost.spirit'a. Но это всё имеет смысл, только если доказывать что-то действительно необычное (как было например в темке про async или например полноценные монады/лифтинг на C++). А тут мне кажется каждому очевидно, что такие вещи пишутся без проблем. В конце концов колбеки и паттерн стратегия — это одни из самых стандартных приёмов.

I>Вещи про которые мы говорим в бусте отсутствуют. Нет там никаких способов превратить апи с одной сигнатурой в другую, смотри сам
I>http://braddock.com/~braddock/future/

Ты вообще о чём?)

I>

I>void getDocument(Callback<Document> cnt, Callback<Error> errCnt);
I>

I>а вызвать её надо так, как будто она максимально близко похожа на свой синхронный вариант:
I>

I>Document getDocument() throws Error;
I>

I>Ну например

I>

I>Promise<Document> getDocument();
I>

I>Валяй, показывай чудеса метапрограммирования — одной строчкой подключил либу и всё палит само. Ручное написание всех сортов врапперов и тд оставь детям. Короче, покажи, наконец "тривиально реализуется обычными способами".

Ты тут путаешь разные вещи. Давай я перечислю все возможные варианты, а ты укажешь что ты конкретно хочешь. Значит имея подобный асинхронный api можно использовать его следующими способами:

1. Собственно асинхронный вызов (обработка результатов происходит в контексте вызывающего). Т.е. код у нас будет вида:

getDocument([](Document d){
    process(d);
}, [](int code){
    error(code);
});

Кстати, замечу, что в том же JS как раз наиболее популярен именно этот вариант.

2. Сделать из асинхронного вызова синхронный. Т.е. код вида:

promise<Document> p;
auto f=p.get_future();
getDocument([&](Document d){
    p.set_value(d);
}, [&](int code){
    p.set_exception(exception(code));
});//весь код выше можно преобразовать в красивый вариант вида auto f=sync(getDocument);
process(f.get());//в get имеем блокировку

3. Асинхронный вызов с продолжением. Т.е. что-то вроде:

promise<Document> p;
auto f=p.get_future();
getDocument([&](Document d){
    p.set_value(d);
}, [&](int code){
    p.set_exception(exception(code));
});//опять же можно упрятать весь код выше в функцию
f.then([](future<Document> d){
    process(d.get());
    return to_string(d.get());
}).then([](future<string> s){
    cout<<s.get();
});

Как видно, здесь можно образовывать цепочки исполнения произвольной длины.

4. Асинхронный код, выглядящий как синхронный. Такое уже делается только с помощью сопрограмм и мы подробно разбирали подобный код. Он выглядит (изнутри — понятно, что при нормальном использование мы маскируем все эти вещи в удобные макросы) приблизительно так:

coroutine __c([](){//маскируем под что-то типа ASYNC(...) - выделение блока асинхронного кода
Document doc;
int __error=0;
getDocument([&](Document d){
    doc=d;
    __c.go();
}, [&](int code){
    __error=code;
    __c.go();
});
__c.break();
if(__code) throw exception(__code);//маскируем весь кусок досюда под что-то типа Document doc=await_async(getDocument);
process(doc);
});

Кстати, в том же JS я что-то не помню реализации чего-то подобного...

Да, ну и так с реализацией какого из этих 4-ёх вариантов у тебя есть какие-то вопросы?

I>Ты утверждал, "для реализации подобного метапрограммирование не требуется. Это тривиально реализуется обычными способами"

Ну да. А что, есть сомнения? )

Здравствуйте, DarkEld3r, Вы писали:

DE>Кстати, меня смущает такой момент, что в С++ разные виды кастов и случайно сделать не то, что надо сложнее, чем с одним кастом. На практике в D с этим не возникает проблем?

Даже не знаю что сказать, т.к. вообще не помню у нас в коде явных кастов. Кстати, для конвертаций типов в стандартной библиотеке D (std.conv) есть любопытное семейство шаблонных функций to.

Здравствуйте, Sinclair, Вы писали:

S>О, а можно ссылки на эти темы?
S>А то я только что наткнулся на .whenAll, .then и прочие примитивы, популярные в JS-фреймворках, и до сих пор под впечатлением.
S>Чтобы наколбасить хоть что-то подобное на С++ у меня тупо не хватит квалификации.

Если говорить про просто классический then, то на это можно взглянуть даже в том же boost.thread.

А в тех темках мы обсуждали более сложные вещи, типа реализации асинхронного кода, выглядящего как синхронный (типа await/async в C#). Началось это с подобных http://www.rsdn.ru/forum/philosophy/5208679.flat#5208679 заявлений и продолжилось дальше страниц на 40. ))) В принципе моё суммарное мнение по данному вопросу можно прочитать здесь http://www.rsdn.ru/forum/philosophy/5218472, а пример кода увидеть здесь http://www.rsdn.ru/forum/philosophy/5219345.

_>>Да все серьёзные ООП оконные библиотеки по сути реализуют нечто подобное внутри себя.
S>Впервые об этом слышу. Вся "асинхронность" в известных мне "серъёзных ООП оконных библиотеках" сводится к аналогам postThreadMessage.

Я про другое. Т.к. во всех подобных библиотеках цикл обработки сообщений скрыт внутри неё (не говоря уже о прямых вызовах оконной функции и т.п.), то внешне обработка сообщений с помощью такой библиотеки напоминает именно реакцию на некие асинхронные вызовы.

S>Эмм... Я, наверное, тупой. Но я совершенно себе не представляю, что и куда можно заинлайнить в случае, когда две "функции" вызываются одновременно. Ну, то есть под капотом там, понятное дело, что-то вроде queueUserWorkItem, а ниже — или пул потоков, или кооперативная многозадачность, или IOCP — по вкусу.

Инлайнятся цепочки исполнения, которые следуют за асинхронными вызовами.

S>Ну, то есть нету ничего опять. Только обещания написать "если поставить целью".

А что конкретно надо то? ) Я пока не видел чётких запросов. )

	От:	alex_public
	Дата:	22.04.14 08:37
	Оценка:

	От:	alex_public
	Дата:	22.04.14 08:40
	Оценка:

	От:	alex_public
	Дата:	22.04.14 09:03
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.04.14 10:35
Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	22.04.14 11:32
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.04.14 10:32
Оценка: