Есть у меня P1 с похожим решением — сбоку вставляется флопчик, или, если откинуть маленькую перегородку, CD привод. Или дополнительная батарея. Хотя совсем другая фирма; видимо, типовое решение. Порт расширения так же точно расположен, наверно, был стандарт какой-то под док-станции.
Насчет накладок на клавиатуру: с некоторыми программами поставлялись в комплекте вот такие полоски с фнукциями этих клавиш. Если используешь часто какой-то редактор или электронные таблицы, можешь вставить полоску с напоминалками.
Есть. В моем самсунге — два, из бетона. Сверху и снизу, оба тяжеленные (машинку тащили вдвоем, но было тяжело). Сама система подвески простая — сверху бак висит свободно на 4х пружинах, снизу ближе к переднему краю — два аммортизатора, компенисрующие радиальные биения. Только биения при отжиме не такие простые, что-то вроде восьмерки, в продольном направлении тоже. Так что аммортизаторы эти не работают.
Не, если взять самсунг, то втулка под подшипники — алюминий. Барабан из нержавейки, бак — пластик. Не разбивается, нет — сами подшипники в хлам уже из-за потекшего сальника и вибраций, а втулка в норме. Перепресовал подшипники и норма. А вот сальник — да, комедия. Диаметр посадочный х.55 мм, стандартных таких нет, только фирмА.
Вообще, самая надежная машинка, что у меня была, только не кидаться помидорами — Вятка-автомат. С 1992 или 1994 служила до 2010 примерно.
как следствие, торможение становится неэффективным и уже не может остановить машину.
Нет. Перегревается диск, колодки и жидкость. Жидкость закипает. То, что диск от нагрева потом поведет винтом — дело десятое. На больших скоростях при резком торможении диски очень быстро накаляются докрасна.
Обычное дело. У меня Самсунг с фронтальной загрузкой, максимум 1200 об/мин, если загрузить пододеяльник, будет скакать по всей ванной. Установлена правильно, просто система аммортизации — дешевейшая, не может гасить таких колебаний. Выдерживает не более 70% от максимальной загрузки и только маленькие отдельные вещи. Боши, даже более старые, таких проблем не имеют.
P сломает коробку, потому что включает механическую блокировку выходного вала. Реверс тоже, потому что мост и движок будут пытаться «скрутить» коробку винтом. А нейтраль — нет. Но это у старых коробок, как с современными — не знаю.
Ничего удивительного. По моим наблюдениям, многие «железячники» (одиночки) считают, что производство устройства — это искусство, подвластное избранным, а вот написать к нему код он сможет сам, так, на коленке. Это ж вообще мелочь. Получается работающий тихий ужас. Они очень обижаются, когда им на пальцах объясняют, почему их код дурно пахнет, потому что… ну… они ж железку сделали, че тут, программа какая-то.
Но ведь наиболее частый сценарий — относительно небольшая область используемой памяти, либо обращение к памяти более-менее последовательно.
Это, право слово, очень вольное допущение.
Именно под эти сценарии в первую очередь оптимизируются современные процессоры.
Не совсем. Этот сценарий в принципе, в отличие от произвольного доступа, возможно оптимизировать, и он оптимизируется. Что в свою очередь заставляет программистов располагать данные и обращаться к ним определенным образом. Здесь нельзя однозначно сказать, где причина, где следствие.
И как раз вот эта оптимизация и страдает, если у вас блокировки происходят часто.
Простите, а вы блокировкой защищаете единичную переменную или массив, который проходите последовательно?
Я к тому, что надо говорить про каждый конретный случай отдельно. В вашем случае — да, страдает. Но lock-free тоже требуют накладных расходов, в зависимости от реализации может быть копирование с опять же выбивание кеша и т.д.
Типичный случай для меня сейчас в текущей работе, например, защита линейного отсортированного массива(пара строка-объект), поиск в котором производится методом дихотомии. При большом размере коллекции скачки поначалу происходят по очень разным адресам, там не то что кеш ЦП будет играть свою скрипку, а банально подкачка страниц.
Тест из статьи — пример плохого, вредного теста. Но плохой он не из-за конструкции теста, а из-за интерпретации результатов и совершаемых выводов.
Скажем так — это средний вывод для среднего теста. Который — да — не учитывает другие факторы, которые могут влиять в другой ситуации.
Вы не сможете смело использовать уже написанные методы в других местах, ведь они могут порождать неожиданные исключения;
А что такое «неожиданное исключение» и почему оно является препятствием? По сути, это неожиданный код возврата. Функция возвращает вам, скажем, длину буфера, или -1 в случае неудачи. А вы не знали, что значение может быть отрицательным — это неожиданный для вас результат. Значит ли это, что код возврата нельзя использовать? Нет. С исключениями то же самое — выбрасываемые в виде кода ошибки исключения должны быть документированы, так же как и возвращаемые функцией значения.
GOTO зло — потому что путает код, передавая управление в произвольную точку. Не следует думать, что передача управления, перепрыгивая произвольное количество вызовов в стеке, меньше путает ваш код, чем GOTO;
Ничего подобного. Если так рассуждать, то мы должны отказаться от конструкций:
for ()...{
break;
}
if (){
…
} else {
…
}
В первом случае у нас есть неявный GOTO вовне цикла, во втором — неявный GOTO к блоку ELSE.
GOTO — не must die. Must die неправильное его использование. Самая большая проблема с goto — это прыжок назад по коду с созданием петли. Именно это тяжело отслежить и понять, именно из-за этого получается пресловутое спагетти. Исключение не бросает нас вверх по ходу исполнения, оно бросает нас вниз, дальше.
Не следует считать, что через 2 года вы влёт вспомните, что этот модуль системы для отрицательных ответов использует исключения
Такой же странный аргумент, как и первый. И тот же самый контр-аргумент. Вот вы надеетесь на то, что код ошибки — это -1. А потом добавили еще -2 и -3. Через поименованные константы, разумеется. А результат функции по-прежнему проверяете на == -1. И? Какая разница? Кто мешает вам ловить все коды ошибки меньше нуля или все исключения (определенные + «остальное»)?
Использовать нужно то, что сделает ваш код читаемым и надежным. Лучше коды ошибок? Пожалуйста. Лучше исключения? На здоровье. Лучше goto с переходом в блок деинициализации в конце функции? Да рали бога.
Насчет накладок на клавиатуру: с некоторыми программами поставлялись в комплекте вот такие полоски с фнукциями этих клавиш. Если используешь часто какой-то редактор или электронные таблицы, можешь вставить полоску с напоминалками.
Вообще, самая надежная машинка, что у меня была, только не кидаться помидорами — Вятка-автомат. С 1992 или 1994 служила до 2010 примерно.
Диски, друзья, тормозные диски.
Нет. Перегревается диск, колодки и жидкость. Жидкость закипает. То, что диск от нагрева потом поведет винтом — дело десятое. На больших скоростях при резком торможении диски очень быстро накаляются докрасна.
Это с какой стати? Вас не затруднит пояснить развернуто? Без каких-либо проблем используем исключения в многопоточных системах.
Это, право слово, очень вольное допущение.
Не совсем. Этот сценарий в принципе, в отличие от произвольного доступа, возможно оптимизировать, и он оптимизируется. Что в свою очередь заставляет программистов располагать данные и обращаться к ним определенным образом. Здесь нельзя однозначно сказать, где причина, где следствие.
Простите, а вы блокировкой защищаете единичную переменную или массив, который проходите последовательно?
Я к тому, что надо говорить про каждый конретный случай отдельно. В вашем случае — да, страдает. Но lock-free тоже требуют накладных расходов, в зависимости от реализации может быть копирование с опять же выбивание кеша и т.д.
Типичный случай для меня сейчас в текущей работе, например, защита линейного отсортированного массива(пара строка-объект), поиск в котором производится методом дихотомии. При большом размере коллекции скачки поначалу происходят по очень разным адресам, там не то что кеш ЦП будет играть свою скрипку, а банально подкачка страниц.
Скажем так — это средний вывод для среднего теста. Который — да — не учитывает другие факторы, которые могут влиять в другой ситуации.
Это если оно unhandled и на самом деле исключение.
С исключениями тоже так может быть — пустой catch/except блок.
Почему бы не ловить все исключения?
Да ну? По-моему посыл как раз использовать исключения только для нештатных ситуаций, а не «смотреть по ситуации».
А что такое «неожиданное исключение» и почему оно является препятствием? По сути, это неожиданный код возврата. Функция возвращает вам, скажем, длину буфера, или -1 в случае неудачи. А вы не знали, что значение может быть отрицательным — это неожиданный для вас результат. Значит ли это, что код возврата нельзя использовать? Нет. С исключениями то же самое — выбрасываемые в виде кода ошибки исключения должны быть документированы, так же как и возвращаемые функцией значения.
Ничего подобного. Если так рассуждать, то мы должны отказаться от конструкций:
for ()...{
break;
}
if (){
…
} else {
…
}
В первом случае у нас есть неявный GOTO вовне цикла, во втором — неявный GOTO к блоку ELSE.
GOTO — не must die. Must die неправильное его использование. Самая большая проблема с goto — это прыжок назад по коду с созданием петли. Именно это тяжело отслежить и понять, именно из-за этого получается пресловутое спагетти. Исключение не бросает нас вверх по ходу исполнения, оно бросает нас вниз, дальше.
Такой же странный аргумент, как и первый. И тот же самый контр-аргумент. Вот вы надеетесь на то, что код ошибки — это -1. А потом добавили еще -2 и -3. Через поименованные константы, разумеется. А результат функции по-прежнему проверяете на == -1. И? Какая разница? Кто мешает вам ловить все коды ошибки меньше нуля или все исключения (определенные + «остальное»)?
Использовать нужно то, что сделает ваш код читаемым и надежным. Лучше коды ошибок? Пожалуйста. Лучше исключения? На здоровье. Лучше goto с переходом в блок деинициализации в конце функции? Да рали бога.