Си с классами

Пока только растения елозят.

Заикнулись про вектор трейтов без аллокаций и vtable, но почему-то показывают какие-то левые вызовы функций.

Марш, показывать вектор трейтов, и доказывать, что я царь. Царя призвал, смотри, сам царем не стань.

Будеш писать на расте, не забудь, что тебе нужно стать трансгендерной лесбиянкой и возможно даже черной

https://blog.rust-lang.org/2020/06/04/Rust-1.44.0.html

The Rust Core Team believes that tech is and always will be political, and we encourage everyone take the time today to learn about racial inequality and support the Black Lives Matter movement.

Какое же дно этот раст.

на западе сейчас иначе нельзя, иначе получишь волчий билет везде

Дело как обычно в людях. Каждый суслик - агроном и пилит своё мало с чем скручиваемое. Начиная с всяческого избегания использования std::error, заканчивая тасканием в зависимостях библиотек tokio и вообще любовью к асинхронщине. Даже там где её не просят.

Это дин. полиморфизм. Аноним про другое.

Пернатый соколик! Ты покажешь не динамический полиморфизм из вектора трейтов? Что ты бегаешь от меня?

Мне показалась интересной задача по ссылке:

https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/

То есть надо получить N пифагоровых треугольников. При этом функция, вычисляющая треугольники, не может их сразу выводить, а должна возвратить значения трёх сторон.

В общем случае генераторы может и лучше (если переменных много, а функция сложная). Но конкретно в этом примере можно было бы просто циклы продолжить:

def get_next_triple
    mref x:int y:int z:int
    *xFront @int x
    *yFront @int y + 1
    for
        for x in xFront; z; 1
            for y in yFront; z; 1
                *x2 @int x * x
                *y2 @int y * y
                *diff @int z * z - x2 y2
                if diff 0
                    return
        z + 1
        xFront = 1
        yFront = 1


def main
    *x; *y; *z @int 1
    for 100
        @get_next_triple x y z
        @print*  x ", " y ", " z "\n"

Пример не на C++ (лень переписывать), но идея должна быть понятна. То есть каждый раз передаём три числа по ссылке и продолжаем циклы. Всё примитивно, эффективно и никаких сущностей типа структур и генераторов не требуется. Не сразу очевидной может быть только эта возня с xFront, yFront.

Ты б ещё в телеграмм канале по раст это спросил. Им не важно как оно работает и какой то там полиморфизм. Им важно что это «модно, молодежно и типа безопасно».

Ты б ещё в телеграмм канале по раст это спросил.

А что там спрашивать. Насколько я помню, раст ругается на Vec<TraitTheBest>, если не указать & dyn и другие страшные закорючки, но я могу неправильно помнить. Вот я и прошу показать нединамический вектор трейтов.

Насколько я понимаю, концепты не запрещают вызывать методы, которые в них не объявлены.

C с классами это Objective-C.

Начинаю проект (личный), выбираю на чём писать: C или C++.

с плюсами возиться не хочется, да и на чистой сишечке, с другой стороны, писать как-то лениво.

Вижу, что ты себя «заставляешь» писать. Выбери другой проект.

Объясните почему так делать не стоит, либо даже наоборот, предложите уже существующие сабсеты плюсов, которые можно перенять.

Совершенно точно, постарайся найти что тебе нравится (проект).

Был бы проект хорош, ты бы им уже занимался, а не обсуждал инструменты. А если нужна практика по конкретному языку, то смысл что-либо обсуждать? Тебе совершенно точно нужны именно плюсы. Даже мне это понятно, а тебя нет. Ну лол просто …

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

описание по ссылке не совсем корректное и не совсем о том. ренжи и корутины делают разные вещи. ренжи делают чейнинг вызовов, создают вьюхи и всё остальное, а корутины делают корутины, две функции выполняются одновременно передавая управление друг другу. внешне одно похоже на другое, но в ренжах будет N вызовов функции (ну как обычный map или какой там адаптер), а в корутине 1.

Насколько я понимаю, концепты не запрещают вызывать методы, которые в них не объявлены.

Да. Это ответственность программиста, добавить все методы которые используют аргументы в концепты, для проверки.

https://godbolt.org/z/9P5chW

Конструкторы/декструкторы и raii — это ещё какой сахар. В «Си-way» же полагается всё руками делать.

Мимо. Объяснения уже были даны выше.

Ну и как тут без аллокации? В любом неигрушечном коде хранить ссылки внутри объектов не получится.

Оно нужно чтобы не долбаться с системными mkdir, stat и хранить пути в предназначенной для этого структуре данных вместо строк.

почти строчка в строчку

Мы точно про fn do_stuff<T: MyTrait>(t: T) говорим? Ибо у вас там простыня кода.

PS: использовать С++20 - это фактически чит.

Си с классами (комментарий)

Точно.

// Rust
pub trait Square: Sized {
    fn sq(self) -> Self;
}

// C++
template <typename T>
concept Square= requires (T x)  { 
     { sq(x) } -> std::same_as<T>;
};

и

// Rust
pub fn square<T: Square>(num: T) -> T {
    num.sq()
}

