Как стать автором
Обновить
16
0

Пользователь

Отправить сообщение

Письмо в ютуб и не может особо ни к чему привести. Зато в случае с судебными процессами, суд по умолчанию становится на сторону менее защищенной стороны, т.е. пользователя. Более того, скорее всего сторона защиты просто не явилась бы на судебный процесс и пострадавший автоматически бы получил судебное решение в свою пользу, на которое ютуб уже не смог бы не отреагировать, плюс компенсацию (она вряд ли была бы высокой, но всё равно приятно)

Почему люди не подают в суд в подобных случаях?

Думаю, это самоорганизация, как и большинство других процессов в организме. То есть, митохондрии сами реагируют на изменение окружающих условий, т.е. изменение концентрации питательных веществ. Сложно представить, как могло бы здесь осуществляться "централизованное управление" — только если с помощью какого-либо гормона, что выглядит довольно затратно и избыточно, ведь придётся точно так же реагировать на концентрацию гормона, так почему бы не реагировать просто на концентрацию питательных веществ?

SQL сейчас активно развивается, так что не исключено, что скоро такая поддержка появится. Однако и в настоящий момент, у этой проблемы есть рабочее решение, в виде атомарных распределённых счётчиков .

а то как сеансы связи кофеварок с тостером читат станут?

А ещё слушать вас через микрофоны, наблюдать за вами через камеры, узнавать ваши пароли с помощью вами же поставленных камер.

Всё ещё выглядит как функциональность, которой не должно быть в обычном списке. Видимо, так работают все QT-ые контейнеры? Выглядит как попытка сделать что-то вроде Java в плюсах — накладные расходы, о которых не просит пользователь, в надежде что он не выстрелит себе в ногу.

Не писал под Qt, поэтому не знал этого нюанса. Спасибо за то, что просветили. Однако, интересно же, получается, Qt нарушает подход разделения функциональности. Список должен хранить. Если мне надо расшарить его я создам shared_ptr. А так, получается, нарушение основы плюсов — не платить за то, что тебе не нужно.

Кстати, самого меня ни разу не штрафовали, а когда уходил предложили увеличение зп в 1.5-2 раза и менеджерскую должность. Я отказался, хотя сумма получалась внушительная. Ни разу не пожалел о том решении.

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


Такая система для IT — из разряда вредных советов "как потопить контору"

А что даже если всерьёз? Что вам-то от этого?

Ну я исправил только этот момент и не стал смотреть дальше. Думаю, там есть ещё моменты в подобном ключе. Извините, но я не поверю, что правильно написанный плюсовый код медленнее, чем всё остальное.

Да, это может существенно повлиять на результаты. Например, взять небольшой фрагмент кода из performer.cpp:


if (mSegments.contains(segment.getClustId())) {
    mSegments[segment.getClustId()] << segment;
} else {
    QList<DcfSegment> list;
    list << segment;
    mSegments[segment.getClustId()] = list;
}

Во первых, два поиска по мапу вместо одного (про это уже сказали). Но наиболее характерный код из ветки else, очень характерный для Java и ужасный для C++. По таким моментам очень легко заметить, что вы обычно пишите на Java и плохо разбираетесь в C++. Для джавы код вполне логичен — вы создаёте новый список и помещаете его в мап. Однако в C++ это будет выполняться так: вы создаёте сначала временный экземпляр класса, кладёте в него элемент, потом создаёте ещё один список внутри хэшмапа, присваиваете локальный список тому, что находится в хэшмапе, при этом по новой происходит выделение памяти в хипе и копирование всего содержимого (пусть это даже всего один элемент), после чего локальная копия уничтожается с освобождением памяти. Итого, у вас лишние поиски по хэшмапу, лишние копирования, и лишние операции с памятью, которые достаточно дорогие.


Но важнее всего то, что здесь вообще не нужен if и ветвление. Создание нового списка происходит при вызове оператора []. Плюсовик написал бы вместо всего этого одну строчку, которая при этом и работала бы быстрее:


mSegments[segment.getClustId()] << segment;

Информация интересная, если принять её на веру. Но все тут люди опытные, к информации относятся критически и для многих (например для меня) множество пассажей выглядят очень сомнительными, как и полученные результаты. Статьи содержащие сомнительную информацию минусят, и это правильно.

Да-да, спасибо, ошибся с термином.

Отдавать сишным функциям указатели на внутренности плюсовых классов всегда было небезопасно, так что тут ничего не поменяется. Что касается того, чтобы писать используя С-строки — это намного менее безопасно и удобно. Пример типичных компонентов, где string_view может дать большой прирост производительности — различные парсеры, которым накладно выделять память, каждый раз, когда они хотят отдать пользователю токен.

Вопрос не в удобстве а в быстродействии. Если вы на место std::srting& передадите const char* произойдёт неявное копирование с выделением памяти в хипе. Здесь — не произойдёт. Если вам нужна 0-терминированная строка, вы всегда можете скопировать string_view в string явно.

Сама необходимость явно вызывать c_str() означает, что пользователь должен знать об этом ограничении, чтобы его невелировать. Отсутствие c_str() у string_view будет ему намекать, что с этим классом так делать нельзя. В общем, не выглядет для меня серьезной проблемой.

Ну да, не будет этот класс совместим с частью сишных функций, хотя про тысячи багов это вы, конечно, преувеличили. Плюсовые функции не ожидают 0 в конце строки, проблемы могут возникнуть только с некоторыми сишными функциями, с которыми в любом случае надо быть осторожным, при работе из плюсов. Очевидно, что string_viewпросто абстракция над парой (const char* data, size_t len), так что по другому и быть не могло.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность