The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си , opennews (??), 07-Май-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


50. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –4 +/–
Сообщение от Ivan7 (ok), 07-Май-24, 13:32 
Только на С++ надо было, а не на С, т.к. на С++ можно получить производительность лучше, плюс он банально удобнее.
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –1 +/–
Сообщение от Прадед (?), 07-Май-24, 13:49 
Правильно было бы спросить
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Прадед (?), 07-Май-24, 14:16 
Собсно автар предвидел негодования любителей больших стандартов

https://github.com/rswinkle/PortableGL/#why-c

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Ivan7 (ok), 07-Май-24, 14:22 
Автор никаких аргументов не привёл, кроме того, что это его первый и любимый язык)
Скорее всего, он просто не знает С++, и, по сути, это и есть главный аргумент)
Но это его дело, на чём писать. Интересно было бы сравнить производительность с Mesa3D llvmpipe.
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/–
Сообщение от Прадед (?), 07-Май-24, 16:08 
Собственно достойный аргумент, учитывая что никто не знает С++ :) учитывая плюсников и это не шутка а строгая констатация. Осталось бы у пациента время на ОупенГЛ коли получал бы наслаждение он от лябмадизации и оуверрайда операторов? Это вопрос ресурсов и приоритетов.

Авторы другого топового проекта потрудились усерднее

https://www.sqlite.org/whyc.html

Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 07-Май-24, 18:42 
Можно использовать только полезную функциональность С++, а лямбды и всякую херню не использовать. В С++ много реально полезных вещей, например, шаблоны и всё, что с ними связано, классы, constexpr, consteval, в его стандартной библиотеке есть полезные вещи, по мелочи много всего. Всё это позволяет создавать более быстрый код.
Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Аноним (107), 07-Май-24, 19:58 
Извините, лямбды - это самая полезная функциональность C++0x. Она позволяет сильно сократить дублирование кода в телах функций при ветвлении if(a){if(b){fizz();}else{sizz();}}else{if(d){fuzz();}buzz();}
Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 22:10 
Полезная функциональность С++ называется С, автор её и использует :)
С++ позволяет создавать код более быстро за счёт сахара не не более быстрый.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

166. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 11:32 
Функтор априори быстрее вызова функции по указателю, поскольку встраивается по месту вызова, а inline в Си - "ненужное заимствование из крестов" (ц)
Ответить | Правка | Наверх | Cообщить модератору

173. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 13:02 
Вот про инлайнинг затирать не дальновидно, нынче компилятор как хочет так и крутит это сам.
Ответить | Правка | Наверх | Cообщить модератору

175. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 13:33 
Компилятор крутит не как хочет, а как ему позволят единицы трансляции. Опция -lto относится вообще к линкеру.
Ответить | Правка | Наверх | Cообщить модератору

130. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Прадед (?), 07-Май-24, 22:41 
Братан, никто не будет спорить что С++ в руках знающего человека хорош, но тем не менее, навести С++ красоту это  труд. Если не продумать и написать быстро - получится как раз наоборот - медленнее будет работать и на порядок сложнее читаться. Я думаю ты тоже что-то в этой жизни видел, и уж точно хреновый С++ код в данном репертуаре тоже присутствовал.
Если ещё меньше продумать - будет ломаться когда у юзера либы другой компилятор и прочее.
Если ещё меньше продумать - осложнит запускон на старых дистрах.
А если даже очень хорошо подумать - всё-равно придётся копаться в ассемблере, чтобы выяснить что андроидовский шланг не понял намёка и не задействовал копи-конструктор. Лично видел религиозного плюсника с 20+ лет опыта который решал подобное (но плюсы не разлюбил, и я его понимаю).
А если книжки по плюсам почитать - так это вообще, там расскажут.
Как бы мы все видели немножко плюсов.

Хотя конечно с лямбдочкой да constexpr можно навести красоту, но всё-же имхо это для гурманов.
Заметил что уже паттерн такой образовался: плюсники приходят в топовый сишный проект и спрашивают а че не на крестах? Я бы лучше на их месте подумал: "о, я вижу кто-то опять на сишке топскую штуку отжарил"

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

144. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 02:32 
С++ - это расширенный С. Если кто-то хочет использовать более ограниченный инструмент (С) и видит в этом преимущество, - флаг ему в руки! Лично я не думаю, что это умное решение. Конечно, бывают разные ситуации, связанные с совместимостью, переносимостью и всякими другими специфическими особенностями, но в таких случаях дело часто не в языке, а в других особенностях...

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

И в С++ дело не в красоте, а именно в возможностях: в С нет классов с конструкторами и деструктором, шаблонов, концептов, нормальной стандартной библиотеки (хотя без неё, безусловно, можно обойтись), и всякой другой полезности типа constexpr, consteval, [[likely]]/[[unlikely]] и т.д. А без классов, шаблонов и концептов писать приложение... такое себе занятие... удовольствие ниже среднего, прямо скажем. В то же время в С++ есть всё, что есть в С.

Ответить | Правка | Наверх | Cообщить модератору

151. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 04:12 
Ну тут такое.
Допустим я стал писать на крестаххх вместо С.
Вместо int напихал auto, заюзал местами какие то итераторы и регэкспы.
Пока код ещё похож на обычный С, те без классов, темплейтов, лямд и проечей фигни это норм, и реально быстрее писать.
Но классы, наследование, темплейты и прочая тарабарщина начинают резко усложнять структуру кода, размазывая простую и очевидную в С логику тонким слоем по десяткам файлов/классов.
Там где я в С делаю какую то отдельную функцию крестовики обычно пихают это в класс, даже если оно примотано туда синей изолентой и от класса там ничего не надо.
Для меня рефакторинг это пройти по всем вхождениям функции в коде и добавить/убрать аргумент, а для крестов там могут найтись дальние наследники и замучишься править.


