Pull to refresh
3
0.1
Малинин Александр @Cfyz

User

Send message
На мой взгляд в статье недостаточно проиллюстрированы озвученные требования к типу-обертке. Практически по всем сразу же возникает мысль «зачем так сложно», хотя допускаю есть причина зачем. Но это затрудняет восприятие решения =|.

Если сообщение неизменяемое (а по умолчанию оно неизменяемое), то методы-getter-ы должны возвращать константный указатель на сообщение. А если изменяемое, то getter-ы должны возвращать не константный указатель.
Если значение иммутабельно как тип, то какой указатель на него не верни, будет значение, которое не получится изменить. Если экземпляр иммутабельного типа можно нечаянно изменить, то это как минимум странно. Если тип на самом деле не иммутабелен, а просто хочется некоторые экземпляры сделать иммутабельными, то наверное это надо делать не силами контейнера?

Когда-то он должен вести себя как std::shared_ptr, т.е. можно иметь несколько message_holder-ов, ссылающихся на один и тот же экземпляр сообщения. А когда-то он должен вести себя как std::unique_ptr, т.е. только один экземпляр message_holder-а может ссылаться на экземпляр сообщения.
Эти стратегии владения настолько разные, что лучше и типа иметь два разных. Иначе получается странный тип, поведение которого прояснится только после (не)успешной компиляции. Ну а чтобы пользователь не расслаблялся в случае успешной компиляции,
А метод make_reference должен изымать указатель у объекта message_holder_t: после вызова make_reference исходный message_holder_t должен остаться пустым.
перенесем один из сюрпризов на время выполнения =). Это что угодно, но только не «make a reference», не надо так =/.

Кстати, выключать конструкторы-операторы можно еще и таким образом, без применения дополнительного наследования:
template<typename T> struct Foo {
    Foo() { }
    Foo(const Foo&) {
        static_assert(std::is_integral<T>::value, "");
    }
};

void test() {
    Foo<int> f1;
    Foo<int> f2{f1}; // Ok
    Foo<std::string> f3;
    Foo<std::string> f4{f3}; // Fail
}

Поправьте меня, если я неправ, но вроде бы по стандарту методы шаблона инстанцируются только если они используются. Ну, как минимум все крупные компиляторы ведут себя желаемым образом =).
По приведенному списку, такой программист и С++ тоже не знает. Или, скорее, вы просто очень неудачно изобразили сарказм, грань между абсурдом и откровенной глупостью очень легко перейти.
Чуть более полная фраза звучит еще веселее: «a future where we will be no longer defined by a gender, but rather how we define ourselves». По-моему это довольно иронично, как раз за разом ради будущего с упором на индивидуальность, а не стереотипы, предлагается стереть индивидуальность.

Ты можешь быть кем хочешь! *

*) До тех пор, пока все, что ты делаешь и что тебя окружает, является серым стерильным расово, гендерно и религиозно-нейтральным суррогатом.
А вот volatile — откуда вообще пошли про него слухи как про волшебную таблетку для многопоточности?
Компилятор не имеет право оптимизировать чтение переменных, помеченных volatile. На это опирался примитивный способ синхронизации потоков с помощью флагов (работаем в цикле пока флаг все еще true) во времена, когда честных атомарных переменных еще не было в языке.
Мне нравился premake где-то лет пять тому назад, но с тех CMake стал чуть не стандартом де-факто (кого чаще всего видно в корне репозитория?), а premake до сих пор так и не вылез из состояния «вот-вот будет готово».

У CMake при всех его недостатках есть одно огромное преимущество — популярность. Теперь остальным инструментам недостаточно быть хорошими, придется предложить прямо какую-то киллер-фичу. А до тех пор люди будут готовы потерпеть синтаксис CMake ради того, чтобы проект в два щелчка открывался во всех популярных IDE на всех популярных ОС.
> они будут активно перемешиваться с «обычными» email, причём по сути они будут спамить ящик тучами мелких писем

А пусть все клиенты учатся при отображении складывать цепочки писем в стопочки, как это gmail делает =).
Или недостаточно сильно мешало на фоне остальных, более важных на тот момент проблем. То, что какой-то признак закрепился, может быть и не его заслугой.
Ну как видим, оно хотя бы выдало предупреждение. Почему по умолчанию это всего лишь предупреждение — непонятно, да.
Из-за этих исследователей я так и не дождусь пальм в Ленинградской области =(.
Где-то там за Нептуном сейчас грустит один Плутон.
Эх, что за любовь выбирать символы позаковыристее. Наверняка возможно составить грамматику с указанием вхождения границ почеловечнее:
for i in [0..256) { ... }

Меня вообще смущает, как в Rust сделали две разные нотации диапазона, не включающий верхнюю границу ".." для почти всего и включающий верхнюю границу "..." для паттернов.

И почему 256 вызывает ошибку, если это значение браться не будет? Вопрос риторический, я понимаю почему в данном случае, но компилятор может быть и поумнее.

Или если уж очень хочется переложить на людей, то можно же было реиспользовать троеточие, было бы хотя бы консистентно:
for i in 0...255 { ... }

А не две разные нотации диапазона, включающего верхнюю границу =(.
крокодил более длинный, чем зелёный, или более зелёный, чем длинный?
Ну это же очевидно: крокодил длинный весь, а зеленый только сверху =).
По-моему, логгирование в таком виде это один из немногих случаев, когда оправдано применение макроса:

LOG(Info, "Message " << with << " some " << data);

Где LOG выглядит, грубо говоря, так:

#define LOG(level, what) do { \
    if (level <= currentLoggerLevel) { \
        std::ostringstream ss__; \
        ss__ << what; \
        WriteSomewhere(ss__.str()); \
    } \
} while (false)

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

Нередко важным плюсом является отсутствие собственно форматирования строки, если уровень логгирования недостаточен и сообщение выводиться все равно не будет.
А у кубика как раз шесть граней =).
Мне уже пояснили, что суды действительно рассматривают это предписание как строгую директиву. Смущает только то, что из самой формулировки это, скажем, неочевидно. Смотрите, там сказано «должнен принять меры к торможению» и все. Если прямо с момента обнаружения опасности я буду честно тормозить, но при этом еще и уйду немного вбок — что я нарушу? Предписание по принятию мер к снижению скорости я выполнил полностью, а уточнениния типа «и ничего более кроме снижения скорости» там не было.

Мне кажется этот пункт ПДД как минимум нуждается в переформулировке.
Хм, но ведь формулировка ПДД предписывает только принять меры к снижению скорости, там нет запрета на одновременное выполнение иных действий помимо обязательного снижения скорости.

Information

Rating
3,080-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity