Я могу согласиться с формулировкой "если можно обойтись без указателей - не используйте". Но то, что они сейчас вообще не нужны - это перебор, в низкоуровневых библиотеках и системном софте явные указатели (с явной арифметикой, кастингом на целые и т.п.) часто необходимы.
Вам встречались другие варианты? Возможно в художественном переводе в каких то контекстах адекватнее другие синонимы, но в технических текстах о выделении памяти альтернатив не видел.
Польза многопоточности очевидна, когда у вас есть физическая возможность исполнять разные потоки независимо ИЛИ когда созданный поток фактически НЕ исполняется, как в случае из вашего примера с запросами.
На мой взгляд это все случаи и покрывает. Создавать несколько счётных потоков на однопроцессорной машине смысла нет. Просто ситуация, когда поток большую часть времени не работает на CPU, а ждёт внешнего события (скажем, пакета из сети или клика мышкой) достаточно частая
Теоретически можно захватить счётчик по ссылке на одной итерации и использовать полученную лямбду на другой - это и в С++ валидно (и как раз такой код будет ломаться от описанного изменения в Go). Другое дело, что большого практического смысла нет.
Новость о том, что на разных итерациях разные переменные. Но внутри каждой итерации переменная одна, никто не мешает захватить её в теле цикла несколько раз в разные closure.
Насколько понимаю, семантически захват в Go всегда по ссылке и просто скопировать значение в общем случае не получится. Скажем, два захвата на одной итерации должны получить одну общую переменную.
Потом почему я их должен различать с точки зрения возможности паралелльного исполнения кусков кода или того как симулируется эта одновременность-параллельность?
Изначально многозадачность - это всё таки возможность выполнения независимых задач (скажем, счётные программки от Васи и Пети) на одном компьютере, и в таком виде она до сих пор живёт и к многопотоковости (как механизму, используемому прикладным программистом для использования конкурентности в своём коде) особого отношения не имеет. Да, если брать современные применения, граница достаточно нечёткая (в случаях, если мы всё таки используем несколько задач для получения общего результата), но изначальный посыл разный.
Первые двух процессорные материнские платы появились в 1999 году, тогда они реально были двух процессорные — в виде двух физических камней на материнской плате
Даже если говорить только о Intel - вышедший в 1995ом Pentium Pro поддерживал двухсокетные конфигурации, соответствующие материнки появились практически сразу. На "больших" компьютерах многопроцессорные конфигурации были гораздо раньше - тут скорее надо поискать, когда появилась материнская плата в современном понимании...
хотя такая конструкция наверно и сейчас никуда не делась, где‑то применяется.
Любой современный серверный процессор поддерживает многосокетные конфигурации. "Где то" - очень слабо сказано )
изобрести концепцию multiprogramming‑а или многозадачности, которые в итоге были оформлены как концепция многопоточности
Всё таки я бы не смешивал многозадачность и многопоточность, хотя вещи действительно связаны - и то и другое вполне живо.
многопоточность, в первую очередь, предназначена для работы с аппаратными функциями внутреннего компьютерного оборудования
Для этого вполне достаточно примитивного concurrency в виде системы прерываний. Многозадачность в первую очередь была сделана для одновременного использования большого дорогого компьютера несколькими людьми. Многопоточность внутри одного процесса - это уже более тонкая концепция, изначально сделанная для упрощения использования concurrency на прикладном уровне.
make всё таки общеизвестная система, не привязанная к коннкретному языку
идея была как раз в том, чтобы показать аргументы командной строки
Аргументы, передаваемые в javac и т.п. в Makefile и так будут в явном виде. А вот аргументы вашего скрипта и код типа if "%1"=="build" - это скорее лишняя сущность, отвлекающая от сути. Но если предполагается, что кто-то из читателей не знаком с make - может, проще и на cmd...
Я не понимаю, почему автор make не запользовал - достаточно низкоуровнево, чтобы показать какими командами реально собирается проект, но без необходимости вручную анализировать аргументы командной строки и т.п.
Я могу согласиться с формулировкой "если можно обойтись без указателей - не используйте". Но то, что они сейчас вообще не нужны - это перебор, в низкоуровневых библиотеках и системном софте явные указатели (с явной арифметикой, кастингом на целые и т.п.) часто необходимы.
В печатных книжках?
Вам встречались другие варианты? Возможно в художественном переводе в каких то контекстах адекватнее другие синонимы, но в технических текстах о выделении памяти альтернатив не видел.
А в Замоскворечье то что такого плохого? И вообще внутри Садового как то мало зелёного...
Ну напишите без них свой аллокатор...
Да, у Остерхута были слайдики на эту тему - https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/ousterhout-threads.pdf Но не очень понятно что делать, если под рукой только синхронные API для ожидания и реагировать при этом надо на разнородные события, которые одним API типа select не покрываются.
На мой взгляд это все случаи и покрывает. Создавать несколько счётных потоков на однопроцессорной машине смысла нет. Просто ситуация, когда поток большую часть времени не работает на CPU, а ждёт внешнего события (скажем, пакета из сети или клика мышкой) достаточно частая
Теоретически можно захватить счётчик по ссылке на одной итерации и использовать полученную лямбду на другой - это и в С++ валидно (и как раз такой код будет ломаться от описанного изменения в Go). Другое дело, что большого практического смысла нет.
Новость о том, что на разных итерациях разные переменные. Но внутри каждой итерации переменная одна, никто не мешает захватить её в теле цикла несколько раз в разные closure.
В С++ никаких новых переменных на каждой итерации не создаётся. Но там захватывать переменную цикла по ссылке - уже взвод курка для выстрела в ногу.
Насколько понимаю, семантически захват в Go всегда по ссылке и просто скопировать значение в общем случае не получится. Скажем, два захвата на одной итерации должны получить одну общую переменную.
Изначально многозадачность - это всё таки возможность выполнения независимых задач (скажем, счётные программки от Васи и Пети) на одном компьютере, и в таком виде она до сих пор живёт и к многопотоковости (как механизму, используемому прикладным программистом для использования конкурентности в своём коде) особого отношения не имеет. Да, если брать современные применения, граница достаточно нечёткая (в случаях, если мы всё таки используем несколько задач для получения общего результата), но изначальный посыл разный.
Даже если говорить только о Intel - вышедший в 1995ом Pentium Pro поддерживал двухсокетные конфигурации, соответствующие материнки появились практически сразу. На "больших" компьютерах многопроцессорные конфигурации были гораздо раньше - тут скорее надо поискать, когда появилась материнская плата в современном понимании...
Любой современный серверный процессор поддерживает многосокетные конфигурации. "Где то" - очень слабо сказано )
Всё таки я бы не смешивал многозадачность и многопоточность, хотя вещи действительно связаны - и то и другое вполне живо.
Для этого вполне достаточно примитивного concurrency в виде системы прерываний. Многозадачность в первую очередь была сделана для одновременного использования большого дорогого компьютера несколькими людьми. Многопоточность внутри одного процесса - это уже более тонкая концепция, изначально сделанная для упрощения использования concurrency на прикладном уровне.
make всё таки общеизвестная система, не привязанная к коннкретному языку
Аргументы, передаваемые в javac и т.п. в Makefile и так будут в явном виде. А вот аргументы вашего скрипта и код типа if "%1"=="build" - это скорее лишняя сущность, отвлекающая от сути. Но если предполагается, что кто-то из читателей не знаком с make - может, проще и на cmd...
Я не понимаю, почему автор make не запользовал - достаточно низкоуровнево, чтобы показать какими командами реально собирается проект, но без необходимости вручную анализировать аргументы командной строки и т.п.
Ну тогда sudo snap install chromium
Конечно будет, полуось и Fleetstreet наше всё )
Нижегородского
Там мог и округлить. Надо всё таки технические спецификации смотреть.
На мой взгляд всё-таки есть некое противоречие между физическим и логическим описанием, в разных случаях применимо разное.
Смотрю на банальный article.cls и сходу не вижу, где там требование иерархии вложенности part/section/subsection/...
Это всё таки специфическая деятельность, я большее о массовой обработке больших документов.