Си с классами

пишут как в Qt

А, ну ясно. Обычно если начал писать на qt потом везде пишешь как на qt. В 90% случаев это говнокод и переход на расты в надежде исправить язык вместо рук.

си - прекрасный язык, могу рекомендовать

Не, я испорчен контейнерами (vector, map). Поэтому и на си я сразу же делаю какие-нибудь односвязные списки. Но это только при отсутствии альтернативы. А так лучше уж C++.

тетрис например

Надо будет как-нибудь. Но просто делать тетрис на SDL не интересно. Подожду когда будет вдохновение приделать DSL к SDL.

На моей ext2

C имеет смысл только в случае если нужно работать с байтами, например, что-то сетевое

Работаю с байтами, приходится обмазываться асертами с ног до головы, чтобы компенсировать отсутствие типов в Си. Нет абсолютно никакого оправдания для того, чтобы не иметь в языке типов, даже если ты работаешь с байтами, потому что все равно эти байты обычно имеют вполне конкретное значение, а постоянные касты в «void *» и «char *» с арифметикой до добра не доводят.

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

Си — это препроцессор для ассемблера. Отсюда все его чудоватые особенности, вроде линии сборки и нуль-терминированных строк.

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

з.ы. в си тоже есть деревья, man tsearch, man hsearch.

типы != ограничения на типы && типы != абстрактные безопасные типы

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

Совсем забыл мой любимый пример - khash.h

uthash еще более упорото. Причина простая — макросы K&R убоги и неюзабельны. Сделайте норм макросы в Си, и кресты можно закапывать. Даже RAII не нужно, только макросы человеческие дайте.

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

препроцессинг - это отдельный этап в сборке. Ты можешь использовать любые макросы какие хочешь, хоть Racket, хоть Lisp, хоть какие-нибудь другие и в С. Просто добавляй такой этап в систему сборки.

Я писал на ассемблере с сишными макросами, просто добавив в make шаг препроцессинга. И видел, кто писал на С с макросами из Lisp. Преград использовать другие макросы нет никаких.

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

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

Лучше так не делать, а писать инлайновые функции-аксессоры. Тогда и типы появятся и ассерты расставлять проще будет.

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

Казалось бы, при чем тут Си.

Преград использовать другие макросы нет никаких

Есть преграда, которая называется «получается неюзабельное и нечитаемое говно».

Тогда и типы появятся

Откуда же они по вашему возьмутся?

Владимир

Ремейк Wolfenstein 3D с Трампом в главной роли

Ну хз, мог бы и не UE мышкой написать. Там вон шаблон FPS представляет собой готовую пулялку шариков по кубикам с физикой и продвинутыми шейдерами поверхностей DX11, которые полчаса компилируются при первой сборке проекта.

Никаких, кроме здравого смысла )

NFAC добавь. Не в качестве оппонентов — просто чтоб они маячили around, с пафосным видом... роняя винтовочные магазины.

Ну раньше ещё итераторы славились вырвиглазием, но с появлением C++11 они стали нужны чуть поменьше

Благодаря чему? Выводу типов (auto)?

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

Да, я спрашивал. Говорю «удобно тебе сидеть на ножке перевернутого стула?», а он мне отвечает «зашибись, лучше нельзя было придумать — аж четыре человека на один стул помещается». Что я могу возразить на такой ответ? Зато в чужом глазу соринку найдет.

Фреймворки, кстати, плохой пример, они во всех языках довольно узконаправленные

Но почему-то в итоге базовые контейнеры в STL, Qt, и UE похожи.

Зато забавен тот факт что подходы применяемые в фреймворке в одном языке, если они удачны, часто перекочевывают в другой язык и фреймворк схожего толка

Карго культ от скудости ума, и не есть хороший пример.

На первом уровне нужно будет уничтожить почтовые ящики с фальшивыми бюллетяни, а на втором найти бюджет и профинансировать полицию. Как тебе?

