Правда в последнее время это отошло на второй план из-за создания кодогенератора. Писать прототипировать на с++ сплошной гемморой из-за специфики разработки на этом языке. Нет, мне нравится с++, но честно, поддерживать структуру проекта, добавлять удалять файлы, разделять объявление и реализацию в разных местах... это же такая унылая работа, а еще надо за сборкой следить если вы пишите на симейке. Такое есть у вижуал студио, но там примитивная генерация классов, а вот можно было бы по факту делать рефакторинг или просто создавать классы по абстрактному описанию. Я ярый пользователь современного с++ и часто пишу используя шаблоны, из последних работ я не помню когда отказывался от шаблонов, в общем там своя специфика из-за которой реализацию нельзя делать в еденице трансляции, а писать процедуру в объявлении! Вы что, это моветон для с++! Так что приходится реализацию писать либо в другом хедере, либо в этом же хедере но под объявлением класса, либо в инл файле, и нет я не стебусь над возможностью языка, просто столько условностей компиляции, которые надо держать в голове только чтобы просто сделать небольшую программу правильно... это то с чем питон юзерам или впринципе юзерам любых других популярных языков программирования никогда не придется столкнуться. Есть ли такие инструменты? Да есть, но часто они платные либо гавно, то что я описал примерно есть на слионе, но онр весят дофига на мой взгляд и платные :), во всяком случае я не работал в айти еще ни разу, но пару лет пишу на с++ и честно, спустя столько времени возник только один вопрос: почему такой кодогенерации нет на просторах? Или лучше, почему еще не додумались сделать это стандартом??? Я за неделю полторы настрогал модель языка в оопшной манере, есть уже кодогенерация, осталось только подправить генерацию алиасов и некоторых случаев связанных с шаблонами и зависмыми именами типа при случае:
struct Type {
using field = int;
}
template<typename T>
typename T::field something();
Что-то вроде этого, и все кодогенератор по сути готов, во всяком случае это тема для отдельной статьи. Странно что наверняка для многих это такая больная тема, но по факту чего такого нет вообще, простого понятного и удобного. Честно хз, зачем я пишу это все, наверное, нет людей которым я мог бы рассказать это все, так что - спасибо за внимание. Может увидимся в статье
Обалдеть, как так вышло что я тоже уже полгода делаю свой движок для создания графических приложений? Даже несколько либ написал, как такое возможно... может коммент не о чем, но просто забавно видеть такое. В том смысле что для меня тоже создание граф приложений на с++ проблема. Недавно нашел баг в алгоритме интерполяции и для наглядности хотел по быстрому сделать проектик в котором по быстрому отлажу алгоритмы строя графики интерполяционных кривых, но чтобы это сделать надо... подключить глфв, подключить глев или глад, настраивать инициализации, контексты, создавать шейдеры писать их, потом пайплайн, организация данных... короче такой геоморой. Вот была бы либа где можно было бы легко рисовать то что тебе надо! В общем я решил написать инструменты для этого, сижу параллельно воплощаю идею в реальность и интересно совершенно случайно наткнуться на такое
Так и я за это. Я даже сначала подумал что вы имеете ввиду разделять хуз на векторы х, у и з. Написал кучу текста почему лучше хранить хуз в одной структуре, приводил доводы, но перечитав ваш комментарий понял что вы имеете ввиду, как раз противоположное. В этом вопросе я полностью на вашей стороне, я собственно сделал поправку в статье в честь этого
Извините, не могу понять, где я использовал в качестве тегов отдельные осевые координаты?
Update: похоже вы имели ввиду там где я представил партикл, да там идут отдельные вектора для хуз, но я указал это скорее для наглядности. В своем коде я разумеется юзаю теги с век3
Я имел ввиду: "SoA быстрее AoS", действительно стоило сделать ссылку на то как грузятся данные в шейдеры. А никто не запрещает использовать заранее подготовленные структуры, их также можно сделать тегом, что собственно я и использовал в тестах этого типа данных. Учитывыя, что есть glm, не вижу в этом никакой проблемы
Соглашусь с тем, что такой комментарий без контекста, действительно неверен. Однако в контексте графики, где атрибуты желательно загружать именно что сплошными кусками памяти(так действительно быстрее), то выбор СоА здесь актуален на мой взгляд. И правда стоило обозначить этот факт!
Большое спасибо за обратную связь! Я даже и представить не мог что мою первую же статью прочитает столько людей, а чтобы кто-то зашел в мою репу?! Помимо этого вы даже дали советы по структуре реп, учитывая что я самоучка, то это бесценный опыт. Невероятный сайт
Выглядит круто. Не замена смэйка, но хорошая альтренатива для быстрого протипирования небольших проектов
Блин жесть читать больно текст, сорри
Правда в последнее время это отошло на второй план из-за создания кодогенератора. Писать прототипировать на с++ сплошной гемморой из-за специфики разработки на этом языке. Нет, мне нравится с++, но честно, поддерживать структуру проекта, добавлять удалять файлы, разделять объявление и реализацию в разных местах... это же такая унылая работа, а еще надо за сборкой следить если вы пишите на симейке. Такое есть у вижуал студио, но там примитивная генерация классов, а вот можно было бы по факту делать рефакторинг или просто создавать классы по абстрактному описанию. Я ярый пользователь современного с++ и часто пишу используя шаблоны, из последних работ я не помню когда отказывался от шаблонов, в общем там своя специфика из-за которой реализацию нельзя делать в еденице трансляции, а писать процедуру в объявлении! Вы что, это моветон для с++! Так что приходится реализацию писать либо в другом хедере, либо в этом же хедере но под объявлением класса, либо в инл файле, и нет я не стебусь над возможностью языка, просто столько условностей компиляции, которые надо держать в голове только чтобы просто сделать небольшую программу правильно... это то с чем питон юзерам или впринципе юзерам любых других популярных языков программирования никогда не придется столкнуться. Есть ли такие инструменты? Да есть, но часто они платные либо гавно, то что я описал примерно есть на слионе, но онр весят дофига на мой взгляд и платные :), во всяком случае я не работал в айти еще ни разу, но пару лет пишу на с++ и честно, спустя столько времени возник только один вопрос: почему такой кодогенерации нет на просторах? Или лучше, почему еще не додумались сделать это стандартом??? Я за неделю полторы настрогал модель языка в оопшной манере, есть уже кодогенерация, осталось только подправить генерацию алиасов и некоторых случаев связанных с шаблонами и зависмыми именами типа при случае:
Что-то вроде этого, и все кодогенератор по сути готов, во всяком случае это тема для отдельной статьи. Странно что наверняка для многих это такая больная тема, но по факту чего такого нет вообще, простого понятного и удобного. Честно хз, зачем я пишу это все, наверное, нет людей которым я мог бы рассказать это все, так что - спасибо за внимание. Может увидимся в статье
Обалдеть, как так вышло что я тоже уже полгода делаю свой движок для создания графических приложений? Даже несколько либ написал, как такое возможно... может коммент не о чем, но просто забавно видеть такое. В том смысле что для меня тоже создание граф приложений на с++ проблема. Недавно нашел баг в алгоритме интерполяции и для наглядности хотел по быстрому сделать проектик в котором по быстрому отлажу алгоритмы строя графики интерполяционных кривых, но чтобы это сделать надо... подключить глфв, подключить глев или глад, настраивать инициализации, контексты, создавать шейдеры писать их, потом пайплайн, организация данных... короче такой геоморой. Вот была бы либа где можно было бы легко рисовать то что тебе надо! В общем я решил написать инструменты для этого, сижу параллельно воплощаю идею в реальность и интересно совершенно случайно наткнуться на такое
Так и я за это. Я даже сначала подумал что вы имеете ввиду разделять хуз на векторы х, у и з. Написал кучу текста почему лучше хранить хуз в одной структуре, приводил доводы, но перечитав ваш комментарий понял что вы имеете ввиду, как раз противоположное. В этом вопросе я полностью на вашей стороне, я собственно сделал поправку в статье в честь этого
Извините, не могу понять, где я использовал в качестве тегов отдельные осевые координаты?
Update: похоже вы имели ввиду там где я представил партикл, да там идут отдельные вектора для хуз, но я указал это скорее для наглядности. В своем коде я разумеется юзаю теги с век3
Я имел ввиду: "SoA быстрее AoS", действительно стоило сделать ссылку на то как грузятся данные в шейдеры. А никто не запрещает использовать заранее подготовленные структуры, их также можно сделать тегом, что собственно я и использовал в тестах этого типа данных. Учитывыя, что есть glm, не вижу в этом никакой проблемы
Соглашусь с тем, что такой комментарий без контекста, действительно неверен. Однако в контексте графики, где атрибуты желательно загружать именно что сплошными кусками памяти(так действительно быстрее), то выбор СоА здесь актуален на мой взгляд. И правда стоило обозначить этот факт!
Большое спасибо за обратную связь! Я даже и представить не мог что мою первую же статью прочитает столько людей, а чтобы кто-то зашел в мою репу?! Помимо этого вы даже дали советы по структуре реп, учитывая что я самоучка, то это бесценный опыт. Невероятный сайт
Действительно, я почему то когда первый раз это обдумывал, почему то посчитал перестановки, а правильно считать число подмножеств