https://github.com/eranif/codelite/issues/3355
Читать трейс вокруг LanguageServerCluster::StartServer.
А чувак всего то хотел прочитать строчку - путь до компелятора или типа того.
И там в проекте такого хватает, я как то сражался за производительность в этом проекте пару раз и чистил авгеевы конюшни класса-в-классе-в-классе-в-классе-...в цикле... ради одного примитивного действия.

Ответить | Правка | Наверх | Cообщить модератору

152. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 04:38 
> Пока код ещё похож на обычный С, те без классов, темплейтов, лямд и проечей фигни это норм, и реально быстрее писать.

Без классов и шаблонов... так в них же как раз вся соль!

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

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

> Там где я в С делаю какую то отдельную функцию крестовики обычно пихают это в класс...

Крестовики могут делать ровно то же самое, что и ты, поверь. По сути, твои программы на С являются корректными программами на С++.

> Для меня рефакторинг это пройти по всем вхождениям функции в коде и добавить/убрать аргумент, а для крестов там могут найтись дальние наследники и замучишься править.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

153. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 05:04 
Да, язык не виноват, людишки не осиливают :)
Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Прадед (?), 08-Май-24, 08:39 
Исторически вижу что в подобных срачах плюсники всегда говорят за теорию а сишнике за практику.

В принципе со временем приходит понимание того, что в реальном мире спорить об этом смысле нет по той простой причине что никто никого не переубедит. Поэтому сишнике и не лезут в Кути или там в Хром с заявлениям  типа "а что не на сишке".
Новые большие проекты да начинают на плюсах, но они не выживают, и в итоге в топе остаются древнейшие ОГРОМНЫЕ проекты на сишке, но огромные не по коду, э, а по функционалу.
Иронично то, что поскоку теперь есть ещё раст, плюснике имеют возможность с упоением поотвечать на "а че не на раст" и в ответ получить гору теоретических размышлений.

Не так давно клиент один хотел либу подключить, а там обвязка на плюсах, он такой ооу, плюсовщинка, как харашо, в итоге выяснилось что автор либы потянул буст только ради (не падайте) shared поинтеров, ну как бы да, были времена, а либа сегодня вдруг понадобилась. При этом обвязка естесственно имела 100500 кода который делал 0. В итоге выкинул нахрен, и выяснилось что надо было 4 функции сишные вызвать.
А вы попробуйте позависеть от буста, там 1500 хедеров друг от друга зависящих

Ответить | Правка | Наверх | Cообщить модератору

167. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 11:43 
shared_ptr проще самому написать, чем тянуть Буст. Другое дело, что зомбирование населения на тему "как хорошо от чего-то зависеть" шло во все времена и лишь набирает обороты.
Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 13:03 
Добавил бус в зависимости - приобщился к великому :))))
Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

176. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 13:37 
Купили аборигенов за стеклянные Бусты. :))
Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

180. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 16:36 
> Да, язык не виноват, людишки не осиливают :)

Не знаю как "людишки". Скажу про себя. Я осилил плюсы, когда учился в школе в 9x годах прошлого века. Да, тогда С++ был проще, но не принципиально.

До этого я изучал Бейсик в школе на Агатах ещё (были такие советские компы с советским процессором, если вдруг кто не в курсе, загуглите - в Википедии есть), и в DOS дома на 286 компе, а потом Си в DOS на 286 и 386 компах.

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

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

185. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 09-Май-24, 00:25 
Я продолжаю настаивать что кресты избыточны и пытаясь занять нишу и С и высокороуровнего языка они фейлятся в виду избыточной сложности. :)

Есть С.
Когда С мало, есть луа, вала чтобы его расширить до высокоуровневости.

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

Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 09-Май-24, 01:41 
> Я продолжаю настаивать что кресты избыточны и пытаясь занять нишу и С и высокороуровнего языка они фейлятся в виду избыточной сложности. :)

Да нет там никакой избыточной сложности. Это всё твои страхи. Всегда чем больше возможностей, тем закономерно выше сложность. А как ты хотел? Жить во времена DOS с компилятором Бейсика и Си? Те времена уже лет 30 как прошли.

> Есть С. Когда С мало, есть луа, вала чтобы его расширить до высокоуровневости.

Ну какие Луа, Вала для расширения С?! Ну что за бред! Если серьёзно, то это годится только для твоих домашних экспериментов.

Когда С мало есть С++. Здесь нечего изобретать велосипед. Умные дядьки всё уже давным давно придумали, сделали, испытали и т.д. Нужно лишь сесть, изучить язык и готовые качественные компиляторы в виде GCC и Clang и применять их на практике. Всё!

Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

190. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 09-Май-24, 10:07 
> Умные дядьки всё уже давным давно придумали, сделали, испытали и т.д.

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


> Когда С мало есть С++.

Это у вас кресты.
У меня есть весь мир. )
Кресты по соотношению сложность/профит себя не оправдывают для того кто уже владеет С.
Выгоднее потратить время на любой другой язык или лучше технологию.


И у меня есть подозрения что через 10 лет луа резко взлетит.
Сейчас дети массово шпилятся в роблох, там сплошная луа, часть из них попробует и будет её двигать дальше.


> Да нет там никакой избыточной сложности. Это всё твои страхи. Всегда чем больше возможностей, тем закономерно выше сложность.

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

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

