Отличная статья, выражаю благодарности автору. Нахожусь на этапе подготовки предложения по рефакторингу файлов сборки текущего проекта, и как вовремя ваша статья выходит.. Если будет интересна тема, напишете о кросскомпиляции, интересуют не только Linux / Windows, но и мобильные платформы, как в этом случае лучше конфигурировать зависимости: особенно когда многие было бы проще сначала собрать, и они разбросаны по кастомным путям
как насчет webrtc от гугла - он написан поверх (не вспомню сейчас как именно называется) другой гугловской либой, которая так же пробивает NAT'ы и обеспечивает связь пиров, они признают, что могут пробить NAT далеко не в 100% случаев, чем Ваше решение лучше\удобнее\эффективнее?
если в первом случае это указатель на функцию, то почему бы не std::function? ну и кмк статья больше не про то, чтобы вообще не использовать, а про то, что есть уже для некоторых кейсов более подходящие конструкции
сам по себе проект крутой, но потеря доли рынка iOS, потенциальные проблемы с Huawei, и даже на андроид, я так понимаю, что все ставится с разрешения ставить с неопознанных источников?
Я отчего-то уверен, что константаная сложность для этого метода приблизительно такая же, как из переменой прочитать)) что там за потери времени такие на вызов, близкий к О(1)? Все таки это не std::list или std::forward_list, где она будет линейной и будет отбирать время
Тем временем ниже автор признался, что дело в несоответствии знакового int и беззнакогового size_t
и так, вы определелили изначально размер строки, которая мутировала внутри цикла и стала меньге, если бы сравнение было с s.size(), цикл бы завершился и все было бы хорошо, а вот в вашем случае, мы продолжим индексироваться уже за пределами массива (строки), а это уже очень трагичное UB
получается, что невольно идет упор на особенности нового железа, ну тогда скорее всего можно выбрать неуниверсальный его вариант и максимально заточить под конретный аппарат
что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов
а зачем создавать репозиторий перед клонированием? можно же сразу клонировать?
Отличная статья, выражаю благодарности автору. Нахожусь на этапе подготовки предложения по рефакторингу файлов сборки текущего проекта, и как вовремя ваша статья выходит..
Если будет интересна тема, напишете о кросскомпиляции, интересуют не только Linux / Windows, но и мобильные платформы, как в этом случае лучше конфигурировать зависимости: особенно когда многие было бы проще сначала собрать, и они разбросаны по кастомным путям
как насчет webrtc от гугла - он написан поверх (не вспомню сейчас как именно называется) другой гугловской либой, которая так же пробивает NAT'ы и обеспечивает связь пиров, они признают, что могут пробить NAT далеко не в 100% случаев, чем Ваше решение лучше\удобнее\эффективнее?
а как же бозон Хиггса?
скороспелость - очередной неологизм, который спишем на "это перевод"?
да и теги других яп, потому что статья не о них
не очень знаком с питоном, но вроде std::async вполне есть в С++11 ?
как заметили выше коллбэки, и кроме того, я бы обощил до любого места, где применяется объект-замыкание \ функциональный объект
сравнение скорости передвижение шедеврально приведено, миллиметры\минуты и микрометры\секунды, сразу сравнительно понятно кто быстрый, кто медленный
если в первом случае это указатель на функцию, то почему бы не std::function?
ну и кмк статья больше не про то, чтобы вообще не использовать, а про то, что есть уже для некоторых кейсов более подходящие конструкции
невалиден, как и во всем stl, впрочем тут нужен не указатель, а std::reference_wrapper<>
а зачем ее ставить абсолютному большиству? большинство приложений есть в GPlay и прекрасно ставятся
сам по себе проект крутой, но потеря доли рынка iOS, потенциальные проблемы с Huawei, и даже на андроид, я так понимаю, что все ставится с разрешения ставить с неопознанных источников?
Я отчего-то уверен, что константаная сложность для этого метода приблизительно такая же, как из переменой прочитать)) что там за потери времени такие на вызов, близкий к О(1)? Все таки это не std::list или std::forward_list, где она будет линейной и будет отбирать время
Тем временем ниже автор признался, что дело в несоответствии знакового int и беззнакогового size_t
то есть в стандарт потихоньку протаскиваются вещи, более удобные для конкретного компилятора?
опять же в чем проблема с вычислениями? какая ассимптокика у этого метода? в целом бля большинства контейнеров она константная
и так, вы определелили изначально размер строки, которая мутировала внутри цикла и стала меньге, если бы сравнение было с s.size(), цикл бы завершился и все было бы хорошо, а вот в вашем случае, мы продолжим индексироваться уже за пределами массива (строки), а это уже очень трагичное UB
size() имеет константную сложность для большинтсва контейнеров, скорее все же дело в int и size_t
получается, что невольно идет упор на особенности нового железа, ну тогда скорее всего можно выбрать неуниверсальный его вариант и максимально заточить под конретный аппарат
что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов