Для каждой задачи есть свой наиболее подходящий инструмент.

И этот инструмент - С!

Язык понятный, элегантный, не содержит чрезмерных наворотов. В общем, эдакая надстройка над ассемблером, где никто не запрещает и на совсем низком уровне писать. И главное - никто не запрещает выстрелить себе в ногу!!! Это очень важно.

В идеале хочется, чтобы шейдер принимал от меня 3-4 флоата, а дальше сам все отрисовывал. OpenGL 4.2.

чтобы он дальше сам все отрисовывал, шейдер сначала надо написать. это вполне реально. и через geometry shaders, и через fragment shaders.

вот например фрагмент-шейдер, рисующий простую сферу:

https://www.shadertoy.com/view/MdXSD8

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

но вообще рисовать сетку в фрагмент-шейдерах неудобно и медленно. рисовать линиями эффективнее.

а так вообще шейдерами можно много чего нарисовать, при большом желании ;)

типа такого http://www.iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm

у него там и библиотека шейдеров есть, для разных примитивов: https://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm

никто не запрещает и на совсем низком уровне писать

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

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

Есть: пишешь сниппеты, функции; используешь библиотеки - вот тебе и высокий уровень.

Из compute шейдера можно генерировать вызовы на отрисовку вообще.

Правда пишут что они тормозят.

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

Пробовал однажды (лет 8 назад, может быть не совсем релевантно :) рисовать геометрическим шейдером сферу из одного полигона. Рисует, но квадратно (из-за лимита) и медленно. Быстрее загнать миллион полигонов через VBO. Можно даже полигоны те сделать прямоугольной равномерной сеткой, а в вершинном шейдере натянуть сову на глобус сетку на сферу — это относительно дёшево.

Двигать надо мир. Всегда. Можно обмазать камеру сахаром и двигать камеру, двигая мир, поэтому ООП рулит в игорях.

А так, выглядит правильный Hello World.

SDL2 это если именно для

покажи примеры сишных высокоуровневых библиотек для опенгля

Мега говнистая библиотека! И никаких «шейдеров» она не использует. Тогда уж лучше по-старинке: с GLUT'ом. Хотя бы не будет приложение лишний десяток МБ оперативы отжирать!

Ну, а если учесть, что SDL еще и с alsa работает, то рекомендовать эту библиотеку в качестве «высокоуровневой opengl» может только тот, кто вообще не в теме!

Эдик, остынь.

Есть: пишешь сниппеты, функции; используешь библиотеки - вот тебе и высокий уровень.

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

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

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

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

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

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

Вопрос вовсе не в какой-то высокоуровневости или абстракции с удобными ограничениями, а в банальной мотивации написания кода. Если тебе херак-херак и в продакшен, и чтобы если что-то пойдёт не так, то можно было бы свалить всё на автора вон того класса/шаблона/etc. то, очевидно, куча пахучего синтаксического «сахара» над ассемблером под названием цепепе - это как раз то что надо. Всегда найдётся высокоуровневая абстракция, из которой можно быстренько слепить то, что можно впарить заказчику не разбираясь в том, что под капотом. Но если тебе надо знать и реально понимать как всё на самом деле работает от начала и до конца - то современный цепепе совсем не то, что нужно. Увы, лучше сишечки пока ничего не придумали. Где-то в стороне, конечно, стоит с умным видом лисп со всеми его разновидностями, но его никто не любит.

Ну то есть ты насмотрелся говнокода и теперь утверждаешь что весь код - говно?

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

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

Ну то есть ты насмотрелся говнокода и теперь утверждаешь что весь код - говно?

Ну так количество неговнокода на цепепе не внушает. Неговнокод на цепепе вообще существует? «Вот бы посмотреть...» (С) Fifth Element.

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

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

Практика показывает что это далеко не всегда что-то нужное и правильное.

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

Выдавать «высокоуровневость» за априори полезную фичу - как минимум опрометчиво. Кто вообще сказал, что высокоуровневость полезна без ограничений? Это же полная херня. Высокоуровневость хороша ровно до тех пор, пока от неё проблем гораздо меньше чем пользы. В какой-то момент высокоуровневость становится весьма существенным недостатком.

От высокоуровневости на самом деле страдает очень многое - от эффективности до ремонтопригодности.

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

Херь полную несешь. «Под капотом» везде будет тонна машкода. Только в случае с С этот машкод имеет нормально выраженное отображение, а в случае с говноЯПами один Аллах знает, что там...

Ну так количество неговнокода на цепепе не внушает. Неговнокод на цепепе вообще существует? «Вот бы посмотреть...» (С) Fifth Element.

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

Практика показывает что это далеко не всегда что-то нужное и правильное.

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

С этим согласен полностью. Но это ортогонально к моему утверждению.

Выдавать «высокоуровневость» за априори полезную фичу - как минимум опрометчиво. Кто вообще сказал, что высокоуровневость полезна без ограничений? Это же полная херня. Высокоуровневость хороша ровно до тех пор, пока от неё проблем гораздо меньше чем пользы. В какой-то момент высокоуровневость становится весьма существенным недостатком.

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

От высокоуровневости на самом деле страдает очень многое - от эффективности до ремонтопригодности.

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

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

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

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

Херь полную несешь. «Под капотом» везде будет тонна машкода. Только в случае с С этот машкод имеет нормально выраженное отображение, а в случае с говноЯПами один Аллах знает, что там...

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

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

От высокоуровневости ничего не страдает, а если страдает то это кривая реализация.

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

Зато профит в том, что повышается продуктивность.

И опять о том же самом. Продуктивность вообще никак не связана с качеством и пользой. Что толку в продуктивности, если производится говно?

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

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

Это ты лучше не позорься!

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

А если сам какой-то алгоритм реализуешь, то использовать нужно такой ЯП, где ты не запутаешься в коде. И это — С!

Кстати, некоторые вещи на крестах будут выглядеть совсем уж уродливо, либо придется писать на С внутри крестовых исходников. Пример — конечный автомат. От гигантской портянки со switch/case никуда не денешься!

але анонимус, у тебя С++ девушку увел, или у тебя стояк на него?

уперся в С++ как баран

в 2018 существует тонна нормальных языков начиная с Java

С и С++ очень узко применимы

Ну и что, что тонна ЯП? Из всей этой тонны только С — нормальный!

Пройдет еще 50 лет, и большая часть этих говноЯП канут в Лету. А С останется!

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

This.

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

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

И где это в процессорах хоть какой-нибудь архитектуры нашлись всякие объекты, инкапсуляции с наследованиями и полиморфизмами т.д.? С какого перепугу бритва Оккама перестала работать применительно к языкам программирования?

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

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

Вот еще раз про фильтр Калмана. Его реализация на плюсах практически близка к предметной области, то бишь матричной алгебре на 100%. Математику, далекому от программирования покажи этот код и ему будет понятно, он даже код сможет поправить если ошибка в формуле. Вот фундаментальная матрица, вот матрица шумов процесса и т.д. А сишная реализация математику не даст ничего ибо набор функций и нужно понимать что за аргументы туда передаются, как они в памяти представлены и так далее. И математик сишный код не поправит от слова совсем.

Сишечка близка к машине, но не так близка к человеческому языку как хотелось бы. Вся же нынешняя ООПщина вообще одинаково далека как от машины, так и от человека.

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

И математик сишный код не поправит от слова совсем.

Вот не надо врать! Можно код на крестах так написать, что никто его не поймет. А можно и на С написать нормально!!!

си близок к машине, а от человека далек

Да ладно!

Вот не надо врать! Можно код на крестах так написать, что никто его не поймет. А можно и на С написать нормально!!!

Ты адекватный нет? Вот только честно? Про то что ерунду писать можно хоть на чем, зачем об этом говорить? Это же очевидно даже ребенку. А теперь еще раз - на плюсах (и на любом другом высокоуровневом языке) ты можешь написать:

Y = F * H + B;

Весь мир тебе будет благодарен.

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

хорошо, что в сишечке этого нет. пусть те, кому это надо, пишут на DSLях, специально для этого предназначенных (типа шейдеров)

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

Прямо как тут:

Известны 10 преимуществ Паскаля перед Си:)
Я приведу только одно, но самое важное.
На Си вы можете написать:

for(;P("\n").R--;P("\ "))for(e=0x3DC;e--;P("_ "+(*u++/8)%2))P("| "+ (*u/4)%2);

На Паскале Вы не можете такого написать.

Предлагаю осознать простой факт: «На Си++ сложнее выстрелить в ногу. Но если получится, ногу отрывает целиком.» И это одна из основных причин, по которой любители Си любят Си. Он простой и примитивный. Если ты видишь там +, это сложение. Не оператор, который может скрывать что угодно, а именно сложение. Всегда.

Ох, ну и конь же ты!

Ну и чем принципиально запись Y = F * H + B; будет отличаться от Y=sum(dotprod(F,H),B);?

Те же яйца!

Ты адекватный нет?

Ты русский нет?

Какой же ты тупой... Это просто кошмар! Перегрузка крестовых операторов - это проблема, а не достоинство! Вот как мне понять: звездочка у тебя это матричное или скалярное умножение?

В документации к классу, к которому применяешь оператор открываешь member functions и смотришь на наличие operator*. Если не находишь, то либо тут не используется перегрузка, либо шлёшь автора библиотеки куда подальше.

Ну и чем принципиально запись Y = F * H + B; будет отличаться от Y=sum(dotprod(F,H),B);?

Тем, что первая запись более читабельная, а второй место в этом твоём лишпе.

Может так: matrix_sum(Y, dotprod(tmp_matr, F,H), B); - меньше malloc-ов.

В документации к классу

которой нет!

И ковыряйся по гребаным исходникам. В C же все прозрачно.

Все равно твоя сишечка в скором времени покроется ржавчиной. Чому б и не глянуть? Ооп там примитивен и не обязателен. Та же сишка, но с RAII искаропки. Правда там UTF-8, но ты без проблем можешь запилить свои строки на кои8.

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

хорошо, что в сишечке этого нет. пусть те, кому это надо, пишут на DSLях, специально для этого предназначенных (типа шейдеров)

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

Ну и чем принципиально запись Y = F * H + B; будет отличаться от Y=sum(dotprod(F,H),B);

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

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

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

А почему интерес к openGl, а не к Vulkan или Metal?

Какой же ты тупой...

Я так понимаю, что у тебя это самый веский аргумент в споре?))

Перегрузка крестовых операторов - это проблема, а не достоинство!

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

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

Согласен на 100%. Мне тоже нравится С своей простотой. Но это же не позволяет мне его использовать для сложных вещей, к сожалению.

Ты просто не пробовал. На С можно написать все, что угодно!

Уж сложней ядра-то вряд ли что можно придумать!

Уж сложней ядра-то вряд ли что можно придумать!

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

Это категоричность молодого и неопытного

Это Эдик, спившийся 40-летний астроном. На лоре вообще с астрономами беда — вилфред на ацетон подсел и сторчался, Эдичка самогонкой спился.

Это Эдик, спившийся 40-летний астроном. На лоре вообще с астрономами беда — вилфред на ацетон подсел и сторчался, Эдичка самогонкой спился.

Я понимаю, что лор это часто (может даже слишком) треш и угар, но как его можно не любить за такое?))

Он уже допился до кирдыка с сердцем, так что, теперь не пьет.

Бедный Эдик.