Что мне даст С++?
Возможность писать не интересный мне софт в не интересных мне областях? (игры, трейдинг) - а зачем?
Условно я и сейчас могу править ++ код, и это решает все мои проблемы.
Если я "выучу" пистон или жабу - то это сделает меня намного более ценным специалистом чем ++.
Луа сделала меня более ценным спецом уже.

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

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

194. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 10-Май-24, 13:01 
Геттеры-сеттеры это всего лишь сахар над "ООП" в Си и ничего нового толком не дают. В плюсах имеет смысл templates (В Си их частично перетянули в виде _Generic) -- это отдельный язык в языке, помощнее препроцессора -- вот они позволяют существенно сэкономить  на писанине, когда требуется кучка похожих функций для различных типов. Но с ними есть нюанс: понимал их досконально только Александреску, но ушёл в D. :)
Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

193. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 10-Май-24, 12:51 
В 90-х годах? Си++ стандартизован в 98-м. Агат (клон Apple-II) собирали на процессоре MOC 6205, его не смогли воспроизвести, в отличие от i8080 и прочих, загуглите сами.
Ответить | Правка | Наверх | Cообщить модератору

197. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 10-Май-24, 19:05 
> В 90-х годах? Си++ стандартизован в 98-м.

Во-первых, 98 год относится к 90-м. Во-вторых, компиляторы появились гораздо раньше, чем был разработан и принят стандарт. Например, "первая доступная версия Borland C++, имевшая номер 2.0, вышла в 1990 году под DOS, а в 1991 году вышла версия 3.0 с поддержкой сборки Windows-приложений", Microsoft выпустила компилятор C++ в 1992 году, Visual C++ был выпущен в начале 1993 года, а в GCC С++ был добавлен ещё раньше - в 1987 году. У меня даже книги сохранились на русском по первым версиям Borland C++ Builder и Microsoft Visual C++, и они (книги) точно 90-х годов (второй половины 90-х - 1995 года или чуть позднее).
https://en.cppreference.com/w/cpp/language/history

Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

201. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 12-Май-24, 10:31 
Гипотетически были какие-то борланды, а практически даже MSVC 6-й версии не поддерживал стандарт, стало быть не являлся conforming implementation. И это без учёта того, что auto_ptr оказался кривой по дизайну и потребовал замены на unique_ptr.

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

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

204. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 12-Май-24, 16:52 
> Гипотетически были какие-то борланды...

Borland был не гипотетически, а реально. Это был лучший компилятор. Я сам его использовал. Это был мой первый компилятор С, а позже и С++. Потом появился Borland C++ Builder, который я также использовал на протяжении многих лет. MSVC в то время ничего сопоставимого предложить не мог.

> а практически даже MSVC 6-й версии не поддерживал стандарт

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

> auto_ptr оказался кривой по дизайну и потребовал замены на unique_ptr.

Когда я изучал С++ никакого auto_ptr ещё не было. Он появился уже позднее.

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

У Линуса была очень специфическая задача.

Лично я использовал Си, когда ещё не знал С++, и было это ещё под ДОСом на 286 и 386 компах. После того, как я изучил С++, чистый Си я никогда больше не использовал (разве что только для программирования микроконтроллеров) и желание его использовать с тех пор никогда не появлялось.

Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

206. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 13-Май-24, 08:15 
>> Гипотетически были какие-то борланды...
> Borland был не гипотетически, а реально. Это был лучший компилятор. Я сам
> его использовал. Это был мой первый компилятор С, а позже и
> С++. Потом появился Borland C++ Builder, который я также использовал на
> протяжении многих лет. MSVC в то время ничего сопоставимого предложить не
> мог.

Угу, лучший, своего рода герой легенд и анекдотов.)) И это при том, что Borland делала упор на совсем другой язык и я лично вешал Delphi совершенно валидным Object Pascal, собирающимся Free Pascal Compiler.

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

Вот я и пишу, что не было стандарта, а значит и не было языка. Была кучка производителей трансляторов, тянувших на себя одеяло. 6-й появился в 1998, в год принятия стандарта. Был явно лучше борландовского, несмотря на постоянные internal compiler error. Конечно, в плане поддержки стандарта ни в какое сравнение не шёл с трансляторами на фронтэнде Edison Design Group, вроде Intel C Compiler или Comeau C/C++ (светлая ему память).

>> auto_ptr оказался кривой по дизайну и потребовал замены на unique_ptr.
> Когда я изучал С++ никакого auto_ptr ещё не было. Он появился уже
> позднее.

auto_ptr - это часть языка, по стандарту. И там же в стандарте есть определение, что такое conforming implementation. Всё остальное - из разряда "на заборе написано".

>> Линус якобы пробовал на плюсах писать ядро, ему это не понравилось.
> У Линуса была очень специфическая задача.

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

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

200. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 10-Май-24, 20:22 
> В 90-х годах? Си++ стандартизован в 98-м.

Есть ещё книга Бьерна Страуструпа (создателя С++) "Дизайн и эволюция C++". Там про историю С++ рассказано подробно, включая идеи - что, зачем и почему было сделано, почему принимались те или иные решения.

Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

202. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 12-Май-24, 10:37 
Кажется, я видел даже STL Степанова и Ли, где макросы были вместо template.
Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

191. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Anonymm (?), 09-Май-24, 19:25 
"Любимый язык" - это достаточная причина
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

101. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (101), 07-Май-24, 19:37 
Перевод для тех кому лень ходить по ссылкам:

"""
Недавно я наткнулся на комментарий к PortableGL, в котором, по сути, спрашивалось: "Зачем реализовывать мертвую технологию на мертвом языке?".

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

Переведено с помощью DeepL.com (бесплатная версия)
"""

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

128. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –2 +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 22:12 
Там сплошные оправдания когда читаешь в оригинале.
У автора не хватает уверенности в себе чтобы заявить что гниль это дно, кресты предсвестник дна и всё в таком духе.
Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –1 +/–
Сообщение от Аноним (82), 07-Май-24, 17:21 
Аргумент про производительность — либо демонстрация глупости/некомпетентности, либо толстый троллинг и провокация на холивар.
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

92. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Bottle (?), 07-Май-24, 18:25 
Ты глупец и толстый тролль. Constexp и consteval позволяют провести повторяющиеся вычисления на этапе компиляции. Например, можно посчитать значения периодической функции на одном промежутке (скажем, синуса), засунуть их в массив и интерполировать между значениями при разных аргументах.
Чтобы реализовать подобное на Си придётся попотеть знатно.
Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (82), 07-Май-24, 19:46 
> Чтобы реализовать подобное на Си придётся попотеть знатно.

Дёрнуть из Makefile внешний скрипт при компиляции, делов-то.

Деды такое на AWK и шеллскрипте делали, сейчас в моде python или что там ещё…

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

Ответить | Правка | Наверх | Cообщить модератору

108. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –1 +/–
Сообщение от Аноним (7), 07-Май-24, 20:04 
> Например, можно посчитать значения периодической функции на одном промежутке (скажем, синуса)

Эталонное ненужно, тащить в бинарь таблицу того, что можно посчитать в райниайме. Она с ssd считываться будет дольше, чем рассчитываться при старте программы. Consteval кривой велосипед, компилятор мог бы сам определять (и определяет) что можно рассчитать на этапе конпеляции. Классы приводят к кривой архитектуре, которую постоянно надо рефакторить. Шаблоны вещь в принципе неплохая в теории, на практике редко нужная и раздувающая время компиляции в сотни раз по сравнению с чистым си.

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

117. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Bottle (?), 07-Май-24, 21:38 
Ты серьёзно? Кучу значений рассчитать в рантайме, чтобы сжечь гигаватты энергии на тысячах компьютеров из-за одинаковых действий, усилить зависимость от аппаратной неточности конкретного процессора, просто чтобы не хранить пару килобайтов данных на диске?
>Классы приводят к кривой архитектуре, которую постоянно надо рефакторить

Не спорю, но структуры ещё хуже.
>Шаблоны вещь в принципе неплохая в теории, на практике редко нужная и раздувающая время компиляции в сотни раз по сравнению с чистым си.

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

Ответить | Правка | Наверх | Cообщить модератору

168. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 11:49 
> Ты серьёзно? Кучу значений рассчитать в рантайме, чтобы сжечь гигаватты энергии на
> тысячах компьютеров из-за одинаковых действий, усилить зависимость от аппаратной неточности
> конкретного процессора, просто чтобы не хранить пару килобайтов данных на диске?

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

Ответить | Правка | Наверх | Cообщить модератору

169. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (169), 08-Май-24, 11:52 
> На практике время компиляции раздувают хедеры вместо модулей

Да ладно, если условный std::map включить импортом вместо хидера, с чего вдруг что-то должно измениться во времени компиляции? Да и сколько времени их рожали, сколько времени ушло на поддержку в компиляторах. Экосистема лоускилов. Сишку конечно тоже что-то никто особо не рвется развивать, это прискорбно.

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

129. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 22:20 
Чувак, нет, не придётся.

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

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

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

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

183. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 18:20 
Для фанатов ручной работы и велосипедостроения чистый Си - это прямо самое то, самый смак)))
Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Ivan7 (ok), 07-Май-24, 18:44 
> Аргумент про производительность — либо демонстрация глупости/некомпетентности, либо толстый троллинг и провокация на холивар.

Ещё раз для особоодарённых: С++ позволяет создавать более быстрый, более производительный код, чем С. А С++ вместе с ассемблером - вообще огонь!

Совсем по-простому: С является подмножеством С++, т.е. С является частью С++. Другими словами, любой компилятор С++ скомпилирует код С. Т.е. С++ обладает намного (вообще несравнимо) большими возможностями, чем С. И вот как раз, используя эти возможности, и можно достичь более высокой производительности по сравнению с С. Под С++ я имею в виду последние стандарты: С++20, С++23.

Учи матчасть, злобный Аноним!

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

102. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/–
Сообщение от Аноним (82), 07-Май-24, 19:39 
> С является подмножеством С++, т.е. С является частью С++

Это неверно. Правильнее сказать, стандарты C++ включают в себя некоторое подмножество стандарта C. Это называется "Clean C" и на нём пишутся всякие header-only библиотеки. В действительности же стандарты C и С++ расходятся с каждым годом всё сильнее.

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

Ещё раз, какие-какие возможности?

> Совсем по-простому: С является подмножеством С++

Забавно — именно по этой самой аргументации C всегда будет быстрее. Потому что для одного и того же кода на C и C++ будет генерироваться тот же самый машинный код. А поддержка "больших возможностей" как раз и отъедает лишние инструкции.

Это именно если «по-простому» беспредметно водить руками в воздухе. На самом деле, есть куча нюансов, вроде профилей и отдельных флагов оптимизатора. Но в общем случае, производительность C++ такая же или хуже, чем аналогичного, грамотно написаннного когда на C. И если это внезапно не так, всегда можно докопаться до причин и исправить сишный исходник. Или плюсовой.

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

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

