США никогда не давали купить электронику для космоса, даже в 90-е, когда наша страна полностью «лежала» под ними. Даже под конкретные мирные исследовательские проекты типа «Фобос-грунт». За что в 90-е мы были под санкциями? Санкции появились не сейчас. Сейчас они стали просто шире.
Есть большие сомнения, что такая низкоуровневая сущность, как флаг, станет доступной в достаточно высокоуровневой LLVM. То же касается стека, который хотя и есть во всех современных архитектурах, но в LLVM напрямую им не управляют, что накладывает некоторые ограничения.
функция возвращает std::expected, однако вместо отдельного дискриминатора типа bool, который вместе с выравниванием будет занимать до 8 байт на стеке, этот бит информации передаётся каким-то более быстрым способом, например, в Carry Flag
Не подскажите, как вызываемая функция может установить Carry Flag, а вызывающая его проанализировать, если компилятор генерирует код не непосредственно, а через LLVM? Что должен выдать компилятор на вход LLVM, чтобы LLVM работал с этим флагом?
А справедливо ли, что вы хранили все сбережения на сберкнижке, и они бац - обесценились в момент?
Но я могу подать в суд, если что-то случилось с моим вкладом. Кто примет Ваш иск в случае, если Ваш вклад упал вместе с биткоином из-за действий правительства Китая?
Разговоры о справедливости оставим бабулькам на лавочке у подъезда. Никакой абсолютной справедливости в мире нет и быть не может
Думаю, в старинных голландских рукописях можно найти наставления по выращиванию тюльпанов. Но готов отдать руку на отсечение, что не существует берестяных грамот с призывом «опасаться московитов»! Пожалуйста, хоть одну берестяную грамоту со словом «московит» в студию!
А ведь автору достаточно было написать не «наши предки из Новгорода, Киева ...», а «наши предки из Новгорода, Москвы ...», тогда бы отсылка к «московитам» была не уместна. И зачем поднимать эту тему? Хочется опять, чтобы как в старину «собрались поляне, радимичи и кривичи и пошли войной на вятичей»? У нас и так перед глазами пример одной соседней страны, где условные радимичи не могут пойти на мировую с условными вятичами. Слава богу, что современные москвичи и новгородцы живут мирно. Зачем поднимать эту муть в блоге иркутской компании?
Наверное, 500 или 1000 лет назад наши предки из Новгорода, Киева и Роттердама тоже хотели передать нам какую-то информацию, которые считали крайне важной. Например, опасатьсямосковитов или разводить тюльпаны.
Эта статья техническая или вы занимаетесь пропагандой?
Латинизм «Московия» был в ходу весьма давно и употреблялся в малом количестве стран и уж точно не был самоназванием. Жители Московского княжества так же не называли себя «московитами», как французы не называли себя «лягушатниками», а итальянцы — «макаронниками». Вот вам цитата из Википедии:
Да он приумножает и коррупцию, и несправедливость! Коррупционеры теперь могут получать коррупционных доход в биткоинах, прятать его от правосудия, уводить активы из страны — от народа, который в результате потерял ровно такую же сумму. А справедливость? Что справедливого в том, что кто-то намайнил биткоины и сделал деньги из воздуха, а кто-то нет? А справедливо ли, что у преступников есть способ сохранять преступно нажитое? Если раньше решение суда о лишении преступно нажитых активов было выполнимо из-за их «приземлённости», то теперь активы ушли в виртуальный мир и их оттуда не вытащишь и не отдашь пострадавшим?
С одной стороны, Вы пишите об управлении памятью в iOS и swift. С другой стороны, у Вас достаточно обязывающий заголовок: «Управление памятью в современных языках программирования». Поэтому можно окинуть критическим взглядом не только iOS и swift. И этот взгляд, упавший на swift показывает, что этот язык хоть и современный, но в некоторых вопросах (судя по Вашему описанию) он отнюдь не современен.
«Существует ограничение в том, что данные, которые предполагается хранить в стеке, обязаны быть конечными и статичными — их размер должен быть известен ещё на этапе компиляции»
В других языках это не всегда так. Тот же Си выходит за описанные Вами рамки двумя способами. Первый — с помощью функций с переменным количеством аргументов, которые, как известно, кладутся на стек перед вызовом функции. Хотя размер стекового кадра известен во время компиляции, но он не статичен, он меняется от вызова к вызову.
Второй способ — с помощью функции alloca, которая выделяет память не в куче, а в стеке. В этом случае размер стекового кадра не только не статичен, но ещё и неизвестен во время компиляции. Правда, пользоваться функцией не всегда удобно. Если, допустим, надо создать в стеке какой-то объект, то сперва надо вычислить его размер и только потом вызвать alloca. Такое преодоление пропасти в два прыжка мешает написать конструктор объекта, который бы сделал это всё сразу.
Проблему решает модель памяти не с одним, а двумя стеками. В ней цепочка подпрограмм использует стеки по очереди: чётные подпрограммы используют чётный стек, а нечётные — нечётный стек. Тогда конструктор, работающий в одном стеке, может создать объект вычисляемой длины в другом стеке. Такие манипуляции возможны потому, что локальные данные конструктора находятся в своём стеке и они не будут перекрываться создаваемым в другом стеке объектом. Подробнее можно посмотреть здесь.
Есть ещё одна интересный вопрос — а как удлинить массив в стеке? На первый взгляд проблема нерешаема: массив в архитектуре x86 растёт в сторону старших адресов, а стек — наоборот, в сторону младших адресов. Тогда надо «перевернуть» массив, чтобы он рос в обратном направлении! По факту элемент массива с индексом [n] станет на самом деле элементом с индексом [-n]. Этот массив может расти при условии, что он находится на вершине стека и за ним ничего нет. Если наращиванием массива будет заниматься какая-то вызываемая функция, то возникнет угроза перекрытия растущего массива и локальных данных этой функции. Так что для аккуратного программирования тут лучше опять использовать модель памяти с двумя стеками. Подробности — здесь. Ещё надо заметить, что массив — не единственный агрегатный тип данных, который может расти в стеке. Расти, наверное, могут многие, если не все — при условии правильного исполнения. Массив же выбран в качестве примера по причине его простоты.
Всё вышеперечисленное подчиняется дисциплине LIFO: буква «L» в этой аббревиатуре означает «Last», «последний». То есть и резервирование памяти с помощью alloca, и создание нового объекта конструктором в двухстековой модели, и удлинение массива — всё это делается в памяти, лежащей ниже последнего («Last») элемента стека.
И последнее: пока что мне не знакомы языки, в которых есть двухстековая модель памяти или удлинение массива на вершине стека. Надеюсь, мои замечания добавили недостающие штрихи к портрету всем известного стека.
Борьба с глобальным потеплением — это цель. А снижение выбросов углекислоты — это метод, а не цель. Но меня удивляет, почему для борьбы с потеплением не пытаются предотвратить поступление тепла. Откуда берётся тепло? Оно поступает от Солнца. В виде света в видимом и невидимых диапазонах. Чтобы избавиться от тепла, надо отразить зеркалом свет куда-нибудь в сторону. Отправить его назад, в космос.
Cамое эффективное зеркало, отражающее энергию Солнца, — это зеркало на орбите. Но стоит оно дорого. Поэтому можно опробовать размещать зеркала на Земле в тех местах, где солнца много. В пустынях, степях. У нас в стране можно подобрать местности, где солнечно и малолюдно. В Калмыкии, например. Производство отражающей плёнки недорого.
На каждый квадратный метр от солнца приходит 1367 Ватт энергии (солнечная постоянная). До земли через атмосферу — доходит порядка 1020 Ватт (на экваторе).
Представляете, один квадратный метр зеркальной плёнки может отразить киловатт солнечной энергии! Чем бороться с углекислотой, не проще ли поставить зеркала? Почему бы не провести эксперименты? В той же Калмыкии летом стоит жара. Надо заметить, что жара стоит днём. А вот ночью нет солнца и жары нет. Почему бы не поставить зеркала и не отразить какую-то долю солнечного излучения? А потом сделать выводы.
Вообще-то двигатель АШ-62, который стоял на АН-2, двухрядный. Но это не значит, что он собран из двух. А вот на Ла-5 стоял двигатель АШ-82. Почитайте Википедию, не стесняйтесь.
Если быть скрупулёзно точным, то возвращаемое кладётся вместо вызова функции. Ровно в то место, где и был вызов. Например:
g(f(x)) // до вызова f
g(первое возвращаемое) // поле вызова f, но до вызова g
второе возвращаемое // после вызова g
В строке
y = f(x) // до вызова f
после вызова f будет
y = возвращаемое // возвращаемое кладётся на место f(x)
Но потом операция присваивания двигает результат справа налево. Было бы логичнее эту операцию выразить так:
y <- f(x)
Но исторически сложилось так, что используют символ знака равенства. И получается так, что вызов у нас использует нотацию
y <- f(x)
(справа налево), а вот объявление (в Вашем варианте) — нотацию
f(тип 1) -> тип 2
то есть слева направо. И в этом нелогичность, поскольку символ «=» трактуется как «<-». Вот если бы присвоение делалось слева направо, как в первоначальных версиях языка Рапира
b + c -> a; // слева — вычисляемое выражение,
// справа — имя перезаписываемой переменной
функция: f: ℕ -> ℕ — имя, потом «тип аргумента», потом «возвращаемый тип»
y = f(x) // вызов функции f
Где тут находится возвращаемое? Возвращаемое находится слева! Значит, и при объявлении функции возвращаемое должно находится слева. Зачем нам такой стиль, что результат надо смотреть то слева, то справа? Надо придерживаться одного стиля. Либо справа налево:
И трижды, и четырежды платит скупой. Но изначально как выглядит? Нам нужно построить некий бизнес-процесс. Какую платформу выбираем? 1С! Это ж почти стандарт по нашей стране. Запилили, всё работает, претензий нет ни по функциональности, ни по производительности. Потом идёт развитие, добавляем и то, и сё, база данных растёт, всё начинает тормозить, появляются глюки. Заказчик недоволен. Разработчик отвечает: «А что ж Вы хотели? Сервер уже не тянет. Посмотрите сами, дисковая подсистема работает зачастую близко к 100% от своих возможностей. Пора покупать новый сервер, старый устарел». Заказчик покупает новый сервер. Проблема уходит, заказчик убеждается, что разработчик был прав. Поэтому когда заказчик дозаказывает новую функциональность, то он уже готов к новым расходам на оборудование.
Я в этой картине ничего не рисовал от себя. Всё из жизни.
Конечно, нормальным я это не считаю. Особенно возмущает, когда для проекта уже изначально выбираются прожорливые технологии.
Но реальные факты из жизни говорят, что такое имеет место быть. Как говорит одесская пословица, если проблему можно решить за деньги, то это не проблема, а расходы. Вот заказчик/собственник и решает, что дешевле — то ли новый сервер купить, то ли выкинуть старое ПО и написать заново новое.
Да, порою оказывается так, что дешевле купить новый сервер, который переварит некоторую неэффективность, чем платить программистам за долгую и кропотливую разработку.
А ещё бывает так, что со временем база данных выросла и сервер начинает тормозить. Вы думаете, из той же 1С начинают выковыривать SQL-операторы и заменять на что-то более шустрое? Я вас умоляю! Просто покупают новый сервер. А бывает, что разработка ещё не закончилась, а уже все согласны купить новый сервер. Потому что так сказали головастые мужики. А неголовастым и возразить нечего.
В начале 1970-х Килдалл разработал язык программирования PL/M, Programming Language for Microcomputers. Он был основан на достаточно популярном в те годы PL/1.
К этому можно добавить, что компилятор Килдалла не брошен. Его в течение не одного десятка лет дорабатывал Дмитрий Юрьевич Караваев, пройдя путь от DOS 1.0 до Win-64. И теперь, по его словам, от исходного компилятора не осталось ни одной машинной команды.
Охренеть! Как же на одномоторном самолёте АН-2 могло отказать 2 (два!) двигателя? Или в салоне валялся второй, запасной. И после отказа первого его быстренько, прямо в полёте поставили на место первого, но и он не заработал?
США никогда не давали купить электронику для космоса, даже в 90-е, когда наша страна полностью «лежала» под ними. Даже под конкретные мирные исследовательские проекты типа «Фобос-грунт». За что в 90-е мы были под санкциями? Санкции появились не сейчас. Сейчас они стали просто шире.
Есть большие сомнения, что такая низкоуровневая сущность, как флаг, станет доступной в достаточно высокоуровневой LLVM. То же касается стека, который хотя и есть во всех современных архитектурах, но в LLVM напрямую им не управляют, что накладывает некоторые ограничения.
Не подскажите, как вызываемая функция может установить Carry Flag, а вызывающая его проанализировать, если компилятор генерирует код не непосредственно, а через LLVM? Что должен выдать компилятор на вход LLVM, чтобы LLVM работал с этим флагом?
Но я могу подать в суд, если что-то случилось с моим вкладом. Кто примет Ваш иск в случае, если Ваш вклад упал вместе с биткоином из-за действий правительства Китая?
Но часто можно добиться относительной!
Думаю, в старинных голландских рукописях можно найти наставления по выращиванию тюльпанов. Но готов отдать руку на отсечение, что не существует берестяных грамот с призывом «опасаться московитов»! Пожалуйста, хоть одну берестяную грамоту со словом «московит» в студию!
А ведь автору достаточно было написать не «наши предки из Новгорода, Киева ...», а «наши предки из Новгорода, Москвы ...», тогда бы отсылка к «московитам» была не уместна. И зачем поднимать эту тему? Хочется опять, чтобы как в старину «собрались поляне, радимичи и кривичи и пошли войной на вятичей»? У нас и так перед глазами пример одной соседней страны, где условные радимичи не могут пойти на мировую с условными вятичами. Слава богу, что современные москвичи и новгородцы живут мирно. Зачем поднимать эту муть в блоге иркутской компании?
Эта статья техническая или вы занимаетесь пропагандой?
> До захвата московитами Новгородское княжество
Латинизм «Московия» был в ходу весьма давно и употреблялся в малом количестве стран и уж точно не был самоназванием. Жители Московского княжества так же не называли себя «московитами», как французы не называли себя «лягушатниками», а итальянцы — «макаронниками». Вот вам цитата из Википедии:
> Новгородская республика в 1478 году была завоёвана Иваном III и полностью вошла в состав централизованного Русского государства.
О «Московии» нет никакой речи. Так что не надо пользоваться сомнительными источниками и распространять сомнительные сведения.
Да он приумножает и коррупцию, и несправедливость! Коррупционеры теперь могут получать коррупционных доход в биткоинах, прятать его от правосудия, уводить активы из страны — от народа, который в результате потерял ровно такую же сумму. А справедливость? Что справедливого в том, что кто-то намайнил биткоины и сделал деньги из воздуха, а кто-то нет? А справедливо ли, что у преступников есть способ сохранять преступно нажитое? Если раньше решение суда о лишении преступно нажитых активов было выполнимо из-за их «приземлённости», то теперь активы ушли в виртуальный мир и их оттуда не вытащишь и не отдашь пострадавшим?
С одной стороны, Вы пишите об управлении памятью в iOS и swift. С другой стороны, у Вас достаточно обязывающий заголовок: «Управление памятью в современных языках программирования». Поэтому можно окинуть критическим взглядом не только iOS и swift. И этот взгляд, упавший на swift показывает, что этот язык хоть и современный, но в некоторых вопросах (судя по Вашему описанию) он отнюдь не современен.
«Существует ограничение в том, что данные, которые предполагается хранить в стеке, обязаны быть конечными и статичными — их размер должен быть известен ещё на этапе компиляции»
В других языках это не всегда так. Тот же Си выходит за описанные Вами рамки двумя способами. Первый — с помощью функций с переменным количеством аргументов, которые, как известно, кладутся на стек перед вызовом функции. Хотя размер стекового кадра известен во время компиляции, но он не статичен, он меняется от вызова к вызову.
Второй способ — с помощью функции alloca, которая выделяет память не в куче, а в стеке. В этом случае размер стекового кадра не только не статичен, но ещё и неизвестен во время компиляции. Правда, пользоваться функцией не всегда удобно. Если, допустим, надо создать в стеке какой-то объект, то сперва надо вычислить его размер и только потом вызвать alloca. Такое преодоление пропасти в два прыжка мешает написать конструктор объекта, который бы сделал это всё сразу.
Проблему решает модель памяти не с одним, а двумя стеками. В ней цепочка подпрограмм использует стеки по очереди: чётные подпрограммы используют чётный стек, а нечётные — нечётный стек. Тогда конструктор, работающий в одном стеке, может создать объект вычисляемой длины в другом стеке. Такие манипуляции возможны потому, что локальные данные конструктора находятся в своём стеке и они не будут перекрываться создаваемым в другом стеке объектом. Подробнее можно посмотреть здесь.
Есть ещё одна интересный вопрос — а как удлинить массив в стеке? На первый взгляд проблема нерешаема: массив в архитектуре x86 растёт в сторону старших адресов, а стек — наоборот, в сторону младших адресов. Тогда надо «перевернуть» массив, чтобы он рос в обратном направлении! По факту элемент массива с индексом [n] станет на самом деле элементом с индексом [-n]. Этот массив может расти при условии, что он находится на вершине стека и за ним ничего нет. Если наращиванием массива будет заниматься какая-то вызываемая функция, то возникнет угроза перекрытия растущего массива и локальных данных этой функции. Так что для аккуратного программирования тут лучше опять использовать модель памяти с двумя стеками. Подробности — здесь. Ещё надо заметить, что массив — не единственный агрегатный тип данных, который может расти в стеке. Расти, наверное, могут многие, если не все — при условии правильного исполнения. Массив же выбран в качестве примера по причине его простоты.
Всё вышеперечисленное подчиняется дисциплине LIFO: буква «L» в этой аббревиатуре означает «Last», «последний». То есть и резервирование памяти с помощью alloca, и создание нового объекта конструктором в двухстековой модели, и удлинение массива — всё это делается в памяти, лежащей ниже последнего («Last») элемента стека.
И последнее: пока что мне не знакомы языки, в которых есть двухстековая модель памяти или удлинение массива на вершине стека. Надеюсь, мои замечания добавили недостающие штрихи к портрету всем известного стека.
Борьба с глобальным потеплением — это цель. А снижение выбросов углекислоты — это метод, а не цель. Но меня удивляет, почему для борьбы с потеплением не пытаются предотвратить поступление тепла. Откуда берётся тепло? Оно поступает от Солнца. В виде света в видимом и невидимых диапазонах. Чтобы избавиться от тепла, надо отразить зеркалом свет куда-нибудь в сторону. Отправить его назад, в космос.
Cамое эффективное зеркало, отражающее энергию Солнца, — это зеркало на орбите. Но стоит оно дорого. Поэтому можно опробовать размещать зеркала на Земле в тех местах, где солнца много. В пустынях, степях. У нас в стране можно подобрать местности, где солнечно и малолюдно. В Калмыкии, например. Производство отражающей плёнки недорого.
Представляете, один квадратный метр зеркальной плёнки может отразить киловатт солнечной энергии! Чем бороться с углекислотой, не проще ли поставить зеркала? Почему бы не провести эксперименты? В той же Калмыкии летом стоит жара. Надо заметить, что жара стоит днём. А вот ночью нет солнца и жары нет. Почему бы не поставить зеркала и не отразить какую-то долю солнечного излучения? А потом сделать выводы.
Вообще-то двигатель АШ-62, который стоял на АН-2, двухрядный. Но это не значит, что он собран из двух. А вот на Ла-5 стоял двигатель АШ-82. Почитайте Википедию, не стесняйтесь.
В строкепосле вызова f будетНо потом операция присваивания двигает результат справа налево. Было бы логичнее эту операцию выразить так:Но исторически сложилось так, что используют символ знака равенства. И получается так, что вызов у нас использует нотацию(справа налево), а вот объявление (в Вашем варианте) — нотациюто есть слева направо. И в этом нелогичность, поскольку символ «=» трактуется как «<-». Вот если бы присвоение делалось слева направо, как в первоначальных версиях языка Рапирато Ваш вариант был бы логичен.
Где тут находится возвращаемое? Возвращаемое находится слева! Значит, и при объявлении функции возвращаемое должно находится слева. Зачем нам такой стиль, что результат надо смотреть то слева, то справа? Надо придерживаться одного стиля. Либо справа налево:либо слева направо:
Я в этой картине ничего не рисовал от себя. Всё из жизни.
Но реальные факты из жизни говорят, что такое имеет место быть. Как говорит одесская пословица, если проблему можно решить за деньги, то это не проблема, а расходы. Вот заказчик/собственник и решает, что дешевле — то ли новый сервер купить, то ли выкинуть старое ПО и написать заново новое.
А ещё бывает так, что со временем база данных выросла и сервер начинает тормозить. Вы думаете, из той же 1С начинают выковыривать SQL-операторы и заменять на что-то более шустрое? Я вас умоляю! Просто покупают новый сервер. А бывает, что разработка ещё не закончилась, а уже все согласны купить новый сервер. Потому что так сказали головастые мужики. А неголовастым и возразить нечего.