// C++
auto square(HasSq auto num) -> decltype(num) {
    return sq(num);
}

Просто в С++ нельзя создавать методы для примитивных типов. Поэтому там чуток отличается. Для class или struct было бы ещё более похоже.

Ты в серьез сравниваешь концепты c++ и трейты раста?

Концепты - это проверка типов и ничего более.

Трейты раста - это больше похоже на std::variant + std::visit.

Трейты раста - это больше похоже на std::variant + std::visit.

С чего бы это?

Трейты мы можем реализовывать для новых типов, а в std::variant мы должны знать заранее.

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

std::variant - это Rust enum.

Да, вот freecoder заметил, что концепты не запрещают в самой функции вызывать методы, которые сам концепт не проверяет. Так что в этом Rust trait лучше, чем С++ concept…

Си с классами (комментарий)

В теории оно всё понятно. Но, как говорит автор статьи, для «простых смертных» это слишком сложно. Возможно, от этого безобразия можно было бы уйти через встроенные DSL, как в C#, который там привели в пример (linq - DSL).

Если вернуться к основной теме, то спрашивается, нельзя ли писать как-то по тупому. Но если писать по тупому, то большая часть синтаксиса C++ становится не нужна и всё сводится уже к внешнему DSL. Тут ещё проблема, что каждый кодер считает важными определённые чисти синтаксиса, поэтому универсальный тупой DSL не сделать.

трейты руста - это type traits из с++11, где-то десятилетний лаг у них, хотя в с++11 они были уже стандартизированы, т.е. даже больше чем десятилетний.

чтобы проверить все методы концепцию надо всего лишь сгенерировать по телу функции, а не писать руками.

Концепты - это проверка типов и ничего более.

Трейты, (не dyn trait, просто в расте две разные фичи, которые реализованы по-разному называются одинакого) - это тоже просто проверка типов, поэтому тут и пишут, что у неё нет оверхеда.

Нет никакого принципиального разногласия :)

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

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

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

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

Если ты про асинхронную халупу как вид корутины, то как они могут этого не знать если первые варианты у них и были так сделаны, а потом обмазали штукатуркой.

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

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

таким людям надо на питухоне писать, вот тебе и дсл.

Согласен. Сомневаюсь, что писать шутер на C и SDL - хорошая идея для того, кто по работе пишет на python. Да и вообще хоть для кого. В том числе и для меня.

С другой стороны, не прекращаются попытки написать более быстрый питон со статической типизацией. Можно вспомнить Boo или Nim. Но они не понимают, что нужен просто DSL, а не средство постигания смысла жизни. Какой смысл в том чтобы вместо одного сложного языка написать другой не менее сложный?

Трейты… не dyn trait…

… обсуждают, потому что «некто пернатый» вбросил про «бесплатный» вектор трейтов без аллокации и vtable.

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

си - прекрасный язык, могу рекомендовать, только надо уделять много внимания деталям. но можно же писать не йоба-шутер, а тетрис например :)

Кошерным проектом в таком стиле могла бы стать Vala с её транспиляцией в C. Но похоже она никому так не пригодилась

Фундаментальная ошибка Vala заключалась в том, что она основывалась на Boxed объектах и вообще классах. То есть, что-то среднее между Java и C++. Причем, без гарантий безопасности памяти, которые дает Java — только за них жаву и терпят. То есть, эдакая жава, только без GC, а на голых счетчиках ссылок, аки Swift. Причина, почему Swift взлетел, а Vala умер, может быть проиллюстрирована вот так:

https://stackoverflow.com/questions/9185969/generic-function-in-vala

Это прость хороший пример, показывающий, насколько криво реализовано обобщенное программирование в Vala — ты должен оборачивать любую операцию над обобщенным значением в объект. Лишняя сущность, которая никакой функции не выполняет.

Собственно, разве Swift не является тем самым кошерным языком «C+»?

Не раз слышал мнение, что Си с классами — мрак. Каких-то вменяемых аргументов при этом мне ни разу никто не привёл. Наверняка, в этом треде хотя бы парочка будет

Потому что ООП — зло. Всё просто: классы — это лишняя сущность, которая не выполняет никакой функции, а мозг нагружает. Популярность ООП получила по академическим причинам — потому что академики любят морочить себе и другим мозги бесполезным мусором. Особенно это удобно делать, когда идеология предполагает наличие чего-то, усложнение, а не упрощение. ООП, тесты, какие-нибудь монады в ФП — менее известных примеров много, на самом деле.

Еще раз напоминаю, что Старуструп изначально проектировал керсты как язык перегруженных функций и обобщений — если кто не верит, то могу поискать интервью с ним.

Я видел код, который перловики, джависты и пхпшники на питоне писали, не хочу так же. В каждом языке свои правила хорошего тона

Питон являетс implementation-defined языком, и в нем под каждую отдельную функцию свой идеоматический стиль вызова, который нужно просто запомнить, потому что внутри есть ad-hoc сишная функция, которая ускоряет выполнение такой конструкции. И это причина, почему я утверждаю, что питон — это сложный и запутанный язык... как ни странно. Что делает ситуацию печальной если вспомнить, сколько людей на полном серьезе берутся писать на питоне «потому что это простой язык», выдавая лютейший говнокод.

Это тебе щас «хочется» плюсов, а когда будешь сидеть в куче лапши и ловить непонятные ошибки (ты ведь не собираешься юзать цланг, правда?)

А в чем проблема шланга?

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

Чем дольше пишу код, тем глубже понимание, что ООП нужно лишь точечно

Опыта мало. Писал бы больше — понял бы, что ООП не нужно совсем.

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

Нет. В Си ты изучаешь фундаментальные понятия, и всё остальное строится на них. В питоне же семантика отсутствует чуть более. чем полностью, и каждая отдельная функция/класс представляют собой свой отдельный мир. Изучив целый питоний фреймворк ты почти не получаешь навыков для того, чтобы изучить второй фреймворк, потому что он не будет иметь ничего общего с первым. Это люто перегружает мозги и заставляет людей либо специализироваться, либо быть поверхностными говнокодерами. Ты можешь возразить «есть жи стандартная либа, стандартные типы» — но нет, в продвинутых фреймворках весь язык под корень переопределяется.

Как подход - нужно, как реализация наподобие той, что есть в с++ - сомнительно. Не обязательно придумывать и вводить в язык сахарок для этого подхода, но какой-то слой абстракции и оторванности должен быть, чтобы задачу можно было представлять в терминах этой абстракции.

Как подход - нужно, как реализация наподобие той, что есть в с++ - сомнительно. Не обязательно придумывать и вводить в язык сахарок для этого подхода, но какой-то слой абстракции и оторванности должен быть, чтобы задачу можно было представлять в терминах этой абстракции

Ну я бы советовал в таком случае для начала приводить свое определение ООП, потому что я все-таки опираюсь на общепринятое. под которым подразумевается класс-ориентированное програмирование, которое не имеет совсем ничего общего с тем «ООП», на которое намекаешь ты, то есть, по Алану Кэю.

Наследование (почти) не нужно, а инкапсуляция и полиморфизм очень даже.

И это всё есть в Си.

инкапсуляция и полиморфизм очень даже

Из-за ООПанутых нынче в гугле стало тяжело искать инфу по полиморфизму, потому что полиморфизм через виртуальный методы — это наследование и не нужно, а всё остальное — это уже не класс-ориентированное программирование, потому при чем оно тут? То же самое по инкапсуляции.

ты сам себе противоречишь, в питоне ты тоже изучаешь фундаментальные понятия и их придерживаешься, но говнокодерам лень что-то изучать ) Семантика там есть, но она целиком и полностью завязана на реализацию под ковром из твоих ощущений, и это возможно сильно бросается в глаза именно тебе, спроси любого говнокодера и он тебе скажет что не чувствует острых углов и ему норм и так. Фреймворки, кстати, плохой пример, они во всех языках довольно узконаправленные. Зато забавен тот факт что подходы применяемые в фреймворке в одном языке, если они удачны, часто перекочевывают в другой язык и фреймворк схожего толка.

Класс-ориентированное это де-факто реализация, и даже те кто лепил на прототипах или вообще не лепил но наспех слепил сейчас пытаются ему подражать (привет js, php, python, etc). Но согласен, я имею в виду не такое «ООП», а именно саму его идею, а не частную реализацию.

такие подходы как правило имеют под собой более сильную базу. например constrains из d прямо ссылаются на концепции из с++, но реализованы они там были раньше чем в с++. форматирование строк из питона - конечно буду. экзекьюторы тоже наверное где-то светились.

обмен идеями - это хорошо и правильно, прямо как опенсорс, люди не только исходниками обмениваются, но и идеями - это работает как ожидается.

главное чтобы неудачные идеи не перекочёвывали. ну вот как тут уже объявились сектанты и рекламируют свою конченую секту, хотя их никто не звал, но они сами пришли.

Все нормальные люди только так на С++ и пишут, т.е. на си с классами, с минимумом фич вообще. Если вообще в принципе нужен C++, т.е. из-за легаси или плюсовых либ итд

Один я, как идиот, насмотрелся разных курсов и решил, что «все нормальные люди» пишут как в Qt и UE, и решил, что писать на этом невозможно. И загубил себе карьеру офисного кодера.

Вон посмотри на glib. Не ну серьезно, посмотри. Так можно. Можно еще на макросах. Но важно не начинать делать из C плюсы и не хотеть полиморфизмы и динамические трансформации… Их тоже можно, но тогда проще взять плюсы. Из сабсетов посмотри MISRA-C++ 2012 дисциплинирует физически. Главное не думать зачем это все. Еще посмотри как игроделы пишут, у них плюсы обычно минималистичные. Ну еще андроидный софт на плюсах до появления rtti. Тоже неплохой пример сабсеттинга плюсов.

Разве офисные кодеры не на java сейчас пишут?

ue и qt так написаны потому что они запускаются на чём угодно, а на чём угодно не всегда будет с++20 и вообще не факт, что все фичи языка или стандартной библиотеки будут вообще присутствовать. какой может быть std::filesystem на кофеварке например?