Не очень понимаю, как это применимо в условиях реального дорожного движения.
Допустим мы даже знаем расписание работы светофоров — тогда на пустых дорогах можно было бы точно высчитать, где ускоряться и насколько, итд. Но как только мы имеем других участников движения — всё это теряет смысл.
Простите, что? То есть метод, выбрасывающий исключения, должен внутри себя предполагать, как выглядит стек трейс до входа в него? Для публичных методов это сильно пахнет нарушением инкапсуляции.
Ситуация должна быть обратной — в документации к методам обычно пишется, какие исключения он выбрасывает, и вызывающий код должен позаботиться об обработке этих исключений.
Мне сразу вспомнились холиварные статьи о goto. Здесь точно так же не хватает реальных примеров, где throw делает жизнь заметно легче.
Лично я не считаю, что в процессе нормальной работы программы должны возникать какие-либо исключения. В конце концов — подумайте о коллегах. Вы сделаете отладку кошмаром. Даже если отключить break on exceptions, debug output будет захламлён, и полезная информация исчезнет из виду.
Exceptions, Исключения — на то они так и называются. Возникают в исключительных ситуациях.
Эту шнягу на присоске, которую нужно приклеивать к лобовухе каждый раз и убирать, когда приехал? Опционально ещё таскать с собой, а не оставлять в машине? Втыкать в прикуриватель, чтобы провод через всю панель тянулся? Я именно таким и пользуюсь. И легко отдал бы 13к, чтобы у меня просто на приборке был экран с картой, который включается, когда я ключ поворачиваю. Хотя калину не купил бы.
Почему для мобильников не делают такие же крэдлы, как для DECT телефонов (контакты слегка утоплены в корпус телефона и ничем не мешают, доставать и ставить в крэдл можно без усилий одной рукой)? Я бы такие штуки поставил дома и на работе. И видно, что на экране, и заряжается, и доставать удобно — не то, что шнур выдёргивать, когда звонит кто-то.
Для Siemens SL45, помню, было что-то похожее, но там надо было аккуратно вставлять, и вынимать, придерживая крэдл — это ерунда.
«с ноутбука, подключённого в диагностический порт автомобиля OBD-II, можно остановить двигатель, блокировать двери, отключить тормоза или фальсифицировать показания спидометра»
Лол, вот это новость! А мужики-то не знали. Да там много чего можно делать. Включать фичи, которых нет в комплектации (типа климат-контроля), менять программу управления двигателем (чип-тюнинг). Как бы порт для этого и предназначен.
Меня статья ввела в недоумение.
Во-первых, зачем это? Какие плюсы, минусы, выводы?
Во-вторых, статья называется «ручное управление памятью», а про реализацию управления ничего и не рассказано.
Я посмотрел код. Вся суть «управления памятью» в том, что мы кладём объекты в массив и меняем размер массива при надобности. Стоило это упомянуть в статье. Или я чего-то недопонял?
Во-вторых, твой код даже не скомпилируется. Недавно пользуешься linq и лямбдами?
Допустим мы даже знаем расписание работы светофоров — тогда на пустых дорогах можно было бы точно высчитать, где ускоряться и насколько, итд. Но как только мы имеем других участников движения — всё это теряет смысл.
var result = elements.Select(e => e.ToInt()).Where(e => e != null);
public static class StringExtensions
{
public static int? ToInt(this string s)
{
int i;
return int.TryParse(s, out i) ? i : (int?) null;
}
}
Более лаконично, и ленивое выполнение.
foreach (var element in elements)
{
int someData;
if (int.TryParse(element, out someData))
result.Add(someData);
}
Можно в две строчки, но неэффективно:
int i;
var result1 = elements.Where(e => int.TryParse(e, out i)).Select(e => int.Parse(e));
Жаль, что нету метода int? Parse(s), который возвращает null в случае неудачи. Но что-то я увлёкся.
Ситуация должна быть обратной — в документации к методам обычно пишется, какие исключения он выбрасывает, и вызывающий код должен позаботиться об обработке этих исключений.
Лично я не считаю, что в процессе нормальной работы программы должны возникать какие-либо исключения. В конце концов — подумайте о коллегах. Вы сделаете отладку кошмаром. Даже если отключить break on exceptions, debug output будет захламлён, и полезная информация исчезнет из виду.
Exceptions, Исключения — на то они так и называются. Возникают в исключительных ситуациях.
По поводу цен на бумажные книги — свежая техническая литература стоит немало, да и найти её порой непросто:
www.ozon.ru/context/detail/id/5047621/
Для Siemens SL45, помню, было что-то похожее, но там надо было аккуратно вставлять, и вынимать, придерживая крэдл — это ерунда.
А я такими вещами на Бейсике под DOS занимался. Фонтанчики, горящий огонь…
Лол, вот это новость! А мужики-то не знали. Да там много чего можно делать. Включать фичи, которых нет в комплектации (типа климат-контроля), менять программу управления двигателем (чип-тюнинг). Как бы порт для этого и предназначен.
Ой, простите, это же пост от Ализара.
Во-первых, зачем это? Какие плюсы, минусы, выводы?
Во-вторых, статья называется «ручное управление памятью», а про реализацию управления ничего и не рассказано.
Я посмотрел код. Вся суть «управления памятью» в том, что мы кладём объекты в массив и меняем размер массива при надобности. Стоило это упомянуть в статье. Или я чего-то недопонял?