IT в России и мире в реалиях мирового кризиса

Цитата: ps_ от 07.11.2024 23:59:32Так я про это и говорю.
Вот сижу я и пишу на с++ с классами и все у меня работает. Но я не один в группе. И есть еще много других групп.
Раз в год появляется студент, идет на курсы продвинутого с++, приходит обратно и под лозунгом "я вас научу ретрограды на современном с++ писать", начинает использовать все эти продвинутые шаблоны и typedecl. А я потом сижу и пытаюсь понять, почему сервер рухнул.

На С++ можно писать безопасный код. Один запрет на использование голых указателей может убрать 99% проблем. В С++ несколько видов "умных" указателей на любой вкус, вопрос только в дисциплине. Но в больших проектах без дисциплины  и явно написанных правил кодирования всё равно нельзя.

Вот вы упоминаете Rust. Его родили в Mozilla. А до этого использовали С++ с огромным количеством изъятий, таких как не использовать шаблоны и тд и тп. Целый талмуд был.  Кастрировали язык и ещё жаловались. И всё это было до принятия дополнений в стандарт, облегчающих управление памятью. Большинство мотиваций перехода на Rust давно утрачены. И С++ без шаблонов - это птица без крыльев. А Rust пусть живёт, С++ он не заменит. А добавить в талмуд запрет на голые указатели не прибавит и 1% сложности.

Кстати, никак не могу понять, как decltype или шаблоны переменной длины могут привести к падению сервера. Всё это механизмы статической проверки типов на этапе компиляции. А новые decltype/using - это просто помощники для написания более понятного кода. В потрохах они не меняют ни-че-го. Не нравятся - старый добрый typedef никто не отменял.

А шаблоны переменной длины делают язык более гибким, мощным и простым. Безопасный с точки зрения типов сode reuse с помощью шаблонов - это наше всё.

Цитата: ps_ от 07.11.2024 23:59:32
Не надо давать ВОЗМОЖНОСТИ использовать всякие хитрые конструкции при написании обычного кода.
В том же rust все эти бесконечные проверки можно отключить при компиляции или внутри специального блока. И разработчики библиотек этим пользуются. Но они знают, что делают. А в нормальной ситуации они помогают писать правильный код

Всякие хитрые возможности в С++ в абсолютном большинстве по наследству заимствованы из С. Обратную совместимость с С в С++ никогда не уберут. Но можно просто не писать код "как на С" и использовать новые стандартные средства управления памятью и работы с типами данных С++ и радоваться [безопасной] жизни. И это можно сделать писаной политикой компании.

Я не против Rust, но скорее всего С++ и его переживёт. Он гораздо более универсальный язык.

И вообще, современные языки программирования тырят друг у друга хорошие идеи. И попутно становятся похожими в том или ином виде. И это замечательно!

Цитата: ivrom от 08.11.2024 00:50:36На С++ можно писать безопасный код. Один запрет на использование голых указателей может убрать 99% проблем. В С++ несколько видов "умных" указателей на любой вкус, вопрос только в дисциплине. Но в больших проектах без дисциплины  и явно написанных правил кодирования всё равно нельзя.
...
Всякие хитрые возможности в С++ в абсолютном большинстве по наследству заимствованы из С. Обратную совместимость с С в С++ никогда не уберут. Но можно просто не писать код "как на С" и использовать новые стандартные средства управления памятью и работы с типами данных С++ и радоваться [безопасной] жизни. И это можно сделать писаной политикой компании.

У вас боязнь указателей, бывает. Еще можно не пользоваться ножом чтобы не порезаться ненароком.
Все ваши умные указатели, идеальные абстракции - дырявые. В реальном коде эти абстракции то и дело рушатся. Да, их каждый раз починяют и говорят что теперь  они совершенны, мда.
Код сложных шаблонов - практически невозможно контролировать. Взаимодействие двух сложных шаблонов - это хаос.
А вот свои указатели - легко и контролировать и тестировать. Если конечно умеешь. Как и с ножом.

Цитата: Прокруст от 08.11.2024 09:28:33У вас боязнь указателей, бывает. Еще можно не пользоваться ножом чтобы не порезаться ненароком.
Все ваши умные указатели, идеальные абстракции - дырявые. В реальном коде эти абстракции то и дело рушатся. Да, их каждый раз починяют и говорят что теперь  они совершенны, мда.

Нет у меня боязни указателей. Есть проблема невладения выделенной памятью обычными указателями в С/С++. При их использовании в С++ без должной дисциплины или утечка памяти случится или обращение к уже удалённому сегменту памяти. И должная дисциплина программирования с использованием указателей на выделенную память подразумевает обязательное определение операторов присваивания и перемещения (operator=()|operator=(&&)) для каждого класса с указателями. Или запрет на копирование/перемещение.  Это слишком глупо и утомительно, и кто-то об этом обязательно забудет (но не вы, правда?). std::unique_ptr/std::shared_ptr сделают всю нудную работу за вас. unique_ptr не имеет издержек времени выполнения по сравнению с обычными указателями.Можете ассемблер глянуть. 

Кстати, о каких дырявых умных указателях вы толкуете? Условно неудачным был std::auto_ptr, но он был создан до появления оператора перемещения в языке. Как только он появился - так auto_ptr из языка и убрали уж 10 лет как. И предупреждали не использовать с С++11. И unique_ptr его прямая замена без недостатков. 

Цитата: Прокруст от 08.11.2024 09:28:33Код сложных шаблонов - практически невозможно контролировать. Взаимодействие двух сложных шаблонов - это хаос.

Шаблоны - это вершина code reuse. Вот просто никаких проблем с ними нет у тех, кто понимает в абстракцию. А кто  нет - тем от С++ нужно держаться подальше.

Например, мой личный библиотечный код как правило на 50-80% состоит из шаблонов. А иногда и на все 100%. Я просто не представляю, как без шаблонов писать универсальный type safe код.
Ну и стоит упомянуть, что STL - это сплошь шаблоны на шаблонах.

Кстати, взаимодействие двух шаблонов чаще проще, чем без них. Иначе каждый класс должен знать о каждом.

Цитата: Прокруст от 08.11.2024 09:28:33А вот свои указатели - легко и контролировать и тестировать. Если конечно умеешь. Как и с ножом.

А вот обычные указатели в С++ почти никогда использоваться не должны. Для этого есть ссылки (если мы не используем управление памятью), которые невозможно не инициировать. Иначе - null pointer dereferencing будет иногда на чаёк заглядывать, не у вас, так у соседа. Редко, действительно редко необходимы именно указатели. Их можно применять в случае частого изменения указателя, как например в связном списке/дереве. Да и то по уму нужно использовать ссылки (и placement new по необходимости) или std::reference_wrapper. У программиста С++ должен выработаться рефлекс: видишь указатель -  это выделенная из кучи память. Иначе - используй ссылку!

Впрочем, если вы толкуете о библиотечном коде/API, вызываемом из С, то да, без указателей не обойтись. Но это же нишевое решение!

PS У меня создаётся впечатление, что большинство рассуждающих о С++ здесь его просто не знают, застряли в прошлом с С++98 в багаже в лучшем случае, или пишут на нём "как на С". И это катастрофа, для С++, конечно же ;(

Цитата: ivrom от 08.11.2024 12:24:44Нет у меня боязни указателей. Есть проблема невладения выделенной памятью обычными указателями в С/С++. При их использовании в С++ без должной дисциплины или утечка памяти случится или обращение к уже удалённому сегменту памяти.

Вот вы и озвучили один из базовых рецептов безопасности. 
Утечки памяти и обращения в никуда неплохо убираются прогонами тестов под valgrind или под проприетарными аналогами. Другое дело, что мало кто желает писать тесты.

Цитата: ivrom от 08.11.2024 12:24:44Нет у меня боязни указателей. Есть проблема невладения выделенной памятью обычными указателями в С/С++. При их использовании в С++ без должной дисциплины или утечка памяти случится или обращение к уже удалённому сегменту памяти. И должная дисциплина программирования с использованием указателей на выделенную память подразумевает обязательное определение операторов присваивания и перемещения (operator=()|operator=(&&)) для каждого класса с указателями. Или запрет на копирование/перемещение.  Это слишком глупо и утомительно, и кто-то об этом обязательно забудет (но не вы, правда?). std::unique_ptr/std::shared_ptr сделают всю нудную работу за вас. unique_ptr не имеет издержек времени выполнения по сравнению с обычными указателями.Можете ассемблер глянуть.

Нету у меня в Си классов, нет возможности делать определение операторов присваивания и перемещения.
Ваши заморочки - у вас в голове.

ЦитатаКстати, о каких дырявых умных указателях вы толкуете? Условно неудачным был std::auto_ptr, но он был создан до появления оператора перемещения в языке. Как только он появился - так auto_ptr из языка и убрали уж 10 лет как. И предупреждали не использовать с С++11. И unique_ptr его прямая замена без недостатков.

Спольски писал на эту тему. Да, он писал про абстракции TCP, но абстракции есть абстракции.

ЦитатаШаблоны - это вершина code reuse. Вот просто никаких проблем с ними нет у тех, кто понимает в абстракцию. А кто  нет - тем от С++ нужно держаться подальше.

Те кто действительно понимает, предпочитает результат играм в абстракцию. Эти игры - весело, понтово, круто. Результат только тоже абстрактный.

ЦитатаНапример, мой личный библиотечный код как правило на 50-80% состоит из шаблонов. А иногда и на все 100%. Я просто не представляю, как без шаблонов писать универсальный type safe код.
Ну и стоит упомянуть, что STL - это сплошь шаблоны на шаблонах.

Это печально. Вы путаете программирование с математикой. Это совершенно разные категории.
Конечно математикам нельзя запретить программировать, но тащить всех в это светлое будущее не надо.

ЦитатаА вот обычные указатели в С++ почти никогда использоваться не должны. Для этого есть ссылки (если мы не используем управление памятью), которые невозможно не инициировать. Иначе - null pointer dereferencing будет иногда на чаёк заглядывать, не у вас, так у соседа. Редко, действительно редко необходимы именно указатели. Их можно применять в случае частого изменения указателя, как например в связном списке/дереве. Да и то по уму нужно использовать ссылки (и placement new по необходимости) или std::reference_wrapper. У программиста С++ должен выработаться рефлекс: видишь указатель -  это выделенная из кучи память. Иначе - используй ссылку!

С++ монстр, который должен умереть. Этот язык лучше не использовать, если конечно вам нужен результат.

ЦитатаВпрочем, если вы толкуете о библиотечном коде/API, вызываемом из С, то да, без указателей не обойтись. Но это же нишевое решение!

PS У меня создаётся впечатление, что большинство рассуждающих о С++ здесь его просто не знают, застряли в прошлом с С++98 в багаже в лучшем случае, или пишут на нём "как на С". И это катастрофа, для С++, конечно же ;(

Библиотеки это нишевое решение? Очень смешно.
PS.
Я очень много писал на С++. И на старом и на 11 и 17 версиях. К черту этот язык.

Цитата: adolfus от 08.11.2024 12:48:56Вот вы и озвучили один из базовых рецептов безопасности. 
Утечки памяти и обращения в никуда неплохо убираются прогонами тестов под valgrind или под проприетарными аналогами. Другое дело, что мало кто желает писать тесты.

Вы поняли в моих словах ровно противоположное тому, что я пытался сказать. Как раз современный С++ не требует жёсткой дисциплины программирования для управления памятью, если используются правильные средства изначально. Например std::unique_ptr. Но не обязательно именно это. Я вообще апологет спрятать сложность в библиотеку, а на верхнем уровне писать просто и беззаботно.

Вот как раз в С управление памятью - полный мрак. Который породил монстров в виде языков со встроенными сборщиками мусора.

valgrind конечно годное средство, но... Вот есть у нас многопоточный/многопроцессорный код с активным использованием IPC в разделяемой памяти. И вот что-то изменилось/поломалось в реализации условной переменной POSIX, размещаемой в shared memory. В glibc, разумеется, поменялось. Соответствующий этой условной переменной устойчивый мутекс в этой самой разделяемой памяти  (POSIX robust mutex) работает нормально в условиях, когда умирает процесс, владеющий блокировкой на мутексе, и реинициирует его со сменой владельца нормально.  А вот с условной переменной что-то стало не то, и процессы стали умирать по segfault при обращении к этой самой условной переменной после восстановления. Всё бы ничего, если можно воспроизвести ошибку. А если случается это раз в месяц под нагрузкой?

В общем, отладка многопоточного кода, усугублённая наличием IPC ни разу не простая задача для valgrind. Может проще программировать так, что valgrind поменьше использовать пришлось бы? В моей личной практике я выявил абсолютно больше проблем с выравниванием данных, чем утечек памяти в собственном коде. И слава богу, что современный С++ предоставляет механизмы контроля выравнивания данных посредством alignas/alignof и страшное наследие С с небезопасным манипулированием raw pointers закончилось.

PS gcc 14 стал ругаться на собственную  STL. Кажется копирующий конструктор std::vector что-то там с выравниванием не то имеет. И этот баг уже больше года всё не пофиксят. Не то это богус предупреждение и всем наплевать, не то для правильного решения требуется смена ABI. И это мрак, если проблема в ABI. Я это сказал просто для показа, как сложен процесс работы с памятью, даже если вовлечены профессионалы высочайшего класса.

Цитата: Прокруст от 08.11.2024 16:19:28Нету у меня в Си классов, нет возможности делать определение операторов присваивания и перемещения.
Ваши заморочки - у вас в голове.

Я так и подозревал, что говоря о С++ вы имели в виду код в виде "пишу как на С". Так, конечно, делать можно. И ошибок в коде будет меньше, так как С++ более безопасен с точки зрения преобразования типов. Но в этом случае - зачем ругать язык, который вы не особо понимаете?

Цитата: Прокруст от 08.11.2024 16:19:28Те кто действительно понимает, предпочитает результат играм в абстракцию. Эти игры - весело, понтово, круто. Результат только тоже абстрактный.

Это оставлю без комментариев. Шаблоны - это ядро языка. И этот язык вам просто не нужен. Забудьте его.

PS Похоже сложился консенсус. Большинство считают С++ слишком сложным в первую очередь для понимания. Это непонимание, как писать на нём просто и безопасно. А раз так, то похоже он будет вытеснен в область системного программирования [только]. И мир продолжит экстенсивный путь развития в виде увеличения размера памяти и количества ядер процессора для покрытия издержек "непонимания". Так тоже делать можно. Только это печально. Да здравствует Питон!

Цитата: ivrom от 08.11.2024 20:39:51  И мир продолжит экстенсивный путь развития в виде увеличения размера памяти и количества ядер процессора для покрытия издержек "непонимания". Так тоже делать можно.  

Это спиральный процесс - сначала есть специалисты, они делают так, потом растут требования, спецов не хватает, идет упрощение потому что оно дает больший эффект при меньших затратах, потом упираются в предел и новый цикл появление сложного инструмента который решает какую-то проблему на более высоком уровне но доступен единицам.
В целом тенденция к разделению - системные становятся совсем плохопонимаемы остальными и их очень мало, а все остальные программисты переходят на декларативный язык - я хочу ЭТО, как именно бедет сделано ЭТО знает только БОГ-машина, и единицы сисстемщиков, а в конечном итоге, когда сложность вырастает до запредела то никто. И так до краха когда эта система валится.

Цитата: ivrom от 08.11.2024 20:39:51Я так и подозревал, что говоря о С++ вы имели в виду код в виде "пишу как на С". Так, конечно, делать можно. И ошибок в коде будет меньше, так как С++ более безопасен с точки зрения преобразования типов. Но в этом случае - зачем ругать язык, который вы не особо понимаете?

Это оставлю без комментариев. Шаблоны - это ядро языка. И этот язык вам просто не нужен. Забудьте его.

Сколько высокомерия. Вы просто не наигрались в свои игрушки.
И да, шаблоны ядро этого языка. И игры с ними отнимают большую часть времени. Бессмыленно сие.
PS.
Вся эта возня с шаблонами в С++ напоминает мне написание текста на иероглифах. Красиво и кратко, угу.
Но я устал в каллиграфию, предпочитаю писать текст буквами.

Цитата: Прокруст от 08.11.2024 22:05:45Сколько высокомерия. Вы просто не наигрались в свои игрушки.
И да, шаблоны ядро этого языка. И игры с ними отнимают большую часть времени. Бессмыленно сие.
PS.
Вся эта возня с шаблонами в С++ напоминает мне написание текста на иероглифах. Красиво и кратко, угу.
Но я устал в каллиграфию, предпочитаю писать текст буквами.

Начну издалека. С++ позволяет писать код, который как минимум не медленнее писанного на С, и часто быстрее за счёт разумного встраивания и устранения косвенной адресации где это возможно. А вот полиморфизм в С++ вводит дополнительную косвенную адресацию, которая ведёт к снижению производительности кода. Огромный пласт проблем можно решить с помощью шаблонов  не прибегая к полиморфизму. Игнорируя "иероглифы", вы теряете всю рацио, если ваша цель - хорошая скорость и минимум ресурсов. А если вы пишите на С - то это всегда о скорости и ресурсах. Ну или о ядре ОС.

PS Я сдался. Пусть цветут все цветы.

PPS У С++ есть один недостаток, и это даже не ложка, а бочка дёгтя. Стандартизованный ABI отсутствует напрочь. Призыв "ABI - now or never", который проталкивали при принятии последнего стандарта С++ , потерпел крах. В смысле от "now" похоже осталось "never". А ABI - это всё о библиотекописании. Аминь.

PPPS По поводу библиотекописания. Как ни странно, но шаблоны позволяют писать/распространять header only библиотеки С++. Это частично устраняет проблемы с ABI. В С это просто невозможно.

Цитата: ivrom от 08.11.2024 22:34:18PPS У С++ есть один недостаток, и это даже не ложка, а бочка дёгтя. Стандартизованный ABI отсутствует напрочь. Призыв "ABI - now or never", который проталкивали при принятии последнего стандарта С++ , потерпел крах. В смысле от "now" похоже осталось "never". А ABI - это всё о библиотекописании. Аминь.

ABI -- не стандарт, это соглашения платформы, а не языка. 
Нет ни одного языка, который выдвигает требования к платформе и ABI. Мало того, стандарты языков пестрят замечаниями "определяется реализацией". Реализация -- это компилятор и если компилятор "желает" присутствовать на платформе, он просто молча "берет под козырек".
ABI -- это двоичный программный интерфейс. Это про то, как передаются параметры в процедуру и как процедура возвращает результаты. 
Это о том, в какие секции объектного модуля попадают объявления и определения переменных. 
Это о том, как в объектном модуле будут представлены символы из программы, т.е. как они будут декорироваться, чтобы "перегруженные" функции имели разные имена, дабы компоновщик мог их различать. 
ABI нужен на языку, а компоновщику, чтобы он мог связать объектные модули, которые родил компилятор из вашего языка, с библиотечными функциями и системными вызовами в исполняемую программу. 
В своей работе компоновщик не использует никакой информации о языке, из которого изготовлен объектный модуль -- это не требуется, а язык не использует ничего из соглашений ABI. Это дело компилятора -- втиснуться в прокрустово ложе формата объектного модуля. Максимум, что может язык, это записать в отдельную секцию отладочную информацию, которая используется и только отладчиками этого языка. Причем формат этой информации, опять же, не зависит от языка программирования.

Новый закон Тайваня запрещает TSMC производить 2-нанометровые (2 нм) чипы за пределами страны

Этот запрет распространяется также на США.

TSMC должна хранить свои самые сложные технологии, такие как производство 2 нм чипов, в пределах границ Тайваня в целях национальной безопасности.

Цитата: DeC от 11.11.2024 23:56:46Новый закон Тайваня запрещает TSMC производить 2-нанометровые (2 нм) чипы за пределами страны

Этот запрет распространяется также на США.

TSMC должна хранить свои самые сложные технологии, такие как производство 2 нм чипов, в пределах границ Тайваня в целях национальной безопасности.

Ога... А сканеры двухнанометровые эти недокитайцы где возьмут?
У ASML, как всегда? Так ASML полностью под американским контролем. Не захотят янкесы, и не будет никаких 2нм.

Цитата: Vaal от 12.11.2024 11:06:17Ога... А сканеры двухнанометровые эти недокитайцы где возьмут?
У ASML, как всегда? Так ASML полностью под американским контролем. Не захотят янкесы, и не будет никаких 2нм.

ASML это не царь и бог, а лишь конечный сборщик труда многих компаний, в том числе и инженеров TSMС. Грубо говоря если Тайвань,  отрезать от голландцев то и самим голландцам может очень сильно поплохеть.

Цитата: South от 12.11.2024 11:11:56ASML это не царь и бог, а лишь конечный сборщик труда многих компаний, в том числе и инженеров TSMС. Грубо говоря если Тайвань,  отрезать от голландцев то и самим голландцам может очень сильно поплохеть.

Там около 200 компаний , в т.ч. несколько российских (по крайней мере были года три назад). И все это ASML.

Цитата: Moksha от 12.11.2024 12:21:48Вы перепутали ASML с TSMC . ASML в Голландии.

   
Это единый организм, ничего я не перепутал.
   
Здесь многие представляют себе ASML как "голландскую компанию, которая продаёт оборудование", что-то вроде эдакой Роде-унд-Шварц.
Это всё равно, что рассуждать о глобальных финансах и займах на уровне "занял у соседа десятку до получки".
    

Цитата: Vaal от 12.11.2024 11:06:17Ога... А сканеры двухнанометровые эти недокитайцы где возьмут?
У ASML, как всегда? Так ASML полностью под американским контролем. Не захотят янкесы, и не будет никаких 2нм.

Литограф  ASML -- это всего лишь инструмент. Очень сложный, но все таки инструмент. Тут все ясно -- нет инструмента, нет и изделия. Но, ASML свои литорафы может продать куда угодно кроме TMSC. Если не сегодня, то завтра. И что этому инструменту подсунут в виде фотошаблонов, то он в кремнии и выдаст. А вот сделать фотошаблоны. чтобы выхлоп литографа  ASML функционировал как задумано, это уже и есть та самая технология. Вот ее TMSC и закокомил.

Цитата: adolfus от 09.11.2024 19:13:50ABI -- не стандарт, это соглашения платформы, а не языка. 
Нет ни одного языка, который выдвигает требования к платформе и ABI. Мало того, стандарты языков пестрят замечаниями "определяется реализацией". Реализация -- это компилятор и если компилятор "желает" присутствовать на платформе, он просто молча "берет под козырек".
ABI -- это двоичный программный интерфейс. 

Когда говорят об отсутствии стандартного ABI для C++ или других ОО ЯП, имеется в виду отсутствие стандарта на двоичное представление классов, объектов, виртуальных функций и тыды. Невозможно описать класс, собрать одним компиляторов в .so/DLL а потом в приложении собранном другим компилятором произвести от этого класса потомка. Собственно проблема стара, для её решения изобретались SOM, IDL, CORBA и другие страшные слова времен OS/2 Warp.

Цитата: LightElf от 13.11.2024 00:32:21 отсутствие стандарта на двоичное представление классов, объектов, виртуальных функций и тыды. Невозможно описать класс, собрать одним компиляторов в .so/DLL а потом в приложении собранном другим компилятором произвести от этого класса потомка.

У нас пользовались в интерфейсах только чисто виртуальными функциями. Тогда в структуре первым элементом идет адрес таблицы с адресами функций. Конечно все равно могут быть разночтения типа 32\64 или соглашения о вызове функций. Во всяком случае так можно было взаимодействовать между борландом и микрософтом.

Цитата: ps_ от 12.11.2024 22:42:44Фотошаблоны делает stepper. Обычно покупается вместе с литографом.
Кстати, я не знаю кто сейчас производит степперы

Фотошаблон производится из файла с описанием топологии изделия. Это просто маска, пропускающая свет где есть дырка и не пропускающая там, где дырки нет. Один фотошаблон -- один слой на кристале для одного изделия. Таких слоев в изделии может быть до нескольких десятков.
Степпер берет шаблон, оптически его уменьшает и "тиражирует" по пластине, сдвигая ее на определенный шаг и засвечивая. Это один из компонент того "сарая", что производит ASML.
И тут вопрос -- каким образом излучение УФ лазера с длиной волны ~100 нм, проходя через маску, создает на кристалле картинку с разрешением несколько нм. Дело в том, что реально на кристалле после прохождения маски из-за диффракции на всей маске создается определенная интерференционная картинка. Т.е. вся маска вносит вклад в каждую точку результирующей засветки, которая представляете собой интерференционную картинку. И создание фотошаблона -- это создание таких масок, проходя через которую картинка на кристалле будет представлять собой требуемую топологию. Достаточно сложная вычислительная задача и не только лишь все... TMSC из тех, кто умеет и ASML к этому никакого отношения.