Прошлой осенью я присутствовал на мероприятии в городе Путраджайя, где Грейс Натан и Гибсон стояли перед камерами с министром транспорта Энтони Лоуком
… Натан буквально кипел от такого отношения со стороны министра.
Сам в RabbitMQ не шарю, но вопрос такой — что мешает создать подписчика, который будет просто слушать все нужные очереди и пересылать сообщения в точку доступа?
Функциональное программирование помогает сделать код более понятным, предсказуемым и легким для чтения
противоречит вот этому
Функциональное программирование имеет тенденцию писать код в слишком абстрактной форме, когда сам программист больше не понимает, что он написал через некоторое время.
Рассчитана на того, кто пару лет назад начал свой путь с манящей доступностью Ubuntu, полтора года назад перешёл на не подверженный воздействию времени Debian, год назад решился продолжить поиск себя в недрах загадочного OpenSuse, полгода назад покорил свой первый и неповторимый ArchLinux и сейчас стоит в нерешительности, устремив свой свободный взгляд на сверкающий пик непостижимого Gentoo… :)
Вообще, может работало бы и быстрее, да, но вот разработка похожей многопоточной системы заняла бы в десятки раз больше времени и средств.
Erlang/Elixit предоставляет очень неплохой инструментарий для разработки высоконагруженных отказоустойчивых многопоточных приложений, и я не знаю такого языка, который бы лучше подошёл ребятам из Discord.
Кесарю — кесарево :)
Во, чего откопал:
Оказывается, при выделении памяти под указатель на char, sizeof() является одним из способов дать понять, зачем нам нужна эта переменная.
То есть.
Тот же char * иногда используют, например, когда упаковывают пакеты перед отправкой на RAW-сокет, и тогда выделение памяти будет выглядеть так:
char *packet = malloc(sizeof(ether_header) + sizeof(struct iphdr) + sizeof(struct udphdr) + sizeof(payload));
Тому, кто будет сопровождать проект будет ясно, что это переменная под пакет. (заголовки и данные)
А если мы напишем sizeof(char) * n, это указание, что эта переменная будет использована как строка.
Я не знаю, зачем так делать (буду благодарен тому, кто объяснит), но тем не менее — в определенных кругах считается аж правилом хорошего тона :)
В общем случае размер типа char на конкретной платформе регулируется значением константы CHAR_BITS, определённой в заголовочном файле limits.h. По умолчанию и на платформах x86 она равна 8
Проблема в том, что подавляющее большинство строк в си, обработанных стандартными функциями, содержит в конце символ '\0'.
Хотите работать без него — тогда придется озаботиться использованием везде функций, которые ограничивают размер перемещаемой памяти (strncpy, snprintf, strncat), а в случае, когда у нас строки формируются из аргументов их использование (по назначению) не всегда возможно (только если не использовать подобие макроса strnsize, описанного в статье).
Это очень усложнит как процесс написания, так и процесс восприятия кода + количество функциональных вызовов на строку увеличится. Да и сам я не встречал проектов, где подобная практика используется :)
Алгоритм — последовательность действий. Динамическая память — инструмент реализации.
Я не говорю, что вы не правы, просто я немного не могу понять суть.
Хорошо, давайте посмотрим с другой стороны.
Если нам придется дебажить программу в рантайме, как мы отличим инициализированные переменные от неинициализированных? Ну, отловили мы контекст, начинаем смотреть память.
А мусор по адресу бывает нередко «похож на правду». Очень часто это может запутать.
По поводу вашего предыдущего комментария — я, очевидно, не так прочел. Я соглашусь, что мусор вылезет сразу, а нули могут замаскировать ошибку. Тем не менее, зануление памяти в Си — очень полезная штука. Это не C# и не Java, здесь занулением никто, кроме программиста заниматься не будет.
Проверка на пустоту массива, например, когда в нем лежит мусор будет некорректной и посчитает только что аллоцированный массив заполненным :)
Отнюдь.
Рассмотрим ситуацию, когда кусок памяти, выделяемой под строку (допустим, тот же «Hello, Habr!\n»), выглядит вот так: 0x602010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x602018: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Тогда после записи туда строки «Hello, Habr!\n» (без символа конца строки), этот кусок будет выглядеть так: 0x602010: 0x48 0x65 0x6c 0x6c 0x6f 0x2c 0x20 0x48
0x602018: 0x61 0x62 0x72 0x21 0x0a 0x00 0x00 0x00
Проблем нет, если мы попробуем распечатать эту строку функцией printf(), которая выводит все символы до тех пор, пока не встретить нулевой символ (конец строки), то она дойдет до первого куска памяти, в котором есть 0x00 (14 символ), и интерпретирует его как конец строки.
Теперь история с мусором: 0x602010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x602018: 0x00 0x00 0x00 0x00 0x65 0x65 0x65 0x00
Грейс Натан — женщина :)
Тот же Radeon ReLive?)
противоречит вот этому
Вопросы выпаса котов — оно такое)
Рассчитана на того, кто пару лет назад начал свой путь с манящей доступностью Ubuntu, полтора года назад перешёл на не подверженный воздействию времени Debian, год назад решился продолжить поиск себя в недрах загадочного OpenSuse, полгода назад покорил свой первый и неповторимый ArchLinux и сейчас стоит в нерешительности, устремив свой свободный взгляд на сверкающий пик непостижимого Gentoo… :)
Вообще, может работало бы и быстрее, да, но вот разработка похожей многопоточной системы заняла бы в десятки раз больше времени и средств.
Erlang/Elixit предоставляет очень неплохой инструментарий для разработки высоконагруженных отказоустойчивых многопоточных приложений, и я не знаю такого языка, который бы лучше подошёл ребятам из Discord.
Кесарю — кесарево :)
Главное, чтоб об этой статье не прознали школьники — количество доморощенных кулхацкеров возрастет по экспоненте))
Оказывается, при выделении памяти под указатель на char, sizeof() является одним из способов дать понять, зачем нам нужна эта переменная.
То есть.
Тот же char * иногда используют, например, когда упаковывают пакеты перед отправкой на RAW-сокет, и тогда выделение памяти будет выглядеть так:
char *packet = malloc(sizeof(ether_header) + sizeof(struct iphdr) + sizeof(struct udphdr) + sizeof(payload));
Тому, кто будет сопровождать проект будет ясно, что это переменная под пакет. (заголовки и данные)
А если мы напишем sizeof(char) * n, это указание, что эта переменная будет использована как строка.
Я не знаю, зачем так делать (буду благодарен тому, кто объяснит), но тем не менее — в определенных кругах считается аж правилом хорошего тона :)
Только что проверил у себя.
Вопросов нет :)
Хотите работать без него — тогда придется озаботиться использованием везде функций, которые ограничивают размер перемещаемой памяти (strncpy, snprintf, strncat), а в случае, когда у нас строки формируются из аргументов их использование (по назначению) не всегда возможно (только если не использовать подобие макроса strnsize, описанного в статье).
Это очень усложнит как процесс написания, так и процесс восприятия кода + количество функциональных вызовов на строку увеличится. Да и сам я не встречал проектов, где подобная практика используется :)
Я не говорю, что вы не правы, просто я немного не могу понять суть.
Если нам придется дебажить программу в рантайме, как мы отличим инициализированные переменные от неинициализированных? Ну, отловили мы контекст, начинаем смотреть память.
А мусор по адресу бывает нередко «похож на правду». Очень часто это может запутать.
По поводу вашего предыдущего комментария — я, очевидно, не так прочел. Я соглашусь, что мусор вылезет сразу, а нули могут замаскировать ошибку. Тем не менее, зануление памяти в Си — очень полезная штука. Это не C# и не Java, здесь занулением никто, кроме программиста заниматься не будет.
Проверка на пустоту массива, например, когда в нем лежит мусор будет некорректной и посчитает только что аллоцированный массив заполненным :)
Рассмотрим ситуацию, когда кусок памяти, выделяемой под строку (допустим, тот же «Hello, Habr!\n»), выглядит вот так:
0x602010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x602018: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Тогда после записи туда строки «Hello, Habr!\n» (без символа конца строки), этот кусок будет выглядеть так:
0x602010: 0x48 0x65 0x6c 0x6c 0x6f 0x2c 0x20 0x48
0x602018: 0x61 0x62 0x72 0x21 0x0a 0x00 0x00 0x00
Проблем нет, если мы попробуем распечатать эту строку функцией printf(), которая выводит все символы до тех пор, пока не встретить нулевой символ (конец строки), то она дойдет до первого куска памяти, в котором есть 0x00 (14 символ), и интерпретирует его как конец строки.
Теперь история с мусором:
0x602010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x602018: 0x00 0x00 0x00 0x00 0x65 0x65 0x65 0x00
Собственно, после записи:
0x602010: 0x48 0x65 0x6c 0x6c 0x6f 0x2c 0x20 0x48
0x602018: 0x61 0x62 0x72 0x21 0x0a 0x65 0x65 0x00
Вывод программы:
-> Hello, Habr!
ee
Примерно так :)
Речь шла о безопасном коде, а не производительном в данном случае.
Еще и ностальгия взяла… :)