Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

K>Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>Опять 25. Почему они не работающие? Они работают даже для ресурсов в отличии от.

K>Потом, что доступность не гарантируют. И для дефицитных ресурсов доступность - это как раз то, чем можно пожертвовать ради закрытия по завершению использования.

EP>>На C++ есть всякие DSL библиотеки, позволяющие писать высокоуровневый, который отлично мэппятся в железо. Например Eigen может во время компиляции выбрать оптимальный путь вычисления матричного выражения, и автоматически векторизовать.

K>Это пример куда лучше, но, тем не менее, числодробление не особенно высокоуровнево.

EP>>Опять-таки высокоуровневый != огромное penalty.

K>Это, конечно, верно. Однако подход высокоуровневого языка заключается в том, чтоб дать широкий набор инструментов, в том числе и таких, где penalty неизбежно, однако постараться минимизировать это "огромное penalty". Ну а подход "вот тут мы можем как-то обойтись без огромного penalty, значит это у нас будет - вот это - нет." - это подход низкоуровневого языка.

EP>>В большинстве кода не то что shared_ptr нет, а даже unique_ptr.

K>В большинстве низкоуровневого кода - да, в большинстве идиоматического ФП-кода - нет.

EP>>Где вычисляется то что ненужно?

K>В примере "монадизации" на D, например.

EP>>Выводы на основе ложных утверждений. Далеко не все абстракции дорогие.

K>Но многие абстракции, востребованные для написания ФП кода как раз дорогие.

K>>>Поэтому никакого высокоуровневого кода и нет - есть только продвинутый интерфейс для двигания указателей. А поддержка высокоуровневых инструментов ограничивается заявлениями о их ненужности.
EP>>См. Eigen.

K>Смотрим. То, что не использовано для написания Eigen - не нужно?

EP>>Да - это именно то решение, которое вы описали для UFP с ресурсами: "ненужно, поэтому запретить".

K>[url=http://rsdn.ru/forum/philosophy/5441274.1]См. здесь[/url]

EP>>1. Какую abstraction penalty вносит указатель сам по себе?

K>Указатель - это абстракция "плоская память произвольного доступа", если мы не "проделаем в ней дыру" и не станем учитывать иерархию памяти и прочее, от чего она нас вроде бы должна абстрагировать - мы будем биться об стену памяти, например. Вот такая вот penalty.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail