Russian Qt Forum

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

Повторюсь, для упоротых - ЭТО говорилка, это НИ О ЧЕМ. ЭТО НЕ РУКОВОДСТВО К ДЕЙСТВИЮ. ЭТО ПРОСТО ЖЕЛАНИЕ ЧЕЛОВЕКА ПОГОВОРИТЬ.

Зная на практике историю развития Qt, не вызывает никакого сомнения, что они (создатели Qt) пошли правильным путем в своё время: создали для многих платформ независимый API, к примеру на уровне контейнеров. Но время "застоя" C++ прошло, и начиная с C++11 начал меняться и стиль программирование и подход к программированию (я про С++ независимо от boost).

И так, собственно, что напрягает:

1. QString. Отличный класс, когда его используешь внутри фреймворка. Как только выход на API ОС, одни преобразования. Да. Если вы посмотрите исходники QString он отличен - там и SSE2 и все прочее. Но std::string круче, когда нужна производительность - есть поддержка малых строк. Не заметил её в QString. Ну и конечно + у QString - плевать как бы на компилятор, QtCore обеспечивает совместимость библиотек.

2. Несовместимость int. Qt - int, std - uint (std::size_t). Понятно, что никакая модель памяти на x86(x64) не поддержит uint по контейнерам. uint - никогда не выйдете за пределы int. Ембедщики по этому поводу не парятся, т.к. они знают свои камни и точно знают что хотят, Qt там не пахнет. Но придушить статический анализ не хочется, а static_cast задолбал

3. Сами по себе контейнеры продвинутей в std - к примеру. Ей богу, не хочу пример, чтобы срача не было.

Имхо, тут конфликт универсальности (поддержка полного набора Unicode) vs оптимальности по памяти/быстродействию. Для интернационализации нужна поддержка Unicode, для конфигов/данных может быть достаточно ASCII. Так что я сомневаюсь, что удастся избежать конвертации строк. Грубо говоря, как сейчас std::wstring <-> std::string.

Тут немного не понял. Аналог std::string в Qt это QByteArray ну и конфликта std::wstring <-> std::string я не вижу. Всегда есть восприятие где ASCII, где вайд. Плевать на вайд, когда вы пишите ГУИ - вывод строки в формочке ни на что не влияет, там можно жертвовать чем угодно. Но к   примеру - вы хотите написать компилятор c++. Более чем уверен, парсер будет ASCII. Ну а комменты. А комменты компилятору не нужны, он их пропускает. Тут вопрос не в том, что вы вскормите компилятору wide, и он поймет. Внутренняя архитектура будет устроена так, что будет однобайтовые строки хавать.

Извиняюсь. Много лирики. Я  не говорю, что что-то плохо и что-то хорошо.
Спрошу по другому: а не перейти ли Qt на контейнеры и строки std?

Ну ладно. Строки еще под вопросом, но остальное может спокойно кочевать в новую ветку Qt - начиная от контейнеров, заканчивая мнопоточностью.

По-моему, вы гипертрофируете проблему.. Я понимаю, если это было bottleneck место в коде.. Ну т.е. оно того стоит? Ну я, просто не в курсе..

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

Но пройдёт лет 5-7 и она уже не будет такой гипертрофированной. Те же 5-7 лет назад у меня не стоял вопрос: какой контейнер использовать, Qt или std. Сейчас все изменилось.

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

Моя главная проблема с Qt контейнерами - что мой отладчик не показывает их содержимое :'( Аргументы в пользу std мне кажутся весьма неубедительными. Ну тот же QString - да по удобству использования std::string и рядом не стояло. Да бог с ним, с уникодом, попробуйте написать неск простых ф-ций-утилиток - и Вы сразу ощутите что нужных, удобных ф-ций под рукой нет, придется постоянно лезть в итераторную мудистику.