Вообще, не нужно было тянуть и в принципе браться за движок, надо было ещё летом начать модельки рисовать и взять готовый движок, был инди-хит в Стиме, если бы задумки удалось реализовать. А так, поздняк на самом деле. Буду пару лет в одиночку мастурбировать движок, пока не надоест.

Но согласен, я имею в виду не такое «ООП», а именно саму его идею, а не частную реализацию

Идея ООП от Алана Кэя не имеет ничего общего со структурами дата-функция в языках программирования, которые на самом деле и являются частной реализацией, частными вариантами которых яже являются класс-ориентирированные, прототип-ориентированные, и протокол-ориентированные объекты. Алан Кей же подразумевал законченную НЕХ, черный ящик, который общается с миром через узкое окошко сообщений и не светит свое состояние. Эта модель, на самом деле, довольно бесполезна — но надо же юному кодеру о чем-то помечтать? Не только о сисястых мадам думать, правильно?

Что сделали академики? Он грит «нужно сеять любовь» — академики логически выводят «давайте сношать собак». Он грит «нужно больше сострадания» — академики выводят «давайте сжигать людей по двое». Ну и так далее, ты понял.

Вон посмотри на glib. Не ну серьезно, посмотри

Посмотрел. Три месяца на фул тайм писал anjuta и glade. Вспоминаю, как страшный сон. Потому что подходит время отчета, а я не имею ни малейшего понятия, когда закончу фичу, потому что у меня повреждение памяти, которое не ловит валгринд. Провтыкал работу с указателями, как обычно. Что характерно, багу в итоге отловил, проект сдал, но осадочек остался. Это прям для любителей острых ощущений, а у меня и так лысина нарисовывается.

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

Ну и кресты не особо облегчают задачу, так что инструмент соответствует задаче в моем случае. В отличие от glib, который типовые задачи не особо облегчает.

Справедливости ради. сейчас пишу как раз на голом Си

А что пишете если не секрет?

Владимир

Ну C++ тут особого профита не даст, просто добавятся классы. Все равно void * останется.

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

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

Я хз, как называется эта прослойка кодеров. Суть в том, что я имею талант писать на небезопасных языках работоспособный софт. А сейчас на рынке это, как правило, C++. Избегая крестов я стал никому не нужным.

Java — блевотина, сравнимая с крестами. Я думал на Clojure переехать, к слову, но там, судя по слухам, все-таки нужно много взаимодействовать с жавой.

Но почему-то в итоге базовые контейнеры в STL, Qt, и UE похожи.

Не могу назвать это все фреймворками, но и не могу сказать что ты неправ. Похожи, потому что решают одни и те же задачи если говорить о контейнерах, сложно придумать другой вариант контейнеров так, чтобы они были эффективными, да еще и на одном и том же языке реализации для всех трех. Тут я могу только пожать плечами и обратиться к богу metaprog, у этого парня есть свой особый взгляд, свой «вижин».

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

типы != ограничения на типы && типы != абстрактные безопасные типы

У тебя Си головного мозга. На уровне высокоуровневого ЯП нет никакой аппаратной реализации, зато есть логические сущности, например «число от минус двух до пяти», или «строка с числом символов, равным значению параметра функции». Типы в Си такие, какие они есть, именно потому, что это препроцессор к асму, который гвоздями прибит к железу, с минимальной переносимостью. Хуже того, эти самые типы кочуют из языка в язык с минимальными изменениями.

В то же время алгебраические типы данных (ADT) — лютая годнота. Самый элементарный пример ADT — это указатель с опциональным значением NULL. Но ADT может быть еще, например, типа «строка или число». Когда ты вводишь подобные типы в сложные структуры, то у тебя внезапно возникает возможность описать сложнейшие байтовые структуры точными типами.

Лучше так не делать, а писать инлайновые функции-аксессоры. Тогда и типы появятся и ассерты расставлять проще будет

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

Справедливости ради. сейчас пишу как раз на голом Си

А что пишете если не секрет?

