За что вы минусуете карму?

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

Вы, главное, если на гит будете выкладывать свой промышленный код под GPLv2, проверьте, что никаких приватных ключей не оставили. Хотя, нет, не проверяйте. Так будет поучительнее.

За что вы минусуете карму?

Названная вами техническая статья была написана именно для Хабра? То есть в ней нет итога проделанной работы?

Да. Но даже если "не только", что изменится? И что вы понимаете под "итогом проделанной работы"?

Вся «подготовка исходных кодов/тестов» не связана с написанием статьи для Хабра. Это отдельная работа, которая оплачена заработной платой программиста и тестировщика. Равно и «подготовка графиков/изображений» не связана с написанием статьи для Хабра, а связана с написанием отчёта о НИР.

Вы правда так считаете? У меня после прочтения пары ваших текстов уже сложилось мнение, что вы - не самый острый нож на кухне. Зачем вы усугубляете?

Конечно, подготовка кода и иллюстраций для статьи для хабра связана со статьёй для хабра. Вы же не думаете, что кто-либо будет выкладывать без модификации свой промышленный код (который часто ещё и под NDA лежит)? И подготовка иллюстраций - если она проводится - тоже делается для хабра. Потому что рабочие иллюстрации обычно тесно связаны с предметной областью - и понятны лишь узкому кругу специалистов. И это не вспоминая про разные уровни доступа к входным и выходным данным, начиная с NDA и заканчивая секретностью. Конечно, их нужно обезличить и опустить до обывательского уровня.

За что вы минусуете карму?

Отчасти ПТСР, но отчасти ещё осознанный перенос активности в другие места. Скажем, завёл чел собственный блог. Несколько раз уже такое встречала - осознанная позиция у людей, статьи сюда не писать.

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

Хотя, объективно, похожим образом ведут себя и Reddit, и Пикабушка, и сотни других развлекательных помоек. Оптимизация расходов, перенос модерации на пользователей. Напоминает, как с приближением к Windows 10 МелкоМягкие отказались от полноценного тестирования винды у себя и перенесли всё на пользователей. С одной стороны, весь зоопарк всё равно не повторить. С другой стороны, лох - не мамонт...

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

Уважаемый @PereslavlFoto,
благодарю вас за ваше мнение, основанное на копирайтерских поделках. К сожалению, вынужден вас огорчить, что ваша деятельность не является ядерным контентом на хабре, позиционирующем себя как площадка для разработчиков ПО.
Поэтому, не рекомендую вам экстраполировать ваш опыт заказного копирайтерства на остальные статьи хабра. Особенно, на глубоко технические или научные статьи, в которых одна только подготовка исходных кодов/тестов/графиков/изображений может занимать недели. Уж поверьте, я, как автор одной разработки - и технической статьи по ней (которая длиннее 3-х ваших, но даже так не покрыла и четверти от изначальной задумки), имею в этом некоторое понимание.

За что вы минусуете карму?

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

Языки смешивать не стоит. Узкое разделение позволит пресекать холивары без угнетения языков. Иначе права менее популярных языков будут урезаться. Условно, lua никогда не догонит c#, но это не значит, что луашнику нужно запретить обсуждать lua, если он что-то не то написал шарпистам - и отхватил за это по жопе.

Вот с этим можно поспорить.

Зависит от того, какую цель мы преследуем. Если цель - снизить накал дискуссии, оставляя пространство для мнений, то восстановление кармы к какому-либо постоянному значению со временем - очень удобный механизм. А если цель - установить стерильное согласие - то, конечно, можно поспорить. Только мы видели, к чему это приводит на тех же джойреакторах и пикабушках. Боты, охота на ведьм, массовые исходы и ной администрации. Из хабра, кстати, тоже было несколько волн исхода. Чего хорошего это принесло, кроме ничего?

За что вы минусуете карму?

Вообще-то, если кто-то добровольно уходит в Read-Only, это ПТРС на минималках.

За что вы минусуете карму?

