Вы можете тут спросить: «Зависит ли результат от порядка следования байтов в системе, в которой выполняется код? А если так — почему я пользуюсь архитектурой, где сначала идёт старший байт?». А я на это отвечу: «Спасибо, что спросили. Хороший вопрос».
Простите, но я не увидел ответ на вопрос. Логично, что если Вы совершаете манипуляции с числами в рамках одной системы — проблем с Endian не будет. Но если это массив данных с другого устройства, где архитектура работает на BigEndian, то у Вас очевидно будут проблемы. Дело в том, что Вы не всегда определяете архитектуру системы. Например, MIPS архитектура полностью построена на BE и является практически стандартом на российском рынке импортозамещения. На мой взгляд, Вы не закончили мысль.
ну так чуть раскидаю:
1. Как сказано выше — у вас реально течет.
2. Для объявления слотов одного Q_OBJECT будет недостаточно, вам нужно полное наследование от QObject. Q_OBJECT отвечает за декларацию типа как базового от QObject для MOC.
3. Связка сигнал-слот априори медленнее чем вызов функции, т.к. механизм сигналов и слотов работает по принципу callback'ов, только после вызова прокручивается весь список подписанных на сигнал этого объекта слотов, проверяются сигнатуры и т.д, весь этот процесс — дорогое удовольствие, и за это мы платим временем. Отсюда вывод — механизм сигнал-слотов НЕ потокобезопасен, слот не должен пользоваться разделяемыми ресурсами или вы должны оградить их блокировкой, но тут вы не угадаете кем, например, первее будет захвачен mutex.
4. Никогда не делайте выполнение слота в вызывающем потоке (Ваш модификатор BlockingQueuedConnection). Особенно GUI, любая неполадка или задержка в GUI сломает вам процесс. Более того — вы изменяете состояние GUI из смежного потока, пусть и в его же слоте. Решением же в вашем случае с массивом может быть только передать в слот кадр этого массива, либо работайте с динамически изменяемыми данными, но стоит ли отдавать что то в слот по указателю — решать конечно вам, от себя лишь скажу, что это по меньшей мере безрассудно.
P.S. последнее, про переопределение типов — признаться, не смог понять зачем вы это здесь написали, к теме не относится
Удивительно, как вас не съел синдром самозванца. Сужу по себе.
Что касается градаций программистов по скилзам, скажу что все очень относительно, но раз вам платили эти деньги — вы их явно стоили, не принижайте себя.
ответил вам выше, добавлю еще, что вместо передачи QMetaProperty в хранитель можно передавать ее индекс в списке propertyes. Так можно оставить по 12 байт на хранитель вместо 40, как вариант.
4lenodevka Попробую с вами подискутировать:
Вы описываете механизм конвертации в JSON объектов с примитивными типами данных, но как быть со вложенными объектами? В вашем случае, если я конечно же правильно понял идею, придется на каждый класс писать свою реализацию своего виртуального оператора, что меня смущает. Моя идея заключается в единоразовом описании полей в Q_PROPERTY и последующей работой с пространством имен.
Насчет Enum и хардкода вектора я полностью с вами согласен, насчет вектора вообще ужасное решение.
А вот насчет выделения памяти надо разбираться, хранимые указатели на целевой QObject занимают всего по 8 байт (на x64), объект QMetaProperty 32 байта, действительно расход большой, 40 байт на хранитель, но эта память освобождается сразу же после разрушения фабрики, которая предоставила в пользование объекты keepers. (т.е. суммарно при сериализации объекта с 5ю полями, на время сериализации будет выделено 200 байт, не кисло). Стоит ли сериализация такого расхода, пусть и кратковременного — решать вам, вообще серализация довольно затратный по памяти процесс.
Как я сказал в конце — приходится чем-то жертвовать, если описывать реализацию оператора сериализации в классе, вы приобретаете в гибкости, но теряете в простоте использования. Более того, вам понадобится такой же оператор и для XML и для бинарного формата(который, я надеюсь, скоро появится в QSerializer), в итоге тут уже попахивает вынесением такой функциональности в отдельный класс (меня привлекает концепция миниатюрных классов, описанная в «Clean Code» Боба Мартина, и, на мой взгляд, стремление к простоте — вовсе не грех).
Я учту ваши замечания, считаю такой опыт полезным, поэтому спасибо за ваше время.
я категорически не согласен с автором этой статьи про то, что обработка ошибок по принципу "получил результат функции-вспомнил про совесть-не зассал проверить ошибку-тут же ее и обработал" есть хорошая практика. Привычный механизм Exeptions надает по рукам за необработку брошенного исключения и развернет весь стек до точки входа. Более того, механизм исключений крайне элегантен в алгоритмах, которые в исключених выбрасывают статус обработки данных, особенно когда статусов, например, 100 (м?) и особенно пробрасывать статус обычным return через 3 вызова мягко говоря некрасиво. Классические Exeptions, которых лишен Go, позволяют написать блок try так, как будто ошибок и вовсе не существует, а обработку отложить в блок(и) catch, вместо загрязнения кода ненужными проверками, бесконечным логированием и возвратами ошибок. Нельзя полагаться на то, что программист "не зассыт" проверить ошибку. Поэтому, на мой СКРОМНЫЙ взгляд, разработчики Go сознательно кастрировли его на одну сторону, выпилив исключения. Я молчу про дженерики.
Я вместе с тем парнем. Тоже из провинции, из самой жопы. Чуть южнее Дагестана. Тоже колледж, потом универ, сопли слюни, урчащий желуок. Только пути у нас с тобой разные, но в целом можешь почитать мою последнюю статью на эту же тему. Всем пис, развивайтесь пацаны, единственное, что невозможно у вас отобрать, как бы не банально звучало, это знания. А они и деньги неплохие приносят))))
Если честно, тут под колледжом я имею ввиду «шарагу». Это все СПО которое есть у нас в стране. По идее там готовят «новых воротничков», но по факту мало чем отличается от школы. Уровень преподавания низкий, программы толком не выстроены, море свободы для студента, но цель такого образования «поскорее уже свалить от родителей». Но и там есть хорошие преподаватели, просто в меньшей концентрации. В основном им просто не интересно учить чему-то студентов, а процент «плавающих» из них весьма и весьма большой.
В университете больше нацелены дать базу, а в колледже — что-то конкретное из специальности, что бы хотя бы сисадмином устроился. В программе колледжа, на развитие базы направлено 5% программы, а в вузе 50%. Я думаю в этом вся разница.
Когда разработчики пытаются решить проблему, иногда они стараются найти такой способ, который решит все проблемы, включая те, что могут возникнуть в будущем.
Я вам вот что скажу: эти будущие проблемы никогда не возникнут, а вам придётся сопровождать огромную кучу кода, который не будет использоваться целиком, либо вам придётся всё переписать из-за туевой хучи неиспользуемого кода.
Я бы сказал, что правильнее действовать посередине. Тоесть встраивать крепления для модулей возврата в орбитальную ракету глупо без надобности, но если есть тенденция на то, что скоро ракеты станут поголовно возвращаться с орбиты, то почему бы не позаботиться об этом заранее? Другое дело, что этот модуль должен быть слабосвязанным с остальными модулями, что бы не приходилось его рефакторить после каждой запятой, он не должен болтаться и цеплять собой остальные модули. Кодовая база увеличится, но для современных многофайловых проектов это не проблема.
Я говорю это к тому, что порой стоит думать наперед при наличии тенденций. Но это, конечно, не задача рядового программиста. Этим занимаются ПМы, аналитики, у кого есть понимание целостного продукта и его перспектив.
И да, с остальным, изложенным в статье, я полностью согласен. В целом статья очень полезная, мне понравилась.
Хороший и развернутый комментарий.
Согласен с нижесказанным, были и преподаватели, которые меняют мировоззрение. Я очень уважаю таких преподавателей и периодически навещаю их. С моей точки зрения, преподаватель — это больше чем профессия. Это призвание.
В моём учебном опыте встречались как преподаватели уровня «как ты вообще стал учителем» которые могли только читать выдержки с учебником и плавали при малейшем вопросе в сторону, так и преподаватели которые за 1 лекцию полностью переворачивали представление о предмете, вносили ясность и желание изучать
Я немного дописал упущенные моменты. Действительно, повествование было рваное. Однако, тут писали, что стремящийся к чему-то человек не замечает каких-то особенных мучений во время обучения.
Возможно из этого и можно сделать крутой лонгрид, но только если привирать.
И чую у многих успешных людей будет такая же проблема. Они не делали ничего особенного с их точки зрения.
Так было и со мной. Я очень рад, что затронул актуальную тему
Ребят, я очень рад, что моя статья вызвала такое бурное обсуждение. Видимо тема и правда не однозначная. Благодарен всем, кто оставил свой отзыв. Отрадно наблюдать, что вокруг собралось такое количество умных людей.
Двумя руками поддерживаю. Полностью согласен, был опыт, правда не в таких масштабах как у вас. Для качественного поднятия своего уровня нужна «мясорубка».
Я решил не засорять совсем нудной писаниной статью. Для меня важно было донести посыл о сути образования. Путь весьма и весьма тернист, но я не ломал себя как-то по особенному, я учился и получал от этого наслаждение.
Краткость сестра талланта? Ну может и так, но орфография — точно не мой конек)
Возможно, вы правы. Но я хочу сказать то, что не затронул в статье. Программирование пробудило во мне любознательность. С тех пор мне интересно все, до чего могу дотянуться, и надеюсь, что это любопытство никогда не сойдет на «нет». Впрочем, время покажет.
Простите, но я не увидел ответ на вопрос. Логично, что если Вы совершаете манипуляции с числами в рамках одной системы — проблем с Endian не будет. Но если это массив данных с другого устройства, где архитектура работает на BigEndian, то у Вас очевидно будут проблемы. Дело в том, что Вы не всегда определяете архитектуру системы. Например, MIPS архитектура полностью построена на BE и является практически стандартом на российском рынке импортозамещения. На мой взгляд, Вы не закончили мысль.
1. Как сказано выше — у вас реально течет.
2. Для объявления слотов одного Q_OBJECT будет недостаточно, вам нужно полное наследование от QObject. Q_OBJECT отвечает за декларацию типа как базового от QObject для MOC.
3. Связка сигнал-слот априори медленнее чем вызов функции, т.к. механизм сигналов и слотов работает по принципу callback'ов, только после вызова прокручивается весь список подписанных на сигнал этого объекта слотов, проверяются сигнатуры и т.д, весь этот процесс — дорогое удовольствие, и за это мы платим временем. Отсюда вывод — механизм сигнал-слотов НЕ потокобезопасен, слот не должен пользоваться разделяемыми ресурсами или вы должны оградить их блокировкой, но тут вы не угадаете кем, например, первее будет захвачен mutex.
4. Никогда не делайте выполнение слота в вызывающем потоке (Ваш модификатор BlockingQueuedConnection). Особенно GUI, любая неполадка или задержка в GUI сломает вам процесс. Более того — вы изменяете состояние GUI из смежного потока, пусть и в его же слоте. Решением же в вашем случае с массивом может быть только передать в слот кадр этого массива, либо работайте с динамически изменяемыми данными, но стоит ли отдавать что то в слот по указателю — решать конечно вам, от себя лишь скажу, что это по меньшей мере безрассудно.
P.S. последнее, про переопределение типов — признаться, не смог понять зачем вы это здесь написали, к теме не относится
Что касается градаций программистов по скилзам, скажу что все очень относительно, но раз вам платили эти деньги — вы их явно стоили, не принижайте себя.
ответил вам выше, добавлю еще, что вместо передачи QMetaProperty в хранитель можно передавать ее индекс в списке propertyes. Так можно оставить по 12 байт на хранитель вместо 40, как вариант.
Вы описываете механизм конвертации в JSON объектов с примитивными типами данных, но как быть со вложенными объектами? В вашем случае, если я конечно же правильно понял идею, придется на каждый класс писать свою реализацию своего виртуального оператора, что меня смущает. Моя идея заключается в единоразовом описании полей в Q_PROPERTY и последующей работой с пространством имен.
Насчет Enum и хардкода вектора я полностью с вами согласен, насчет вектора вообще ужасное решение.
А вот насчет выделения памяти надо разбираться, хранимые указатели на целевой QObject занимают всего по 8 байт (на x64), объект QMetaProperty 32 байта, действительно расход большой, 40 байт на хранитель, но эта память освобождается сразу же после разрушения фабрики, которая предоставила в пользование объекты keepers. (т.е. суммарно при сериализации объекта с 5ю полями, на время сериализации будет выделено 200 байт, не кисло). Стоит ли сериализация такого расхода, пусть и кратковременного — решать вам, вообще серализация довольно затратный по памяти процесс.
Как я сказал в конце — приходится чем-то жертвовать, если описывать реализацию оператора сериализации в классе, вы приобретаете в гибкости, но теряете в простоте использования. Более того, вам понадобится такой же оператор и для XML и для бинарного формата(который, я надеюсь, скоро появится в QSerializer), в итоге тут уже попахивает вынесением такой функциональности в отдельный класс (меня привлекает концепция миниатюрных классов, описанная в «Clean Code» Боба Мартина, и, на мой взгляд, стремление к простоте — вовсе не грех).
Я учту ваши замечания, считаю такой опыт полезным, поэтому спасибо за ваше время.
я категорически не согласен с автором этой статьи про то, что обработка ошибок по принципу "получил результат функции-вспомнил про совесть-не зассал проверить ошибку-тут же ее и обработал" есть хорошая практика. Привычный механизм Exeptions надает по рукам за необработку брошенного исключения и развернет весь стек до точки входа. Более того, механизм исключений крайне элегантен в алгоритмах, которые в исключених выбрасывают статус обработки данных, особенно когда статусов, например, 100 (м?) и особенно пробрасывать статус обычным return через 3 вызова мягко говоря некрасиво. Классические Exeptions, которых лишен Go, позволяют написать блок try так, как будто ошибок и вовсе не существует, а обработку отложить в блок(и) catch, вместо загрязнения кода ненужными проверками, бесконечным логированием и возвратами ошибок. Нельзя полагаться на то, что программист "не зассыт" проверить ошибку. Поэтому, на мой СКРОМНЫЙ взгляд, разработчики Go сознательно кастрировли его на одну сторону, выпилив исключения. Я молчу про дженерики.
В университете больше нацелены дать базу, а в колледже — что-то конкретное из специальности, что бы хотя бы сисадмином устроился. В программе колледжа, на развитие базы направлено 5% программы, а в вузе 50%. Я думаю в этом вся разница.
Я бы сказал, что правильнее действовать посередине. Тоесть встраивать крепления для модулей возврата в орбитальную ракету глупо без надобности, но если есть тенденция на то, что скоро ракеты станут поголовно возвращаться с орбиты, то почему бы не позаботиться об этом заранее? Другое дело, что этот модуль должен быть слабосвязанным с остальными модулями, что бы не приходилось его рефакторить после каждой запятой, он не должен болтаться и цеплять собой остальные модули. Кодовая база увеличится, но для современных многофайловых проектов это не проблема.
Я говорю это к тому, что порой стоит думать наперед при наличии тенденций. Но это, конечно, не задача рядового программиста. Этим занимаются ПМы, аналитики, у кого есть понимание целостного продукта и его перспектив.
И да, с остальным, изложенным в статье, я полностью согласен. В целом статья очень полезная, мне понравилась.
Согласен с нижесказанным, были и преподаватели, которые меняют мировоззрение. Я очень уважаю таких преподавателей и периодически навещаю их. С моей точки зрения, преподаватель — это больше чем профессия. Это призвание.
Так было и со мной. Я очень рад, что затронул актуальную тему
Краткость сестра талланта? Ну может и так, но орфография — точно не мой конек)