Ответить | Правка | Наверх | Cообщить модератору

109. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 07-Май-24, 20:08 
>> С является подмножеством С++, т.е. С является частью С++
> Это неверно. Правильнее сказать...

Мелочи погоды здесь не делают.

>> используя эти возможности, и можно достичь более высокой производительности по сравнению с С
> Ещё раз, какие-какие возможности?

Самые-самые разные. Например, в С++ есть [[likely]] и [[unlikely]], которыми можно помечать более или менее приоритетные if'ы. Это напрямую влияет на генерируемый ассемблерный код.

>> Совсем по-простому: С является подмножеством С++
> Забавно — именно по этой самой аргументации C всегда будет быстрее. Потому что для одного и того же кода на C и C++
> будет генерироваться тот же самый машинный код. А поддержка "больших возможностей" как раз и отъедает лишние инструкции.

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

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

> Но в общем случае, производительность C++ такая же или хуже, чем аналогичного, грамотно написаннного когда на C.

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

Ответить | Правка | Наверх | Cообщить модератору

131. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 22:41 
> Например, в С++ есть [[likely]] и [[unlikely]], которыми можно помечать более или менее приоритетные if'ы.

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


Послушайте, вам уже указали на основную проблему крестов: стандарт слишком сложный для изучения, понимания и применения (и для компеляторов тоже, они долго жуют исходники).
На практике это означает написать какую то фигню на крестах которая выглядит вполне безобидно но катастрафически гробит производительность очень легко. Хуже всего что обычно на глаз код выглядит вполне нормально и красиво, и чтобы понять что творится фигня нужно либо копатся в исходниках и читать код в куче разных файлов потому что там разные классы взаимодействуют либо запускать это под профайлером.
Да, на С тоже можно написать фигню, но эту фигню в 90% видно сразу при чтении, без прыгания по исходникам и без дополнительных инструментов, особенно рантайм.

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

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

Ответить | Правка | Наверх | Cообщить модератору

141. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 02:02 
>> Например, в С++ есть [[likely]] и [[unlikely]], которыми можно помечать более или менее приоритетные if'ы.
> Это уже давно стало опциональным расширением С компеляторов.
> Как по мне, лучше избегать подобного.

Смысл избегать, если это часть стандарта, элементарно применяется и повышает производительность почти за бесплатно?

> Послушайте, вам уже указали на основную проблему крестов: стандарт слишком сложный для изучения, понимания и применения

Возможностей у С++ намного больше, потому и сложнее. Я изучал С++ в школе. Для школьника он вполне доступен.

>(и для компеляторов тоже, они долго жуют исходники).

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

> На практике это означает написать какую то фигню на крестах которая выглядит вполне безобидно но катастрафически гробит производительность очень легко.

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

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

С++ много чего облегчает. Для этого он и был создан, т.е. для расширения С. так его и нужно воспринимать. Если тебе С хватает - ОК. На С ты можешь написать какую-нибудь библиотеку, маленькую утилиту, но создавать большое приложение... - точно нет, мазохизм!

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

Так это как раз и хорошо)

> И чтобы вы понимали, под диалектом я имею ввиду не какой то местный "поребрик", а когда половина или больше слов не понятно или не уверен в их значении на 100%.

Ну так изучи то, что тебе не известно) Делов то!


Ответить | Правка | Наверх | Cообщить модератору

148. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 03:47 
> Смысл избегать, если это часть стандарта, элементарно применяется и повышает производительность почти за бесплатно?

Потому что это вносит лишние слова и логику в чтение кода.
Бесплатно - часто можно переписать чтобы выкинуть/переместить условие.
И не факт что оно срабатывает в плане увеличения производительности так часто как вы его применяете.
А при использовании данных профилировщика думаю оно вообще игнорируется.


> Возможностей у С++ намного больше, потому и сложнее. Я изучал С++ в школе. Для школьника он вполне доступен.

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


> Нормально они по времени компилируют - секунды занимает компиляция обычно.

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


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

Вы опять не читаете.
На С фигня в 90% выглядит как фигня сразу.
На крестах чтобы понять что это фигня и дичь надо копатся по куче исходников потому что там класс в классе классом погоняет, или смотреть стактрейсы.


> С++ много чего облегчает. Для этого он и был создан, т.е. для расширения С. так его и нужно воспринимать. Если тебе С хватает - ОК. На С ты можешь написать какую-нибудь библиотеку, маленькую утилиту, но создавать большое приложение... - точно нет, мазохизм!

Да да.
LUA мне тоже облегчает, и тоже для расширения С :)))
Фря почти вся на С написана, линукса ядро тоже совсем не маленький проект.
Насколько помню самба ещё не на крестах, уж точно qemu с его 8к+ файлов на С.
Это по вашему маленькие проекты?

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


> Так это как раз и хорошо)

Удачи вам в болгарии с вашим русским, там тоже кирилицей пишут )))))))))))


> Ну так изучи то, что тебе не известно) Делов то!

Зачем мне кресты!?
Пограмист на крестах это как землекоп: ему кодить с утра и до обеда, по 3 зелёных свистка в час.
Всмысле это тупая работа по переводу с человеческого на машинный, которую чатгпт уже почти заменил.
Говоря более обще: проектов на крестах интересных мне почти нет, как и задач.

