Состоялся стабильный релиз утилиты ack 3.0.0. ack - это аналог grep'а, но для программистов, который написан на Perl'е.

( читать дальше... )

>>> Подробности

Делаю простой мессенджер на сокетах, TCP/IP. Есть клиент и сервер, дошёл до этапа обработки запросов и задумался над тем, каким образом наиболее труЪшным ооп путём организовать приём и обработку пакетов. Пакеты могут быть разные, черновой вариант такой:

enum RequestType {
    Register,
    Authenticate,
    Message, // текстовое сообщение
    Attachment, // файл
};

Пока идея такая:

• Все пакеты первым полем должны содержать int type
• Все пакеты кроме Attachment вторым полем будут иметь поле unsigned size, а далее JSON рамером в size с необходимыми полями
• Attachment, в отличие от остальных, не JSON, у него три поля: кому recipient, имя файла char name[32] и его размер unsigned size, далее идут данные

Приём пакетов делаю так:

void Client::start()
{
    char *buffer;
    unsigned long bytes;

    m_socket->setBlocking(false); // неблокирующий режим

    while (true) {
        bytes = m_socket->waitForRead();

        if (bytes == 0) {
            // Disconnected
            delete m_socket;
            return;
        }

        // Вот здесь нужно организовать приём и формирование пакетов

        buffer = new char[bytes];

        m_socket->recv(&buffer[0], bytes);

        delete []buffer;
    }
}

Конечно можно решить задачу «в лоб», но мне интересно:

• Как наиболее правильно с точки зрения ооп сделать задуманное? Что-то мне подсказывает для каждого пакета создать класс, которому передавать buffer и bytes, который будет формировать пакет?
• Какие наиболее подходящие паттерны для подобных задач?
• Где и как лучше всего осуществлять проверку аутентифицирован ли пользователь, или нет?

Может у кого есть хорошие примеры. Thanks in advance, так сказатб.

На сервере высокий WA по iotop и atop по диску в топе один процесс, процесс работает с несколькими файлами. Как узнать запись в какой именно файл нагружает систему?

Все прекрасно знают (или сейчас узнают), что std::vector не умеет в const T. Хотя, вполне себе можно представить как такой контейнер будет себя вести:

• под капотом std::aligned_alloc
• добавляем через emplace_back(Args&&), который делает placement new
• operator[] отдает через std::launder (C++17)

У меня есть метод, что подтягивает данные с базы. Хочу возвращать контейнер с const обьектами. Чтоб означить, что их не следует менять. Конечно ничего не мешает возвращать не-const

Есть ли что-нибудь на замену std::vector, чтоб самому не писать? Может boost?

Всем привет, ищу удалённую работу compiler engineer'ом на C++. Опыт работы с крестами больше 10 лет, опыт работы с LLVM - года 4, в основном подсистема DebugInfo (реализовывал стандарт DWARFv5), но работал и с другими подсистемами, участвовал в реализации бэкенда для стековой машины, накладывал ее на регистровую модель llvm. Активно общался с сообществом, есть право на комммит в llvm. Работаю как ИП, зп желательно USD. Вилка обсуждаема.

email: vleschuk at gmail.com

skype: ast.vleschuk

Господа, имеется такое безобразие (на нескольких серверах):

  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       1

При этом: zfs scrub, например, проходит успешно. В итоге, получаем alerts, что диску хана, а по факту scrub - говорит что всё ок. Но диск не полностью полон.

Как правильно поступать в такой ситуации? Менять диск не обращая внимания на zfs? Проводить низкоуровневый формат и надеяться что уберутся ошибки? Или просто выбросить такие диски и забыть?

Пытался понять как реализовать SVG фильтр feComposite, ибо SVG дока унылая, поэтому залез в сорцы вебкита. Там тоже документации ноль, ещё и код очень странный.

Вот что это за ужас (src):

