Facebook платит за устранение багов в реализации языка программирования D

Ну.. Там нет классов.

Понятно, спасибо за обьяснение.

ХЗ, я пока боюсь Rust в реальных рабочих проектах применять.

Они пока, наверное, даже и сами не рекомендуют? (:

Правильно я понимаю, что сначала всем элементам массива присваивается значение 0.1? А вместе с инициализацией это проделать нельзя? Как-то так, например?

Вроде бы нельзя. Хотя вопрос хороший, надо посмотреть. Смысл там больше в следующей строчке: массив знает своб длину, она обозначается внутри него как $. Ну и конечно, можно делать такие штуки:

real[] a = new real[10];
real[] b = a.dup;
b[] += 12.5
real[] c = new real[2*a.length];
c[0 .. $/4] = a[0 .. $/2] + b[$/2 .. $]^^-0.5;

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

double[] arr = uninitializedArray!(double[])(100);
arr[] = 0.1;

Откройте для себя std::vector, умеющий все это и многое другое, а так же совместимый со всеми сишными либами.

Спасибо за ссылку, сходил и просветился. Немного мене удобно, но сойдёт. Вопрос такой: где достать быстрое Фурье преобразование, работающее с 128 bit floating point?

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

Он-то как раз хотел инициализировать его в одной строчке, чтобы не нужно было писать

arr[] = 0.1;

При необходимости можно и на D извращаться:

import std.stdio: writeln;
import std.array: uninitializedArray;

void main()
{
	double[] arr = uninitializedArray!(double[])(5);
	arr.writeln;
	arr[] = 0.1;
	arr.writeln;
	auto arr2 = (uninitializedArray!(double[])(5)[] = 0.2);
	arr2.writeln;
	return;
}

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

Вот это здорово, что они такое предусмотрели.

И такой подход нравится. В смысле по умолчанию «просто и безопасно», но с возможностью выжать побольше производительности по необходимости.

Вообще про работу с массивами, слайсы, $ и т.д. немного читал, но не до всего ещё добрался.

И уж точно такие конструкции не нужны в реальной работе - язык разработан чтобы избежать подобного.

Реальная работа - она разная бывает...

Тем более, что возможности есть, хотелось бы понять как их правильно применять. Да и интересовали меня не только указатели (кастовать ведь не только их можно), а и строки, например.

приложение действительно падает при попытке собрать код помеченный undefined behaviour,

Ну меня просто смутила логика - можно написать код, который заведомо (всегда?) неправильный. Ведь можно не давать такое компилировать.

На всякий случай, уточню - в С++ есть отдельный конст_каст, другими (ну кроме сишного, конечно) константность убрать нельзя. И при использовании надо четко понимать реально ли константные данные или нет. Такая проблема может возникать из-за несовершенного апи и язык даёт возможность это неудобство обойти. Если в документации просто неправильно выразились и правила такие же, то никаких претензий нет, просто хочу это понять.

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

Цели подловить нет, но куда-то «идти» лень, если честно. Тем более, что есть подозрение, что по мере изучения вопросы сами отпадут (но интереснее их прояснить сразу).

Я бы попробовал вам помочь, но не понял, честно говоря, где там код на D?

Везде, где не указано, что это С/С++. (:

Для преобразования типов нужно пользоваться to! из std.typecons

А cast зачем?

Есть еще minimallyInitializedArray - инициализирует указатели, ссылки и слайсы, остальное оставляет неинициализированным - для безопасности. Кстати по вопросу о константности указателей, что ты задавал ранее, дополню, что const в D транзитивен (как и immutable). Ты не сможешь ничего изменить через константный указатель, в этом отличие от плюсов.

Ты не сможешь ничего изменить через константный указатель, в этом отличие от плюсов.

В смысле? В С++ нельзя изменить ничего через указатель на константный объект. Нужно же различать изменение указателя от изменения объекта, на который указывает указатель.

int *
const int *
int * const
const int * const

Это все разные случаи. Как они будут выглядеть в D?

На всякий случай, уточню - в С++ есть отдельный конст_каст, другими (ну кроме сишного, конечно) константность убрать нельзя. И при использовании надо четко понимать реально ли константные данные или нет. Такая проблема может возникать из-за несовершенного апи и язык даёт возможность это неудобство обойти. Если в документации просто неправильно выразились и правила такие же, то никаких претензий нет, просто хочу это понять.

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

Цели подловить нет, но куда-то «идти» лень, если честно. Тем более, что есть подозрение, что по мере изучения вопросы сами отпадут (но интереснее их прояснить сразу).

Прекрасно понимаю, именно поэтому стараюсь избегать отвечать на вопросы - потому что человеку все равно недостаточно интересно.

В D примерно то же самое.

Эм. В C++ static_cast, dynamic_cast, const_cast и reinterpret_cast. И все для разных случаев. В D же вроде только один cast.

Функция to из std.typecons является безопасной, она проверяет типы при преобразовании, например. А каст - он же голый каст. В debug режиме я использую to, а в release - cast, если нет возможности обойтись без него.

Я же говорю - константный указатель, а не указатель на константный объект. Если константный указатель указывает на мутабельный объект, компилятор не даст изменить значение этого мутабельного объекта через этот константный указатель.

const(int)* ptr1; // mutable ptr to const int
const(int*) ptr2; // const ptr to mutable int

// mutable ptr to mutable int
int * = int* 
// mutable ptr to const int
const int * = const(int)* 
// const ptr to mutable int
int * const = const(int*) == const int*  
// const ptr to const int == const ptr to mutable int
const int * const = const(const(int)*) == const int*  

В обоих случаях компилятор не даст изменить содержимое указателей

Почему/зачем так сделали?

Эм. В C++ static_cast, dynamic_cast, const_cast и reinterpret_cast. И все для разных случаев. В D же вроде только один cast.

Один. Он просто на все руки мастер и его хватает одного. :)

Он просто на все руки мастер и его хватает одного.

Ага, как сишный. Плохое решение, ИМХО.

Это вытекает из системы типов, в частности наличия квалификатора immutable. Для immutable транзитивность очевидна по определению - никакая переменная с данным квалификатором не может содержать mutable данных. Но immutable слишком строгий квалификатор и чтобы сделать мостик между функциональным кодом и императивным const сделали тоже транзитивным. Фактически const(T) является супертипом для T и immutable(T) - переменная типа const(T) может принимать значения и T, и immutable(T). Но раз она может принимать значения immutable(T), значит и const(T) не может содержать мутабельных данных, иначе это нарушит гарантии immutable. Immutable вообще интересная концепция, но требует затрат на оценку.

immutable-данные сейчас модная концепция. Я вот только не вижу связи с разговором об указателях. Почему не может существовать immutable-указатель на изменяемые данные? Указатель - это совершенно самостоятельный объект со своим типом, он никак напрямую логически не связан с объектом, на который указывает. И с const тут ситуация та же самое. Т.е. если бы указатели были не встроенными типами, то по-моему было бы вполне логично отличать Ptr<int>, const Ptr<int>, Ptr<const int>, const Ptr<const int>

Вполне возможно что ты прав, я испытывал некоторые проблемы с cast, в частности с удалением квалификаторов, которое делается просто без указания аргументов, но там есть некоторые «но» - и на мой взгляд эти скрытые «но», которые надо знать не вписываются в концепцию языка как удобного средства. Хотя возможно у меня просто кривые руки. Но должен признаться, что было это один раз и вообще я стараюсь избегать cast().

Ну тут тебе нужно понять концепцию immutable. Она на самом деле не просто модная штука, а очень полезная вещь. И тогда все станет понятно.

immutable значит неизменяемое на всем протяжении программы (на самом деле - до тех пор, пока на эти данные кто-то ссылается, тут и выходит на сцену сборщик мусора). Если ты объявляешь immutable указатель, то делаешь immutable и все его содержимое. Это позволяет использовать функциональный стиль, а также передавать данные между потоками безопасно и без каких-либо затрат - ты просто передаешь указатель на эти данные в другой поток и не заботишься о синхронизации, потому что данные неизменямые. Но я вот пишу и понимаю, что не могу это объяснить доходчиво, к сожалению. :(

Ну тут тебе нужно понять концепцию immutable

Я пользуюсь immutable-данными в других языках. С чего ты взял, что я не понимаю? Просто вопрос про указатели ортогонален.

Если ты объявляешь immutable указатель, то делаешь immutable и все его содержимое.

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

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

Эм. Этого можно достигнуть и без описанного тобой правила.

Эм. Этого можно достигнуть и без описанного тобой правила.

Как?

Мне нужна была высокая точность вычислений. D поддерживает 128-битные действительные числа... Я написал программу и посчитал нужный мне результат, мы написали статью...

Большое спасибо. Вот это действительно мне интересно. И, как я понимаю, согласуется с тем, что я писал про области применения D — как раз расчеты и вычисления, где требуются возможности языка, а не наличие сторонних библиотек.

Есть ещё какие-либо варианты? C/C++ не хочу, это очень не удобно работать с массивами, которые понятия не имеют о собственной длине и которые нужно руками удалять.

C++ зря не рассматриваете. Есть std::vector, std::array вместо ручного управления памятью. 128-битовые вещественные числа, судя по информации в Инете, поддерживаются в GCC и Intel. Есть библиотеки для такой арифметики:

http://www.boost.org/doc/libs/1_54_0/libs/multiprecision/doc/html/boost_multi...

http://www.nongnu.org/hpalib/

http://gcc.gnu.org/onlinedocs/libquadmath/

Для распараллеливания вычислений можно задействовать как OpenMP, так и возможности C++11.

На этапе прототипирования вы можете писать так:

А в финальной реализации вы можете написать так:

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

В этом смысле сейчас в тяжелой ситуации разве что Java-разработчики оказываются, им действительно приходится писать много тупого кода. Но вот уже в Scala или даже в C# все уже гораздо получше.

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

Для организации message passing между нитями это оказалось далеко не всегда удобно. Если объект-сообщения объявляется иммутабельным (что естественно), то автоматически иммутабельными становятся все ссылки, которые находятся в сообщении. Т.е. если сообщение передает ссылку на массив чисел для обсчета, то это нормально. А вот передать в иммутабельном сообщении ссылку на объект (например, логгер), у которого затем нужно вызывать немутабельные методы, то все, уже не получится.

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

Я пользуюсь immutable-данными в других языках

Далеко не во всех языках immutability транзитивна.

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

Опять же, «транзитивность».

Преимущество подобного подхода прежде всего в том, что «immutable is implicitly shared» и, следовательно, корректная многопоточная работа с такими данными гарантирована на уровне системы типов. Это тесно связано с тем, что все типы данных по умолчанию - thread-local non-shared.

Стоит ли игра свеч - пока не ясно.

А вот передать в иммутабельном сообщении ссылку на объект (например, логгер), у которого затем нужно вызывать немутабельные методы

Плохая идея.

А как правило распространения квалификатора указателя на объект связано с подобным подходом и вообще смыслом этого квалификатора?

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

Проблема в том, что на самом деле любая подобная изменяемая ссылка / «логическая» константность - это потенциальный многопоточный баг, причём очень неприятного характера. D просто переносит необходимость подумать об этом на этап проектирования, а не этап отладки.

Что хреново с иммутабельными объектами в D, так что это, что несмотря на маркетинг, они на данный момент не работают с std.concurrency

Еще раз, преимущества immutable данных понятны. Непонятно, зачем хардкодить, что immutable указатели указывают на immutable-данные.

Проблема в том, что на самом деле любая подобная изменяемая ссылка

Ссылка не изменяемая. Ссылка должна быть на немутабельный объект. Представьте, что у вас многопоточное приложение, взаимодействие между нитями в котором идет на объеме сообщениями. И вы рассылаете сообщение о том, что с этого момента должен использоваться вот такой вот логгер.

Или в этом приложении обработка данных построена на стадиях, каждая стадия — это отдельная нить. На первой стадии создается некий объект (например, описание заказа), ссылка на этот объект передается следующей стадии, которая вычисляет комиссию по заказу и модифицирует объект заказа, после чего передает ссылку на него дальше. Следующая стадия вычисляет бонус для заказа и так же модифицирует объект. И т.д. и т.п. Т.е. объект в конкретный момент времени находится в распоряжении всего одной нити. Но он не константный. А ссылку на него нужно передавать в иммутабельном объекте-сообщении.

В C++ такое делается запросто. А в D, с его специально предназначенной для многопоточности «вирусной» иммутабельностью, не получается.

Спасибо. OpenMP знаю, использовал в Фортране, хорошая штука. GCC действительно поддерживает 128 разрядную арифметику, но встреченные мною библиотеки Фурье преобразования типа fftw3 и линейной алгебры типа lapack пока не могут с ними работать, т.е. придётся писать самому. Максимум на что можно рассчитывать --- встроенные спецфункции, и то они больше в Фортране.

Посмотрел на std::vector, штука неплохая. Хотя до удобства пользования теми же фортрановскими массивами не дотягивает сильно.

Какое оборудование используете для 128 разрядных вещественных вычислений? Или это эмуляция?

Какое оборудование используете для 128 разрядных вещественных вычислений? Или это эмуляция?

Процессоры x86, начиная с Phenom, кажется, уже имеют нативный 128-битный FPU. (У Core 2 Duo ещё был 80-битный) У нас конкретно Bulldozer FX-8150 стоит.

AVX ?

AVX ?

AVX там есть, первого поколения. Но AVX это же в первую очередь векторные инструкции с целыми числами средствами FMAC. Меня же интересовали чисто FPU вычисления.

FPU везде 80-ти битный. По моему Вы что-то путаете. SSE и AVX работают с вещественными числами. С целыми работает mmx.

ссылку на него нужно передавать в иммутабельном объекте-сообщении.

Зачем? Иммутабельность нужна объектам, одновременно доступным из разных нитей, что явно не относится к объекту-сообщению.

Иммутабельность нужна объектам, одновременно доступным из разных нитей, что явно не относится к объекту-сообщению.

Когда у сообщения более одного получателя, то еще как относится.

FPU везде 80-ти битный. По моему Вы что-то путаете. SSE и AVX работают с вещественными числами.

Что-то я путать могу легко. Насколько я понимаю, сейчас 128 бит делаются за счёт double-double эмуляции. И действительно используются, кажется, SSE3 или, может быть, SSSE3. Но для этого нужно, чтобы физически был 128-ный FPU, потому что на старом 80-битном всё это будет ужас как долго работать.

Ссылка не изменяемая. Ссылка должна быть на немутабельный объект.

Транзитивно изменяемая. В контексте D говорить о любом другое типе (не)изменяемости бессмысленно.

Так вот, в приведённом примере абсолютно непонятно, зачем immutable вообще нужен. Передаваемый объект изменяется, следовательно, объекту-сообщению тоже вполне хватит shared. У него могут быть дополнительные поля, ссылку на которые хочется сохранить - вот их отдельно можно объявить как immutable. А само сообщение - зачем? Это типичное использование инструмента в целях, для которых он не предназначен. Объявлять такое в С++ как const - только вводить в заблуждение.

Семантика «только эта нить имеет доступ к модификации» реализована через квалификатор shared, immutable тут ни при чём.

Еще раз, преимущества immutable данных понятны. Непонятно, зачем хардкодить, что immutable указатели указывают на immutable-данные.

Потому что immutable подразумевает shared. А транзитивность shared необходима для гарантии многопоточной корректности системой типов - иначе можно было бы получить ссылку на разделемый объект так, как будто бы он был локальным.

А само сообщение - зачем? Это типичное использование инструмента в целях, для которых он не предназначен.

1. Если вы не понимаете, зачем что-то нужно конкретному разработчику, это не значит, что разработчик не прав. Судя по вашим сообщениям вероятнее, что вы не разбираетесь в некоторых вещах.

2. Если язык не позволяет разработчику достичь того, что ему нужно (и что возможно в других языках), то язык идет куда подальше, вместе с его пропагандаторами.

Теперь пояснение на пальцах для «LOR-экспертов».

Есть объект-сообщение, который должен должен быть доставлен получателям. Получатели могут работать на разных нитях, обработка экземпляра объекта-сообщения может происходить параллельно. Всем получателям должен придти один и тот же экземпляр сообщения, клонировать сообщения, чтобы в каждой нити был собственный экземпляр, слишком накладно. Защищать экземпляр сообщения синхронизирующими объектами, при доступе к нему на рабочих нитях, так же слишком накладно. В итоге, к получателям приходит ссылка на объект. Очень желательно на уровне языка запретить изменение объекта по ссылке. Чтобы гарантировать получателям, что никто не изменит объект, пока они с ним работают.

В качестве иллюстраций приведу примеры кода на C++, чтобы не путаться в синтаксисе D.

Итак, пусть есть сообщение о каком-то событии в приложении. Его будут обрабатывать несколько получателей. Один будет сохранять его в log-файле. Второй будет проверять наличие в сообщении каких-то ключевых слов и делать что-то. Третий будет подсчитывать интенсивность сообщений такого рода. И т.д. и т.п.

Само сообщение:

struct log_message {
  // Кто инициировал сообщение.
  std::string sender;
  // Тип события, связанный с сообщением.
  std::string action;
  // Описание события.
  std::string description;
  ...
};

Разные типы обработчиков сообщения. Каждый работает на своей рабочей нити:

class logger {
  public :
    void on_log_message( const log_message & msg ) {
      // Запись сообщения в журнал.
      ...
    }
};

class message_analyzer {
  public :
    void on_log_message( const log_message & msg ) {
      // Анализ содержимого сообщения.
      ...
    }
};

class event_statistic_collector {
  public :
    void on_log_message( const log_message & msg ) {
      // Обновление статистики на основе данных в сообщении.
      ...
    }
};

Здесь язык гарантирует, что ни в одном из показанных выше обработчиков нельзя просто взять и написать: msg.action = "WTF?", компилятор даст по рукам. И это позволяет на разных нитях обрабатывать объект-сообщения без синхронизации доступа к нему.

Именно поэтому сам объект-сообщения должен быть иммутабельным. И это должно гарантироваться средствами языка. Вот в Java или C# таких гарантий нельзя получить в принципе.

Но в некоторых случаях сообщения должны содержать в себе ссылки на мутабельные объекты. Примеры я уже приводил. Если для таких случаев нужно уметь передавать между получателями ссылки на мутабельные объекты-сообщения, то это выглядит как маразм.

Потому что immutable подразумевает shared.

О, еще одно захардкоженное правило?

Иммутабельность нужна объектам, одновременно доступным из разных нитей, что явно не относится к объекту-сообщению.

Когда у сообщения более одного получателя, то еще как относится.

Один объект-сообщение (да еще и содержащий один объект «описание заказа») принимается разными нитями? Думаю, такое плохо ложится на любой язык, в котором как-то поддерживается параллельное программирование (в Си и Си++ оно не поддерживается никак).

О, еще одно захардкоженное правило?

Есть иерархия степеней неизменяемости, что ли. В общем, immutable, самое последнее в ней и охватывает все предыдущие.

Один объект-сообщение (да еще и содержащий один объект «описание заказа») принимается разными нитями?

Блин, ну ты-то хоть дурочку не включай. Обмен-сообщениями это механизм взаимодействия. Который вполне может быть реализован в виде библиотеки/фреймворка не заточенного под конкретную задачу. Такая библиотека может поддерживать как peer-to-peer передачу сообщений, так и broadcast.

А уже поверх можно строить что угодно. Хоть передачу объекта с описанием задачи по цепочке стадий. Хоть делать параллельную обработку какого-то одного события разными способами.

Думаю, такое плохо ложится на любой язык, в котором как-то поддерживается параллельное программирование (в Си и Си++ оно не поддерживается никак).

Под параллельным программированием ты понимаешь что? Есть две разные вещи: parallelism и concurrency. Они предназначены для разных вещей. И обмен сообщениями больше относится именно к concurrency, нежели к parallelism. Как раз применительно к этому я и указываю на недостатки «вирусной» иммутабельности в D. А вот в C++ с этим как раз дела лучше обстоят.

Один объект-сообщение (да еще и содержащий один объект «описание заказа») принимается разными нитями?

Блин, ну ты-то хоть дурочку не включай.

Не объяснишь, что означает:

eao197> у сообщения более одного получателя

? Если это broadcast или multicast, то в чем моя дурость?

Обмен-сообщениями это механизм взаимодействия. Который вполне может быть реализован в виде библиотеки/фреймворка не заточенного под конкретную задачу

Не понял, к чему ты это, но можешь считать иммутабельность средством фреймворка параллельного программирования, встроенного в спецификацию языка D. Если этот фреймворк тебе не подходит, ты его не используешь. AFAIK, не запрещено передавать между нитями обычные мутабельные объекты.

Есть две разные вещи: parallelism и concurrency

«Ну хоть ты-то дурочку не включай» (ц) Языковые механизмы одинаковы что для concurrency, что для parallelism (и вообще разница между concurrency и parallelism высосана из пальца).

вот в C++ с этим как раз дела лучше обстоят.

Ну да, нет иммутабельности - нет и проблем с ней.