serge-phi

Спасибо за ответы, я понял суть возможной проблемы. Я не использую долгосрочные блокировки, поэтому про дедлок не подумал.

А для чего создается отдельный lock? Почему нельзя сделать lock(this)? C C# работаю не так давно, поэтому это не критика, а запрос информации.

Может и к лучшему, что молодежь не знает про списки. Для небольшого набора данных лучше использовать массив, для большого — хеш-таблицы или деревья. Почти никогда за тридцатилетнюю практику не использовал списки.

По личному опыту, x2go работает побыстрее rdp. Рекомендую попробовать.

Усложнение кода и замедление операций преобразования.
Я бы динамической хеш-таблицей расширил диапазон [0..255] до [-1000..1000]. Хотя это и не очень тривиально в многопоточной среде.

Официально не приобрести, насколько я знаю.
Не думаю, что у тех, кому эта информация требуются, возникнут хоть какие-нибудь затруднения с опсосами. А те, у кого возникнут — видимо не имеют полномочий запрашивать подобные данные. В общем, вопрос остается.

C QIWI не очень понятно. Кошелек привязан к сим-карте посредством номера телефона. Сим-карту без идентификации не приобрести. Зачем же еще раз на сайте вводить идентификационные данные, если владельца кошелька и так можно определить по номеру телефона? Из-за «серых» симок?

Задачи разные бывают. Зачастую закешировать результат запроса в памяти клиента эффективнее, чем занимать ресурсы сервера.

Писатели кода может и счастливы, а вот читатели — не очень, как мне кажется. Сделать одно и то же несколькими способами — это не всегда преимущество.

У человека семья, ее надо обеспечивать, что может быть затруднительно до того момента, пока стабильно не устроился на новом месте. Кардинальные изменения в жизни трудно предпринимать, когда на тебе ответственность за других. Я говорил про что-нибудь менее радикальное, типа изучения новой технологии, участие в открытом проекте и тому подобное. Нечто, что приносит удовлетворение и при этом не влияет на благополучие близких.

> Мне сейчас 26, у меня двое детей, я перестал расти и развиваться, и я не верю, что скучное течение моей жизни когда-нибудь изменится.

Может в этом и заключается проблема? Когда настроение плохое, то и все вокруг кажется плохим. Релокация тут не поможет, нужно искать интерес в жизни.

Использование «else» не очень интуитивно. Не зная язык, логично предположить, что код ветки «else» вызывается, если не было ни одной итерации.

Не нужно забывать и о том, что камеры могут не только упрощать поиск преступников, но и своим наличием предотвращать преступления. Вы ведь снижаете скорость, когда знаете, что на дороге установлена камера, фиксирующая нарушение скоростного режима. Но везде нужно знать меру. Действовать по английскому сценарию, а не по китайскому.

А причина беспокойства какая? Вроде наоборот спокойнее — под камерой может и не станет толпа гопников убивать.

И client/server.

Да, пока без гибридного решения с использованием оффлайн-касс в местах с нестабильной связью не обойтись. Но если процент таких точек не очень большой, то выгода от перевода кассы в облако может быть значительной. Особенно с учетом того, что ФН тоже может быть в облаке, а на точках только чековые принтеры.

Я думаю, бюджет будет меньше, чем стоимость использующегося в настоящий момент лицензий ПО. Вопрос связи с удаленными точками действительно острый. Но время идет, интернет уже стал почти как электричество, думаю в ближайшие несколько лет решат.

Про перенос ПО в облако не задумывались? Решит проблему с обновлением и сохранностью данных, на POS будет запускаться только сервер оборудования и тонкий клиент. Или сильно завязаны на текущее ПО?

Я и не говорил, что дженерики не нужны. Я объяснил опасность подобных кастов.

Подозреваю, что похожие касты возникают, когда надо побыстрее накодить костыль (говорю это без осуждения, самому приходится заниматься костыльным программированием из-за нехватки времени). По хорошему надо добавить добавить метод «print» в интерфейс «geometry». Язык тут ни при чем. Вопрос цены изменения кода. Если этот интерфейс реализует не три класса, а три тысячи, то костыль с кастом будет быстрее закодировать. Но этот костыль потом с большой вероятностью воткнется в спину, когда через некоторое время нужно будет добавить три тысячи первый класс, реализующий интерфейс «geometry», а человек, который добавляет новый класс, не в курсе про этот костыль.

Понял. Смутило memcmp в названии функции.

Что-то совсем уже сонный. Конечно

...
if (p1 == NULL)
  return -1;
else if (p2 == NULL)
  return 1;
...

Я не понимаю return *p1_u8/return *p2_u8

А так PVS будет ругаться?

i32 bxi_memcmp(const void * p1, const void * p2, u32 cnt)
{
    if (!cnt || (p1 == p2))
        return 0;
    else if (p1 == NULL)
        return 1;
    else if (p2 == NULL)
        return -1;
    else {
        const u8   * p1_u8 = p1;
        const u8   * p2_u8 = p2;
        const pu_t * p1_pt = p1;
        const pu_t * p2_pt = p2;
        ..........
    }
}

Потому что завтра может возникнуть задача, для которой нет библиотечного решения.

Как боролись с задержками от сборки мусора? Использовали предварительное выделение памяти и отключали сборщик?

Это делается в том числе и для доказательства того, что язык тьюринг-полный.

Похоже на то. Go, кстати, не совсем к месту в этом списке. Очень консервативная штука. Я совсем не понимаю, откуда вокруг него столько хайпа у молодежи. Из-за гугла что-ли?

Глупое предположение. Как можно апеллировать к авторитету в интернете? Ключевое слово «промышленный».
Такой софт живет десятки лет и переживает смену многих программистов. Для такого софта тотальная огороженность и упрощенность Go очень подходит.

Смысл фразы во второй части предложения, а не в возрасте.

Повзрослел человек, сменились ценности. Вместо интереса процесса стал важнее простой и надежный результат.

Я по возрасту ближе к Пайку и занимаюсь промышленным программированием более тридцати лет, поэтому разделяю его подход к разработке языка. И я не считаю неопытных программистов быдлокодерами.

Когда нормальная работа подсистемы невозможна, то она должна быть отключена. Для этого нужно ее соответствующим образом запрограммировать (в виде процесса или потока). А исключительные ситуации удобны для разработки библиотек, а в обычном коде ошибки надо обрабатывать, а не перебрасывать их «вышестоящему коду».

В вышеприведенном коде нет обработки ошибок, только их переброс наверх. Подход Go подталкивает к обработке ошибок, а не на отсылку их выше в надежде, что кто-нибудь разберется.

Тернарный оператор в Lua и не нужен. (cond? true_val: false_val) в Lua выглядит так: (cond and true_val or false_val)

github.com/avelino/awesome-go#advanced-console-uis

termbox-go неплох

Я не утверждаю, что исключения — это зло, которое должно быть искоренено. Я просто говорю, что и без исключений можно жить, поэтому неправильно делать вывод о том, что язык такой-то — это мусор, потому что в нем нет исключений.

Потому что я не согласен с тем, что Go — это мусор из-за отсутствия поддержки исключительных ситуаций. Полезность исключительных ситуаций вообще спорна.
google.github.io/styleguide/cppguide.html#Exceptions
llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions

Довольно спорный вывод. В Go panic используется для сигнала об ошибке программиста, а не работы программы (кроме самых простых случаев, напр. panic(«command line argument error...»)). То есть обычно panic используется для эмуляции assert. Пришельцы из языков с поддержкой исключительных ситуаций пытаются использовать panic/recover для эмуляции исключительных ситуаций, но это не приветствуется.

Два раза сталкивался с подобной ситуацией. Провайдер менял мой ip на достаточно удаленный от обычного (я в Калуге, ip менялся на Пермский). Первый раз в панике менял все пароли везде где только можно, во второй раз посмотрел, какой у меня текущий ip-адрес, и понял суть проблемы.