• Bsd-socket. Почему бесконечное чтение при http запросе?

    jcmvbkbc
    @jcmvbkbc
    "I'm here to consult you" © Dogbert
    При повторной итерации read, по идее, должен вернуть 0, так как все прочитано

    Неа, не так это работает. 0 из read возвращается в одном единственном случае: если та сторона закрыла сокет на передачу и все посланные ею данные получены. В противном случае (сокет не закрыт) поведение зависит от настроек сокета: синхронный сокет при попытке чтения может заблокироваться в функции read или вернуть из неё -1 (и установить errno, например, в EINTR). Асинхронный сокет вернёт из read -1 и установит errno в EAGAIN или EWOULDBLOCK.
    Ваш HTTP-сервер наверняка оставляет соединение открытым после того как прислал ответ на первый запрос, это можно понять по наличию заголовка Connection: Keep-Alive или отсутствию заголовка Connection: close в его ответе если это HTTP/1.1. Его можно попросить закрыть соединение после ответа, послав запрос с заголовком Connection: close или можно избежать блокировки в read прочитав только данные ответа размер которых прислан в заголовке ответа Content-Length.
    Ответ написан
    2 комментария
  • Выдаст ли ошибку при аллоцировании памяти?

    @Mercury13
    Программист на «си с крестами» и не только
    Нормально.
    Аварии в деструкторе и конструкторе — дела сложные, но возможные.
    Но тут ни того, ни другого не будет. До вызова конструктора просто не дойдёт.
    } catch (const std::bad_alloc&) {}
    Ответ написан
    Комментировать
  • В чем "вкус" react?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    Вкус любого фреймворка в том что бы не делать лишнюю работу.
    В реакте есть реативность, виртуальный виртуальный DOM, роутинг , состояния

    Причем это все из коробки.
    Кроме того куча разработчиков написало уже компоненты на все случае жизни.

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

    UPD
    вот сравните https://qna.habr.com/q/1229430
    сложность оригинального кода автора и мое решение, видно что в моем случае включается "магия"
    Ответ написан
    Комментировать
  • В чем "вкус" react?

    vfreelancer
    @vfreelancer
    php
    представьте форму из 5 табов, в каждой по 15-20 полей. при изменении некоторых селектов часть полей пропадает, другие появляются, плюс какие-то селекты заполняются с сервера. плюс часть полей зависят от того, кто именно заполняет, плюс локализация, плюс валидация онлайн с проверками в бд на сервере. с реактом решение в разы легче и быстрее должно быть
    Ответ написан
    Комментировать
  • В чем "вкус" react?

    @12rbah
    В связи с этим у меня вопрос, чем же обоснована такая популярность этой библиотеки у работодателей?
    Если вы программируете 3 месяца то скорее всего не поймете. React или другой фреймворк изначально подразуевает то, что код хорошо делится по модулям и компонентам, что очень удобно, в обычном js нужно принимать больше усилий чтобы добиться этого. Также есть много готовых решений из коробки, которые уже были отлажены другими более опытными людьми.
    а модульность со мной сыграла злую шутку (прочитал, что хорошим тоном считается разбивать проект на мельчайшие модули, разбил свой, через пару недель я просто почти забыл, что от чего у меня зависит и какой модуль у меня что тянет за собой и главное куда тянет!
    Видимо вы попробовали выучить реакт за неделю, потом потом на 2-3 недели ушли заниматься своими делами и не трогали его и "внезапно" всё забыли. В целом можно писать комментарии для пояснения. Модульность как раз наоборот упрощает чтение кода и если правильно всё называть и прописывать, то в небольших проектах до 5-10к строк можно будет без проблем разобраться за пару дней тому кто не писал это код.
    P.S. Возможно вам лучше выложить вопрос с сылкой на ваш проект и вам подскажут что не так вы сделали, будет полезнее.
    Ответ написан
    Комментировать
  • Есть ли хоть какое-то преимущество использования функтора перед обычной функцией в данном случае?

    @MarkusD Куратор тега C++
    все время мелю чепуху :)
    У функтора перед функцией есть только одно преимущество - это наличие состояния функтора, которое может меняться между обращениями к его функциональному оператору и влиять на его поведение. Функтор настраивается эксклюзивно, функция - по понятным причинам - только глобально.
    У функции перед функтором тоже есть преимущество - это адрес функции, по которому сразу можно начать ее исполнение. У функтора всегда будет два адреса - адрес метода функционального оператора и адрес самого функтора.

    Исходя именно из этих преимуществ и следует выбирать между функтором и функцией.
    Скажем, если бы нужно было nums вписать в CSV таблицу в виде матрицы, то проще использовать функтор. Создать его, настроить поток вывода, символ-разделитель столбцов, количество выводов до перехода на следующую строку и передать в std::for_each.
    Если такая настройка поведения не требуется, от функтора лучше отказаться в пользу функции во всех случаях.

    Функтор используется в реализации идиомы делегата и коллбека. Делегаты позволяют универсальным образом хранить самые разные точки исполнения кода и безопасно проводить по ним исполнение.
    Если использование делегатов оправдано необходимостью, в делегаты оборачивают даже указатели на функцию, чтобы сохранить единообразие подхода к управлению исполнением.
    Ответ написан
    Комментировать
  • В чем преимущество статического массива перед динамическим?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    В первом случае у вас не статический массив, а локальный. Память для него выделяется на стеке и ограничена размером стека.
    Во втором случае выделяется динамический массив. Память под него ограничена свободной памятью системы или предельным размером динамического массива, если такое ограничение есть в системе.
    Ответ написан
    6 комментариев
  • В чем преимущество статического массива перед динамическим?

    Vindicar
    @Vindicar
    RTFM!
    Насколько мне известно...
    Статический массив:
    - Размер должен быть известен на момент компиляции. Твой пример - это нестандартная фишка ряда компиляторов, по-хорошему для статического массива размер не должен быть динамическим (определяться во время выполнения).
    + Компилятор сам позаботится об удалении массива.

    Динамический массив:
    + Размер может определяться во время выполнения.
    - Нужно не забыть освободить память массива самостоятельно.

    А вообще, если нет причин делать иначе, используй std::vector. Если тебе понадобится именно массив в стиле C, вектор позволяет его легко получить методом .data().
    + Размер не просто динамический, вектор может переаллоцировать свою память по мере надобности. Так что для ситуаций, когда размер заведомо неизвестен, вектор весьма удобен.
    + Вектор сам управляет своей памятью. Убил вектор - убил управляемый им массив.
    Ответ написан
    1 комментарий