Действительно, шанс высок, однако, длительные регулярные процедуры кондиционирования(уничтожения костного мозга) препаратами и/или излучением и вливания костного мозга позволяют минимизировать риски, если я ничего не путаю.
Полностью убивать иммунку – также не вариант, пациент умрёт раньше, чём все лимфоциты, поэтому тут речь именно о мутации определённого гена и пересадки костного мозга с такой мутантной ДНК пациенту.
К сожалению, аутологическая РТПХ тут – не вариант, т.к. нужна мутация гена CCR5-Δ32, которая увеличивает тяжесть течения бубонной чумы, но при этом даёт устойчивость к ВИЧ(человек выздоравливает).
В принципе, при наличии больших денег и неплохого здоровья можно создать прецедент выздоровления, как раз-таки с помощью пересадки костного мозга.
Насчёт демонизированной тут РТПХ – само собой, что такая может возникнуть, иммуносуппрессоры, противовоспалительные и более дорогие и интересные препараты помогают эффективно подавить воспаление до тех пор, пока ткань не приживется. И совместимость нормально надо проверять.
Ничего не устарело, просто я открыл для себя с изучением Хаскеля, что недостаточно просто «сказать» программе, что я хочу её раскидать на десять кластеров, а надо-таки раскидывать этот лёгкий-для-параллелизма из коробки по парам и секам.
Написать-то можно, если задаться, но к многопоточности приходишь, как набираешься чуть опыта и видишь, где от неё профит словить.
Асинхронный пример принят, сам как-то не подумал.
Непонятно следующее: каким образом /*фактическая*/ переменная, объявленная со словом const, может быть изменена в процессе выполнения программы?
Большинство современных компиляторов плюсов выдадут ошибку, если в коде её значение попытаться изменить.
Дело в количестве потоков исполнения и они есть, если я не ошибаюсь, во всех языках общего назначения, а не только в спп:
Если он 1 – то программа выполняется построчно, и пока поток выполнения находится в функции, объект назван его формальным параметром, то есть условно const int& x.
Если же их более, чем 1 – переменная действительно может измениться, ну тут уже смотрите, чтоб не было гонок.
Мы обсуждаем странное понятие иммутабельности – позвольте уточнить, что иммутабельные данные – это не коробка байт, которые не изменятся, даже если подача тока прекратится/коротнёт. Это коробка байт, которую можно открыть и посмотреть, но не трогать байты руками.
Если же мы обсуждаем изменение данных «извне» (напр., тупую ассемблерную подмену данных тем же артмани), то для того, чтоб программа корректно(?!) обрабатывала такие изменения, придётся использовать продвинутые техники.
Всё-таки давайте не будем смешивать в кучу язык общего назначения и SQL.
Кстати, fun fact: Я был так много наслышан о том, как Хаскелл хорошо параллелится, ещё когда начал учить первый язык, что когда я схватился за Хаскелл, был поражён, что параллелить надо через монаду, что накладывает не одно ограничение на мой код, т.к. я ещё не понял их и трансформеры. Итог: не один десяток малых параллельных проектов на С++ и ни одного на Хаскелле.
объект «иммутабельный» внезапно из стула не превратится в верблюда, потому что кто-то снаружи что-то внутри него дернул
Вы апеллируете к многопоточному программированию?
В таком случае, это вопрос организации взаимодействия и разделения данных между потоками.
Решил продемонстрировать, как я это вижу:
#include <thread>
#include <chrono>
int func(const int& x)
{
std::this_thread::sleep_for(std::chrono::seconds(1));
if (x < 1)
return -1;
else return x;
}
int main(void)
{
/*const*/ int i = 1;
std::thread thr(foo, i);
++i;
thr.join();
}
В такой ситуации закомментированный const как раз снимает вопрос.
Ни разу не встречал обсуждение «проблемы const», Вами так с лёгкостью окрещённой, однако, могу представить Вам пример полноценной иммутабельности на С++:
int main(void)
{
const int i = 0;
++i;
//Всё как мы и ожидали, ошибка компиляции «expression must be a modifiable value»
}
Const – имхо не самая сложная тема при изучении С-подобных языков.
Если во внешнем скоупе объект иммутабельный, то такой проблемы и не будет (бишь, функциональный подход для меня по большей части в этом и заключается), а с неизменяемостью по умолчанию – не придётся вообще писать mutable var.
ref – Указание, что принимаемый тип будет ссылочным, а var же указывает на мутабельность.
Я провожу аналогию в меру своих знаний, а именно:
На плюсах можно написать:
/*void foo*/
(int a)
(int& a)
(const int& a)
Что будет значить три разных вещи. 1 – int скопируется новой переменной. 2 – будет передан мутабельный параметр по ссылке. 3 – передастся ссылка на константную (то есть, неизменяемая, она же мутабельная) переменную (константную ссылку на переменную, но не суть).
Имеем:
ref strategy: Int –> const int& strategy
strategy: Int –> const int strategy
var ref bar –> template T& bar
ref bar –> template const T& bar
Почему я использую ref для strategy – привычка, больше скажу, я консты не всегда пишу, и потому всеми конечностями за иммутабельность по умолчанию
P.S.: Насчёт ссылочности и сохранения иммутабельности, как по мне, всё просто: пример кода в статье на эту тему – негодный и не должен ни компилиться, ни, тем более, запускаться. В сигнатуре функции надо обязать указывать mutable var для изменяемых переменных. При правильно прикрученной системе вывода типов получим синтаксис функции вроде:
function foo(var ref bar/*Тип указан только для второй переменной, в то время, как тип первой выводится*/, ref strategy: Int) /*Тип возвращаемого значения выводится сам*/
{
bar += 1;
//Ошибочный код:
//strategy += 1;
return bar;
}
Что в принципе миленько – возможность контроля типов получаемых и возвращаемых значений функции, как и их модификаторов.
Вообще, симпатичный синтаксис, однако, рекурсия тут задумана как некий «Unsafe» элемент… Стоп, что? Язык, претендующий на функциональность со всеми этими иммутабельностью, пайплайнами, вызовами фильтер/мап/редьюсов в ДжаваВосемь-стиле, только через стрелочки, и этот язык предлагает огромную кодобазу отмечать как рекурсивную, хотя мне не припоминается, чтоб у компиляторов когда-либо были проблемы с распознаванием рекурсивных вызовов в коде, с тех пор как в них добавляли поддержку рекурсивных вызовов.
Крайне занятная задумка со стринг-типами, хотя слишком сыро и конкретно – надо расширить на систему типов по возможности (я вижу отличное применение такому функционалу – он вполне может потеснить костыльнуть Хаскелльные тайпклассы, пусть и работает в другую сторону, так же, как и концепты из С++20).
Также интересно отсутствие UB, но это не гарантирует, что программа будет себя вести, как задумано. Более того, никто ещё не видел ошибки реальных программ, а это очень важно – всегда придерживался и придерживаюсь мнения, что максимум ошибок надо ловить в компайлтайме.
Общее впечатление: симпатичный синтаксис (а больше пока ничего и нет), вангую проприетарный майкрософтовский F# x переRust.
Ничего себе, они там забесплатно, что ли, работают?
Насчёт демонизированной тут РТПХ – само собой, что такая может возникнуть, иммуносуппрессоры, противовоспалительные и более дорогие и интересные препараты помогают эффективно подавить воспаление до тех пор, пока ткань не приживется. И совместимость нормально надо проверять.
Ничего не устарело, просто я открыл для себя с изучением Хаскеля, что недостаточно просто «сказать» программе, что я хочу её раскидать на десять кластеров, а надо-таки раскидывать этот лёгкий-для-параллелизма из коробки по парам и секам.
Написать-то можно, если задаться, но к многопоточности приходишь, как набираешься чуть опыта и видишь, где от неё профит словить.
Непонятно следующее: каким образом /*фактическая*/ переменная, объявленная со словом const, может быть изменена в процессе выполнения программы?
Большинство современных компиляторов плюсов выдадут ошибку, если в коде её значение попытаться изменить.
Если он 1 – то программа выполняется построчно, и пока поток выполнения находится в функции, объект назван его формальным параметром, то есть условно const int& x.
Если же их более, чем 1 – переменная действительно может измениться, ну тут уже смотрите, чтоб не было гонок.
Мы обсуждаем странное понятие иммутабельности – позвольте уточнить, что иммутабельные данные – это не коробка байт, которые не изменятся, даже если подача тока прекратится/коротнёт. Это коробка байт, которую можно открыть и посмотреть, но не трогать байты руками.
Если же мы обсуждаем изменение данных «извне» (напр., тупую ассемблерную подмену данных тем же артмани), то для того, чтоб программа корректно(?!) обрабатывала такие изменения, придётся использовать продвинутые техники.
Кстати, fun fact: Я был так много наслышан о том, как Хаскелл хорошо параллелится, ещё когда начал учить первый язык, что когда я схватился за Хаскелл, был поражён, что параллелить надо через монаду, что накладывает не одно ограничение на мой код, т.к. я ещё не понял их и трансформеры. Итог: не один десяток малых параллельных проектов на С++ и ни одного на Хаскелле.
Вот тебе и «easy parallelism by design».
Вы апеллируете к многопоточному программированию?
В таком случае, это вопрос организации взаимодействия и разделения данных между потоками.
Решил продемонстрировать, как я это вижу:
В такой ситуации закомментированный const как раз снимает вопрос.
int main(void)
{
const int i = 0;
++i;
//Всё как мы и ожидали, ошибка компиляции «expression must be a modifiable value»
}
Const – имхо не самая сложная тема при изучении С-подобных языков.
mutablevar.Я провожу аналогию в меру своих знаний, а именно:
На плюсах можно написать:
/*void foo*/
(int a)
(int& a)
(const int& a)
Что будет значить три разных вещи. 1 – int скопируется новой переменной. 2 – будет передан мутабельный параметр по ссылке. 3 – передастся ссылка на константную (то есть, неизменяемая, она же мутабельная) переменную (константную ссылку на переменную, но не суть).
Имеем:
ref strategy: Int –> const int& strategy
strategy: Int –> const int strategy
var ref bar –> template T& bar
ref bar –> template const T& bar
Почему я использую ref для strategy – привычка, больше скажу, я консты не всегда пишу, и потому всеми конечностями за иммутабельность по умолчанию
mutablevar для изменяемых переменных. При правильно прикрученной системе вывода типов получим синтаксис функции вроде:function foo(var ref bar/*Тип указан только для второй переменной, в то время, как тип первой выводится*/, ref strategy: Int) /*Тип возвращаемого значения выводится сам*/
{
bar += 1;
//Ошибочный код:
//strategy += 1;
return bar;
}
Что в принципе миленько – возможность контроля типов получаемых и возвращаемых значений функции, как и их модификаторов.
Крайне занятная задумка со стринг-типами, хотя слишком сыро и конкретно – надо расширить на систему типов по возможности (я вижу отличное применение такому функционалу – он вполне может
потеснитькостыльнуть Хаскелльные тайпклассы, пусть и работает в другую сторону, так же, как и концепты из С++20).Также интересно отсутствие UB, но это не гарантирует, что программа будет себя вести, как задумано. Более того, никто ещё не видел ошибки реальных программ, а это очень важно – всегда придерживался и придерживаюсь мнения, что максимум ошибок надо ловить в компайлтайме.
Общее впечатление: симпатичный синтаксис (а больше пока ничего и нет), вангую проприетарный майкрософтовский F# x переRust.