The OpenNET Project / Index page

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



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

"Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от opennews (??), 07-Май-24, 09:25 
После более года разработки подготовлен выпуск проекта PortableGL 0.98, развивающего программную реализацию графического API OpenGL 3.x, написанную целиком на языке  Си (C99).  Теоретически  PortableGL может быть использован в любых приложениях, принимающих текстуру или фреймбуфер в качестве входных данных. Код оформлен в виде одного заголовочного файла и распространяется под лицензией MIT...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61131

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

Оглавление

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


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

7. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (7), 07-Май-24, 10:05 
Крайзис на  CPU запускали, вроде и фпс был приемлимый. С avx512 так вообще 1 ядро процессора сравнимо с 1 CU видеокарты по вычислительной мощности. Можно параллельно блок из 16 пикселей в float32 в шейдере обрабатывать или 32 пикселя в float16.
Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +5 +/
Сообщение от Аноним (15), 07-Май-24, 11:04 
У avx512 смутное будущее... В 12-14 поколениях интела его уже нет.
Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +4 +/
Сообщение от Аноним (-), 07-Май-24, 11:42 
Да они просто реализовать не смогли его нормально, завезли какой-то недоаналог
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (44), 07-Май-24, 13:07 
Интел ещё кто-то покупает? В амд есть в потребительском сегменте и анонсируют ещё АЛУ докинуть.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

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

84. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Аноним (44), 07-Май-24, 17:30 
Понятненько, пользователи 4770k размышляют о нужности avx512.
Ответить | Правка | Наверх | Cообщить модератору

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

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

136. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –1 +/
Сообщение от Аноним (15), 08-Май-24, 00:14 
Давайте подумаем вместе. АМ4 выпущен в конце 2016 года, АМ5 выпущен в конце 2022 года. Итого срок жизни сокета 6 лет.

Вы, конечно, можете сказать, что с 2016 до 2024 прошло не 6, а 8 лет. Но ведь уже больше года как доступна АМ5, а вы всё ещё на АМ4. Так что можно смело предположить, что и после выхода АМ4 вы ешё несколько лет сидели на АМ3. Так что оставляем срок жизни сокета АМ4 в 6 лет.

За эти шесть лет вы сменили, по вашим словам, "кучу процов и несколько материнок". Если только вы не считаете "кучей процов" два проца, то вашу фразу можно рассматривать как "не меньше 5 процов и не меньше 3 материнок". То есть, несмотря на более долгую поддержку сокета АМ4, вы всё равно меняете процессор минимум каждый год, а материнку - минимум через год.

С такой частотой смены железа откровенно непонятно, почему вы считаете Интел одноразовым, а АМД - нет. Если вы готовы раз в два года менять материнку, политика Интела вас тоже устроит.

Добавлю про себя. Сидел с 2012 года на сандибридже, проблем не знал, всё устраивало. В конце 2023 года решил обновиться. И знаете, что заметил? Какую бы платформу я не выбрал в 2012, в 2023 мне всё равно пришлось бы менять всё. На деле АМД оказался таким же одноразовым, как и Интел.

Более того, при выборе АМД в конце 2023 я имел выбор либо взять АМ4 (который совсем не факт, что будет поддерживаться ещё хотя бы три-четыре года), либо взять АМ5 (и переплатить вдвое за оперативную память и 10к плюсом за материнку). Спасибо АМД, но как-то не тянет покупать за оверпрайс материнку с днищенскими 5200 для DDR5 да ещё и с невозможностью поставить 4 планки памяти. А если извернуться и найти в списках совместимости экзотику, способную работать с 4 планками, то контроллер процессора сбрасывает скорость памяти до 3600 (это DDR5, напомню).

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

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

145. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Ivan_83 (ok), 08-Май-24, 03:18 
АМ4 ещё не EOL, ещё какие то процы типа свежие/рефрешы выходят, биосы выходят даже к матерям на 3хх чипсетах для поддержки распоследних процов.
На АМ4 я закатился сразу после выхода в продажу, и оно было сырое довольно :))))
Память кажется даже 2400 не заводилась, но потом биосы допилили и теперь на той же плате 3200 легко.

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

Самый простой пример это наш медиацентр: 2200G, 3200G, 5750G.
Притом с последним процом он ещё года полтора отработал моим основным компом.

2200G ушёл одному юному шнырю в подарок, вместе с материнкой покупавшейся на посмотреть (из интереса: асрок 350 про4).
3200G ушёл ребёнку, пока что.

У меня в компе за это время побывало:
- 1700х, А9700 (бристольридж), 1200х, 2700х, 5950х
- х370 тайчи, х370 гаминг х, асус 450м про, асус 450м про-с.

Тайчи ушла в домашний сервер в итоге, кажется там и 370 гаминг х побывал до того.
Гаминг х ушёл в тестовый комп в итоге, кажется со вторым 3200g из второго медиацентра. По сути это резерв для починки сервера.
асус 450м про ушёл второму ребёнку (в начале побывав у первого) вместе 3200g.
2700х первому ребёнку достался и новая мать.
1200 всплыл деффект с зависанием через несколько суток, я его подарил на опыты, вместе с бристолем.

И не факт что это конечные конфигурации.
С интелом у меня бы было или 3-4 поколения не совместимых между собой материнок/процов или нужно было искать откровенное старьё где то на вторичке.
А под АМ4 я до сих пор могу купить новые матери и процы.
Сейчас если я правильно помню у нас 7 компов на АМ4.


Это же интел меня избаловал: сокет 370, 775.
Да, они как бы формально были не совсем долгожителями, интел специально ломал совместимость как только мог.
Но в сети были мануалы что и как надо перепаять в 370 чтобы на старую мать и старый чипсет вставал и работал распоследний проц.
775 такое не прокатывало, но по сути начиная с 3х чипсетов они ничего не ломали после 9хх чипсетов, только серверные процы требуют какую то минимальную переделку для работы.

Сидел я на 370 с 2000 по 2007, дальше с на 775 до самого райзена. До бузеонов я как то не додумался в то время :)
Март 2017 кажется первые мать с процом я приобрёл и всунул в комп, раньше в магазах не было.
Те 7, 10 и 7 лет практически.

С АМ4 я не собираюсь уходить ещё минимум лет 5, ибо с одной стороны у меня их куча, с другой они всё тянут без проблем и там запаса ещё дофига.
Единственное что надо будет докупить 2,5Г адаптеры, как минимум местами.
И может ещё пару процов и одну-две материнки.
И какие то видяхи по современнее, в медиацентры может интелы, чтобы AV1 аппаратно в 8к 60фпс тянули.

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

189. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (189), 09-Май-24, 06:01 
> А если извернуться и найти в списках совместимости экзотику, способную работать с 4 планками, то контроллер процессора сбрасывает скорость памяти до 3600 (это DDR5, напомню).

Gigabyte  B650 AORUS ELITE AX - 4 DIMM на 5600

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

208. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (208), 13-Май-24, 17:52 
Расскажите подробнее, каково это - быть АМДшником? Купили хорошую материнку, а процессор её сливает.

В спеках 7700 и 8700G (другие лень смотреть):

> Max Memory Speed:
>  2x1R: DDR5-5200
>  2x2R: DDR5-5200
>  4x1R: DDR5-3600 <-- смотреть сюда
>  4x2R: DDR5-3600 <-- смотреть сюда

- https://www.amd.com/en/products/processors/desktops/ryzen/70...
- https://www.amd.com/en/products/processors/desktops/ryzen/80...

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

210. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от n00by (ok), 13-Май-24, 20:13 
Если действительно интересно, а не поспорить, то спрашивать следует: какие модули он поставил, и что подкручивал. Материнка точно так же _официально_ поддерживает 4 плашки на 4800 в списке совместимости (ссылку лень кидать).
Ответить | Правка | Наверх | Cообщить модератору

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

178. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Герострат (?), 08-Май-24, 14:21 
Широко используется = не взлетел. Ясно, понятно.
Ответить | Правка | Наверх | Cообщить модератору

209. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (208), 13-Май-24, 17:55 
Настолько широко используется, что интел с ледяным спокойствием отключили его в 12 поколении, не испытывая вообще никаких терзаний по этому поводу.
Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (134), 07-Май-24, 23:53 
Да, только сколько ядер у CPU, а сколько у GPU.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

23. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (23), 07-Май-24, 11:28 
Как-то так:
- https://github.com/rswinkle/PortableGL/blob/master/demos/sha...
- https://github.com/rswinkle/PortableGL/tree/master/external/glm
В смысле "по сравнению с работой на GPU"? Он на GPU и может.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

28. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Андрей (??), 07-Май-24, 11:50 
Какой GPU ? Это же софтверная библиотека и реализация. Тут единственное, что сложно понять, так это то, чем mesa не устраивает, если она вроде как раз про то и даже больше. Возможно код действительно проще, но тогда не совсем ясен задел на точность. С другой стороны - это круто, иметь программную реализацию OpenGL, которую можно в чистую линковать на любом устройстве на котором хочешь вывести 3D графику, да ещё и так, чтобы сохранить переносимость кода с полными реализациями OpenGL, типо той же месы.
Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от rezzet (?), 07-Май-24, 11:57 
Насколько понял GPU не может. GPU в отличие от CPU имеет непереносимую специфичную для каждого поколения GPU архитектуру и обеспечить работу на нем может только производитель GPU в своем драйвере. Этот проект это именно рендер на CPU за счет этого получается переносимость везде где есть Си-компилятор, именно о этом пишет автор проекта на странице github. Идея вполне себе жизнеспособная, фактически это процессорный растеризатор.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

135. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (135), 08-Май-24, 00:10 
С горечью признаю что был не прав - в контексте данной библиотеки прикрутить GPU нельзя.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

71. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Kuromi (ok), 07-Май-24, 15:55 
Хороший пример - то как визуально отличались Carmageddon с ускорением на (пусть даже ранних) GPU и чисто программный режим по умолчанию. Если лень гуглить - программный режим это жуткая мешанина пикселей, иначе оно просто не вывозило.
Так что либо красивая картинка и слайдшоу либо ужос с приемлемым FPS.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

85. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Аноним (88), 07-Май-24, 17:31 
В наше время на картинку особо никто не обращал внимание, главное геймплей. Лично играл в Carmageddon с 5 FPS на Pentium 60 МГц, который батя купил по объявлению газеты "из рук в руки", я был счастлив.
Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (88), 07-Май-24, 17:32 
> я был счастлив.

P.S. На контрасте после Денди.

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

2. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (88), 07-Май-24, 09:39 
Ну что тут скажешь.. круто!
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором  +1 +/
Сообщение от нитгитлистер (?), 07-Май-24, 09:50 
Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –6 +/
Сообщение от Аноним (5), 07-Май-24, 10:00 
Посмотрел код, пример типичного овнокода. С одной стороны так наверняка быстрее, но поддерживать такое поделки будет сложно. Поэтому тут два пути или упрощённый функционал. Или медленное или быстрое забвение как только уйдет кор девелопер (да он там один)
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Middle Go Developer (?), 07-Май-24, 10:37 
Это как я был на одной олимпиаде, а организатор сказал, что чтобы решить задачу, надо уметь в "спортивное программирование", которое нигде больше не пригодится
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +5 +/
Сообщение от Аноним (-), 07-Май-24, 10:58 
> которое нигде больше не пригодится

Доводилось работать с олимпиадником.
Его код... ну, это сложно описать.
Срезание углов где только можно - "разумеется!"
Забивание на краевые случаи.
Подогнать код под тесты или выкинуть "ненужные" тесты - "легко!"
Застрять на ненужной оптимизации какого-то случая, который выпадает раз в 100 лет, переписать его на нечитаемое месиво хаков и при этом ускорить всего на 10% - "а почему бы и нет?")).
На фоне всего этого принципиальное отсутствие форматирование кода было просто забавной особенностью)

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

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

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

33. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Аноним (33), 07-Май-24, 12:20 
> А что там за проблема с форматированием?

Ну не там, а конкретно у этого.
Код пишется как текст. По несколько конструкций в одну строку, расстановка скобок по велению левой пятки, расстановка пробелов - еще хуже. Так и не получилось переубедить, что нужно хотя бы пользоваться автоформатированием IDE, пришлось добавлять линтер на CI.
Причем я бы понял если бы это был стиль такой, ну просто особенный.
Но это был просто рандом: какой палец раньше на клавишу попал - в том порядке и будет пробел.
Нейминг переменных - i, ii, i2, a, aa и так далее. Нейминг функций получше, но не слишком.

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

77. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –6 +/
Сообщение от Аноним (77), 07-Май-24, 16:20 
Это не его проблема с форматированием. Он художник/поэт/писатель/итп. Он так видит. Это твоя проблема неосилить инструмент «форматер кода». Коих есть вагон и маленькая тележка, даже для «не таких как все» фетишистов форматирования.
Ответить | Правка | Наверх | Cообщить модератору

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

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

38. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от 111email (??), 07-Май-24, 12:41 
Пригодится разве что при решении алгоритмических задач при поступлении на работу. А уже после поступления - ну, может раз в пять лет.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

41. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Аноним (5), 07-Май-24, 12:53 
Даже сабж пытались спонсировать какие-то поставщики промышленных устройств в том числе для оборонной промышленности. Но решили что столько магии они не потянут и проспонсировали только два месяца.
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от 12yoexpert (ok), 07-Май-24, 10:46 
ты явно ничего не знаешь о высокопроизводительном коде
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

24. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (23), 07-Май-24, 11:30 
Пожалуйста, покажите пример хорошего кода на С. В целом, у вас есть в наличии свой открытый код?
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

36. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –1 +/
Сообщение от Прадед (?), 07-Май-24, 12:35 
https://gitlab.gnome.org/Archive/cogl/-/blob/cogl-1.22/cogl/...

В принципе любое на джилибе. А так же Кайро.

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

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

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

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

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

55. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от тыквенное латте (?), 07-Май-24, 14:08 
*bsd, suckless, gnu (в зависимости).
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

62. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Прадед (?), 07-Май-24, 14:43 
Две папайи данному джентельмену

https://git.suckless.org/dwm/file/dwm.c.html#l246

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

66. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от тыквенное латте (?), 07-Май-24, 14:57 
чшорт, а я всегда фигачил if/else if/else, дублируя код по всем функциям, и наворачивая спагетти.
а как надо было?
Ответить | Правка | Наверх | Cообщить модератору

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

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

163. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от тыквенное латте (?), 08-Май-24, 09:35 
> Люди так привыкли к ненависти..

далеки мы стали от гос pad'a. ой далеки.

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

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

    296         if ((!r->title || strstr(c->name, r->title))
    297         && (!r->class || strstr(class, r->class))
    298         && (!r->instance || strstr(instance, r->instance)))
    299         {

Лучше бы так
    296         if ((!r->title || strstr(c->name, r->title)) &&
    297             (!r->class || strstr(class, r->class)) &&
    298             (!r->instance || strstr(instance, r->instance))) {

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

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

146. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan_83 (ok), 08-Май-24, 03:20 
Вы думаете о красивых диффах, а я об удобстве чтения.
У меня оно выровнено и похоже на табличку, где чётко видна логика, повторяющаяся.
Ответить | Правка | Наверх | Cообщить модератору

161. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от тыквенное латте (?), 08-Май-24, 09:30 
> Вы думаете о красивых диффах, а я об удобстве чтения.
> У меня оно выровнено и похоже на табличку, где чётко видна логика,
> повторяющаяся.

вопрос выравнивания:


296         if ((!r->title    || strstr(c->name,  r->title))
297          && (!r->class    || strstr(class,    r->class))
298          && (!r->instance || strstr(instance, r->instance)))
299         {

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

172. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (172), 08-Май-24, 12:45 
Вот у тебя как раз логику увидеть сложнее. Перепиши, например, свой вариант для менее тривиальной  структуры и с условиями разной длины. В варианте с префиксными операндами достаточно прочитать начало всех строк чтобы примерно понять структуру, в твоём же нужно читать абсолютно всё потому что суфикснрые операнды хрен знает где расположены
Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

140. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (172), 08-Май-24, 01:41 
Так точно не лучше, единственный правильный вариант форматирования это с префиксными логическими операциями. Если немного подумаешь кочерышкой, то мб поймёшь, что твой вариант читать менее удобно.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

147. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan_83 (ok), 08-Май-24, 03:24 
Удобнее - это субъективно.
У меня чётко видна периодическая структура кода, а с префиксами для этого потребуется двигать первую строку кучей пробелов, что с точки зрения текста убого.

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

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

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

164. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от n00by (ok), 08-Май-24, 11:11 
Это не для дифов, а для простоты чтения. Когда не форматируют ради "78 символов в строке", то && не видно.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

91. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/
Сообщение от Bottle (?), 07-Май-24, 18:21 
FTEQW - source-port движка Quake.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

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

27. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Аноним (27), 07-Май-24, 11:46 
> Посмотрел код, пример типичного овнокода.

Да? Где?

> Или медленное или быстрое забвение как только уйдет кор девелопер

Там код настолько маленький и простой.

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

56. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Аноним (56), 07-Май-24, 14:16 
Вот всегда лично надо проверять такие утверждения - залез, посмотрел - код аккуратный, ясно написан, с подробными по делу комментариями. И сложилось такое мнение, что онокодер тут только ты, мальтшик - иди уроки делай.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

61. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/
Сообщение от Ivan7 (ok), 07-Май-24, 14:40 
Нормальный там код, понятный, ясный и с комментариями, которые абсолютно по делу. Так что не трынди!
Кому что-то непонятно, пусть развиваются и улучшают свою квалификацию.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

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

А потом удивляются откуда берутся enterprise hello worlds на 6 гигов исходников.

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

110. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (5), 07-Май-24, 20:39 
В Энтерпрайза платят и вовсе за количество строк или ещё худший кипиай. Но зато все понятно и решаемо поменяй разраба и он доделает работу на изи какой бы сложной она не была.
Ответить | Правка | Наверх | Cообщить модератору

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

19. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +3 +/
Сообщение от Аноним (19), 07-Май-24, 11:13 
Живешь ты допустим в 3042 годе и решил вспомнить молодость, погаматься в игры твоих предков, а OpenGL давно уже выпилили отовсюду, везде голограммы, нейроинтерфейсы, телепорты мать их за ногу. Вот на помощь твоему процу с 100тыс. ядер и придет PortableGL
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

25. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (25), 07-Май-24, 11:36 
Вот бы на FreeDOS его портировали.
Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan7 (ok), 07-Май-24, 15:14 
Так никто и не запрещает использовать его на FreeDOS или даже вообще без ОС.
Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (34), 07-Май-24, 12:28 
>как переносимость, соответствие API OpenGL, простота использования, простой код и высокая производительность

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

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

43. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (43), 07-Май-24, 13:00 
Поясните, зачем это нужно, если есть https://docs.mesa3d.org/drivers/llvmpipe.html ? На крайняк можно было откопать softpipe, swrast и osmesa.
Ответить | Правка | Наверх | Cообщить модератору

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

86. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от X512 (?), 07-Май-24, 17:32 
Например чтобы не тащить жирную libllvm в зависимостях.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

90. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (90), 07-Май-24, 17:50 
libllvm есть в каждой системе на основе Linux, Windows и BSD, она основной компонент графических драйверов и рантаймов с JIT, и избавиться от неё невозможно. В своих разработках я не использую LLVM исключительно потому, что она настолько монструозная, монолитная и постоянно меняющаяся, что нормальной короткой документации "делаем полезные фронтенд, бэкенд, JIT, оптимизатор и линкер за 100 строк каждый", которая ожидается от подобных вещей, тут просто не существует. Даже самостоятельно её компилировать - это долго и не каждая машина потянет, а бэкенды вообще там все внутри, отдельно от неё не живут. Микроконтроллеры же, которые libllvm не тянут, рендеринг 3D-графики с помощью OpenGL не потянут и подавно. Я конечно против дропа софтовых растризаторов без LLVM, но будем реалистичными - кому был нужен OpenGL - тот мог откопать их, привести в соответствие с кодовой базой Mesa, и поддерживать в рабочем состоянии, и получил бы результат гораздо лучше, чем указанная поделка.
Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Аноним (105), 07-Май-24, 19:54 
>libllvm есть в каждой системе на основе Linux

Здесь ты погорячился. Если у тебя не самая распоследняя видяха и ОС, в которой что-то можно изменить по своему усмотрению, то ты ещё можешь пока сидеть на на mesa-21 (подправив .ebuild) или mesa-amber. И можешь обходиться без LLVM'ов в системе.

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

119. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (119), 07-Май-24, 21:52 
Зачем обходится без LLVM, если штатный оригинальный проприетарный драйвер для этой видяхи под винду был сделан на основе LLVM?
Ответить | Правка | Наверх | Cообщить модератору

120. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (119), 07-Май-24, 21:53 
P.S. Видяха больше чем на 10 лет устарела.
Ответить | Правка | Наверх | Cообщить модератору

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

137. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (137), 08-Май-24, 00:15 
А какое же мне должно быть дело до что там в Винде?
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

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

179. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (179), 08-Май-24, 14:40 
А с чего вы решили, что я вообще в Винде сижу? Ясно же написал, что использую Mesa. Это не про Винду.
Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от nox. (?), 07-Май-24, 13:14 
> Код оформлен в виде одного заголовочного файла

Нет.

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

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

95. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan7 (ok), 07-Май-24, 19:04 
> Нет.

Не нет, а да! См. README.md:

in clean C99 as a single header library (in the style of the stb libraries)

и portablegl.h:

Do this:
    #define PORTABLEGL_IMPLEMENTATION
before you include this file in *one* C or C++ file to create the implementation.

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

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

52. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +1 +/
Сообщение от Ivan7 (ok), 07-Май-24, 13:42 
Есть инструкции по компиляции в разделе Building:
...
On Windows you can grab the zip you want from the same releases page linked above.
...
I have used these same Makefiles to build under MSYS2 on Windows.
...
Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от n00by (ok), 07-Май-24, 14:33 
Зачем для header-only библиотеки под MIT бинарник для win64?
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

48. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (48), 07-Май-24, 13:24 
https://www.opennet.ru/opennews/art.shtml?num=54337
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  –3 +/
Сообщение от Анонимemail (47), 07-Май-24, 13:28 
это не то. это mesa бинарники которой на гитхубе в наличае всегда. речь идет о том, что раз этот проект делают, то должны выкладывать готовые сборки под самую популярную систему на земле. а не под насваем,- бери и делай все сам.
Ответить | Правка | Наверх | Cообщить модератору

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

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ообщить модератору

63. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/
Сообщение от Ivan7 (ok), 07-Май-24, 14:54 
Плохо, что геометрические шейдеры не реализованы. Без них трудновато обходиться. Можно, конечно, рассчитывать вершины самостоятельно, не используя вершинный и геометрический шейдеры, но тогда это уже будет более старый OpenGL.
Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (68), 07-Май-24, 15:07 
> написанную целиком на языке Си

github.com/rswinkle/PortableGL
Languages:
C 80.7%
C++ 18.5%

Кто-то немного призвездел..

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

76. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (76), 07-Май-24, 16:20 
В репозитории есть несколько демонстраций на c++. Сам код библиотеки на чистом C.
Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (82), 07-Май-24, 16:27 
Кто-то немного трепло.

.cpp там в тестах, демках и примерах.
И GLM ещё в папке external/, который тоже на cpp.

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

80. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +2 +/
Сообщение от Анонус (?), 07-Май-24, 16:30 
Чем лучше https://github.com/C-Chads/tinygl ?
Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от X512 (?), 07-Май-24, 17:35 
> Rather than write or include a GLSL parser and have a built in compiler or interpreter, shaders are special C functions that match a specific prototype.

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

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

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

98. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (105), 07-Май-24, 19:31 
Тут говорят, будет медленно. Я вот что подумал, прочитав новость про GCC 14. Есть там пунктик такой "В бэкенде генерации кода для GPU AMD Radeon (GCN) реализована поддержка GPU AMD Radeon gfx90c (GCN5), gfx1030, gfx1036 (RDNA2), gfx1100 и gfx1103 (RDNA3). Повышена производительность для устройств AMD серий MI100 и MI200. По умолчанию активирована архитектура устройств gfx900 (Vega)."
В связи с тем, что Mеsa свернула куда-то не туда, стала шланго-ллвмом обмазываться. Скомпилять PortableGL под CGN и... может быть, тогда Mesa вообще ненужна?
Ответить | Правка | Наверх | Cообщить модератору

150. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan7 (ok), 08-Май-24, 04:11 
Как минимум в Mesa3D llvmpipe реализация OpenGL намного более полная вплоть до поддержки OpenGL 4.6, а PortableGL в лучшем случае обрезок от OpenGL 3.2, причём поддерживаются только вершинные и фрагментные шейдеры, и их придётся переписывать на С.
Ответить | Правка | Наверх | Cообщить модератору

177. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Аноним (179), 08-Май-24, 13:43 
1. Есть шанс скомпилировать PortableGL в машинные коды GCN и исполнять непосредственно на GPU. А этот ваш llvmpipe предназначен для исполнения на CPU.
2. Если этого обрезка окажется достаточно, чтобы отрисовывать окошки на рабочем столе, заметим, аппаратно ускоренно, то уже хорошо. Т.е., по сути, аппаратное 2D. Комуто-то этого может быть достаточно. Мне, например.
3. Сегодня там не всё поддерживается, понятно, проекту только год. Позже добавят ещё.
4. Оно и так на C. Зачем переписывать с C на C?
Ответить | Правка | Наверх | Cообщить модератору

188. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Ivan7 (ok), 09-Май-24, 01:53 
> 1. Есть шанс скомпилировать PortableGL в машинные коды GCN и исполнять непосредственно на GPU.

Зачем? У AMD нет драйверов OpenGL? Я просто не в курсе - у меня NVIDIA.

> 4. Оно и так на C. Зачем переписывать с C на C?

Шейдеры OpenGL на GLSL, а не на C.

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

100. "Выпуск PortableGL 0.98, реализации OpenGL 3 на языке Си "  +/
Сообщение от Skullnetemail (ok), 07-Май-24, 19:33 
Так оно не делает libGl чтобы можно было его загрузить?
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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