И вот мы пришли к
if (c>='0' && c<='9')
с которого начинали :-)
Серьёзно: case не нужен (c у нас всегда char, это не часть алгебраического типа), when от if ничем не отличается (у нас императивщина, не забыли?)
Это всё прекрасно и отлично решает свои задачи (диспатч по типу и декомпозиция объекта — просто, понятно, без оверхеда и места для глупых ошибок).
Но я говорил о более простых вещах. Обратите внимание на диапазоны в моём примере. #0..#31, '0'..'9', 'A'..'Z'. Дико бесит, что в C вместо них сделали какой-то невнятный костыль с проваливанием в следующий кейс, если не написал break.
Ничем не плох, но не покрывает некоторые нужды.
К примеру, привычная задача посимвольной обработки строки. Характерный код на паскале:
case c of
#0..#31 : skip_char();
' ' : process_space();
'0'..'9' : process_digit(c);
'A'..'Z' : process_alpha(c);
end;
Как записать просто и понятно? (да, я в курсе, что жизнь стала сложнее и символ по нынешним временам может занимать 4 байта, а то и более, но мне хотя бы в рамках ASCII)
Ну просто после сравнения установившихся значений светового потока и энергопотребления (основные параметры) смотреть на график можно только любопытства ради.
И я не думаю, что изготовитель «ваял» переходные характеристики. Он в курсе, что покупатель будет в первую очередь смотреть не на них, а на яркость.
Разве что можно схалявить и сделать лампу в первый момент поярче — чтобы при проверке перед покупкой покупатель решил, что всё Ok). Т.е. «ваять» имеет смысл красную кривую, а никак не чёрную (чтобы при одинаковых установившихся параметрах выиграть в начальных), да и то сомнительно.
Нормировать имеет смысл или на разницу между начальной и конечной (так хорошо видно экспоненту), или на крайняк на максимум в кельвинах (бывает интересно для металлов).
Нормировать на максимум в градусах цельсия бессмысленно, т.к. ноль в шкале цельсия взят от балды.
В голову бы не пришло сравнивать лампы по графикам, нормализованным на начальные значения.
Вы действительно с этого начали или это только для создания интриги?
Взять из ML (F#) pattern matching — конечно, тоже польза, но он хорош для функционального стиля.
А я говорил про совсем простую вещь для императивщины — диапазоны значений в case.
Ну и убрать слово case у меток, как ненужное.
Ну, справедливости ради — не все. Тот же ущербный C-шный синтаксис switch-case остался, добавилась лишь защита от совсем уж дурацких ошибок.
С for понятно — foreach решает практически все задачи, кроме циклов в вычмате.
Да, с for сейчас за счёт всевозможных foreach полегче стало.
Switch с break по дефолту — гуд, но ещё желательна адекватная запись (уж на что 20 лет назад апологеты C ругали паскаль за многословность — такой кучи слов case в нём нет) и поддержка диапазонов (типа 0..31).
Радует запись в Haskell, но он всё же весьма специфичен и не мейнстрим ни разу.
Актуальные реализации паскаля — это прекрасно, но будем смотреть правде в глаза: паскаль мёртв. Его вытеснили другие языки. 2% распространённости — это агония, вероятно, на поддержке старых проектов.
А вот украсть из него (в линейку си-подобных) удачные решения — было бы неплохо.
Странно, что никто не вспомнил старый добрый паскаль. Уже больше 15 лет, как перешёл на C-подобные языки, но каждый раз, как пишу switch (и иногда for) — с тоской думаю о том, что просрали язык, где это было сделано по уму...
Видимо, потому, что появление новых поисковых систем и смерть старых происходит у всех на глазах. Вы помните альтависту? А давно вы искали что-то в yahoo?
Так что есть основания считать, что если новый честный поисковик будет лучше гугла — он может и вытеснить гугл.
Я не призываю лично вас строить этот поисковик, но я уверен, что если он нужен (и для пользователей действительно будет лучше нынешних) — он появится и победит. Или нынешние гиганты подкрутят свои алгоритмы, чтобы сражаться на равных.
По опыту нескольких роботов-пылесосов — вряд ли помешаете. Мощность у них несопоставима с обычным пылесосом, уровень шума тоже.
Так что самый полезный наворот к нему — не расписание и не удалённое управление, а база, как у Кёрхер — чтобы пылесос туда заехал и сам выложил весь мусор.
Описания волнового алгоритма, которые я встречал, не конкретизируют, как именно перебирать точки фронта. Говорится лишь "для каждой точки, помеченной на предыдущей итерации..."
Никто, у кого опыт программирования хотя бы полгода, не будет для поиска помеченной точки перебирать весь массив.
Если поищете упоминания сложности волнового алгоритма — найдёте O(n²). Довольно-таки прозрачный намёк.
Хм… Беда в том, что если у вас не супер-пупер-дупер офигенная команда и куча денег на разработку — то browser-like приложение будет кривым недобраузером.
Характерный пример — приложение aliexpress, в котором даже табов (чуть ли не основной функционал для современного браузера) нет. И осовная польза от него — скидки за заказ в мобильном приложении. Найти товар на сайте и заказать через приложение — оригинально-с.
Так что если ваше приложение построено вокруг webview — это повод задуматься, нужно ли оно вообще.
Да ладно, кто ж будет обходить все клетки для поиска фронта, когда можно фронт держать в виде списка или массива?
Всей разницы — для Дейкстры приходится держать очередь с приоритетами, т.к. шаги до соседних вершин имеют разную длину.
И вот мы пришли к
if (c>='0' && c<='9')
с которого начинали :-)
Серьёзно: case не нужен (c у нас всегда char, это не часть алгебраического типа), when от if ничем не отличается (у нас императивщина, не забыли?)
Это всё прекрасно и отлично решает свои задачи (диспатч по типу и декомпозиция объекта — просто, понятно, без оверхеда и места для глупых ошибок).
Но я говорил о более простых вещах. Обратите внимание на диапазоны в моём примере. #0..#31, '0'..'9', 'A'..'Z'. Дико бесит, что в C вместо них сделали какой-то невнятный костыль с проваливанием в следующий кейс, если не написал break.
Ничем не плох, но не покрывает некоторые нужды.
К примеру, привычная задача посимвольной обработки строки. Характерный код на паскале:
Как записать просто и понятно? (да, я в курсе, что жизнь стала сложнее и символ по нынешним временам может занимать 4 байта, а то и более, но мне хотя бы в рамках ASCII)
И я не думаю, что изготовитель «ваял» переходные характеристики. Он в курсе, что покупатель будет в первую очередь смотреть не на них, а на яркость.
Разве что можно схалявить и сделать лампу в первый момент поярче — чтобы при проверке перед покупкой покупатель решил, что всё Ok). Т.е. «ваять» имеет смысл красную кривую, а никак не чёрную (чтобы при одинаковых установившихся параметрах выиграть в начальных), да и то сомнительно.
Скорей просто удешевлял…
Нормировать имеет смысл или на разницу между начальной и конечной (так хорошо видно экспоненту), или на крайняк на максимум в кельвинах (бывает интересно для металлов).
Нормировать на максимум в градусах цельсия бессмысленно, т.к. ноль в шкале цельсия взят от балды.
В голову бы не пришло сравнивать лампы по графикам, нормализованным на начальные значения.
Вы действительно с этого начали или это только для создания интриги?
Взять из ML (F#) pattern matching — конечно, тоже польза, но он хорош для функционального стиля.
А я говорил про совсем простую вещь для императивщины — диапазоны значений в case.
Ну и убрать слово case у меток, как ненужное.
Ну, справедливости ради — не все. Тот же ущербный C-шный синтаксис switch-case остался, добавилась лишь защита от совсем уж дурацких ошибок.
С for понятно — foreach решает практически все задачи, кроме циклов в вычмате.
Да, с for сейчас за счёт всевозможных foreach полегче стало.
Switch с break по дефолту — гуд, но ещё желательна адекватная запись (уж на что 20 лет назад апологеты C ругали паскаль за многословность — такой кучи слов case в нём нет) и поддержка диапазонов (типа 0..31).
Радует запись в Haskell, но он всё же весьма специфичен и не мейнстрим ни разу.
Актуальные реализации паскаля — это прекрасно, но будем смотреть правде в глаза: паскаль мёртв. Его вытеснили другие языки. 2% распространённости — это агония, вероятно, на поддержке старых проектов.
А вот украсть из него (в линейку си-подобных) удачные решения — было бы неплохо.
Странно, что никто не вспомнил старый добрый паскаль. Уже больше 15 лет, как перешёл на C-подобные языки, но каждый раз, как пишу switch (и иногда for) — с тоской думаю о том, что просрали язык, где это было сделано по уму...
Я подумывал об аналогичном, но пришёл к выводу, что при необходимости проще переснимать записи смартфоном.
Вы меня шокировали.
Не поведением провайдера, а тем, что часть трафика идёт мимо VPN. Как так?!
Видимо, потому, что появление новых поисковых систем и смерть старых происходит у всех на глазах. Вы помните альтависту? А давно вы искали что-то в yahoo?
Так что есть основания считать, что если новый честный поисковик будет лучше гугла — он может и вытеснить гугл.
Я не призываю лично вас строить этот поисковик, но я уверен, что если он нужен (и для пользователей действительно будет лучше нынешних) — он появится и победит. Или нынешние гиганты подкрутят свои алгоритмы, чтобы сражаться на равных.
По опыту нескольких роботов-пылесосов — вряд ли помешаете. Мощность у них несопоставима с обычным пылесосом, уровень шума тоже.
Так что самый полезный наворот к нему — не расписание и не удалённое управление, а база, как у Кёрхер — чтобы пылесос туда заехал и сам выложил весь мусор.
Ну, кто как, а я обращу внимание на иконку звука в таб баре — и сайт отправится в чёрный список за компанию с прочими, кто без спроса включает звук.
Хм… Беда в том, что если у вас не супер-пупер-дупер офигенная команда и куча денег на разработку — то browser-like приложение будет кривым недобраузером.
Характерный пример — приложение aliexpress, в котором даже табов (чуть ли не основной функционал для современного браузера) нет. И осовная польза от него — скидки за заказ в мобильном приложении. Найти товар на сайте и заказать через приложение — оригинально-с.
Так что если ваше приложение построено вокруг webview — это повод задуматься, нужно ли оно вообще.
Да ладно, кто ж будет обходить все клетки для поиска фронта, когда можно фронт держать в виде списка или массива?
Всей разницы — для Дейкстры приходится держать очередь с приоритетами, т.к. шаги до соседних вершин имеют разную длину.
Дык вроде алгоритм Дейкстры — это по сути и есть заливка, только для более общего случая...
"Я сделал домашку, но 32-битный индекс переполнился" :-)