Здравствуйте, Тёмчик, Вы писали:

Тё>Ну вот, а всё "индусокод". "руссокод"
Артёмкакод, Артёмка...

Здравствуйте, Тёмчик, Вы писали:

KP>>Я лично занимаюсь прорывными задачами в прорывной области. <b>Детали</b> после 2023, пока никак нельзя рассказать
Тё>Ну понятно, надуваешь щёки

У нас в области всё или почти все под NDA. Я не вижу смыслу в его нарушении ради того, что бы Тёмчик снова не понял о чем речь идет и начал про крутость JS вещать

KP>>Ты бы лучше микросервисы на PHP писал
Тё>Для микросервисов есть node и go.

Микросервисы — говно. Через лет 5-10 ты это тоже поймешь

Здравствуйте, Shmj, Вы писали:


S>Что происходит?

У людей нет выбора.
Ребенком пришлось забирать с пасьбы овец дядькиных.
Выяснилось, что они совершенно не соображают куда идти, и только когда все стадо бежит
только тогда наблюдается какой-то вектор.
А так да, выбрал бы лиспы(C# не сильно лучше плюсов).

(defstruct point x y)

(defvar p1 (make-point
        :x 1
        :y 1))
  
(defvar p2 (make-point
        :x 1
        :y 1))

(defvar p3 (make-point
        :x 11
        :y 1))

(when (equalp p1 p2)
    (write-line "p1 eq p2"))

(when (not (equalp p1 p3))
    (write-line "p1 not eq p2"))    

(defgeneric toStr (obj))
(defmethod toStr ((obj point))
  (format nil "[Point: x=~A, y=~A]"
      (point-x obj)
      (point-y obj)))

(defvar notPoint 1)

(dolist (e (list p1 p2 p3))
  (write-line (toStr e)))

(handler-case (toStr notPoint)
  (error (c)
    (format t "Ошибка дорогой!~%")
    (values 0 c)))

Здравствуйте, кубик, Вы писали:

К>Привет,
К>Прочел что чел программировал 17 лет что составляет 2/3 его жизни и что он устал. Он еще статьи какие то читает по С++ (во странный...)
К>Дальше я читать поленился.
К>Я так думаю что С++ тут не причем, может человек влюбился, авитаминоз, может просто он не видит результатьов своего труда...

Да, вы видимо правы. Проблема не в инструменте, а в аутпуте твоих усилий при использовании. Под output'ом я имею ввиду — признание начальства как минимум, как максимум видеть миллионы счастливых юзеров.

Я писал такой же пост 10 лет назад, он висит как раз под этим из ТС. Писал потому что сломал голову, пока писал какой-то примитивный сканер вирусов. Год писал. До этого еще 10 лет вбухал в изучение.

С тех пор ушел на C# и был доволен. Хотя истинное удовольствие испытал относительно недавно, когда мое приложение "взлетело" и я вижу сколько людей им пользуются каждый день. Аминь.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, landerhigh, Вы писали:

L>>Инженер должен уметь применять готовые решения, а не городить велосипед на каждый чих, разве нет?
CC>Инженер должен находить оптимальные решения а не "сводить задачу к предыдущей", дозабивая едва воткнутый гвоздь по шляпку.

Если нужен tar, самое оптимальное решение — скачать tar и не морочить себе моск.

А тут речь идет о "тестовом задании", оптимальность которого определяется собеседователем.

Здравствуйте, Тёмчик, Вы писали:

Тё>http://reactivex.io/RxCpp/.

Это значит, что если вам потребуется паттерн Observer, то вы сходу затащите в проект самое тяжелое и монстроузное из имеющегося на рынке, но зато модное и молодежное?

Здравствуйте, CreatorCray, Вы писали:

S>>По мне, так сложным можно назвать, например, такое
CC>За такое надо бы тапком.

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

А для библиотеки, да еще с оглядкой на старые стандарты C++, вполне себе ничего.

Здравствуйте, so5team, Вы писали:


S>Сходу не понятно, какой смысл здесь использовать std::list, а не std::vector.

Удаление из середины. Незнание как сделать для вектора эффективно или нежелание заморачиваться. Дупликаты при засовывании тоже не отслеживаются наверное от лени.

Здравствуйте, andyp, Вы писали:

S>>Сходу не понятно, какой смысл здесь использовать std::list, а не std::vector.

A>Удаление из середины. Незнание как сделать для вектора эффективно или нежелание заморачиваться. Дупликаты при засовывании тоже не отслеживаются наверное от лени.

Там каждый элемент -- это два указателя, т.е. 16 байт в 64-х битном режиме. Если планируется хранить не более десятка-двух подписчиков, то удаление из середины vector-а на современных процессорах будет эффективнее, чем оное в list-е. Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.

Плюс сюда же добавляем и то, что при добавлении новых элементов в list в разное время соседние по list-у элементы скорее всего будут располагаться далеко друг от друга в памяти. Т.е. даже проход от начала списка к концу для нотификации окажется менее эффективным, чем такой же проход по vector-у.

Здравствуйте, varenikAA, Вы писали:

Хорошее в мире IT не приживается. Всюду C++ и прочие голанги и бидоны вместо лиспа, докеры вместо solaris zone, линуксы вместе благородных юниксов и BSD.

Здравствуйте, so5team, Вы писали:

>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.

Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?

Здравствуйте, Тёмчик, Вы писали:

Тё>Даже когда я писал на C++, такое говнище не делал.

Есть твой код с открытыми исходниками?
Если есть — ссылку дай.

Здравствуйте, smeeld, Вы писали:

>>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.

S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?

Если бы у бабушки ..., то это был бы дедушка.

Мы же не про сфероконей в вакууме разговариваем, а о конкретном примере кода. В котором хранятся, по сути, POD-ы объемом либо в 8, либо в 16 байт (в зависимости от архитектуры). И который вряд ли предназначен для хранения более 2-3 обработчиков (ну ладно, пусть будет даже десяток).

Даже на миллионах тяжелых объектов может оказаться, что list<T> сольет вчистую какому-нибудь специализированному chunked-list-у с unique_ptr<T> внутри.

Здравствуйте, smeeld, Вы писали:

S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?

Приведенный код — реализация обсервера.
Если подписчиков вдруг ни с того ни с сего — миллионы, то у этого кода есть проблемы посерьезнее стоимости удаления из середины вектора.

Здравствуйте, smeeld, Вы писали:

S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?

удаление из вектора для данного кейса (когда порядок элементов не важен) это O(1) операция, т.е. не зависит от размера вектора

Здравствуйте, smeeld, Вы писали:

S>Хорошее в мире IT не приживается. Всюду C++ и прочие голанги и бидоны вместо лиспа, докеры вместо solaris zone, линуксы вместе благородных юниксов и BSD.

В одной крупной финансовой компании есть современная система в продакшене. Написана на Scheme.
Не может оно быть мейнстримом. Академическая лаконичность разбивается о суровые реалии.

Здравствуйте, Умака Кумакаки, Вы писали:

УК>удаление из вектора для данного кейса (когда порядок элементов не важен) это O(1) операция, т.е. не зависит от размера вектора

Что ты заливаешь? Удаление из list это O(1), так как там всего лишь перекинуть prev-ы и next-ы. Для удаления из массива нужно или искать его в массиве, причём линейным брутфорсом, а не бинарным поиском, так как не массив неупорядочен, или при закидывании в массив сохранять индекс, и при удалении сдвигать все эелементы с изменением их индексов. И это вместо перекыдвания prev-ов и next-ов. Что касается упоянутого so5stream-ом неэффективного расхода памяти, при использовании list-а, то это, наверно, в его практике такое возможно. Обычно в нормальных проектах пилятся свой аллокаторы памяти для объектов, выделяющих память из пула, и хранящих сами куски в линейных массивах. Объекты для list будут жить там.

Здравствуйте, Тёмчик, Вы писали:

Тё> клона Maven которому 20 лет,

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

Тё>и кривая тормозная попытка клона ко-рутин с Питона, которым тоже 20 лет, ощущение, что попал на машине времени в диал-апные времена.

Здравствуйте, so5team, Вы писали:


S>Там каждый элемент -- это два указателя, т.е. 16 байт в 64-х битном режиме. Если планируется хранить не более десятка-двух подписчиков, то удаление из середины vector-а на современных процессорах будет эффективнее, чем оное в list-е. Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.

Есть же эффективная схема, если порядок элементов в векторе не важен — поменять местами с последним и удалить.

S>Плюс сюда же добавляем и то, что при добавлении новых элементов в list в разное время соседние по list-у элементы скорее всего будут располагаться далеко друг от друга в памяти. Т.е. даже проход от начала списка к концу для нотификации окажется менее эффективным, чем такой же проход по vector-у.

А то. Локальности не будет.

Здравствуйте, smeeld, Вы писали:

S>Что ты заливаешь? Удаление из list это O(1), так как там всего лишь перекинуть prev-ы и next-ы. Для удаления из массива нужно или искать его в массиве,

Ага, а в списке он сам себя находит