static unsigned char clampByte(int c)
{
    unsigned char buff[] = { static_cast<unsigned char>(c), 255, 0 };
    unsigned uc = static_cast<unsigned>(c);
    return buff[!!(uc & ~0xff) + !!(uc & ~(~0u >> 1))];
}

Я так понимаю, они проверяют что int в 0..255 диапазоне, но уж слишком странным образом.

UPD: коммит, который добавил этот код.

Сабж. Но почему?

#include <type_traits>
int main() { return std::is_assignable_v<int, int>; }
// --> 0

https://wandbox.org/permlink/59MyGGpqRz2q1zzq

Нравится мне делать подобные штучки :)

Результаты бенчмарка (со всяческими другими быстрыми вариантами):

 erthink       ... [min   21.900ns, rms   56.925ns, max   72.200ns]
 floaxie       ... [min   25.200ns, rms   66.722ns, max   88.900ns]
 emyg          ... [min   32.600ns, rms   76.577ns, max   92.600ns]
 milo          ... [min   32.200ns, rms   76.754ns, max   92.400ns]
 grisu2        ... [min   67.600ns, rms   89.862ns, max  110.100ns]
 doubleconv    ... [min   58.400ns, rms   94.065ns, max  116.500ns]
 fmt           ... [min   82.900ns, rms  134.049ns, max  159.000ns]
 fpconv        ... [min   87.400ns, rms  136.806ns, max  159.000ns]
 sprintf       ... [min  634.600ns, rms  717.793ns, max  783.600ns]
 ostrstream    ... [min 1019.400ns, rms 1104.349ns, max 1168.800ns]
 ostringstream ... [min 1107.200ns, rms 1200.868ns, max 1275.700ns]
 null          ... [min    1.200ns, rms    1.277ns, max    1.300ns]

$ gcc -v
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

Делюсь, думаю кому-нибудь пригодится. Лицензия zLib, исходники и бенчмарк с примером использования на github. Функция header-only и совсем не делает ничего лишнего:

• генерирует минимум символов (намеренно без десятичной точки);
• не пишет \0 в конце;
• не проверяет inf и nan (ибо во многих случаях нужна кастомная обработка, например как в json);
• но всё корректно.

Поэтому смотреть лучше начиная с примера по ссылке. При необходимости «красоты», в том числе вывода десятичной точки можно делать примерно так.

Я тут на досуге посидел с ручкой-бумажкой и выписал штук 10 чисто технических причин, почему Rust, как язык, совершенно ни на что не годится и не нужно тратить время на его изучение. Чисто технических - в смысле, не включающих в себя пункты про отсутствие нормальной IDE, малый размер сообщества, и тому подобные. Не знаю, насколько это кому-то интересно, но предлагаю провести эксперимент. Напишите в комментариях свою версию этих пунктов, а потом сравним. Есть серьезные подозрения, что в Rust намного больше недостатков чисто с точки зрения дизайна языка, чем мне сейчас приходит на ум. Но как с любой другой новой технологией, евангелисты сосредоточены исключительно на преимуществах, закрывая глаза на недостатки.

1. Есть несколько книг на выбор. Нужно определить какую книгу стоит прочитать первой, а какие позже. Главные критерии для упорядочивания: «фундаментальность» касательно ООП, практичность и доступность (грамотность) в изложении материала.

Вот список:

1. Философия Java // Б.Эккель
2. ЯП C++ // Б.Страуструп
3. ООП с ANSI-C // А.Шрайнер
4. Типы в ЯП // Б.Пирс

2. Посоветуйте лучший, по вашему мнению, учебный материал по паттернам проектирования (статьи, книги, видео, что угодно).

Май 2011-го. Собираю NetBSD-current (вроде бы) на своём первом ноутбуке для работы над проектом GSoC'11. После неудачного обновления, или чего-то в этом роде, ноут стал сильно греться на компиляциях, и в самые интересные моменты просто выключался.

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

Да, это была моя единственная машинка на AMD. Приказала долго жить в сентябре того же года, уже во второй раз, и, судя по всему, навсегда. Так и не донёс до ремонта.

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

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

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

