The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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

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

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




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

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