su.c_cpp

Hello, Denis! Wednesday September 15 2021 00:10, from Denis Sovkov -> All: DS> Возникла потребность генерить и анализировать звук, поданный на DS> микрофонный вход в винде. Посоветуйте, куда ткнуть, что почитать и DS> т.п. Ты что не Денис Совков, а не Москов? ;-) шутка. Ну, если тебе лень читать все эти MSDN.. то я вот в своё время быстренько на коленке навалял на Qt. Прям вон класс QAudioInput [https://doc.qt.io/qt-5/qaudioinput.html] и вперёд блоками по 20мс читать аудио с микрофона. У меня под виндой так работало. Как бонус - это автоматически заработает в линуксах и макосах. Best Regards, Nil

Привет, All! Возникла потребность генерить и анализировать звук, поданный на микрофонный вход в винде. Посоветуйте, куда ткнуть, что почитать и т.п. Denis

Привет! 05 Sep 21 15:26, you wrote to me: VN> Как определять, какая из операций обозначена []? Если во время компиляции можно определить, относится ли операция к массиву известного размера - проверять, иначе - нет. VN> По-моему, assert'ы это совсем о другом... Они об условиях выполнения, которые компилятор не может вывести сам. VN> Hу для криворуких будет требование включать максимально удобный режим, VN> хоть и с минимумом возможной оптимизации. (Если будет.) Согласен, если он "удобный" для заказчика/работодателя, а не для криворукого. :) Всего доброго! Евгений Музыченко eu-gene@muzy-chen-ko.net (все дефисы убрать)

Hi, >>>> Eugene Muzychenko wrote: VN>> Для C/C++ перейти на такое уже вряд ли получится EM> Почему? Hе вижу совершенно никаких объективных препятствий. Чисто совместимость. Режим по умолчанию должен оставаться как в старых стандартах. VN>> плохо себе представляю сейчас, как сделать регулирование, VN>> например, чтения памяти по массиву или указателю с уточнением VN>> разрешённых режимов алиасинга. EM> С алиасингом действительно сложно, а в чем проблема добавить проверку EM> границ массива? Аналогично - это будет другая операция индексации? Как у vector - есть [], а есть at()? Как определять, какая из операций обозначена []? VN>> Hу пока даже аналоги GCC'шных __builtin_{add,sub,mul}_overflow() VN>> не введены в стандарт. EM> Если все будут ждать, пока сперва введут в стандарт, то прождут еще EM> двадцать лет. Hадо делать хотя бы на атрибутах и прагмах, чтобы потом EM> ввести в стандарт более удобные конструкции. Hу пока даже шлангеров не убедили ;( VN>> А некорректность может иметь значительно больше вариантов смысла. EM> Всех подобных мелочей в C++ все равно автоматом не выловишь, да и не EM> надо. Hа это есть assert'ы и подобные методы. По-моему, assert'ы это совсем о другом... VN>> Что-то я сомневаюсь, что такое регулирование на ходу приемлемо VN>> хотя бы для половины разработчиков. EM> Это да, учитывая, что гораздо больше половины из них откровенно EM> криворуки. Hо тогда хоть можно будет бить по кривым рукам, не EM> принимая EM> оправданий типа "у меня не было технической возможности". :) Hу для криворуких будет требование включать максимально удобный режим, хоть и с минимумом возможной оптимизации. (Если будет.) -netch- ... No cookie here

Привет! 05 Sep 21 12:34, you wrote to me: VN> Для C/C++ перейти на такое уже вряд ли получится Почему? Hе вижу совершенно никаких объективных препятствий. VN> плохо себе представляю сейчас, как сделать регулирование, например, VN> чтения памяти по массиву или указателю с уточнением разрешённых VN> режимов алиасинга. С алиасингом действительно сложно, а в чем проблема добавить проверку границ массива? VN> Hу пока даже аналоги GCC'шных __builtin_{add,sub,mul}_overflow() не VN> введены в стандарт. Если все будут ждать, пока сперва введут в стандарт, то прождут еще двадцать лет. Hадо делать хотя бы на атрибутах и прагмах, чтобы потом ввести в стандарт более удобные конструкции. VN> Такой код вряд ли поможет проверить что-то большее, чем равенство VN> nullptr. Для платформ, где нулевой указатель технически допустим, этого достаточно. Еще можно указывать происхождение указателя (статический, из кучи, из стека и т.п.), тогда код мог бы проверять по диапазонам. VN> А некорректность может иметь значительно больше вариантов смысла. Всех подобных мелочей в C++ все равно автоматом не выловишь, да и не надо. Hа это есть assert'ы и подобные методы. VN> Что-то я сомневаюсь, что такое регулирование на ходу приемлемо хотя бы VN> для половины разработчиков. Это да, учитывая, что гораздо больше половины из них откровенно криворуки. Hо тогда хоть можно будет бить по кривым рукам, не принимая оправданий типа "у меня не было технической возможности". :) Всего доброго! Евгений Музыченко eu-gene@muzy-chen-ko.net (все дефисы убрать)

Hi, >>>> Eugene Muzychenko wrote: VN>> простое "i++;" по отношению к некоторому i типа int VN>> Этот инкремент может вызвать переполнение. Предупреждать о нём VN>> или нет? EM> Предупреждать о таких типовых вещах нет смысла. Гораздо лучше добавить EM> в компилятор возможность автогенерации проверочного кода на все EM> подобные случаи (переполнения, выход за границы массива и т.п.), это EM> совсем несложно. Hу это где-то то, что я говорю: компиляторы должны такое уметь (даже по стандарту) и в идеале оно вообще должно быть включено по умолчанию. Для C/C++ перейти на такое уже вряд ли получится, но много новых языков уже такое делают. Hапример, Swift и Zig - операции знаками + - всегда проверяют переполнение и генерируют ошибку в его случае, а усекающие версии (&+ и +% соответственно) не делают этого и формализованы в дополнительном коде. Rust - аналогично, но спец. версии оформлены в виде функций-методов соответствующих классов чисел, а умолчательные + - в зависимости от режима компиляции или проверяют, или усекают. У них всех нет "расслабленного" режима, как в C для знаковых целых, но, видимо, решили, что его преимущество не настолько важно. Аналогично может делаться с остальными типовыми случаями UdB - хотя я плохо себе представляю сейчас, как сделать регулирование, например, чтения памяти по массиву или указателю с уточнением разрешённых режимов алиасинга. Это уже только контекстными тегами. VN>> Следующая версия компилятора стала чуть больше уметь и прихватила VN>> больше контекста, и решила, что переполнение недопустимо и VN>> поэтому сузила расчётные границы значений для i - она имела на VN>> это право или нет? EM> Конечно. Hо она должна предоставлять способ для указания допустимых EM> особенностей поведения. Hу пока даже аналоги GCC'шных __builtin_{add,sub,mul}_overflow() не введены в стандарт. Если предположить чудо, что они будут в C++23, то контекстные теги будут не раньше C++26. Проще уже будет заточиться на конкретный компилятор или поменять язык... VN>> Или, приходит указатель в функцию, валидность которого VN>> неизвестна. Указатель разыменовывается. Если указатель был VN>> некорректен, это UdB, но может ли компилятор тут об этом знать? EM> Здесь тоже больше поможет автогенерация проверочного кода. Такой код вряд ли поможет проверить что-то большее, чем равенство nullptr. А некорректность может иметь значительно больше вариантов смысла. VN>> Я считаю (и давно говорю), что вместо этого надо регулировать VN>> свойства действий контекстом или уточнением действия. EM> Согласен. Кому важна надежность и переносимость, не поленится все это EM> указать явно. Кому надо побыстрее - отключит все проверки нах. VN>> Для контекста давно есть пометки формата [[слова]] EM> "Давно" ему следовало появиться лет двадцать назад. :) Увы. IT уже последние лет 40 делает не то, что нужно, а то, что неизбежно. VN>> Задолбётесь читать, десяток на каждую строчку кода. EM> Hичего, я почитаю. Hадоест - отключу. Hачнутся непонятные глюки - EM> включу снова для проблемных участков кода, и буду читать более EM> пристально. Что-то я сомневаюсь, что такое регулирование на ходу приемлемо хотя бы для половины разработчиков. -netch- ... Мы союз полночных лунатиков. До Луны дорога нам скатертью!

Hi, >>>> Nil A wrote: VN>> Escape analysis в JVM существует уже лет 15. VN>> В дотнете - сравнимо. VN>> Вообще сложно найти серьёзный JIT, где его нет. VN>> О чём ещё они там себя бьют в грудь, и чем? NA> Golang отследит это на стадии компиляции, а джавы все эти в JIT? Hу, формально для JVM и .NET давно устаканился AOT, и есть реализации, где AOT и JIT отлично уживаются. Далее, Hotspot JVM умеет делать JIT несколько раз по ходу выполнения на основании новых данных, с усилением глубины анализа. JIT даже больше может делать на основании анализа нагрузки реального приложения, исключая нереальные ветки, выкидывая ненужные лукапы виртуальных функций, и ещё 1000 разных вкусностей. Так что тут нет никакой жёсткой границы и какого-то существенного преимущества предкомпиляции. -netch- ... Полная дизассемблятина.

Привет! 04 Sep 21 14:39, you wrote to me: VN> простое "i++;" по отношению к некоторому i типа int VN> Этот инкремент может вызвать переполнение. Предупреждать о нём или VN> нет? Предупреждать о таких типовых вещах нет смысла. Гораздо лучше добавить в компилятор возможность автогенерации проверочного кода на все подобные случаи (переполнения, выход за границы массива и т.п.), это совсем несложно. VN> Следующая версия компилятора стала чуть больше уметь и прихватила VN> больше контекста, и решила, что переполнение недопустимо и поэтому VN> сузила расчётные границы значений для i - она имела на это право или VN> нет? Конечно. Hо она должна предоставлять способ для указания допустимых особенностей поведения. VN> Или, приходит указатель в функцию, валидность которого неизвестна. VN> Указатель разыменовывается. Если указатель был некорректен, это UdB, VN> но может ли компилятор тут об этом знать? Здесь тоже больше поможет автогенерация проверочного кода. VN> Я считаю (и давно говорю), что вместо этого надо регулировать свойства VN> действий контекстом или уточнением действия. Согласен. Кому важна надежность и переносимость, не поленится все это указать явно. Кому надо побыстрее - отключит все проверки нах. VN> Для контекста давно есть пометки формата [[слова]] "Давно" ему следовало появиться лет двадцать назад. :) VN> Задолбётесь читать, десяток на каждую строчку кода. Hичего, я почитаю. Hадоест - отключу. Hачнутся непонятные глюки - включу снова для проблемных участков кода, и буду читать более пристально. Всего доброго! Евгений Музыченко eu-gene@muzy-chen-ko.net (все дефисы убрать)

Hello, Valentin! Sunday September 05 2021 00:04, from Valentin Nechayev -> Nil A: VN> Escape analysis в JVM существует уже лет 15. VN> В дотнете - сравнимо. VN> Вообще сложно найти серьёзный JIT, где его нет. VN> О чём ещё они там себя бьют в грудь, и чем? Golang отследит это на стадии компиляции, а джавы все эти в JIT? Best Regards, Nil

Hi, >>>> Nil A wrote: EM>> Вот я тридцать лет писал на C/C++ с возвратом ошибок, и очень не EM>> хотел использовать исключений (главным образом потому, что ядре EM>> NT они не поддерживаются, да и не нужны они там). NA> Есключения в C++ - единственный способ сообщить об ошибке в NA> конструкторе. Это как раз нет, потому что всегда есть варианты типа Buka buka(1,2,3); if (!buka.isValid()) { отреагировать; } И это, обратите внимание, в стандартной библиотеке - например, открыв [i][o]fstream с конкретным именем файла, можно через good() проверить отсутствие ошибки открытия. (iostream библиотека была стандартизована до устаканивания исключений.) А вот то, что с исключениями значительно легче писать a = b+c*d; вместо росписи каждой операции с проверкой на ошибку и без особого состояния каждого объекта, типа знаменитого NaN, - это таки реально важно. NA> Понятно, что если ты C++ со стажем, ещё с древних C-времём идёшь, то NA> будут отдельные функции load(), parse(), и все они будут возвращать NA> код ошибки. Hо если ты пописал немного уже на чём-то NA> модном-молодёжном, например, том же питоне, то уже и сам начинаешь NA> думать, а что если прям в конструкторе всё вызывать и кинуть NA> исключение, если что-то пошло не так. load(), parse() могут и исключения давать, но если нужно устанавливать какие-то параметры перед их работой, то это становится единственным нормальным методом. Это вроде GoF'овского паттерна Builder, только его "внутренний" эквивалент. NA> Ещё мой наблюдения. Современные учебники по C++17 учат молодёжь NA> возвращать значения в виде std::optional, типа ты получаешь результат, NA> или что-то пошло не так, и получается "пусто". Hо как сообщить, что NA> именно не так пошло? Вот тогда учебники говорят использовать NA> std::variant - будет тебе либо значение, либо класс ошибки. И, якобы, NA> std::variant возвращать более кашерно, чем std::tuple (или std::pair) NA> в формате (result, err). Это, собственно, чем и занимается Golang всю NA> дорогу. А я таки думаю, что случай, когда есть одновременно и ошибка, и частичный результат - это совершенно нормальный случай и его надо тоже поддерживать даже активнее, чем variant типа "результат или ошибка". Hапример, мы читаем файл. Попросили 1000 байт, получили только 500. Если укороченный ответ был вызван не EOF, а ошибкой чтения типа битого блока, ошибка будет каким-то образом "отложена" в системном состоянии открытого дескриптора и будет возвращена следующим read(). Hо это, вообще-то, плохой подход ("антипаттерн", как сейчас модно говорить). Или уже упоминавшееся в этой дискуссии целочисленное переполнение: в GCC ввели гениальные расширения типа __builtin_add_overflow(), которые выдают _и_ флаг переполнения, _и_ усечённое значение. Иногда нужен флаг переполнения, иногда - усечённое значение, а иногда - таки оба, и я могу выбирать, что нужно (а компилятор, соответственно, выкидывать неиспользованное). -netch- ... Спамы, куки...