если в первом случае это указатель на функцию, то почему бы не std::function? ну и кмк статья больше не про то, чтобы вообще не использовать, а про то, что есть уже для некоторых кейсов более подходящие конструкции
сам по себе проект крутой, но потеря доли рынка iOS, потенциальные проблемы с Huawei, и даже на андроид, я так понимаю, что все ставится с разрешения ставить с неопознанных источников?
Я отчего-то уверен, что константаная сложность для этого метода приблизительно такая же, как из переменой прочитать)) что там за потери времени такие на вызов, близкий к О(1)? Все таки это не std::list или std::forward_list, где она будет линейной и будет отбирать время
Тем временем ниже автор признался, что дело в несоответствии знакового int и беззнакогового size_t
и так, вы определелили изначально размер строки, которая мутировала внутри цикла и стала меньге, если бы сравнение было с s.size(), цикл бы завершился и все было бы хорошо, а вот в вашем случае, мы продолжим индексироваться уже за пределами массива (строки), а это уже очень трагичное UB
получается, что невольно идет упор на особенности нового железа, ну тогда скорее всего можно выбрать неуниверсальный его вариант и максимально заточить под конретный аппарат
что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов
как насчет интеграции с системами сборки, например тем же CMake из коробки?
отмечается плохое покрытие тестами у авторских библиотек, как с этим обстоят дела? как я понял из-за сложности так же покрытие не полное? кроме того тесты отдельным проектом ну такое
скороспелость - очередной неологизм, который спишем на "это перевод"?
да и теги других яп, потому что статья не о них
не очень знаком с питоном, но вроде 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) немного медленный рост реальных проектов
как насчет интеграции с системами сборки, например тем же CMake из коробки?
отмечается плохое покрытие тестами у авторских библиотек, как с этим обстоят дела? как я понял из-за сложности так же покрытие не полное? кроме того тесты отдельным проектом ну такое
не очень заметил какую-либо документацию
то ли у меня проблемы с восприятием, то ли перевод машинный и "кривой" по части терминологии
В современном С++ вроде макросы не очень хороший стиль, и модулями уже можно заменять беспорядочные include, зачем же вот это все((
можно еще поюзать синтаксический сахар, не имеющий отношения к задаче, и использовать что-то типа:
std::is_same_v<>