«ведущие"разработчики пишут код.

Менее эффективных разработчиков отправляют покрывать всё юнит-тестами.

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

Вернемся к теме того что авторы кода не пишут к нему тесты.

Разве это нормально? Очевидно же что именно автор кода может (и должен) подробно проверить свой собственный метод, класс, модуль, прежде чем переключить свой контекст своего мозга на дельнейшие задачи, ибо именно он лучше всех знает то что должно приходить на вход и выходить на выходе как правильный результат. Именно он знает что есть ошибка а что нет.

И если за него обнаружат баг а он уже делает n+1 задачу -будет дороже его пофиксать же.

Зачем привлекать к написанию тестов людей которые:

1. должны будут где-то узнать что должно входить (контракты), и что на выходе есть ок а что не ок (это им придется тратить время, а если документации нет (как правило) - то дергать автора кода, и тормозить его этим)

2. в некоторых случаях им придется создавать искусственно окружение для тестирования. А у автора оно по любому было на момент разработки.

Т.е. вижу только тормоза и вред для бизнеса если код тестируют не авторы, ибо детектинг багов и фиксинг будет происходить медленнее.

Или это как-то оправдано в компаниях где в приоритете время релизов а не качество продукта?

Объясните.

Есть код с C++Weekly от Jason Turner (только немного изменены имена): https://wandbox.org/permlink/EWlifMBMhvBhSn5B

Info: http://eel.is/c++draft/temp.variadic#5

template <typename... Functors>
struct CompositeVisitor : public Functors...
{
#if 1
  template <typename... Args>
  CompositeVisitor(Args&&... args) : Functors{std::forward<Args>(args)}...
  {
  }
#endif

  using Functors::operator()...;
};

template <typename... Functors>
CompositeVisitor(Functors...) -> CompositeVisitor<std::decay_t<Functors>...>;

struct Foo {};
struct Bar {};
struct Baz {};

int main() {
  CompositeVisitor visitor{
    [](const auto&) { std::puts("got some part"); return true; },
    [](const Bar&) { std::puts("got Bar"); return false; }
  };
  
  Foo foo;
  Bar bar;
  Baz baz;
  
  visitor(foo);
  visitor(bar);
  visitor(baz);
}

Clang собирает и работает, GCC не хочет:

prog.cc: In instantiation of 'CompositeVisitor<Functors>::CompositeVisitor(Args&& ...) [with Args = {main()::<lambda(const auto:1&)>, main()::<lambda(const Bar&)>}; Functors = {}]':
prog.cc:30:3:   required from here
prog.cc:11:72: error: mismatched argument pack lengths while expanding 'Functors'
   11 |   CompositeVisitor(Args&&... args) : Functors{std::forward<Args>(args)}...
      |                                                                        ^~~

Если подать типы Functors explicit, то собирается. Только с лямбдами немного накладно сделать.

Баг ли?

STL надо знать и уметь, это понятно. Но не алгоритмами едиными живёт новичок от мира программирования. Надо же ещё своё Г ещё как то хотя бы визуализировать. Пока для себя открыл ncurses - консольная радость; openGL - это классика это знать надо; cairo - что бы не писать велосипеды для 2д графики;

Какие ещё базовые библиотеки стоит изучать? Безотносительно области применения. Просто как обзорный вопрос.

Сфотографировал свою кухню, пока на ней никто не бренчал. Люблю её.

Итак, что мы имеем на фото.

Нижняя клавиатура - рабочая станция Korg Trinity. Почтенный пожилой японец, родоначальник обширного семейства Trinity/Triton и их многочисленных производных. Несмотря на почтенный возраст (ориентировочно 15-20 лет, точнее сказать не могу, брал с рук), на синтезаторе ни царапинки, работает идеально. С него я обычно играю и пишу всякие пианинки, электропианинки, органы, пады, колокольчики, вот это всё - очень густое, жирное звучание. Электронные тембры, разумеется, по большей части морально устарели и годятся разве что воссоздавать дух эпохи. На таких машинках в конце девяностых - первой половине нулевых было сделано куча радио-хитов, благо, эта техника позволяет делать аранжировки, не задействую какой-либо дополнительный инструментарий: в наличие навороченный секвенсор, большой тачскрин, флоппи-дисковод, а также возможность расширять функционал за счёт установки дополнительного железа - жёстких дисков, плат, реализующих дополнительные алгоритмы синтеза, дополнительных входов/выходов, и т. д. Само собой, сейчас такой функционал гораздо проще реализуется с помощью десктопа и программного секвенсора, так что такие специализированные устройства постепенно уходят в прошлое.

На втором этаже разместилась миди-клавиатура CME UF50. Добротное устройство с кучей контроллеров и возможностью их перенастраивать как угодно под себя, с приятной упругой клавиатурой, хотя, к сожалению, достаточно шумной. Подсоединяется это миди-устройство к ноутбуку через беспроводной USB-свисток. С миди-клавиатуры я обычно играю то, что выигрышнее звучит через программный секвенсер, в основном живые акустические инструменты - скрипочки, дудочки, этнику, иногда рояльки, хотя четырёх октав маловато для комфортной игры на рояле.

На отдельном пюпитре расположился ноутбук Acer Aspire V5. На ноутбуке установлена Slackware 14.2 с Xfce, потому что ультрастабильно и легко пересобрать нужные компоненты системы под себя. Ядро пересобрано с настройками для лучшей отзывчивости, наложены патчи, добавляющие планировщик MuQSS (бывший BFS). Включен rtirq - демон, дающий высокий приоритет реального времени псевдопроцесам ядра, ответственным за работу с аудио, а также компонентам системы, отвечающим за вывод звука, и аудиоприложениям.

На ноутбуке запущен DAW - Reaper, нативный, звук выводится через бэкэнд ALSA. От использования JACK я отказался, при том же размере буфера он иногда потрескивает. Задержка ввода/вывода при игре с миди-клавиатуры составляет чуть больше 11 миллисекунд. Внутри DAW загружено несколько инстанций секвенсера Kontakt. На отдельные дорожки повешены отдельные пресеты/тембры, переключаясь между дорожками через контроллеры миди-клавиатуры или хоткеи, я переключаю тембры.

На заднем плане в кадр попали микшер, здоровенный басовый кабинет, два гитарных кабинета один на другом в углу, барабанка сбоку, в общем, типичное оборудование для «тяжёлой» комнаты на репетиционной базе.

Так и живём.

Добрый день.
Есть необходимость производить некоторое количество геометрических расчетов. Поиск точек пересечения, некоторые операции с векторами на плоскости и т.п. Так вот столкнулся с известными проблемами double (потеря точности). Как бы вы сделали, заморачивались бы с double самостоятельно или просто взяли бы готовую библиотеку, которая позволяет представлять числа с фиксированной точностью (Boost.Multiprecision)?

Привет, ЛОР.

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

Жил-был чувак по имени Norbert Preining. Коммитил он в дебиан, писал код, стал даже одним из разработчиков проекта. Пока ВНЕЗАПНО ему не порезали права и не понизили до простого мейнтейнера за пост в его бложике, где он по неосмотрительности нарушил CoC, упомянув Сару Шарп (она же ныне Sage Sharp, она же О БОЖЕ МОИ ГЛАЗА АААА ЗА ЧТО) используя неправильное с точки зрения политкорректности местоимение — she вместо they. К слову, когда ему указали на его оплошность, он местоимение поправил, но было поздно. Плюс ко всему, ссылки на его блог были удалены из Planet Debian.

Ссылка раз: https://lists.debian.org/debian-project/2018/12/msg00038.html Здесь Норберт просит указать, за что же собственно его наказали, и получает от ворот поворот, потому что негоже холопу обсуждать действия Debian Anti-harassment Team.

Ссылка два: https://lists.debian.org/debian-project/2019/01/msg00170.html Здесь один из поциентов, уже после понижения Норберта в правах, просит прислать истории отрицательного взаимодействия с Норбертом, дабы как-то это самое понижение в правах оправдать.

Чуть более подробный разбор ситуации есть здесь: https://lists.debian.org/debian-project/2018/12/msg00006.html. Плюс там же вкусная драма из жизни одного из крупнейших дистрибутивов Linux.

Спасибо за внимание!

Вопрос про хорошие пользовательские классы исключений в Си++.

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

Это конечно не какой-нибудь дамп многострочный, который наверное должен создаваться не через e.what() а через что-то специальное. Но хотелось бы чтобы в исключение можно было напихать как минимум char*, string, и любые другие от bool до double нативные типы. Потому что кажется что это было бы очень удобно с точки зрения использования:

throw SomeException() << "blabla " << "index " << i << " array_size" << arr.size() и т.п.

Ну и вот теперь вопрос - кто-нибудь такое делал, и как вы это сделали?

Это достаточно легко сделать средствами STL, берём std::string, берем std::to_string() и ура, если для числовых типов обернуть шаблоном, то вероятно потребовался бы один метод на все случаи :)

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

try{
  throw SomeException();
} catch (const SomeException &e) {
  //можем сюда не попасть.
}

Да, да, чтобы такого не было можно закостылить внутри методов иключения, в которых может породиться другое исключение свой try-catch - но это как-то не эстетично, и наверерное нагрузочно на стек вызовов, а хочется чего-то легкого, что имело бы больше шансов на удачное создание, жизнь и уничтожение, когда осталось мало ресурсов на стеке программы, в куче и тому подобном...

Вопросы

Можно ли придумать что-то более лучшее чем:

1. std::string или динамически расширяемый char * заменить исключительно на char * константной длинны (массив) и в случае захода за длинну просто не заполнять его дальше, а конец массива сделать многоточием - что будет обозначать что это не весь текст исключения.

2. Взамен to_string напрашивается что-то из std::sprintf(buf, «%ld», value) - https://ru.cppreference.com/w/cpp/io/c/fprintf но к сожалению не знаю/не_помню и по ссылке не нашел, что будет если в buf не хватит размера для преобразования числа в строку?

3. И немного глупый вопрос про низкий уровень: если в коде есть строка

A << val1 << val2 << val3 << val4

Правильно что хоть сколько в ряд таких операторов записать то стек не потратится больше чем на размещения вызываемого метода + входящей в него переменной?

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

А вот это грубо говоря просто пошагово должно быть: A << val1 << val2 << val3 << val4 это тоже самое что int a=0; a+=f(); a+=f(); a+=f(); т.е. хоть «беcконечность» таких a+=f(3); сделай - это не покрошит программу, т.к. не переполнит программный стек (ну разве что, безопасно для рантайма,переполнит тип int).

Часто приходится слышать критику типа «ко-ко-ко, C++ сложный язык, стандарт распух более чем на полторы тыщи страниц, это нивазможна выучить!!!11».

Как известно, стандарт условно делится на Core («сам язык C++») и Library-части (стандартная библиотека). Это не на 100% строгое разделение, «сам язык» знает кое-что о стандартной библиотеке (std::size_t, std::ptrdiff_t, std::initializer_list и т.д.), поэтому я говорю «условно делится».

Стандарт начинается с Core-части, после идёт описание библиотеки. Вот табличка страниц, с которых начинается Library-часть («Library introduction») в разных версиях стандарта:

• C++98 — стр. 311
• C++03 — стр. 317
• С++11 — стр. 424
• C++14 — стр. 414
• C++17 — стр. 445

итого, за почти 20 лет «сам» C++ распух чуть более чем на 100 страниц, на треть от C++98.

Всё остальное распухание с 776 до 1618 страниц приходится на стандартную библиотеку.

В чём сложность осилить 100 страниц за 20 лет? Ладно, там не только добавляли, но и меняли уже имеющееся. Страниц на 200-250 новшеств может набралось.

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