А почему в Яндекс картах не используется SVG?
Браузер сам отлично справляется с прорисовкой/парсингом/обработкой контуров (возможно даже рисуется с аппаратным ускорением).
SVG лучше подходит для печати с высоким DPI, чем растровые картинки сейчас.
Похоже Ваше мнение о сложности std::list не популярно, как и моё :).
По сути «химера» это лишь дополнительное поле размера, которое создаёт линейную сложность лишь при вставке части от другого списка.
Однако при вставке другого списка целиком — сложность константна (т.к. размер вставляемого списка известен).
Исходя из структуры данных «двусвязный список», линейная сложность вставки куска из другого списка действительно «сюрприз». Но для универсальной библиотеки контейнеров это лучше, так как многие другие операции будут эффективнее. Это можно понять и простить :).
А почему люди должны быть с ним согласны?
Я, например, не согласен с тем что они «улучшили» сложность size() в std:list до константы за счёт других операций.
Стандарт можно только понять и простить :)
Название статьи на мой взгляд не отражает что сам чат во главе это Stream API. А Python, Django и React по сути лишь обвязка для рекламируемого сервиса.
В коде написаны явные вызовы size() и оператора индексирования [] для каждого элемента массива. Для такой простой операции как увеличить на 1 — это может быть довольно накладно.
Код работает даже лучше, чем написан. В чём извращение? :)
Без глубокого погружения в тему смарт-контрактов продуктивная дискуссия с обществом не представляется возможным, особенно по китайской документации :).
На мой взгляд — редактировать Main при добавлении каждой новой функции излишне, лучше чтобы сами функции там регистрировались, например, при помощи декоратора.
В частных распределённых бухгалтерских книгах смарт-контракты являются одним из тех терминов, которыми консультантами разбрасываются без особого внимания к чётким определениям или цели. Консультанты по корпоративному программному обеспечению обычно зарабатывают на двусмысленности, а смарт-контракты — апофеоз корпоративного мракобесия, потому что их можно определить буквально как что угодно.
Оно там и было, исходя из механики игры после прицеливания предмет должен был попадать без промаха.
Просто чемодан очень медленно передвигался, на других предметах не так заметно.
Какой-то не до конца асинхронный пример получился :)
Нужно как-то ближе к реальности.
Пока резал морковку — вода уже выкипела, нужно залить новую.
Не успел порезать лук — морковка переварилась.
Чтобы резать — нужен нож и доска… и прочие прелести асинхронности
У меня тупой вопрос:
Каким образом при добавлении морковки и лука мы знаем что они уже порезаны?
По куску кода явных await там нет, хотя это вроде как длительный процесс, первый кандидат на async.
Как «повар» я сразу могу начать кипятить воду, а также резать морковку и лук.
При этом когда готовы вода+морковка её можно добавить в воду и продолжать резать лук, который добавить потом, после того как морковка сварится.
Хорошая статья по ссылке для отрисовки фигур, но для небольшого размера шрифта в пикселах карта текстур (точнее даже атлас, как написали ниже) будет лучше и быстрее.
Софтварный растеризатор шрифта для малых размеров учитывает хинты / привязку к пикселям для хорошей читаемости. А текстура не требует многократной перерисовки одного и того же фрагмента.
Журналисты «Интернэшнл геральд трибюн» ну никак не могли подождать пока публикация романа завершится. Какое-то странное отношение к читателям Артура Кларка.
На мой взгляд стоило бы продолжить публикацию романа, хуже от этого вряд ли было бы.
А так перебои в публикации привлекли ненужное внимание читателей к этой теме.
Браузер сам отлично справляется с прорисовкой/парсингом/обработкой контуров (возможно даже рисуется с аппаратным ускорением).
SVG лучше подходит для печати с высоким DPI, чем растровые картинки сейчас.
А потом попросят добавить фонетическую сортировку в Японском и желание писать "свои" сортировки с хардкод-таблицами куда-то пропадёт :)
Со стороны пользователей мобильных устройств не хотелось бы тратить заряд батареи на такие вычисления :)
Думаю легенды обошлись бы одним вызовом, а не пятью :)
У нормальных градиентов нет проблемы с алиасингом
По сути «химера» это лишь дополнительное поле размера, которое создаёт линейную сложность лишь при вставке части от другого списка.
Однако при вставке другого списка целиком — сложность константна (т.к. размер вставляемого списка известен).
Исходя из структуры данных «двусвязный список», линейная сложность вставки куска из другого списка действительно «сюрприз». Но для универсальной библиотеки контейнеров это лучше, так как многие другие операции будут эффективнее. Это можно понять и простить :).
Я, например, не согласен с тем что они «улучшили» сложность size() в std:list до константы за счёт других операций.
Стандарт можно только понять и простить :)
Название статьи на мой взгляд не отражает что сам чат во главе это Stream API. А Python, Django и React по сути лишь обвязка для рекламируемого сервиса.
Код работает даже лучше, чем написан. В чём извращение? :)
На мой взгляд — редактировать Main при добавлении каждой новой функции излишне, лучше чтобы сами функции там регистрировались, например, при помощи декоратора.
habr.com/ru/post/475022
Просто чемодан очень медленно передвигался, на других предметах не так заметно.
Тем более в оригинальной статье это был JPG в 119 КБ.
Нужно как-то ближе к реальности.
Пока резал морковку — вода уже выкипела, нужно залить новую.
Не успел порезать лук — морковка переварилась.
Чтобы резать — нужен нож и доска… и прочие прелести асинхронности
Каким образом при добавлении морковки и лука мы знаем что они уже порезаны?
По куску кода явных await там нет, хотя это вроде как длительный процесс, первый кандидат на async.
Как «повар» я сразу могу начать кипятить воду, а также резать морковку и лук.
При этом когда готовы вода+морковка её можно добавить в воду и продолжать резать лук, который добавить потом, после того как морковка сварится.
Хорошая статья по ссылке для отрисовки фигур, но для небольшого размера шрифта в пикселах карта текстур (точнее даже атлас, как написали ниже) будет лучше и быстрее.
Софтварный растеризатор шрифта для малых размеров учитывает хинты / привязку к пикселям для хорошей читаемости. А текстура не требует многократной перерисовки одного и того же фрагмента.
На мой взгляд стоило бы продолжить публикацию романа, хуже от этого вряд ли было бы.
А так перебои в публикации привлекли ненужное внимание читателей к этой теме.