Или QList. Слышал мнение что, мол, теперь, когда есть крутой move (все чего-то "мувят") QList уже ничего не дает, только оверхед. Позвольте, а как хранить неперемещаемые данные? Насколько мне известно, какой-то "официальной" альтернативы в std нет, придется использовать вектор указателей. Это далеко не так удобно, хотя, справедливости ради, и предоставляет больше возможностей

Я к тому, что вряд ли будет один класс строки, который удовлетворит все потребности, поэтому конвертаций (std::wstring <-> std::string) не избежать. И тут может уже не так важно будет, переводить std::string в std::wstring или в QString. Конечно, чем меньше зоопарк - тем лучше, но, в то же время, не в ущерб функциональности и оптимальности.

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



Вообще не понял. Т.е. смысл понятен, но интерпретаций с моей стороны куча.
Давайте уберем свистелки - перделки, которые мы засовываем в контейнеры - аля чето-там с гуи или свои пару значений. Мы ими пользуемся (контейнерами) по удобству (в данном случае), а не по функционалу. Ну если мне удобней map использовать для своих пару значений, чего я буду выслушивать крики что: "вектор или лист быстрее будет". Да это вообще не имеет значение.

Итак, свистелки откинули, более "большие" массивы - т.е. алгоритмы.
И тут мы приходим к следующему - те, кто пишет реальные алгоритмы они пытаются сделать структуры данных как раз не перемещаемые - т.е. нету там указателя на внутренние данные, яркий пример std::string, где большинство строк влазит во внутреннюю структуру. Ведь вызов new/delete мало того, что требует ресурсов, так ещё и располагает данные неизвестно где в памяти, а не рядом.

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

Но,  конечно, это накладывает ограничения: данные живут в векторе, он их владелец. НО! на то они и алгоритмы, чтобы работать с массивами данных, а получать оттуда ссылки.

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

<boost/algorithm/string.hpp> перекрывает QString

Никого не "топлю"  :), просто говорю что мне QString куда удобнее. Ну хотя бы нужно "обрезать" альфа-символы в начале и конце строки. Это не так уж просто с std::string. Поиск, замена и многое другое в QString намного лучше, просто больше полезных вещей (ну или "плюшек"). А не хотите плодить строки (всякий раз выделять память) - есть отличный класс QStringRef

Даже если бы и так - о том что std::string он "тем более перекрывает" Вы конечно благоразумно умолчали  :)

Достоинства вектора никто не умаляет, он самый популярный контейнер, и в любом проекте обязательно найдутся данные для него, рискну даже утверждать что их будет большинство. НО, помещая туда данные, мы соглашаемся с их "перемещаемостью", т.е. в общем случае адрес эл-та вектора хранить нельзя. Приходится хранить индекс, но он, в отличие от указателя, "не самодостаточен". А если еще есть вставки/удаления - то индекс вообще не годится. Короче, если данные - "хорошие" структуры, на которые ссылаются другие, то вектор не годится, тогда где их хранить? Иногда в мапе/хеше, но не всегда. Вот и выплывает идея QList, по-моему вполне разумная. Конечно можно спорить что "перемещаемо" а что нет - но сути это не меняет

Вы бы хоть смотрели, что вам предлагают. :)
boost/algorithm/string.hpp это алгоритмы для std::string.

Только вроде беду с const решили, а тут новая напасть... негде хранить "хорошие" структуры. Жесть. :)

Та вообще, вообще это не имеет никакого значения.
О чем мы говорим - то, что указатель теряется в векторе?
Да ребят, у нас нет алгоритмов, которые съедают куча производительности.
Вектор с миллионами записей не гуляет по программе, он спрятан. И когда вещь заходит о производительности....
О чём говорим.... Раз мы пишем на плюсах, мы автоматом пишет ++i вместо i++. Да, это хорошо, раз мы такие, но это ничего не значит.
Да, это хорошо, когда мы стараемся (плюсы обязывают) писать наиболее производительный код, даже жопой понимая, что в конкретном случае это не важно.

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

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

В qt6 будет SSO. Так-то негоже ломать совместимость каждые полгода, а SSO требует нарушения BC. Почему в Qt5 не добавили, отдельный вопрос, но патч уже вроде бы тогда был.

О чем Вы - не знаю, а я да, об этом. Неперемещаемые данные (указатели на которые хранятся в др классах) неизбежны, и это ситуация типовая. QList решает эту проблему - и это хорошо

Кхе. Извиняюсь, если не корректно выразился.
Смысл моего посыла был таков: когда вы работаете с большим массивом данных, указатель на конкретный элемент не имеет значение.
Я понимаю, что: не говори мне как делать, и я не скажу тебе куда идти.
А почему? (не имеет значение указатель). Когда идет работа с большим массивом данных, встают другие проблемы (производительности) и такие мелочи, как  потеря указателя теряет свою актуальность и её обходят. Но почему вот вам нужен один указатель на один элемент среди миллионов.

Пример из моей практики. Вот 3D модель имеет вертексы и фейсы. Ну разумеется они хранятся в векторах, эти данные могут быть сколь угодно велики. Пусть немногие но есть фичи которые используют индексы вертексов (напр skin или morph) или фейсов (напр фейс материал). Если "топология" изменилась (произошла вставка/удаление) то либо "ой" - ссылающийся стал невалидным, либо городить немалый remap (тот еще гемор). Поэтому "размер имеет значение". Но даже несмотря на это используются вектора, др контейнеры обойдутся слишком дорого.

Но вот хранить сами модели в векторе и бегать потом с индексами - это уже полная глупость. Хотя их тоже может быть достаточно много. Вот Вам простой пример перемещаемых/неперемещаемых данных.

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

В продолжении про контейнеры - почему простое добавление QMap<QString, QString> в класс увеличивает итоговый размер на ~17кб ?

А что такое SSO? (вику глядел но там явно не то). Спасибо

По поводу производительности - как говорится, "чисто не там где убирают..". Если напр юзается  "удобный" QString::split, то производительности не будет при любых поддержках. То же и с новомодным "мувом" - сначала нагадят передавая по значению, а потом хотят мувом вытереть.

И вообше ход мысли порочный, типа "там есть такая-то фишка (малые строки) - ну значит там круче". Да мало ли где чего есть? Чего оно Вас так волнует? Вот не могу жить без малых строк - и все тут! Гнаться за модой свойственно женщинам

А короткие строки там до какой длины планируются?

Сколько влезет:) афаик, 4 указателя делить на 16 бит минус сколько-то инфо под флаг «ссо или нет», возможно минус 1 указатель (пока размер)

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

Я понял, вы решили добавить "перчика".

А с чего бы это мне не нужны малые строки, если я пишу парсер. Вот уж извините, производительность парсера это как раз и его фишка. Так что не могу жить без малых строк - и все тут! Тем более, никто их к модным фишкам не приписывает, т.к. особо и не знают. Да и не видно эту моду. Ну как можно показать код и сказать - тут у меня модные короткие строки. А тебе так хрясь по башке: ТЫ КАК std::string то назвал!

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

Какая мода. Написать и забыть - вот моя мода.

А вы такой - мув? Да вы че, салабоны, а ну копировать! Лямбды им б..... подавай.
Да и какой к черту мув это фишка. Обычный COW с обменом, просто рассказанный всем так, чтобы вообще никто ничего не понял и думали что это магия.
 
И про крутые фишки: да их столько крутых, что никто на C++ за ними не гонится, просто изучать приходиться, что, конечно, свойственно женщинам.

Так "если" или "пишу"? В этом все дело  :)

Думаю малые строки никак не связаны с производительностью парсера. Конечно каких-то компиляторов я не писал, но распарсить тестовик раз в 1-2 года приходится. И этого опыта достаточно чтобы утверждать - парсер не должен создавать новых строк вообще. Ни больших, ни малых. Он должен оперировать только со ссылками на (неизменную) исходную строку/текст.