Я всегда говорил что я лучше изучу технологии, которые не важно на каком языке юзать.
Или какой то высокоуровневый язык.
Вот всё смотрел на петон. Но меня от него тошнит, как от синтаксиса, так и от экосистемы.
Потом потыркал джаву в вузе в прошлом году, как раз вот эти ваши классы и прочее. Ну такое себе. У меня задач/интересов для этого нет с одной стороны, с другой ничо нового почти.
В этом году изучил Lua и теперь пытаюсь его везде с С крещивать и пихать :)
От луа куда больше синергетического эффекта чем от крестов - он всё же реально высокоуровневый, и уши его торчат то тут то там...

Ответить | Правка | Наверх | Cообщить модератору

157. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (157), 08-Май-24, 08:08 
Postgres еще на сишичке написан - собирается просто мгновенно для проекта такого объёма.

Чувак просто деревянный и молиться на паттерны проектирования, классы и интерфейсы без осознания задачи. Не может подняться над задачей. Каждой задачи свой инструмент, а он все молотком забивает. Меня помню один идиот спрашивал как я буду реализовывать процессинг: я ему про персистентность, транзакционность,про хранинение НЕ в флоатах... а он мне все не верно - нужно создать базовый класс. Академик из детского сада.

Ответить | Правка | Наверх | Cообщить модератору

182. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 16:48 
> Postgres еще на сишичке написан - собирается просто мгновенно для проекта такого объёма.

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

> Чувак просто деревянный и молиться на паттерны проектирования, классы и интерфейсы без осознания задачи. Не может подняться над задачей. Каждой задачи свой инструмент, а он все молотком забивает. Меня помню один идиот спрашивал как я буду реализовывать процессинг: я ему про персистентность, транзакционность,про хранинение НЕ в флоатах... а он мне все не верно - нужно создать базовый класс. Академик из детского сада.

Дядька просто намного опытнее тебя.

Ответить | Правка | Наверх | Cообщить модератору

184. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 21:30 
Хромиум на крестах, 60к+ файлов, собирается за 3-5 часов на 5950х.
quemu на С, 6,6к файлов, собирается за 3-10 минут.

Дополнительно отмечу что кресты жрут памяти сильно больше при сборке.

Ответить | Правка | Наверх | Cообщить модератору

187. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 09-Май-24, 01:46 
Уверен на 100%, что объём твоих программ сильно меньше объёма исходников Хромиума, поэтому скорость сборки для тебя не должна быть какой-то проблемой.

Я проблем с потреблением памяти компиляторами С++ никогда не замечал. Пользовался самыми разными компиляторами от Borland, Microsoft, Intel, GCC, Clang и др.

Ответить | Правка | Наверх | Cообщить модератору

192. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 10-Май-24, 01:44 
У меня то да.
Но это как бы к вашему: "большие проекты только на крестах можно писать".

Да, когда собираешь в один поток два файла всего то не проблема.
А когда компеляешь тот же хромиум в 32 потока, то с++ жрущий по 300+мб на процесс уже весьма заметно - 9 Гб.

Ответить | Правка | Наверх | Cообщить модератору

198. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 10-Май-24, 19:50 
> А когда компеляешь тот же хромиум в 32 потока, то с++ жрущий по 300+мб на процесс уже весьма заметно - 9 Гб.

У меня в компе 128 Гигов оперативки, поэтому я память особо не считаю. Но раньше было гораздо меньше. Когда у меня был 286 комп, то памяти вообще было 640 кБ и DOS :)

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

160. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от тыквенное латте (?), 08-Май-24, 09:17 
> В этом году изучил Lua и теперь пытаюсь его везде с С
> крещивать и пихать :)

Perl же! Guile же! :-D

> От луа куда больше синергетического эффекта чем от крестов - он всё
> же реально высокоуровневый, и уши его торчат то тут то там...

хороший проект так примерно и выглядит.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

112. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (44), 07-Май-24, 20:47 
Почему тогда между си кодом и ближайшим С++ конкурентом разрыв 595% в такой распространённой задаче, как использование регулярных выражений? https://habr.com/ru/articles/812953/
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

114. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от тыквенное латте (?), 07-Май-24, 21:25 
> Почему тогда между си кодом и ближайшим С++ конкурентом разрыв 595% в
> такой распространённой задаче, как использование регулярных выражений? https://habr.com/ru/articles/812953/

потому что С++ код писали без [[likely]] и [[unlikely]], очевидно же!

Ответить | Правка | Наверх | Cообщить модератору

132. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Прадед (?), 07-Май-24, 22:59 
Дружище, лайкли и анлайкли - это только верхушка айсберга (которая сюрприз по факту сишниками используется, хоть в стандарте и нет, гном ими по уши наполнен). Есть ещё целая куча подобных фич.
Одна из них кстати С++ не поддерживается на уровне стандарта, а в сишке да : тадададам - restrict.
Также курим: cold functions (не путать с cold calls, это к другому отделу))), const functions (e.g. G_GNUC_CONST), register, векторайзеры там ещё всякие.
Если откроешь код любого хорошего проекта - увидишь всё это с лихвой
Ответить | Правка | Наверх | Cообщить модератору

118. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (119), 07-Май-24, 21:50 
В C++ очень быстрые регулярные выражения, в конечный автомат во время компиляции преобразуются*.

* с использованием библиотеки CTRE. Си позобным похвастать не может, там ручками нужно автомат писать.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

124. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 22:00 
С может похвастатся тем, что в нём практически нет диалектов.
Все диалекты которые есть - это диалекты специфичных либ, в пределах которых опять же практически польностю отсутствует разбивка на диалекты.

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

Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 07-Май-24, 21:57 
Не позволяют кресты создавать более производительный код.
Всё отличие в том, что в кресты понапихали синтаксического сахара.
Потом обдолбавшись сахаром авторы принялись расширять сознание и попытались сделать из крестов высокоуровневый язык без ручного манагемента памяти.
Как итог у них получилась полная бормотуха, где один разработчик не понимает до конца что пишет его сосед, потому что хотя у них компелятор и один но диалекты у каждого разработчика могут быть свои и сильно отличающиеся.
А потом бедный компелятор крестов пыхтит в 20 раз дольше по сравнению с обычным С компелятором при сборке чтобы расшифровать эту фигню и перевести в машинные коды.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

142. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 02:14 
> Не позволяют кресты создавать более производительный код.

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

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

В С++ доступно абсолютно такое же, как в С, управление памятью. Это подмножество С++, и почти любая программа С компилируется компилятором С++. Т.е. в С++ можно использовать абсолютно такое же управление памятью, как в С, если хочется.

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

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

> А потом бедный компелятор крестов пыхтит в 20 раз дольше по сравнению с обычным С компелятором при сборке чтобы расшифровать эту фигню и перевести в машинные коды.

Компиляция средней программы на С++ занимает секунды. Пишешь программу ты на порядки дольше. При написании программы С++ экономит тебе кучу времени. Выгода от использования С++ очевидна.

Ответить | Правка | Наверх | Cообщить модератору

149. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 03:59 
Если ты лезешь в асм - то нафига тебе кресты?
Если мне нужна производительность то я посмотрю в сторону инстриктов и там всяких профилировщиков, все эти unlikely - это обычно ниачом.


> Я с таким в своей практике не сталкивался.

А мне было забавно наблюдать как одни разрабы просили новую разработчицу не сильно увлекатся кажется 17, они ещё 14 не осовоили ))))

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


> При написании программы С++ экономит тебе кучу времени.

Ага. Особенно когда ты понял что накосячил с архитектурой, и теперь тот класс что везде используется надо основательно переписать разбив на 5, и попутно отрефакторить код в сотне файлов.
На хубре недавно была статья про то что гнить для игор не заходит ибо сильно сковывает, у меня к крестам такие же ощущения :)

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

Ответить | Правка | Наверх | Cообщить модератору

154. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 05:08 
> Если ты лезешь в асм - то нафига тебе кресты?

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

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

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

>> Я с таким в своей практике не сталкивался.
> А мне было забавно наблюдать как одни разрабы просили новую разработчицу не сильно увлекатся кажется 17, они ещё 14 не осовоили ))))

Бедняги) Книжку взять на русском языке - это очень сложно и страшно - там же очень-очень-очень много букв)

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

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

А если нужно наследование? А если нужны похожие структуры, в которых есть поля с одинаковыми именами, но эти структуры - не наследники друг друга, но со всеми этими структурами должна работать какая-то функция? Ужас! Лучше даже не думать об этом. А в С++ такое легко и просто, даже играючи - классы, наследование, концепты, шаблоны... Даже препроцессор не нужен)

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

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


>> При написании программы С++ экономит тебе кучу времени.
> Ага. Особенно когда ты понял что накосячил с архитектурой, и теперь тот класс что везде используется надо основательно переписать разбив на 5, и попутно отрефакторить код в сотне файлов.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

155. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan_83 (ok), 08-Май-24, 07:21 
> В С то же самое, только ещё хуже: вместо классов структуры, malloc/free для этих структур в непонятных местах, после выделения памяти не забыть вызвать инициализирующую эту структуру функцию, перед уничтожением не забыть вызвать функцию-деструктор, а функции, работающие со структурами, должны принимать указатели на структуры или указатели на указатели на структуры,

Всё так.
Но при этом это всё происходит в явном виде.
Я могу взять структуру, заинитить там одно поле и пульнуть в какую то другую функцию и получить результат.
В крестах оно обязательно вызовет и конструктор и деструктор, и там будет куча неочевидного месива.
Деструкторы тоже вызываются не всегда очевидно как.
https://github.com/eranif/codelite/issues/3355
трейс вокруг LanguageServerCluster.
Там что то типа: char *path = app()->debuger()->getpath();


> а вдруг им передан нулевой указатель - надо не забыть проверить... Тот ещё гемор, в общем.

Да, обязательно, ведь как завещал МыщьХ: код наверняка будут вызывать враги и нужно проверить все!


> А если нужно наследование? А если нужны похожие структуры, в которых есть поля с одинаковыми именами, но эти структуры - не наследники друг друга, но со всеми этими структурами должна работать какая-то функция?

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

> Но в С всё то же самое, только хуже, потому что приходится изобретать велосипед

Разбивка на файлы это что то новое?)


> В С так же. С большими программами и сложными структурами данных в любом языке примерно та же история.

C не толкает использовать классы и всякие навороты.


> Луа - это скриптовый язык для программ и к тому же медленный, совсем не замена С++

Это вы так думаете :)
Да, это не С/С++, но при правильном использовании - в виде клея для С функций/либ, он как и питон и как и кресты будет далеко не самым узким местом.


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

Он вполне годен и для бизнесслогики.
Ещё для make систем это просто киллер фича: у него зависимостей по либам нет, сам маленький, а нагородить в нём можно легко больше и проще чем с Cmake и meson.

Ответить | Правка | Наверх | Cообщить модератору

171. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 12:40 
> Да, обязательно, ведь как завещал МыщьХ: код наверняка будут вызывать враги и
> нужно проверить все!

Осталось понять, почему в его эмуляторе JS "в 1000 строчек на Си" (ц), сделанном для McAfee по заказу Пентагона, внутри была V8, для которой обёртки писал посторонний, поскольку сам Криска не знал Си++.

