Как стать автором
Обновить
@vamirehread⁠-⁠only

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

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

Мы с удовольствием прочитали ваше мнение, и оно какое-то извращённое, но никак не соотносится с комментарием, на который вы отвечали.

Соевым же скажу следующее: пожалуйста, никогда, ни при каких условиях не возвращайтесь! Здесь страшно: кровавый мордор, мобилизация, отсутствие демократии и смеются над грузинскими массажистами и прочими меньшинствами большинствами цивилизованных стран. Вас же ждут в райском саду - езжайте туда, там ваши навыки и умения оценят по достоинству. Пожалуйста, не возвращайтесь!

Читатель, очевидно, не знает, что у std::unique_ptr нет конвертирующего конструктора из raw pointer

Совсем забыл, что нужный конструктор explicit.

Промазал, это ответ @KanuTaH

У читателя также может возникнуть вопрос: "Зачем было заменять emplace_back на push_back"?

У читателя совсем другой вопрос: зачем было добавлять std::make_unique? Ведь вы говорите

Контейнер modificators – это двусвязный список "умных" указателей std::unique_ptr

Значит, метод push_back уже принимает std::unique_ptr.

Хотя, в ответ наверняка будет что-то, сводящееся к "явное лучше неявного"...

Вообще хорошая манера делать конструкторы noexcept

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

достойный скрам-мастер

Именно такую и отправят в декрет. А недостойные будут работать.

Хех, сколько во мне сексизма, аж самому приятно

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

Кроме того, как говорилось выше, функции-члены могут быть объявлены без = default, а определены именно с = default. Таким образом в будущем можно будет написать свою реализацию - это способствует минимальной перекомпиляции клиентов и бинарной совместимости.

В C++17 RVO - это не просто оптимизация, а обязанность компилятора в оговорённых случаях, даже если у типа нет конструкторов копирования/перемещения. Как можно видеть, в C++14 такого ещё нет.

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

И это всё как раз в ответ на мой комментарий, где я говорю, что именно таково лицемерное лицо хабровчан. Браво! Не снижайте накал борьбы! Не останавливайтесь!

У вас есть план или вы просто подстрекаете к свержению действующей власти?

В этой попытке уйти от сути разговора как-то окончательно угас огонёк сарказма и иронии.

И пока что вы выглядите как верун в справедливый мир.

С точностью до наоборот: я указываю, что хабровчане такие же, как их представления об оппонетах. Искренне надеюсь, что они поднажмут в своих попытках доказать мою неправоту, и я более не смогу комментировать раз в час и наконец-то пойму глубину своего заблуждения в read-only.

Люди протестуют там и таким образом, где их протест имеет хоть какой-то видимый эффект.

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

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

Не знаю кто "этот", но понимает неправильно. Мой тезис так и не понят: на хабре одни и те же люди одновременно и возмущаются ограничениям в общественно-политической жизни, и сливают карму людям с противоложной политической позицией. И не видят в этом никакого диссонанса.

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

Можно ли узнать, как проверялось, какая позиция имеет поддержку в народе

Конечно же неправильно проверялось, ведь все выборы подтасованы, а несогласные гниют в зиндане.

Но я так понимаю, что по сути моего комментария - сливанию кармы на хабре за политичекую позицию, но при этом возмущению ограничениям - у вас вопросов не возникло.

учитывая, что публичное проявление неугодных позиций - административно и уголовно наказуемо?

И вы уже ждёте чёрный воронок за этот комментарий? Или вы осуществили тракторную мечту всякого порядочного хабровчанина?

Хабр давно уже не IT-ресурс, а клуб нытиков с одинаковой политической позицией. Поскольку в реальной жизни эта позиция не получила поддержки в народе, то интернет - это всё, что у этих людей осталось.

Здесь все комментаторы будут заламывать руки и показательно страдать, что теперь не могут попасть через VPN на запрещённый ресурс, но как раз сами будут минусить комментарии и сливать карму тем, кто имеет противоположное мнение.

Так что высказывающиеся здесь вовсе не герои, готовые, в соответствии с известным изречением, приписываемым Вольтеру, умереть за право других высказывать своё мнение, а ровно наоборот: им нестерпимо больно, что список запрещённых ресурсов определяют не они. Как говорится, ЭДПН

Есть ли бенчмарки или разбор того, как компилятор это оптимизирует? Теоретически это всё сводится примерно к тому же коду, что был на ифах, но осиливает ли компилятор такие оптимизации? Не вносят ли корутины слишком много накладных расходов?

Сделать из сопрограмм do-нотацию не нова, вопросы оптимизации компилятором обсуждались на CppCon 2021. Если кратко: при должно усердии можно заставить компилятор всё оптимизировать до уровня обычных if. Но при сборке без оптимизации, конечно, будет тормозить.

Доступность места должна проверяться при вызове write, несмотря на то, что данные скорее всего останутся в буфере. Хотя, если почитать вот это, то можно узнать, что это не всегда так. Но что вы будете в этом случае делать? Возможно, вы уже десятки раз записывали в файл, просто так исправить это не получится.
Ещё там пишут, что не проверять результат close — это ошибка. Но варианты, когда вызов будет не успешен:
  • Невалидный дескриптор — это логическая ошибка при программировании, во время исполнения её уже не исправить, можно лишь залогировать
  • Ошибка ввода-вывода — опять же, а что вы будете делать?
  • По поводу EINTR интересно почитать это — можно свести к рекомендации использовать fsync, а не надеяться на обработку ошибки close

Лично моё мнение: если в API функции «очистки» могут возвращать ошибку, то с API что-то не так.

Что за набор слов? Что такое "переопределять функцию", если необходим адрес "старой" функции?

Решаемая задача - заменить в коде один идентификатор на другой во всех случаях возможного использования.

А это вы вообще озвучиваете задачу рефакторинга.

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

Ниже показывают, что возможно. Но вот необходимость подобного извращения вами не объяснена.

Задача решена так, как она поставлена: и при вызове, и при взятии адреса.

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

Как не используя макросы препроцессора С/С++ можно переопределить имя функции как при её вызове, так и для операции взятия адреса функции?

Написать другую функцию, вызывающую нужную

template<typename... Args>
decltype(auto) foo(Args&&... args)
{
  return bar(std::forward<Args>(args)...);
}

Смотрите, если есть тип B, унаследованный от А, и тип С, не входящий в дерево наследования, то обычный полиморфизм не позволяет использовать объекты типов B и C взаимозаменяемо (через указатель на базовый класс A, например). Внешний полиморфизм позволяет это сделать.

Опять же, а что вы называете "обычным полиморфизмом"? В той же TAPL даётся три основных вида полиморфизма: параметрический, ad-hoc, подтипов. С ней в целом согласны и английская вики, и русская. И все они вполне будут работать в предложенном случае безо всяких новых терминов.

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

Таким образом, у этих двух подходов явно разные свойства. Поэтому есть и отдельный термин.

Честно говоря, я не увидел никаких разных свойств.

Вероятно, термин происходит из этой статьи.

Просмотрел эту статью. Моя ошибка была в том, что я сразу не понял (не обратил внимания), что речь о паттерне, а потому относился к данному термину как к чему-то серьёзному.

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

Вероятно, термин происходит из этой статьи.
Мой перевод определения: "паттерн, который позволяет использовать
классы, не связанные наследованием и/или не имеющие виртуальных методов,
как полиморфные.

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

Цель куда в примере - показать как, зная конкретные требования, несложно сделать оптимизацию вручную

Не описана причина, по которой оптимизация у вас работает: small object optimization в std::function рассчитана на иной размер.

1
23 ...

Информация

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