Если пользоваться микрософтовскими тулами - то отдельный исходник на MASM, реализующий вызываемые из C/C++ функции; насколько помню, поддержку инлайн ассемблера при компиляции под Win64 убрали. В gcc/clang можно и инлайн вставки делать.
В статье больше про IDE и работу с Win32 API. Реально на ассемблере сейчас скорее пишется самодостаточный код, который ничего не вызывает. И чтобы поиграться - на мой взгляд проще скомпилировать сишный код через gcc -S и дальше модифицировать сгенерённый ассемблер.
Полезно знать про регистры, calling convention, режимы адресации, атомики и разные подходы к ним на разных архитектурах, SIMD - но ничего этого нет.
Это действительно полезно. Но статья о конкретике кодинга в VS2019 под 32-бинтую винду, а по работе может понадобиться сделать, скажем, маленькую вставку в gcc на Aarch64 )
Но чтоже делать тем кто поднимался в карьере 5-10 лет назад?
Продолжать учиться, при этом раскладывая по полочкам старые знания, становясь экспертом в какой-то области - чтобы по соответствующим сложным вопросам по крайней мере в ближайшем окружении обращались к тебе. Это, правда, если работа не чистый кодинг, а R&D с заметным элементом R.
И что это даёт пользователю? Лет двадцать периодически покупаю билеты на сайтах авиакомпаний. Раньше нужную функциональность прекрасно обеспечивал статический html с формочками и cgi на сервере. Сейчас у всех "веб приложения" со скриптами на клиенте и микросервисами, я от этого вижу только тормоза при отрисовке и запросах к разным серверам, функциональность абсолютно та же.
Я могу согласиться с формулировкой "если можно обойтись без указателей - не используйте". Но то, что они сейчас вообще не нужны - это перебор, в низкоуровневых библиотеках и системном софте явные указатели (с явной арифметикой, кастингом на целые и т.п.) часто необходимы.
Вам встречались другие варианты? Возможно в художественном переводе в каких то контекстах адекватнее другие синонимы, но в технических текстах о выделении памяти альтернатив не видел.
Польза многопоточности очевидна, когда у вас есть физическая возможность исполнять разные потоки независимо ИЛИ когда созданный поток фактически НЕ исполняется, как в случае из вашего примера с запросами.
На мой взгляд это все случаи и покрывает. Создавать несколько счётных потоков на однопроцессорной машине смысла нет. Просто ситуация, когда поток большую часть времени не работает на CPU, а ждёт внешнего события (скажем, пакета из сети или клика мышкой) достаточно частая
Теоретически можно захватить счётчик по ссылке на одной итерации и использовать полученную лямбду на другой - это и в С++ валидно (и как раз такой код будет ломаться от описанного изменения в Go). Другое дело, что большого практического смысла нет.
В начале 90х многие знакомые писали под ДОС на Турбо Паскале в таком стиле )
Если пользоваться микрософтовскими тулами - то отдельный исходник на MASM, реализующий вызываемые из C/C++ функции; насколько помню, поддержку инлайн ассемблера при компиляции под Win64 убрали. В gcc/clang можно и инлайн вставки делать.
Сейчас скорее регистры (когда хватает) - стандарт, а стек - legacy на древних платформах типа 32-битного Интела )
В статье больше про IDE и работу с Win32 API. Реально на ассемблере сейчас скорее пишется самодостаточный код, который ничего не вызывает. И чтобы поиграться - на мой взгляд проще скомпилировать сишный код через gcc -S и дальше модифицировать сгенерённый ассемблер.
Полезно знать про регистры, calling convention, режимы адресации, атомики и разные подходы к ним на разных архитектурах, SIMD - но ничего этого нет.
Это действительно полезно. Но статья о конкретике кодинга в VS2019 под 32-бинтую винду, а по работе может понадобиться сделать, скажем, маленькую вставку в gcc на Aarch64 )
Продолжать учиться, при этом раскладывая по полочкам старые знания, становясь экспертом в какой-то области - чтобы по соответствующим сложным вопросам по крайней мере в ближайшем окружении обращались к тебе. Это, правда, если работа не чистый кодинг, а R&D с заметным элементом R.
Согласен, что надо быть готовым ко всему и советы в целом полезны, но кое что в тексте очень наивно
Это вообще самое начало, обычно только через год начинаешь понимать, что к чему в компании.
Хорошее правило - тебя должен знать и ценить менеджер твоего менеджера.
И добавлю, что лучше и в хорошие периоды иметь пару вариантов в других проектах компании и снаружи, куда тебя всегда готовы взять.
Просто пойнтер поддерживает то, что необходимо итератору с произвольным доступом, и никакой дополнительный итератор из него конструировать не надо.
Понимаю )
Ну вот навскидку https://pspdfkit.com/blog/2018/how-to-program-a-calculator-pdf/
Что, половина группы Владлены и Оюшминальды ? )
И что это даёт пользователю? Лет двадцать периодически покупаю билеты на сайтах авиакомпаний. Раньше нужную функциональность прекрасно обеспечивал статический html с формочками и cgi на сервере. Сейчас у всех "веб приложения" со скриптами на клиенте и микросервисами, я от этого вижу только тормоза при отрисовке и запросах к разным серверам, функциональность абсолютно та же.
Я могу согласиться с формулировкой "если можно обойтись без указателей - не используйте". Но то, что они сейчас вообще не нужны - это перебор, в низкоуровневых библиотеках и системном софте явные указатели (с явной арифметикой, кастингом на целые и т.п.) часто необходимы.
В печатных книжках?
Вам встречались другие варианты? Возможно в художественном переводе в каких то контекстах адекватнее другие синонимы, но в технических текстах о выделении памяти альтернатив не видел.
А в Замоскворечье то что такого плохого? И вообще внутри Садового как то мало зелёного...
Ну напишите без них свой аллокатор...
Да, у Остерхута были слайдики на эту тему - https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/ousterhout-threads.pdf Но не очень понятно что делать, если под рукой только синхронные API для ожидания и реагировать при этом надо на разнородные события, которые одним API типа select не покрываются.
На мой взгляд это все случаи и покрывает. Создавать несколько счётных потоков на однопроцессорной машине смысла нет. Просто ситуация, когда поток большую часть времени не работает на CPU, а ждёт внешнего события (скажем, пакета из сети или клика мышкой) достаточно частая
Теоретически можно захватить счётчик по ссылке на одной итерации и использовать полученную лямбду на другой - это и в С++ валидно (и как раз такой код будет ломаться от описанного изменения в Go). Другое дело, что большого практического смысла нет.