Здравствуйте, lpd, Вы писали:
lpd>Интересен был бы опрос среди С++ программистов чтобы понять процент любителей угловых скобочек, но такого пока не попадалось.
С вводом auto для параметров ф-ий кол-во угловых скобочек резко поубавилось, оставшись в основном для шаблонных типов.
Но и там через template using сценарии их использования в клиентском коде резко облегчились.
Здравствуйте, lpd, Вы писали:
_>>Ну сменили бы конечно не все, но очень многие. Более того, многие начали бы переходить ещё лет 10 назад, только не на Rust, а на D. И только выход C++11 предотвратил этот процесс. lpd>Уже все перешли на Java и C#. А те, кому эти два языка не подходят ну совсем никак, готовы сбежать куда угодно.
Эти два языка в принципе не подходят для системных целей, которые обеспечивают всю базовую инфраструктуру IT. И сбегать с C++ в данный момент в этой нише некуда. Есть только Rust, от перехода на который в данный момент больше минусов, чем плюсов. Возможно в дальнейшем это изменится, не знаю, не берусь прогнозировать этот момент.
lpd>Вообщем С++ из универсального языка превратили в что-то сильно специфическое. Интересен был бы опрос среди С++ программистов чтобы понять процент любителей угловых скобочек, но такого пока не попадалось.
Так а ты был скажем на CppCon или хотя бы C++ Russia? Познакомился бы там хоть с темами докладов что ли? Или может ты сторонник очередной теории заговора, о том что на такие конференции приглашают исключительно сторонников некого мнения меньшинства?
Здравствуйте, Pzz, Вы писали:
_>>Так и не понял, каким образом "переносимость между архитектурами" сочетается с "Для каждой аппаратной платформы существует своя реализация Go-ассемблера"? И с тем фактом, что в рантайме Go мы видим отдельные реализации функций под каждую аппаратную платформу отдельно. Pzz>https://golang.org/doc/asm Pzz>Он полу-абстрактный. Вещи, общие для всех разумных архитектур делаются в нем одинаково (например, MOV из регистра в регистр). Процессороспецифические вещи делаются специфическим для процессора образом (например, AES).
Так а регистры то разные на каждой архитектуре! О какой переносимости такого кода можно говорить?
_>>Реально переносимые ассемблеры — это трансляций в некоторый выдуманный процессор (llvm, wasm, и т.п.), который потом (на целевой платформе) транслируется (JIT или АОТ) в реальные машинные коды. Pzz>Не обязательно на целевой платформе во время исполнения.
Да это вообще не суть. Главное что там код реально переносимый. И это совсем не то, что в исходниках Go.
Реализация от Microsoft в ATL была открыта независимо Яном Фалкином (англ. Jan Falkin) также в 1995 году. Он случайно унаследовал базовый класс от класса наследника. Кристиан Бомон (англ. Christian Beaumont), заметив этот код, решил, что он не может быть скомпилирован, но, выяснив, что может, решил положить эту ошибку в основу ATL и WTL.
Pzz>>И эти люди меня убеждают, что C++ не является переусложненным языком.
V>Эта идиома доступна и в C#.
Мне нравится подход. "Он случайно унаследовал базовый класс от класса наследника. Кристиан Бомон (англ. Christian Beaumont), заметив этот код, решил, что он не может быть скомпилирован, но, выяснив, что может, решил положить эту ошибку в основу ATL и WTL".
Если это работает и в C#, это не комплимент в пользу C#
Здравствуйте, alex_public, Вы писали:
Pzz>>Он полу-абстрактный. Вещи, общие для всех разумных архитектур делаются в нем одинаково (например, MOV из регистра в регистр). Процессороспецифические вещи делаются специфическим для процессора образом (например, AES).
_>Так а регистры то разные на каждой архитектуре! О какой переносимости такого кода можно говорить?
Ну никто и не предполагает, что на этом ассемблере можно руками написать программу, которая без изменений будет работать на разных архитектурах. Речь идет о том, чтобы в кодогенераторе компилятора можно было общие вещи написать единообразно.
Здравствуйте, Ночной Смотрящий, Вы писали:
G>>Но есть один нюанс. Проблемы из-за кода ну максимум треть от всех проблем.
НС>А из-за чего еще у тебя две трети проблем в проекте?
Я так понимаю, он железом занимается. Две трети проблем в таких делах возникают от того, что у тех, кто, собственно, железо проектирует, руки не из того места растут. А поскольку переделать железку очень дорого, отдуваться приходится программистам.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
_>Эти два языка в принципе не подходят для системных целей, которые обеспечивают всю базовую инфраструктуру IT. И сбегать с C++ в данный момент в этой нише некуда. Есть только Rust, от перехода на который в данный момент больше минусов, чем плюсов. Возможно в дальнейшем это изменится, не знаю, не берусь прогнозировать этот момент.
Ну понятно что Java не подходит, только C++ отдал им большую нишу корпоративного софта. Вроде как ваш гениальный Страуструп считает что так и нужно, вот это и получили: язык любителей шаблонов.
_>Так а ты был скажем на CppCon или хотя бы C++ Russia? Познакомился бы там хоть с темами докладов что ли? Или может ты сторонник очередной теории заговора, о том что на такие конференции приглашают исключительно сторонников некого мнения меньшинства?
Очевидно, это как интернет-опрос, о популярности интернета. На С++ конференциях конечно не был никогда, и нет ни малейшего желания посещать и слушать про решение всех проблем ИТ новыми шаблонами и RAII. Я вообще из прикладного софта вернулся в драйвера Linux на С, не только из-за С++, но отчасти и из-за него.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>На С++ конференциях конечно не был никогда, и нет ни малейшего желания посещать и слушать про решение всех проблем ИТ новыми шаблонами и RAII.
Здравствуйте, Pzz, Вы писали:
Pzz>Мне нравится подход. "Он случайно унаследовал базовый класс от класса наследника.
Кривой перевод или журнализд наврал. Это не наследование от наследниника, это использование типа до его определения, но после объявления. Вполне себе практика С/С++ и до всяких шаблонов.
Pzz>Если это работает и в C#, это не комплимент в пользу C#
НС>>А из-за чего еще у тебя две трети проблем в проекте?
Pzz>Я так понимаю, он железом занимается. Две трети проблем в таких делах возникают от того, что у тех, кто, собственно, железо проектирует, руки не из того места растут. А поскольку переделать железку очень дорого, отдуваться приходится программистам.
Компания чипами, я фирмварой для них.
Насчет руки не из того места — это грубо и глупо. С таким же успехом можно сказать что если у тебя есть баги, то у тебя руки не из того места. А у тебя они бывают наверняка.
Это одна из проблем, да. После пары ревизий чипа она становится совсем второстепенной. Для первой ревизии она одна из самых больших.
Потом другие вылезают: интер-операбилити, большие и постоянно выходящие новые версии стандартов, клиенты периодически находят новые сценарии использования которые выявляют слабые места у продукта, нужно все больше и больше добавлять функциональности и делать все быстрее и быстрее на том же железе пока не выйдет новое, потом нет предела улучшениям (новые алгоритмы и приемы чтобы передавать быстрее, меньше латентность, меньше терять, лучше работать в условиях шума, и т.д.)
А код здесь как инструмент делать это все.
Pzz>>>Он полу-абстрактный. Вещи, общие для всех разумных архитектур делаются в нем одинаково (например, MOV из регистра в регистр). Процессороспецифические вещи делаются специфическим для процессора образом (например, AES).
_>>Так а регистры то разные на каждой архитектуре! О какой переносимости такого кода можно говорить?
Pzz>Ну никто и не предполагает, что на этом ассемблере можно руками написать программу, которая без изменений будет работать на разных архитектурах. Речь идет о том, чтобы в кодогенераторе компилятора можно было общие вещи написать единообразно.
А например разное количество регистров? Как это единообразно решить?
Здравствуйте, Pzz, Вы писали:
M>>Статический полиморфизм — CRTP
Pzz>
Реализация от Microsoft в ATL была открыта независимо Яном Фалкином (англ. Jan Falkin) также в 1995 году. Он случайно унаследовал базовый класс от класса наследника. Кристиан Бомон (англ. Christian Beaumont), заметив этот код, решил, что он не может быть скомпилирован, но, выяснив, что может, решил положить эту ошибку в основу ATL и WTL.
Pzz>И эти люди меня убеждают, что C++ не является переусложненным языком.
В процитированном есть сомнительные места. В CRTP наследуют базовый класс, параметризованный наследником. Это раз. Второе — неясно, почему это названо ошибкой. Баги в C++ как в языке есть, но это не из их числа
Здравствуйте, gardener, Вы писали:
Pzz>>Я так понимаю, он железом занимается. Две трети проблем в таких делах возникают от того, что у тех, кто, собственно, железо проектирует, руки не из того места растут. А поскольку переделать железку очень дорого, отдуваться приходится программистам.
G>Компания чипами, я фирмварой для них.
Класс. А что за чипы, нельзя полюбопытствовать?
G>Это одна из проблем, да. После пары ревизий чипа она становится совсем второстепенной. Для первой ревизии она одна из самых больших. G>Потом другие вылезают: интер-операбилити, большие и постоянно выходящие новые версии стандартов, клиенты периодически находят новые сценарии использования которые выявляют слабые места у продукта, нужно все больше и больше добавлять функциональности и делать все быстрее и
Я в таком режиме wifi занимался.
G>А код здесь как инструмент делать это все.
Не только. Я застал модное поветрие "давайте сделаем чип максимально дешевым, и все, что можно, вынесем в прошивку". Сейчас, мне кажется, когда время жизни батарейки стало ценным ресурсом, такой подход несколько вышел из моды.
Здравствуйте, lpd, Вы писали:
_>>Эти два языка в принципе не подходят для системных целей, которые обеспечивают всю базовую инфраструктуру IT. И сбегать с C++ в данный момент в этой нише некуда. Есть только Rust, от перехода на который в данный момент больше минусов, чем плюсов. Возможно в дальнейшем это изменится, не знаю, не берусь прогнозировать этот момент. lpd>Ну понятно что Java не подходит, только C++ отдал им большую нишу корпоративного софта. Вроде как ваш гениальный Страуструп считает что так и нужно, вот это и получили: язык любителей шаблонов.
C++ был в нише корпоративного ПО (если мы под этим подразумеваем кастомное внутрикорпоративное ПО, а не коробочное инфраструктурное (оно опять же обычно на C++), используемое в тех же корпорация) только в 90-ые годы, когда ничего более подходящего просто не было. А как только появилось, то сразу же C++ уступил эту нишу. И правильно — зачем использовать инструмент не по назначению?
_>>Так а ты был скажем на CppCon или хотя бы C++ Russia? Познакомился бы там хоть с темами докладов что ли? Или может ты сторонник очередной теории заговора, о том что на такие конференции приглашают исключительно сторонников некого мнения меньшинства? lpd>Очевидно, это как интернет-опрос, о популярности интернета. На С++ конференциях конечно не был никогда, и нет ни малейшего желания посещать и слушать про решение всех проблем ИТ новыми шаблонами и RAII. Я вообще из прикладного софта вернулся в драйвера Linux на С, не только из-за С++, но отчасти и из-за него.
Всё же так и не могу понять твою мысль. Ты хотел опрос среди пользователей C++ — чем конференция по C++ не репрезентативна то? ) Или всё же ты веришь в теорию заговора? )))
Здравствуйте, alex_public, Вы писали:
_>И правильно — зачем использовать инструмент не по назначению?
_> Ты хотел опрос среди пользователей C++ — чем конференция по C++ не репрезентативна то? )
Выделил ключевое слово. Язык программирования — это инструмент, не более. На конференциях по С++ выступают только люди, увлекающиеся языком программирования С++. Я считаю для программиста более важным знание устройства ОС, протоколов, железа, алгоритмов, предметной области, умение проектировать, умение решать задачи вообще. И на последнем месте после всего этого нужны тонкости языка программирования. Шаблоны — последний из приоритетов, вроде функциональных языков(тоже их не знаю). Для себя я лучше поизучаю науки какие-нибудь(у меня когда-то был хобби один из разделов математики). Если тебе шаблоны нравятся — изучай, но говорить что код без навороченных шаблонов — устревший, не надо.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
G>>Компания чипами, я фирмварой для них.
Pzz>Класс. А что за чипы, нельзя полюбопытствовать?
SoC в-основном WiFi, ну и всякой всячины вокруг накрученной.
G>>Это одна из проблем, да. После пары ревизий чипа она становится совсем второстепенной. Для первой ревизии она одна из самых больших. G>>Потом другие вылезают: интер-операбилити, большие и постоянно выходящие новые версии стандартов, клиенты периодически находят новые сценарии использования которые выявляют слабые места у продукта, нужно все больше и больше добавлять функциональности и делать все быстрее и
Pzz>Я в таком режиме wifi занимался.
Ну, вот оно и есть.
G>>А код здесь как инструмент делать это все.
Pzz>Не только. Я застал модное поветрие "давайте сделаем чип максимально дешевым, и все, что можно, вынесем в прошивку". Сейчас, мне кажется, когда время жизни батарейки стало ценным ресурсом, такой подход несколько вышел из моды.
Оно и сейчас так работает. Если можно вынести в прошивку и чип все еще укладывается в ограничения скорости, потребления и размера памяти, то это будут выносить. Разработка дешевле, время вывода на рынок выше, цена ошибки ниже, более гибко.
Я работал в нескольких компаниях которые wifi чипами занимались. У всех примерно один и тот же подход.
Здравствуйте, kaa.python, Вы писали:
B>>или алготрейдинг KP>А это не так уж и много имеет общего с "с сокетами, протоколами и потоками", да и тут активно внедряют Go. Хе-хе.
Дилетанта видно издалека. Никакого гоу и сплошные сокеты да протоколы (но потоков конечно мало, в основном спинят по одному на каждый cpu).