Было бы не так плохо, если бы карма была не общей, а разделялась между хабами. И карма внутри и вне хаба имела бы разное влияние на возможности пользователя. Ну, например, отдельная карма для ЯП, отдельная - для социальных и научных хабов. Получил плюс или минус за пост или коммент - он делится у тебя между хабами статьи. Нашкодил у Go'шников - тебя туда не пускают. Но писать у змееустов, например, у тебя право остаётся. Обратно, поднялся у плюсовиков - получил право на разные плюшки. Но это не делает тебя автоматически крутым парнем в машинном обучении и прочих фронтендах. А карму за политоту я бы вообще отматывал к нулю со временем, потому что ограничивать пользователя за мнение, не нарушающее законов страны его пребывания, - это даже не тоталитаризм, это статья.

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

Но, стоит забрести в какую-нибудь жаренную тему, особенно, в политоту... Стоит сказать там хоть слово неудачное... Или, тем более, стоит попытаться отстаивать там своё мнение... Вся карма сливается в момент.

Вот только эту карму уже не вернуть. И новую не заработать. Все свои плюсы ты уже получил в своём небольшом кружке по интересам. Чтобы вернуть карму, нужно потратить очень много сил на качественные статьи. Ради чего, ради кармы? Ради хабра тратить силы и прыгать через голову? Да проще послать этот хабр и всё его сообщество, местами переросшее в карго-культ, и уйти на все шесть сторон. Что, собсно, многие и делают - благо, у хабра есть альтернативы, где и сообщество не меньше, и токсичность не выше, и вот таких палок в жопу не вставляют.

Вы, @Exosphereи @Boomburum, можете, конечно, не соглашаться. С опорой на эти ваши графики и прочую статистику, которую могут посмотреть не только лишь все. А я 4 года назад ушёл, когда мне из-за политоты рот заткнули. Много минусов не потребовалось, чтобы ручкой помахать, не волнуйтесь. На графике я был маленькой ямкой по сравнению с взаимолюбованием местных звёзд. Вернулся я на хабр по случайности - и, не думаю, что надолго тут задержусь. От чего, кстати, сильно страдать не стану. И что-то мне подсказывает, что мой случай далеко не уникальный. Не знаю, даже, что... Комменты ниже?

За что вы минусуете карму?

А что целого в таких овцах?

С++ и Raylib как глоток свежего воздуха

А что тут не понятно-то? Уплати своему графу налог 0 крон.

Tiny-qORM: рассказ без счастливого конца

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

Учитывая поставленную задачу? Основные накладные расходы происходят внутри Qt при использовании сеттеров. Без изменения самого Qt любой выигрыш на кешированиях будет теряться в долях процентов. А без Qt нет рефлексии.

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

Во-первых, я имел в виду прежде всего код оптимального обхода структур. Во-вторых, разве мускул и постгря так далеко разошлись от ANSI SQL, чтобы универсальные запросы не работали? Ну и в-третьих, а почему нет? Это плюсы, детка!

Вместо этого сделайте такое API, чтобы объекты запросов (ВНИМАНИЕ -- это не только строки, это ещё и метаданые, во имя рефлексии) можно было кэшировать. 

Плюсы - не Питон, они работают немного не так. Что толку кешировать типы, если передача всё равно будет по значению - с многократным копированием в процессе?

Кстати вообще не поняли. Как тестировать работу REPL? Как тестировать поведение REPL с учётом отправки команд и анализа результата? Как протестировать, не сломался ли REPL?

stdin + stdout? Терминал - и REPL - это обмен сообщений по стандартным пайпам. Весь REPL - это read_stdin->eval->write_stdout. А все вставки текста, автодополнения, цветные символы и прочие перделки - это управляющие последовательности и спецсимволы. Поэтому ваших страданий по тестированию зоопарка целиком я вдвойне не понял. Делайте прокси для пайп, записывайте тестовую сессию, воспроизводите её в режиме "без терминала".

Tiny-qORM: рассказ без счастливого конца

Очень сложно проводить аналогии между ORM для Питона и плюсов. В том смысле, что расширение функционала сортировкой-фильтрами - is not a rocket science - дело чисто техническое. Решается через стек объектов-команд и усложнённый генератор запросов. А вот с наращиванием производительности - большая беда.