Да неужели? :) Посмотрите с каким вожделением лепится что-то типа std::bind, forward, decltype и.т.п. (в том числе и на этом форуме). Текст без этого не катит - ну это же просто "С с классами". А когда разберешься со всеми этими прибамбасами - выясняется что "содержательная часть" близка к нулю :'( Человека можно понять - он ведь "выучил", значит "надо применить" (не зря же учил). Но объективно это пижонство чистой воды :)

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

Пижонство - это нифига не зная, гордо заявлять, что это хорошо и правильно. Попытки оправдать глупость выглядят очень жалко. :)

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


Ну, буду отвечать в вашем стиле. Думаете или знаете?
Парсер не создает новых строк только в одном случае - если вы пишите самостоятельную работу ну или там банер погодки распарсиваете (на плюсах????).
Да хотя бы ключевые слова там хранятся. Или другой вариант, компилируете вы программуленку, тут у вас куча ошибок, вы файл закрыли в иде и О ЧУДО, все ошибки исчезли..... Не, внутри много оптимизаций со stringView. Но вот в чем засада. Да даже Токен с короткой строкой, короче (по ресурсам), чем токен с позицией и длиной строки да и ещё и с самим указателем на исходник строки да ещё и с контролем что исходник строки жив.


Ну вот я не представляю эту ситуацию. Сидит чел, кодит. И вы подсматриваете за ним. И тут видите вожделение на его лице. Глядь в экран, а он, в этот момент набирает std::bind, forward, и, что хуже - decltype! (хотя по мне самый противный std::bind).

Ну чтож. Пусть мы с вами не правы и никогда не сойдёмся.
Что делаем - отрываем исходники stl  - и понимаем, писали его одни вожделенцы!

От подонки. Ещё и в комитете сидят. Гнобят память дедов наших! А не, стоп. Просто гнобят дедов. Тоже не то. Во! Гнобят нас.

Не, мысль можно вашу понять.
Ну вот не знаю я ваш std::bind. Да, могу написать, поковырявшись, но так лениво, вот смотрите, я уже алгоритм набросал рабочий, пока вы там биндингом с форвардингом занимались. А у вас что? Вот оно, работает! Но отставание все же будет расти, и в какой то момент времени, если не набить руку с этой всей трахамурдией, вы начнете много времени тратить "не на то". Я вот тоже никогда (и сейчас тоже) не мог запомнить синтаксис указателя на функцию (чтобы самому накалякать). В конце концов с этим смирился и подсматриваю его в инете. Но уж если у меня таких вещей будет половина.....

Ну и ещё + использование новомодних плюшек сразу: Вы на них руку набиваете и знаете уже. Если же просто понял и не набил руку, приходится все заново проходить и код уже не "вылетает из под пальцев" и не так быстро воспринимается.

Диды на фортране писали! Помню, в 45м под берлином...


Вариант с тайпдефом\использованием на месте я тоже не могу запомнить, но можно подложить соломки

Я пошерстил рассылку и уже не так уверен, что SSO гарантированно будет.
В любом случае, они где-то писали, что "640к хватит всем", т.е. большинство строк таки влезут.
Энивей, если SSO будет в QString, то и в батарей (или точнее 8битную строку, вроде бы хотят отпилить батарей отдельно) должны завести, а там можно будет юзать 8битную кодировку.
Но там столько планов, что хз, когда и что из этого они сделают в итоге.