Ответить | Правка | Наверх | Cообщить модератору

170. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 08-Май-24, 11:58 
> Совсем по-простому: С является подмножеством С++, т.е. С является частью С++. Другими
> словами, любой компилятор С++ скомпилирует код С.

C.5 C++ and ISO C [diff.iso]

1 This subclause lists the differences between C++ and ISO C, in addition to those listed above, by the chapters of this document.

...

char* p = "abc";          // valid in C, invalid in C++

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

181. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 16:40 
Правильнее с const. В С++ работает:
const char* p = "abc";

Часто такое использую. Не знаю, что там в стандарте, но на практике всегда и во всех компиляторах работало.

Так же, как включение (#include) чисто сишного файла в файл С++. Вообще, с проблемами сочетания кода на чистом С с кодом на С++ я никогда не сталкивался.

Ответить | Правка | Наверх | Cообщить модератору

195. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 10-Май-24, 13:05 
Ну так в том "чисто сишном" файле стоят #ifdef __cplusplus :)
Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 10-Май-24, 13:07 
> Правильнее с const. В С++ работает:
> const char* p = "abc";
> Часто такое использую. Не знаю, что там в стандарте, но на практике
> всегда и во всех компиляторах работало.

Так надо почитать, что там в стандарте, для того и указал наименование главы. Что бы не писать дезинформацию про "подмножество" -- это принимаются остальные эксперты копировать.

> Так же, как включение (#include) чисто сишного файла в файл С++. Вообще,
> с проблемами сочетания кода на чистом С с кодом на С++
> я никогда не сталкивался.

Ну так в том "чисто сишном" файле стоят #ifdef __cplusplus :)

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

199. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 10-Май-24, 20:02 
Изначально С++ - это был Си с классами. Гораздо позже стали появляться стандарты С++ и С и языки стали немного отличаться, но отличия чисто косметические. Возможно в последних версиях стандарта Си там что-то добавили, но последнюю версию на практике мало кто использует, т.к. на Си в основном написаны старые программы при создании которых использовались старые стандарты. Новые приложения никто в здравом уме на чистом Си писать не будет. А те, кто пишет на Си понимают, что чаще всего их код будет использован в приложениях С++, в том числе ими самими, поэтому они обязаны обеспечить совместимость с С++. Из-за этого на практике в реальной жизни встретить код Си, который бы не компилировался компилятором С++, почти не реально.
Ответить | Правка | Наверх | Cообщить модератору

203. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 12-Май-24, 10:44 
Я пишу новое "приложение" на чистом Си. Потому что имеющаяся стандартная библиотека плюсов неимоверно жирная, а свою имплементацию переделывать пока слишком хлопотно. Честно сказать, плевать, будет ли его собирать g++ -- на данный момент это совершенно напрасная трата времени. Это к тому, что не стоит говорить за других. Лучше почитать стандарт и не делать противоречащих ему заявлений.
Ответить | Правка | Наверх | Cообщить модератору

205. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 12-Май-24, 17:16 
> Потому что имеющаяся стандартная библиотека плюсов неимоверно жирная

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

> Лучше почитать стандарт и не делать противоречащих ему заявлений.

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

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

Ответить | Правка | Наверх | Cообщить модератору

207. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от n00by (ok), 13-Май-24, 08:34 
>> Потому что имеющаяся стандартная библиотека плюсов неимоверно жирная
> Можно использовать С++, но не использовать его стандартную библиотеку или использовать
> её по минимуму. Я, например, так и делаю. Зато я получаю
> ООП, шаблоны, концепты, кучу других удобств, возможность использовать самые разные библиотеки
> С++ и прочее. Глупо не использовать эти возможности.

Что значит "по минимуму"? Вызвать десяток экспортов из libstdc++.so вместо сотни-другой? Не понятно, что это меняет.

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

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

> В стандарте много чего нет, что
> есть в компиляторах, и что полезно, нужно и принципиально важно на
> практике, и это всё в совокупности и определяет выбор в пользу
> С++ и конкретных компиляторов.

Это называется "расширения языка", а не противоречия со стандартом.

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

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

> Можно цепляться к каким-то мелочам из последних стандартов Си, которые в реальности
> мало когда и кем используются.

"Мало кем" - голословное утверждение, без статистики. Применительно к моему случаю оно оказалось очевидно ложным.

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

Подмножество - термин из теории множеств. Язык Си не является подмножеством языка Си++, что видно из стандарта.

Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Аноним (101), 07-Май-24, 19:32 
> Только на С++ надо было, а не на С

Вкусовщина. Так же можно сказать, что надо было на Pascal или вообще на каком-нибудь Haskell.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

103. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –3 +/–
Сообщение от Аноним (105), 07-Май-24, 19:43 
Если на Pascal или, тем более, на Haskell, ты такую либу не вызовешь из кода ни на C, ни на C++.
Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/–
Сообщение от Аноним (101), 07-Май-24, 21:55 
Если на Pascal или, тем более, на Haskell, ты такую либу не вызовешь из кода ни на C, ни на C++.
Давац ещё что-нибудь рассажи))
Ответить | Правка | Наверх | Cообщить модератору

143. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/–
Сообщение от Ivan7 (ok), 08-Май-24, 02:17 
>> Только на С++ надо было, а не на С
> Вкусовщина. Так же можно сказать, что надо было на Pascal или вообще на каком-нибудь Haskell.

Не надо Pascal и тем более Haskell. C и С++ имеют максимальную переносимость под любой процессор и микроконтроллер, производительность, и для них много качественных компиляторов и библиотек на любой вкус.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру