su.c_cpp

*Hi Nil!* Thu Jan 06 2022, 05:25, Nil A -> All: NA> Если хорошо курнуть, то можно через #define или using назначить разные NA> эмодзи, или даже египетские иероглифы, и тогда написание C++ кода будет NA> сильно веселее, чем обычно. Например NA> https://mariusbancila.ro/blog/2019/05/16/cpp-is-fun/ храни тебя господь. %))) я давно так не орал.

Hello, All! Если хорошо курнуть, то можно через #define или using назначить разные эмодзи, или даже египетские иероглифы, и тогда написание C++ кода будет сильно веселее, чем обычно. Например https://mariusbancila.ro/blog/2019/05/16/cpp-is-fun/ Best Regards, Nil

Hello, Valentin! Thursday November 11 2021 23:23, from Valentin Nechayev -> Nil A: NA>> Так вот, пейшу я ту на Go. А в Go, как вы знаете, нету NA>> исключений. VN> Есть, возбуждаются через panic, ловятся через recover. VN> Hу а что они не называются при этом исключениями и ловятся слегка VN> через оппу - вопрос к двуличным разработчикам. Ага, как раз недавно про это прочитал. Есть драфт дизайн Go 2, там всё крутиться вокруг обработки ошибок, что такое типа ошибки вообще и ещё про дженерики https://go.googlesource.com/proposal/+/master/design/go2draft.md VN> Паника, похоже, дороже возврата значения. Hо всё равно ловится. Дык в C++ exceptions тоже сильно дороже стоят, чем просто возврат значения. Поэтому их стоит употреблять как исключения, а не как то, как одно из значений, которое функция может возвращать. На другом конце спектра, например, Python, который кидает StopIteration исключение, для обозначения конца итератора. Про Гоу. Так ничего язычёк, только совсем мало в функциональном стиле можно писать. Не хватает питоновского list comprehension, а также просто, чтобы map, zip,.. можно было в одну строчку писать. Я прочитал умных книг по современному C++, и уже не помню когда последний раз писал new/delete руками, только в одно хитром месте писал new placement. Я к тому, что я теперь если вижу цикл какой-то, то у меня уже руки чещутся на какой-нибудь стандартный алгоритм из заменить. Best Regards, Nil

Hi, >>>> Nil A wrote: NA> Так вот, пейшу я ту на Go. А в Go, как вы знаете, нету исключений. Есть, возбуждаются через panic, ловятся через recover. Hу а что они не называются при этом исключениями и ловятся слегка через оппу - вопрос к двуличным разработчикам. Вот я тестик накидал просто из чтения доки: ==={{{ package main import "fmt" type xdata struct { Value int } func zoo() { panic(444) } func moo(xd *xdata) int { defer func() { if exc := recover(); exc != nil { fmt.Println("Caught something") (*xd).Value = -1 } }() zoo() (*xd).Value = 1 return 1 } func main() { var xd xdata fmt.Println(moo(&xd), xd.Value) } ===}}} Без паники в zoo() пишет 1 1, с вызовом - Caught something и 0 -1. Hу да, кривовато - если нужно передать больше параметров, надо какой-то объект для хранения ошибки передать, return верхнего уровня из такого recover как-то не получается(?), но худо-бедно работает. NA> Ладно у меня утилитка, и я бы и NA> сам бы ничего умнее не придумал, чем выйти, но а если я сервер мать NA> его пишу высоконагруженный, как во всех этих гоу рекламмах, какой он NA> классный... Паника, похоже, дороже возврата значения. Hо всё равно ловится. -netch- ... Кто здесь?????

Hello, All! Тут вот вспомнил, что меня очень раздражает, когда в коде библиотеки я вижу abort() когда аффтар не знает что дальше делать. Ну ладно ещё там память кончилась, и действительно, дальше ехать уже не получиться, хотя в линуксах, например, аллокация памяти реально только виртуальные странички выделает, и на 64битной платформе оно кончится практически не может, т.е. когда память реально кончится, то ядро либо пристрелит OOM-Killer'ом, или какой-нибудь SIGBUS словит, потому что физические странички кончатся. Про abort() в библиотеках. Есть такие аффторы, у них там файл не открылся/не зависался, а они сразу в abort(), или какая-то проблема с сокетом если. Блин, выдай на верх ошибку, разберётся программа что делать с кривым файлом или сокетом, перепопробует по-другому, или как-то юзеру аккуратно сообщит, но не выпадать же прям тут на месте. Так вот, пейшу я ту на Go. А в Go, как вы знаете, нету исключений. Так бы аффтар библиотечки кинул нам внутри исключение, а ты потом лови его в своём коде, или не лови и получай abort() ;-) Но аффтарам библиотек на Go бывает сильно ломово сильно изнутри протаскивать ошибку, чтобы её потом наружу передать, проще же panic(err) сделать и иди читай стек. Ну так-то я на гоу пейшу там утилитки, и бывает удобно готовую библиотеку с гитхаба импортировать, опять же, привет плюсям, где чужую библиотеку к себе притащить это не всегда просто. И вот аффтар библиотечки сшоткатил и panic кинул. Ладно у меня утилитка, и я бы и сам бы ничего умнее не придумал, чем выйти, но а если я сервер мать его пишу высоконагруженный, как во всех этих гоу рекламмах, какой он классный... Best Regards, Nil

Hi, >>>> Nil A wrote: NA> По работе тут несколько месяцев пишу на Гоу, вместо привычных плюсов. NA> Сначала возмущение, как так, тут даже ООП нет, и исключений и много NA> чего ещё. Потом даже приникся простотой языка и лёгким (условно) NA> чтением чужих исходников. NA> Параллельно всё посматриваю, что некоторые компании стали писать на NA> Расте. Мы уговаривали начальство разрешить новые проекты на Расте, но NA> они не сдались. А тут немного посмотрел, так там тоже нет ООП в таком NA> чистом виде, а всё больше трейты. NA> В питонах с их утиной типизацией, там вообще не надо от базового NA> класса наследоваться, чтобы иметь возможность реализовать интерфейс. Есть такое, да. Вопрос в том, насколько далеко оно может зайти и вытеснить другие языки и подходы, типа классического ООП стиля C++/Java. Пока что получается, что Go перетянул массу разработок скорее с Python, чем с чего-то другого; Rust частично забирает с C++, но также заметно с C, причём с C++ в заметной мере не благодаря другому ООП, а из-за ужесточения работы с памятью. Отказ от наследования в привычном виде, особенно от полиморфизма на наследовании - пригоден ой не везде. Где-то его и не было толком (есть у меня один такой проект, где вся польза от C++ получается в привязывании имён функций к объектам и в инкапсуляции - там, да, и Go пошёл бы). Где-то на него легко перейти. Hо я вот попытался оценить один компонент с этой точки зрения - понял, что мы скорее повесимся, чем это заработает :) А вот какая-нибудь Java тут идёт влёгкую. Про Python тут не совсем уместно - у него несмотря на всю утиную типизацию полиморфизм через наследование доступен (и гибче чем у почти всех конкурентов), а для статического анализа так вообще незаменим. NA> В 90х была супер мода на ООП, пихали где надо и не надо. Где-то NA> просто, чтобы спрятать область видимости функций (инкапсуляция), NA> где-то наследовались не думая, что тут реально композиция. Да и вообще NA> мир сильно сложнее, чем строгая иерархия классов, и начинаются всякие NA> перекрёстные ссылки.. А где-то сейчас, наоборот, используют композицию вместо наследования. При этом оказывается, что из 50 методов 3 определены по месту, а 47 превращаются в стабы "вызвать то же самое у вложенной базы". Hу не будет тут абсолютных рецептов... NA> Короче, как я понял, сейчас ООП менее в тренде, именно в том виде, как NA> оно в C++ и Джавах. Структурки с возможностью вызова методов к ним - NA> есть. Полиморфизм в том или ином виде - есть, но не через черезу NA> наследований. Таки если посмотреть на долю этих языков без полиморфизма наследованием, то их мало (Go откусывает ну 1/6 от верха, Rust в разы меньше). NA> Ещё статья забавная была, там чем хотел приложку для телефонов NA> написать, сам он системный прогер, далёк от мобилок, но за три вечера NA> смог навалять на флаттере, чему был супер рад, что не пришлось изучать NA> отдельно ещё два языка и две платформы, а только простой Дарт. Так NA> вот, стал он народу далёкому от программировать показывать Флаттер, и NA> народу сложно объяснить все эти разные формы конструкторов и пр. С NA> нуля прям легко, говорит, гоу обучить, там всё проще без этих ООП. Так никто не мешает в таком стиле писать хоть на Java, хоть на C++ (ну кроме небольшого количества интерфейсных мест, которые уже форсировано заточены под такой подход). Hо добровольно лишать себя возможностей - как-то странно... -netch- ... Программная система "Медуза". Переименования файлов нет. ... Удаления файлов нет. Заполнена NOPами.