А эта 8-ми битная строка не будет той же std::string, только в профиль? :) В std строк полно (https://en.cppreference.com/w/cpp/string), выше писали, что в бусте алгоритмов для строк наделали, в ICU вроде наработок хватает. Пора бы уже унифицировать это зоопарк, а не ещё зверушек плодить :).

Да, получится что-то типа зоопарка строк в std::
Нужно (минимум)
Utf8String
Utf16String
ByteArray aka std::vector<std::byte> возможно с простыми строковыми операциями (типа replace но без toUpper/toLower/toInt)

Возможно, нужен отдельный быстрый Latin1String.
Ибо щаз есть проблемы.
Батарей не использует std::byte и теперь его название мягко скажем неудачное для всех, кто не пишет на Qt.
Батарей может содержать любые строки (привет, std::string), но обычно содержит utf8 (привет, std::string). Но toLower/toUpper почему-то работают только для latin1. w00t?

string, wstring, utf32 офк не нужны - первое это тот же вектор байтов, второй имеет разный размер на разных платформах и не переносим, третий нигде не используется.

Да елки палки, тут стандартизированого синтаксиса хватает, а тут ещё и дополнительный сленг.
Какие батареи? Шланги и т.д. Мне мозги ещё тут нужно выносить и искать с умным видом, типа я знаю, что такое ваши батареи, как и остальным SSO. Да можно же написать короткие строки (англ SSO). Батареи......

офк. Что значит офк?

Тогда уж пишите всё в этой фигне, типа кутя.

Да и что значит ваши батареи

ofc - of course
батарей - bytearray
шланг - clang
у вас там телепаты в отпуск ушли, что ли?
Выросло, блин, поколение не сидящее на форумах

В какой вселенной of couse становится офк?
В какой вселенной clang становится шлангом?
Но что QByteArray становится батарей, это полный алес. Ну как минимум байтэрей. Ну хоть как то по написанию.

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

Ну, ладно. Но когда же вы будете тогда последовательны. Я прошу - перепешите ваш текст в соответствии с вашими предпочтениями, уберите всякие std::string в англ. слова на телепатические. Чтобы поржать.

Circle - киркле
Line  - лине
И т.д.

1:1  :)

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

Согласен, нет ничего плохого в "набить руку", но увы, тут массовые перегибы. Текст прямо загажен этим "новьем" хотя никакой смысловой нагрузки оно не несет. При этом человек искренне уверен что "пишет на современном с++" :)

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

Кстати о птичках. Вот опять понадобилась сторонняя либа (там великом не возьмешь). И вот буквально вчера нашел подходящую, сейчас изучаю, на первый взгляд то что нужно, хотя кто знает. И опять: std практически НЕТУ. Ну разве что std::sort, и vector и string там "на задворках". Хотя либа очень молодая, июль этого года, еще и до версии 1.0 не дошла.   

Ну и о чем это говорит? О том, что чувак который её писал плюсы не знает. Но, то что ему вообще плачевно разрабатывать, то он прекрасно изучил (а точнее, то что ему из коробки понятно) тот же sort и вектор. Пошел вашим путём. Что здесь хорошего то?

Что Вам помешало дать ссылку на ту либу, как на наглядное доказательство того, что в 2019 г. стандартная библиотека С++ не нужна?

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

А чем "мой путь" отличается от "вашего"? Вы ведь тоже не бросаетесь все изучать, не гордитесь заученным и.т.д. Или я ошибался?  :)

Ну там довольно узкая специфика (микс анимаций), поэтому для наглядности не очень. Предыдущая (https://www.embree.org/) (недавно апдейтился) подходит гораздо лучше

Гораздо проще гордится незнанием. Да. :)
Сразу раз и "гений" во всем. :)

К чему эта "предыдущая" в контексте моего вопроса?

Embree API (https://www.embree.org/api.html)

В API на C99 действительно не нужны новомодные фишки С++ (равно как и какие-либо вообще его же).

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

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


Тут на столько все у всех многогранно, что одним предложением никто не обойдётся.
Ну вот Александреску я сразу отправил в топку и до сих пор оттуда не вернул.

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

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

К примеру, не воспринимаю std::pair (QPair) (да, не концептуальная вещь, но для примера годится). Зачем мне этот pair, если создавать свою структуру с корректными именами меньше минуты. Да, для шаблонов stl нормально, там все знают: в мапе first это кей. (это пример, не говорите что уже там в 20 или каком они уже именуются).

Да и как знать, что тебе оно не нужно, если ты об этом не знаешь и не понимаешь его.
Критерий крутости тоже разный. Volkov Commander был написан на ASM, сейчас сделай на ASM (например Far), у виска покрутят.


Ну и конечно делом, делом.
Кричать и гордится - я крут: неуважение к себе. Раз вы крут, то вы сами об этом знаете, какое дело вам до мнения бездарей. Но как скажи: "Дай ссылку на GitHab, посмотрим исходники твоего open source проекта", так обосрутся. Я первый :)

К тому что на первую еще есть отмазка (там, насколько я понял, один автор),  мол, "та чувак не понимает". А вот "Intel не понимает" - уже не скажешь (слон слишком велик).

С плюсами там все норм, есть даже довольно тяжелые template. Но вот std места почему-то не находится. Ну может просто нет денег чтобы нанять настоящих специалистов?  :)

А разве я кричу что крутой? :) Просто у меня фишка неизменно выпадает так что моих скромных познаний в std оказывается вполне достаточно. При первой же либе с интенсивным std все будет выучено (куда деваться). Но ее все нет и нет - так чего суетиться?

Вообще я совсем не уверен что std = светлое будущее человечества. Скорее это "одно из направлений", и не исключено что тупиковое. В общем "куда идем, в Москву или в Монголию?"

Мы с Вами "на ты" не переходили. А чтобы обосраться Embree подходит гораздо больше. Это очень крутая либа. Вот и скачайте, откройте, гляньте, покритикуйте (если захотите). А то чего я буду сыпать ссылками если они Вам неинтересны?

Вам очень, очень вдумчиво нужно научится читать чужие посты.
Потом через часик ещё раз перечитать, и тогда вы поймете, что имелось с виду.
Там большинство вообще не про вас, а вы как тот конь в стойле копытом бъёте - в бой, в бой!
Я вообще за большинство реализаций не берусь, пока не пройдет какое-то время, к Old мой месседж последний был, а не к вам, разве это ваша цитата?
И какое на "ты не переходили". Это не к вам личностное обращение, и не к Old личностное, это оборот речи.

Причем здесь "Intel не понимает"? И в описании и по исходникам видно, что библиотека растет из чисто сишной, поэтому взять и переписать ее на C++, даже для такого слона как intel, затея трудоемкая и бесполезная. Поэтому, там так мало C++.
А вот по новому коду видно, что там уже и шаблоны, умные указатели и даже итераторы используют. :)

Аналогично, так темлейты получаются гораздо лучше, продуманнее

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

Есть такой грех. Но и есть оправдание. Уж точно не намеренно и вижу свои ошибки, но только на следующий день :)

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


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

А теперь переведите это на знания.
Вот так, ни с того ни с сего, потеряв кучу времени вы за неделю нагоните даже stl.
Даже со всеми своими теоретическими знаниями, пусть даже вы вселенную понимаете.
Нет. Это так не работает.

Прям как студенты в своих мечтах.
Ещё 3 месяця. Успею.
Ещё 2 месяца. Успею.
Ещё месяц. Успею.
Две недели! А чего уже начинать то!.

И, что обижает здесь многих - stl, это не отдельная библиотека. stl - это часть языка. Это сам C++. Точка. Никаких если, никаких но.

Ну, и чтобы добить, ГАВНО ваша Embree.

Про Intel Old уже сказал, и я с ним согласен. Добавлю только, что, во-первых, ещё могут давить требования C интерфейса, обратной совместимости, С++11 и не больше. Судя по копирайту, разработка началась до С++11 и в исходниках видны и свой RefCount и вектор и т.п. В Вашем продукте такие же ограничения (C API для dll, C++11)? Во-вторых, если бы эту библиотеку начали писать в этом году на C++17, то, скорей всего, это была бы совсем другая библиотека (по API и исходному коду).


Не знаю, что у Вас там не находится, у меня, на скорую руку, нашлось следующее:

C++ (Qt)
std::runtime_error
std::vector
std::lower_bound
std::unique_ptr
std::forward_iterator_tag
std::binary_search
std::swap
std::sort
std::string
std::shared_ptr
std::pair
std::istream
std::stream
std::ostream
std::numeric_limits
std::make_pair
std::cout
std::size_t
std::ptrdiff_t
std::set
std::atomic
std::memory_order_acquire
std::memory_order_release
std::endl
std::cerr
std::flush
std::to_string
std::ios
std::streamsize
std::move
std::allocator
std::alignment_of
std::list
std::exception_ptr
std::rethrow_exception
std::isfinite
std::greater
std::plus
std::ostringstream
std::setw
std::setprecision
std::stringstream
std::forward
std::bad_alloc
std::exception
std::isinf
std::tie
std::tuple
std::make_tuple
std::map
std::string,std
std::stof
std::string,
std::less
std::deque

Но в целом, на мой поверхностный взгляд, заметно, что ноги у библиотеки растут из C, и написана больше в стиле "С с классами". Но в данном случае это совсем не упрёк, учитывая историю и ограничения. Без const_cast они как-то смогли прожить, в отличие от :)  (да есть несколько в imgui.cpp, но это уже tutorial, и не совсем понятно, насколько сильно он там нужен). На тяжёлые шаблоны ещё не смотрел, но есть вероятность, что с С++17 они были бы полегче.

Ничего "емкого" в упор не вижу :)
Не увлекайтесь ролью учителя :)
Либа (любая) привлекается не потому что что она плоха или хороша - а потому что без нее не обойтись. Уже на SSE это "говно" бьет наш самопальный raytracer вдвое, на AVX - еще больше. Все-таки интересно как Вы пришли к такому глубокому (философскому) выводу что говно?  :) Ну откомпилить примеры точно не успели, наверное что-то "не понравилось" в первом же наугад открытом файле. Что?

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


То, что это не ваш проект. Это как строитель (прараб и т.д.) говорит, что это он построил многоэтажный дом.
Я его даже не смотрел.

Да и как мне увлекаться ролью учителя, с сообщениями меньше 100

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

Ага, а потом я сижу неделями и разбрасываю по коду std::unique_ptr потому что предыдущий разработчик посчитал писать "delete ptr" "мелким неудобством" и вообще забил на освобождение ресурсов. Как итог краши на выходе потому что половина программы живет дольше чем остальная половина которая таки разрушается (типа QApplication на стеке).

Угу, вопрос только в том, сколько времени он потратил на написание своего аналога std::filesystem, std::thread, std::atomic или std::future.
Не, если у вас либа которая матрицами ворочает, то вам действительно не надо ничего, кроме арифметических операций.

Блин, хорошо вами быть. Проигнорировав все аргументы про "ноги растут из C", с важным видом заявлять: ну вот видите, можно и без std получить мощнейший продукт. :)
Да никто и не спорит, можно просто писать на C, но это будет уже не C++ с его std. :)
Можно использовать только if/else  и for с индексами по вектору, можно. Только это не значит, что современные возможности языка никому не нужны и это только понты.
Они не нужны вам, потому что вы не можете их освоить, несмотря на их простоту. И именно это вас все время раздражает. :)

Насколько я помню в более ранних версиях так и было, и под каждую платформу. Наверно разработчик на этом отдыхал от BVH дерева и др. :) Конечно париться самому напр с thread - удовольствие ниже среднего, спасибо что "дали". Но в проекте роль таких вещей - не первая, не вторая, и даже не десятая. Даже если "все руками" (что конечно сейчас глупо), то и тогда эти затраты - жалкие крохи по сравнению с основным ф-ционалом.

Не матрицами, а лучами. Кстати и использование этой либы также не требует какого-то обильного std, дуста и.т.п. ("использование" здесь не "вызов ф-ций либы", а достигаемый с ее помощью ф-ционал).

неужели, использование СИШНОЙ либы не требует стд и дуста=)
оно еще и с++ не требует, ага ;)