Учитывая ваш богатый опыт, было бы странным предположить, что вы не видели функций, принимающих несколько аргументов. Имена этих функций могут быть достаточно длинными. Аргументов может быть больше, чем 3 и вообще эти функции могут оказаться частью API сторонней библиотеки. Да, вы правы, часто можно записать все в несколько отдельных строк. Но с моим неидеальным и многословным C++, не все удается вместить в 80-90 символов и перенос на следующую строку бывает неплохим компромиссом.
Функциональное программирование — штука интересная, но на практике, императивное программирование до сих пор доминирует.
Я сам противник писать несколько инструкций в одной строке. Лично меня больше заботит возможность переноса длинных строк.
Это разделители инструкций (statements). Если обходиться только концами строк, придется либо вводить ограничение «одна строка — одна инструкция», либо придумывать какой-то маркер переноса длинных инструкций на новую строку. В C перенос можно сделать где угодно, а в JavaScript и Python (языки без обязательных разделителей инструкций) уже другие правила.
Гугл, как и все крупные компании, уже давно заболел «мы лучше знаем, что вам нужно». Именно поэтому крупные компании в принципе не способны сделать отличный продукт — им наплевать на мнение пользователей. Они будут лицемерить, объяснять все заботой или защитой (ничего не напоминает?), но по факту они просто диктуют нужные им правила, удобные для бизнеса.
На моей ASUS Xonar Essence STX II можно получить задержку около 10 мс с использованием WASAPI (на ASIO в принципе так же, хотя у моей карты кривой драйвер). ASIO это все же про еще меньшие задержки. Говорят, на нормальных аудиоинтерфейсах доистижима задержка в 2-5 мс.
Читая заголовок подумал, что будет про разработку «под ASIO», оказалось, статья про работу со сторонней библиотекой, умеющей работать с ASIO. Так бы и писали, «использование библиотеки Bassasio».
В качестве примеров работы с ASIO можно посмотреть исходники проектов rtaudio и portaudio.
По поводу меню Пуск, советую попробовать альтернативный подход — keypirinha. Это такой аналог линуксовых launcher'ов из GNOME и KDE, который всплывает по комбинации клавиш и умеет кучу всего, от поиска/запуска установленных программ и диалоговых окон с настройками, до специальных команд, выполняющих самые разные действия (калькулятор, конвертация систем счисления, валют и т.п.). Все это дело написано на Python и расширяемо. Иными словами заменяет Пуск сильно больше, чем полностью.
Walter Bright, создатель первого полноценного компилятора C++ и автор языка D писал, что
There are a few things I (perhaps surprisingly) suggest should not be considerations… Easy parsing. It isn’t hard to write parsers with arbitrary lookahead. The looks of the language shouldn’t be compromised to save a few lines of code in the parser. Remember, you’ll spend a lot of time staring at the code. That comes first.
…Somewhat more controversial, I wouldn’t bother wasting time with lexer or parser generators… They’re a waste of time. Writing a lexer and parser is a tiny percentage of the job of writing a compiler.
Мой очень скромный опыт тоже подтверждает эту мысль. Написание LL-парсера вручную не является особой проблемой. Гораздо больше сил уходит на все остальное.
У меня двоякое отношение к языку D. С одной стороны он имеет множество очень интересных возможностей и писать на нем весьма приятно и продуктивно. Но с другой стороны, создается впечатление, что язык в принципе довольно плохо проработан. С точки зрения C++ разработчика, в D есть несколько нелепостей, от которых сильно «бомбит». Например квалификатор const. В D отсутствует аналог mutable из C++ и при этом константность транзитивна. Т.е. если указатель константный, значит и данные, на которые он ссылается, тоже изменять нельзя. Из-за этого в константном методе невозможно реализовать ленивую инициализацию, инкремент счетчика ссылок или даже захватить мьютекс. Общепринятая практика в D — по возможности не использовать const вообще. Еще пример — в D нельзя передать rvalue в функцию, которая принимает ссылку на const данные. Из-за этого приходится создавать временные объекты или плодить перегрузки функций в геометрической прогрессии. Так же в D есть квалификаторы типа shared, scope, которые имеют свои проблемы. Ну и самое «вкусное» — это конечно сборщик мусора. Я нисколько не против его наличия, но в случае необходимости его отключения, придется расстаться и с половиной «стандартной» библиотеки phobos. Кроме того, отвалятся встроенные динамические и ассоциативные массивы, а так же классы. Т.е. по сути, существенная часть возможностей превращается в тыкву.
Вы меня неправильно поняли. Нет никакой проблемы найти расположение файлов WSL. Проблема в том, что при их модификации/копировании с помощью Windows программ, портятся их метаданные. Т.е. файлы как бы есть, но трогать их можно только из WSL. Поэтому тот же CLion, при использовании WSL тулчейна, работает через SSH подключение.
Невозможность производить операции с файлами в WSL файловой системе средствами Windows программ.
Каждый WSL терминал имеет свой собственный init процесс, из-за чего приходится городить огороды, чтобы получить постоянно работающий SSHD. Гораздо разумнее было бы пускать WSL-init фоном, как виндовый сервис.
Использовать WSL для разработки под Linux неудобно, проще работать в Linux.
Использовать WSL для разработки под Windows (линуксовые утилиты + кросскомпиляция) так же неудобно, уж лучше MSYS2/MinGW. Отсюда вопрос — зачем оно? Чтобы без PuTTY иметь возможность подключаться к Linux машинам, сидя в Windows окружении?
Ну значит блеф не удался и пришлось включать заднюю. США же не дураки развязывать ядерный конфликт, пусть даже со страной, которую они многократно превосходят по количеству и качеству вооружений.
Как по мне, так Трамп достаточно предсказуем. Его метод — довести ситуацию до крайности и заставить оппонента пойти на уступки. Он не рискнет (или ему не позволят) принимать такое решение, которое навредит своим же интересам. Все что он делает — либо блеф, либо не несет особо негативных последствий для самих США.
Учитывая ваш богатый опыт, было бы странным предположить, что вы не видели функций, принимающих несколько аргументов. Имена этих функций могут быть достаточно длинными. Аргументов может быть больше, чем 3 и вообще эти функции могут оказаться частью API сторонней библиотеки. Да, вы правы, часто можно записать все в несколько отдельных строк. Но с моим неидеальным и многословным C++, не все удается вместить в 80-90 символов и перенос на следующую строку бывает неплохим компромиссом.
Функциональное программирование — штука интересная, но на практике, императивное программирование до сих пор доминирует.
Я сам противник писать несколько инструкций в одной строке. Лично меня больше заботит возможность переноса длинных строк.
В качестве примеров работы с ASIO можно посмотреть исходники проектов rtaudio и portaudio.
Мой очень скромный опыт тоже подтверждает эту мысль. Написание LL-парсера вручную не является особой проблемой. Гораздо больше сил уходит на все остальное.
Использовать WSL для разработки под Linux неудобно, проще работать в Linux.
Использовать WSL для разработки под Windows (линуксовые утилиты + кросскомпиляция) так же неудобно, уж лучше MSYS2/MinGW. Отсюда вопрос — зачем оно? Чтобы без PuTTY иметь возможность подключаться к Linux машинам, сидя в Windows окружении?