На плюсах красивая рефлексия на данный момент практически отсутствует - и её было ещё меньше в начале-середине 2018 года, когда этот код писался. Поэтому любая попытка сделать ORM обречена либо на значительное изменение кода и использование кучи меток, либо на внешний препроцессор. В Qt метасистема пошла по обоим путям: с одной стороны, необходимо описывать структуру класса, оставляя макросы Q_OBJECT Q_GADGET и тп. С другой, поверх этого кода проходится moc, который для всех помеченных классов создаёт весьма уродливый код: там и касты в void*, и магические числа, и прочее прочее. Был даже цикл статей о том, как это работает - и почему. И, в общем-то, ничего сверхъестественного под капотом нет. Уродливое, не самое гибкое, порой, весьма неэффективное решение - но не сверхъестественное. И, главное, рабочее.

Проблема ещё и в том, что и сам moc, и сгенерированный им код вообще не дружат с шаблонами. Автор moc даже сделал версию, поддерживающую шаблоны, потом написал "не, фигня какая-то получается" - и забросил её. Не могу его осуждать (но осуждаю). И constexpr в метасистеме не сказать, чтобы часто встречается. Поэтому, в оригинальном qt не получится перенести генерацию кода запросов на этап компиляции. Можно было бы, если бы да кабы. Но нельзя. А, значит, всё будет делаться на этапе исполнения, самым обобщённым (читай, медленным) способом. Отсюда и сумасшедшие показатели времени запроса select по сравнению с явным созданием структур. Правда, я не смотрел, что там подвезли в самые свежие версии. Быть может, теперь всё не так плохо.

А по поводу вашей задачи, я не очень понял, в чём, собсно, проблема. Если у вас есть зоопарк, вы отдельно тестируете каждый вольер, отдельно - каждое животное. А потом тестируете их вместе, как единое целое. Или вы чисто технически не понимаете, как встроить тесты в ваши миксины? Начните с того, что тесты - это тоже миксины, которые чередуются с обычными миксинами и проверяют текущее состояние вашего приложения против известного нормального. Например, при рестарте последний завершающийся тестирующий миксин выключает свет и оставляет записку с PID'ом на пороге, а первый запускающийся тестовый проверяет, что этого PID'а с записки уже нет в живых. Или после каждого миксина каждого модуля ставится миксин тестов этого модуля против нужной версии и набора функций. И тд и тп.

Эволюция лямбд в C++14, C++17 и C ++20

O'reilly? Ну, давайте по пунктам:
struct V{ int x:1; } value, values[32];
cout << "pointer " << is_pointer<V>::value; // pointer 0
&(value.x); // error: attempt to take address of bit-field
cout << sizeof(value); // 4
cout << sizeof(values); // 256

Как-то не очень похоже на указатель на сущность размером 1 бит. Больше похоже, что кто-то нас пытается покормить говнецом.

При этом, на современных 64-битных системах можно реализовать адресацию битов даже без оверхеда по памяти. Благо, объёмы ОЗУ даже на суперкомпьютерах и близко не скребут потолок максимального значения указателя.

Эволюция лямбд в C++14, C++17 и C ++20

Позвольте, а почему вы должны иметь указатели на эти сущности? Указатели - это низкоуровневый инструмент, адрес в памяти. А C++ - высокоуровневый язык программирования, не макроассемблер. Многие из его сущностей не могут иметь адреса в силу своей виртуальности.

Вы, если что, кроме адреса конструктора не можете иметь ещё и адрес деструктора. Потому что единственная причина их использовать - placement new - лишает объект контекста, а компилятор - возможности следить за временем жизни, и обязывает вас явно вызывать их для используемого вами типа. Максимально явно.
Хотя у меня есть претензия к языку, почему нельзя было сделать delete (ptr) Type; вместо явного вызова деструктора?

Перечисленные вами сущности являются виртуальными. У нас есть масса других сущностей, те же перечисления enum class, которые создают свой собственный тип. Вас же не смущает, что два перечисления с одним именем и размером имеют разные типы, и если они оба окажутся в одном пространстве имён, будет ошибка компиляции?

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

Упрощаем код с помощью if constexpr и концептов C++17/C++20

Да нет, у него простые подстановки, за что препроцессор в плюсах и хейтят. Заслуженно.

Но, знаете, мне не ясна ваша претензия.

Или, может быть, вы объясните, какую цель преследует проверка правил типизации в коде, не предназначенном для исполнения? Конечно, содержательно объясните, а не в ключе "мы сделали лопату с черенком из суковатого дерева, и теперь так само естественно получается, что сучья цепляются за разные предметы".

В приведённом вами участке проверки правил типизации не проводится. Там более простая проверка error: use of undeclared identifier 'aaaa'

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

Меня, например, всегда бесило подобное в интерпретируемых языках: у тебя всё работает, всё работает, всё работает, всё АААААА КАКОЕ-ТО ГОВНО В ЭТОЙ ВЕТКЕ НАПИСАНО!!! я на выход! И там действительно какая-нибудь очевидная опечатка, которую в других языках тебе бы сразу в морду лица бросили. Но тебе не бросят, пока не попадут в эту ветку. Вкуснее всего, если ошибка на финальных шагах работы какой-нить числодробилки.

Упрощаем код с помощью if constexpr и концептов C++17/C++20

Без "сумерек рассудка" проблема синтаксического анализа и тем более проверки типизации в никогда не выполняющемся и тем более не компилируемом коде не должна вообще возникать.

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

Во-вторых, никто не отменял несовершенство компиляторов - и самого стандарта, пестрящего разными UB и UB.

И, позвольте, вы бы точно так же кричали, "Почему там выполняются базовые проверки синтаксиса?!", если бы вместо не существующих имён переменных там была бы закрывающая фигурная скобочка или объявление класса?

Пробел в нумерации, или почему никто не говорит про IPv5

Не знаю, что там про лень и раздолбайство, но вот реализация широковещательных сообщений без подписки (то, что в IPv4 называют broadcast, а в IPv6 multicast) в IPv6 настолько геморрная, что лично я её не осилил.

В IPv4 достаточно сделать socket.ip | socket.network_mask
В IPv6 нужно себе в куче мест прострелить ноги. Выставить флаг мультикаста, выставить иные флаги, выставить маску сети, которая ещё и не самым простым образом вычисляется, и потом ещё бодаться с роутерами, которые могут требовать маски сети не по стандарту, а кратные собственному значению - и вообще пох, как ты об этом должен узнать.

И я бы не был так предвзят, если бы для IPv6 был где-нибудь репозиторий с простыми примерами "был вот такой механизм на IPv4, на IPv6 его можно делать вот так или вот эдак". Новотхер!

ЗЫ. Да, пока не забыл. FF02::1 не работал в моей сети. Почему? Спросим об этом TP-Link

Введение в метаклассы

Это UB, воин.

Apple в 2019 году — это Linux в 2000 году

Ну, как, ложь… Вам никто не запрещает всё делать никсово. Но…
Но вот вы сидите на 10.12.2, потому что поддержка устройства закончена. И вы такой «поставлю-ка я себе xCode». И не поставите, потому что из магазина она не втянется. И вы такой «А скачаю-ка я её с сайта». И скачаете все xCode вплоть до 8 версии, но ни одной не поставите, так как для одних нужна 10.12.4, а для других 10.11. И вы такой «Ну ладно, руками поправлю файл версий». И это не сработает. И вы такой «ну нафиг, пойду проституткой!» и поставите себе Qt Creator.

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

У стен и окружения не хватает теней. Не рассчитанного освещения, а банальных теней. Всё остальное сверху комом собирается.

C++20 укомплектован, C++23 начат. Итоги встречи в Кёльне

А можно вообще всем подосрать, добавив namespace co {}
Можно будет писать и

template <class T>
T function(string s) {
    if (s.empty()) {
        return {}; // OK
    }
    co::await query(s);
    co::yield s;
    co::return {"Done: " + s};
}

и

template <class T>
T function(string s) {
    using namespace co;
    if (s.empty()) {
        return {}; // OK
    }
    await query(s);
    yield s;
    return {"Done: " + s};
}

C++20 укомплектован, C++23 начат. Итоги встречи в Кёльне

*пробивая головой заросший выход из берлоги*
А про habr.com/ru/company/infopulse/blog/334284 больше ничего не слышно?