Примерно 80% CO2 переносится в организме эритроцитами, еще 7-10% гемоглобином эритроцитов (который таскает кислород) и оставшееся — плазмой крови.
Вы уверены?! Не в плазме в виде бикарбоната? А то я уже стал подзабывать физиологию…
А вообще-то мерять SpO2 в условиях даже мягкой гиперкапнии при дыхании обычным воздухом — не слишком осмысленно. Вазомоторные эффекты такое влияние окажут, только цены на бананы и увидишь.
mem::replace прекрасен, но он unsafe…
Кажется, что Pin/Unpin нужны из-за того, что компилятор локально не может определить, что нечто не перемещается нигде и никогда. И поэтому надо различать нечты, которые сломаются при перемещении в памяти и нечты, которые от места размещения в памяти не зависят. Или я фантазирую?
Все делают ошибки, я не являюсь исключением. Но ни делание ошибок, ни избегание ошибок не являются самоцелью.
Меня смущает зацикленность защитников и апологетов Rust на безопасности и борьбе с ошибками. Пара знакомых, профессионально пишущих на Rust в нем привлекает строгость и выразительность языка и его системы типов. То же самое я вижу в публикациях признанных корифеев языка. Напирать на то, что язык не дает «отстрелить ногу», с моей точки зрения странно. Не принимаю это за главное в языке.
Помнится, апологеты ранних версий Java любили обсасывать ошибки освобождения памяти без GC. Не понимая того, что GC — особая стратегия управления памятью со своими плюсами и минусами, а отсутствие необходимости писать free/delete один из плюсов, причем, не самый важный.
Мне кажется, с Rust похожая история, второй принцип Цермело в действии, так сказать. Rust прекрасен, но не безопасностью.
Вы такой категоричный! Не поверите, мой код работает как раз на «каких-то» ARM'ах, и volatile там вполне достаточно. На более продвинутых процессорах — там да, нужны барьеры памяти, даже в MMIO регистр записать. Но на тех платформах, работа с которыми заполняет мои дни — нет. Поэтому я использую «нормальный язык», в котором reintrpret_cast — имя переменной. И из него работающий инструмент не выбрасывают.
Сдается, что Вы переживаете на пустом месте. В плюсах Вы полностью реализовались до стадии «дня сурка», когда каждый следующий день не несет ничего волнующего. И даже утратили возможность писать код на C++, поскольку видите в написанном больеше проблем и неопределенности, чем решения задачи. Это нормально.
Лет 20 назад я по похожим мотивам сменил интенсивную терапию и рентгено-хирургию на C++-программирование. А лет 5 назад сменил С++ на чистый С и микроконтроллеры. Нормально себя ощущаю, не жалею о потраченном вермени и ни за что не соглашусь расстаться с каким-то переодом.
Может быть просто стоит шаг?
Да сколько угодно таких альтернатив. Та же Ada или Oberon.
Синтаксис всех паскалеподобных языков мне кажется омезительным. И что теперь? Синтаксис всех языков программирования чудовищен, по крайней мере местами. Синтаксис Rust не хуже и даже получше прочих — ближе к ML, хотя тоже еще тот подарок.
Ну, создания Филипа Кана для меня никогда не были авторитетными. А то, что возможность комбинаторного взрыва проглядели — печально. Можно было бы потребовать явного квитирования вложенного виртуального вызова, но это а)полумера и б)не было бы радикальным решением. Да и заботы у комитета другие…
В Rust — принято делать так, чтобы ошибочные конструкции было писать сложно, а правильные — легко.
С первым соглашусь, со вторым — не уверен). Какое это имеет отношение к реализации виртуальных функций-членов производных классов в C++?! Мы же не о разных языках говорим, а о конкретной фиче конкретного языка.
То, что это стоило бы запрещать компилятору — согласен. Но Страуструп такой мягкий человек, а крик поднимается такой всеобщий…
Петя сделал 12 ошибок на C++, а Вася сделал 10 ошибок на Rust. Их программы работают одинаково (т.е. не работают). Если не видно разницы, зачем искать лучших программистов?
Так? ))))
Что-то много полемического задора и мало конкретики.
Совершенно верно. Но решается это не упрощением создания кривого и плохо работающего кода, а созданием прослойки, которая позволит писать код несколько более удобным и безопасным образом.
Скажем так: возможность перекрывать дефолтные обработчики событий и процедуру отрисовки в производных классах, когда вся «машинерия» взаимодействия с «системой» упростило программирования в стравнении с C API? Меня будет трудно разубедить в этом.
Навороты и нетривиальное взаимодействие — результат неортогональности и в целом противоречивого дизайна как самих оконных систем, так и библиотек и фреймворков.
Все как всегда: нет особых проблем перекрывать четко заданные точки кастомизации поведения, если интерфейс статический. Нет особых проблем перекрывать полностью замкнутые в себе «листья», такие, как обработчики конкретных событий. Менее тривиальные случаи проблематичны и плохо масштабируются при усложнении системы, что усугубляется столь распространенным не самым удачным дизайном с переплетением в одном классе разных consern'ов и т.д. и т.п.
Но это не основание говорить, что наследование реализации *абсолютное зло* всегда и везде. Это просто неверно: мы спорим благодаря плодам наследования реализации.
Вы уверены?! Не в плазме в виде бикарбоната? А то я уже стал подзабывать физиологию…
А вообще-то мерять SpO2 в условиях даже мягкой гиперкапнии при дыхании обычным воздухом — не слишком осмысленно. Вазомоторные эффекты такое влияние окажут, только цены на бананы и увидишь.
Кажется, что Pin/Unpin нужны из-за того, что компилятор локально не может определить, что нечто не перемещается нигде и никогда. И поэтому надо различать нечты, которые сломаются при перемещении в памяти и нечты, которые от места размещения в памяти не зависят. Или я фантазирую?
Меня смущает зацикленность защитников и апологетов Rust на безопасности и борьбе с ошибками. Пара знакомых, профессионально пишущих на Rust в нем привлекает строгость и выразительность языка и его системы типов. То же самое я вижу в публикациях признанных корифеев языка. Напирать на то, что язык не дает «отстрелить ногу», с моей точки зрения странно. Не принимаю это за главное в языке.
Помнится, апологеты ранних версий Java любили обсасывать ошибки освобождения памяти без GC. Не понимая того, что GC — особая стратегия управления памятью со своими плюсами и минусами, а отсутствие необходимости писать free/delete один из плюсов, причем, не самый важный.
Мне кажется, с Rust похожая история, второй принцип Цермело в действии, так сказать. Rust прекрасен, но не безопасностью.
Не стыдно?
Лет 20 назад я по похожим мотивам сменил интенсивную терапию и рентгено-хирургию на C++-программирование. А лет 5 назад сменил С++ на чистый С и микроконтроллеры. Нормально себя ощущаю, не жалею о потраченном вермени и ни за что не соглашусь расстаться с каким-то переодом.
Может быть просто стоит шаг?
Синтаксис 1С вызывает восторг (не владею, так что условно):
Синтаксис всех паскалеподобных языков мне кажется омезительным. И что теперь? Синтаксис всех языков программирования чудовищен, по крайней мере местами. Синтаксис Rust не хуже и даже получше прочих — ближе к ML, хотя тоже еще тот подарок.
С первым соглашусь, со вторым — не уверен). Какое это имеет отношение к реализации виртуальных функций-членов производных классов в C++?! Мы же не о разных языках говорим, а о конкретной фиче конкретного языка.
То, что это стоило бы запрещать компилятору — согласен. Но Страуструп такой мягкий человек, а крик поднимается такой всеобщий…
Так? ))))
Пример в студию?
Навороты и нетривиальное взаимодействие — результат неортогональности и в целом противоречивого дизайна как самих оконных систем, так и библиотек и фреймворков.
Все как всегда: нет особых проблем перекрывать четко заданные точки кастомизации поведения, если интерфейс статический. Нет особых проблем перекрывать полностью замкнутые в себе «листья», такие, как обработчики конкретных событий. Менее тривиальные случаи проблематичны и плохо масштабируются при усложнении системы, что усугубляется столь распространенным не самым удачным дизайном с переплетением в одном классе разных consern'ов и т.д. и т.п.
Но это не основание говорить, что наследование реализации *абсолютное зло* всегда и везде. Это просто неверно: мы спорим благодаря плодам наследования реализации.