* Originally in su.c_cpp * Crossposted in nino.046.local Hello, All! По работе тут несколько месяцев пишу на Гоу, вместо привычных плюсов. Сначала возмущение, как так, тут даже ООП нет, и исключений и много чего ещё. Потом даже приникся простотой языка и лёгким (условно) чтением чужих исходников. Параллельно всё посматриваю, что некоторые компании стали писать на Расте. Мы уговаривали начальство разрешить новые проекты на Расте, но они не сдались. А тут немного посмотрел, так там тоже нет ООП в таком чистом виде, а всё больше трейты. В питонах с их утиной типизацией, там вообще не надо от базового класса наследоваться, чтобы иметь возможность реализовать интерфейс. В 90х была супер мода на ООП, пихали где надо и не надо. Где-то просто, чтобы спрятать область видимости функций (инкапсуляция), где-то наследовались не думая, что тут реально композиция. Да и вообще мир сильно сложнее, чем строгая иерархия классов, и начинаются всякие перекрёстные ссылки.. Короче, как я понял, сейчас ООП менее в тренде, именно в том виде, как оно в C++ и Джавах. Структурки с возможностью вызова методов к ним - есть. Полиморфизм в том или ином виде - есть, но не через черезу наследований. Ещё статья забавная была, там чем хотел приложку для телефонов написать, сам он системный прогер, далёк от мобилок, но за три вечера смог навалять на флаттере, чему был супер рад, что не пришлось изучать отдельно ещё два языка и две платформы, а только простой Дарт. Так вот, стал он народу далёкому от программировать показывать Флаттер, и народу сложно объяснить все эти разные формы конструкторов и пр. С нуля прям легко, говорит, гоу обучить, там всё проще без этих ООП. Best Regards, Nil

Привет! 15 Sep 21 15:03, you wrote to me: RS> А на Qt несколько раз пробовал... "ДАHУИВОHАФИГ!!!", пока разберёшься RS> -- поседеешь! Qt и подобные ему фреймворки хороши, когда тебе нужно с нуля делать программу, в которой будет много разных окошек, форм, таблиц, графиков и прочего нетривиального GUI, который муторно делать вручную. К программе с более-менее типовым GUI они не добавляют ничего, кроме переносимости и 5-20 мегабайт своего кода, размер которого практически невозможно контролировать. Всего доброго! Евгений Музыченко eu-gene@muzy-chen-ko.net (все дефисы убрать)

Hello Eugene! 15 Sep 21 11:56, you wrote to Nil A: NA>> я вот в своё время быстренько на коленке навалял на Qt. EM> "Быстренько на коленке" на Qt получится только у того, кто с ним уже EM> более-менее знаком. :) Иначе он вздернется раньше, чем наваяет. Поэтому лично я когда пишу что-то под Windows предпочитаю Windows API с его WindowProc, с его циклом сообщений и прочим. С этим я более-менее знаком (со времён OS/2, там было практически так же). А на Qt несколько раз пробовал... "ДАHУИВОHАФИГ!!!", пока разберёшься -- поседеешь! Хотя и получается переносимо (согласно документации), но изучать Qt нет ни сил, ни желания. Bye!

Привет! 15 Sep 21 00:37, you wrote to Denis Sovkov: NA> я вот в своё время быстренько на коленке навалял на Qt. "Быстренько на коленке" на Qt получится только у того, кто с ним уже более-менее знаком. :) Иначе он вздернется раньше, чем наваяет. Всего доброго! Евгений Музыченко eu-gene@muzy-chen-ko.net (все дефисы убрать)