Формально — in-memory базу данных, фактически — костыль для устранения GIL в питоне. Многие проекты для этой цели переписывают язык, я же пытаюсь оставить CPython в полном составе.

Ну C++ тут особого профита не даст, просто добавятся классы. Все равно void * останется

Даже классы приятно иметь, потому что отвратительная система типов Си не позволяет оперировать подтипами без лютых костылей в виде копипасты структуры и замысловатых для переносимого вычисления размера струткуры:

(char*)p->first_subtype_member - (char*)p->first_type_member

Ну в плюсах же то же самое, просто завернуто в обертку. И ты заверни.

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

И тогда понимали прекрасно. Просто, протиратели штанов из комитетов год за годом не могли выдать ни одного юзабельного языка, а тот же Algol-W комитет отклонил, потому что язык был слишком ясен и прагматичен. ООП — это еще один неудачный подход к снаряду, который просто задержался в индустрии немного дольше. Индустрия до сих пор продолжает плодить мусор, потому что так устроена культура, экономика, и политика. «Вы, друзья, как ни садитесь, а в музыканты не годитесь».

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

Да, между C++ и Java разница примерно как между «быть изнасилованным тремя грузинами» и «идти пятсот километров пешком до ближайшего населенного пункта» соответственно.

Ну в плюсах же то же самое, просто завернуто в обертку. И ты заверни

Ну и какие инструменты в языке Си есть для реализации подобной фичи? Там как ни крути — все равно нужно явно указывать конкретные поля для расчета отступов/размера.

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

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

В расте хотя бы догадались сахарок добавить, на го невозможно смотреть.

Сделай чтобы на кровать можно было поссать. Только это будет дюк нюкем, а не Вульф.

Вообще тебе наверное UE должен норм зайти, там как раз такой с++ как ты хочешь и даже местами наверное больше чем ты хочешь. Про выборы не парься, через 4 года ещё одни.

Ok, был неправ.

Я имел в виду в первую очередь for по контейнерам.

С третьего раза понял. Только ссать должны проститутки.

В частности можно использовать классы только для реализации ADT и управления ресурсами, а всю управляющую логику писать процедурно, не реализовывая никаких паттернов и не дробя сущности на 100500 классов. И оно будет выглядеть очень достойно, ООП будет использоваться для расширения системы типов ну и ещё может для грубого структурирования кода

Я вот снова и снова это читаю, но никак не пойму, почему я не мог прочитать это в молодости. Вы же не хотите сказать, что 95% учебных материалов по крестам — говно? Неужели ты сам дошел до такой позиции по крестам? Грубо говоря, спустя 5 лет писания на крестах у человека срабатывает таймер и человек перестает писать классы.

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

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

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

И я еще раз повторюсь, что не обязательно руками выбрасывать ошибку, но обязательно ошибку обрабатывать в строке сразу после вызова функции, генерирующей ошибку. Основная претензия к исключениям в C++/Object Pascal/etc у меня именно в этом. То есть, исключения сильно снижают читаемость кода. Как ни странно.

В расте хотя бы догадались сахарок добавить, на го невозможно смотреть

В го тоже добавили сахара.

Лень читать весь тред. А какое направление разработки.

Классы тоже не особо нужны - полиморфизм и у структур есть. Разве что когда нужно наследование и vtable

Ахаха, лол. Ты серьёзно? Хотя, чего я ожидал - здесь все эксперты такие

О, еще один не знает определения полиморфизма. Академики постарались на славу.

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

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

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

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

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

Я как первый раз увидел раст, то мне очень понравилась идея. Потом, по мере более близкого знакомства, я стал всё замечать знакомый мне почерк комитетных крыс и академического быдла, которые вносят в язык формально четкие и фактически фатальные особенности.

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

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

Хоть бери и сам делай язык. Но тут нужно хотя бы еще одна голова и руки — я ж не мозила.

В llvm ir этого не будет. Эта оптимизация производится кодогеном раста, и производится всегда.

Увы, это не царь.

Еще один. Может быть ты покажешь вектор трейтов без аллокаций и vtable?