Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
А где же картинки?
Иногда мне скучно, и я занимаюсь указанием неточностей и ошибок в статьях, которые задевают интересующую меня тему, простите меня за это :)
1. Не QT, а Qt. Официально. Это все равно, что если бы к вам обращались не «Иван» а скажем «ИВАН» или «ИвАн»
2.
Бред! Правильно сказать — для объявления класса главного окна.
Бред! Правильно сказать — определение методов класса главного окна.
3.
4.
Назовите хоть одну объективную причину, по которой вы засунули все данные и все не переопределяющие методы в секцию protected, а не private (этот же вопрос относится и к слоту geese_coord)
5.
Ваш игрок всегда будет иметь 17 очков.
6.
Метод объявлен,… уже,… всегда,… без вашего вмешательства… в базовом классе… как виртуальный
А это значит что вы его лишь переопределяете, кстати, если вы его не переопределите, метод с этим именем тоже будет вызван, в базовом классе, конечно же.
7.
Таймер, не завершает свою работу, он посылает сигнал и сбрасывает счетчик. Таймер завершает работу либо при вызове метода stop(), либо разрушении объекта таймера.
Я не буду судить OpenGL часть кода, потому что не силен в этом.
Я не буду комментировать стиль кода, наличие огромного количества неименованных констант и т. д. — это очевидно.
Выводы:
1. Это не статья для новичков, это статья от новичка.
2. Это вредная статья для новичков, она учит программировать неряшливо, и не понимая сути происходящего в коде.
Еще раз извините, если задел чьи-то чувства.
1. Не QT, а Qt. Официально. Это все равно, что если бы к вам обращались не «Иван» а скажем «ИВАН» или «ИвАн»
2.
mainwindow.h — для объявления всех глобальных данных
Бред! Правильно сказать — для объявления класса главного окна.
mainwindow.cpp — методы нашей программы
Бред! Правильно сказать — определение методов класса главного окна.
3.
#include <QTimer>4.
protected:
[skipped длинный список переменных и прочих методов]Назовите хоть одну объективную причину, по которой вы засунули все данные и все не переопределяющие методы в секцию protected, а не private (этот же вопрос относится и к слоту geese_coord)
5.
QString::fromUtf8("Вы набрали %1 очков:").arg(17)Ваш игрок всегда будет иметь 17 очков.
6.
*Event() — если метод объявлен…
Метод объявлен,… уже,… всегда,… без вашего вмешательства… в базовом классе… как виртуальный
А это значит что вы его лишь переопределяете, кстати, если вы его не переопределите, метод с этим именем тоже будет вызван, в базовом классе, конечно же.
7.
В данном случае мы создаем таймер, который будет ждать 750мс после чего он завершает свою работу, отправляя нам сигнал timeout()
Таймер, не завершает свою работу, он посылает сигнал и сбрасывает счетчик. Таймер завершает работу либо при вызове метода stop(), либо разрушении объекта таймера.
Я не буду судить OpenGL часть кода, потому что не силен в этом.
Я не буду комментировать стиль кода, наличие огромного количества неименованных констант и т. д. — это очевидно.
Выводы:
1. Это не статья для новичков, это статья от новичка.
2. Это вредная статья для новичков, она учит программировать неряшливо, и не понимая сути происходящего в коде.
Еще раз извините, если задел чьи-то чувства.
Вы правы, статья от новичка (3 месяц знакомства С++ в целом) в этом вопросе, но я постарался доступным языком рассказать это и другим таким же как я.
Все замечания обязательно учту и даже благодарен за откровенное мнение.
P.S. Вы извините статью снимать не буду, пусть люди учатся на чужих ошибках.
Все замечания обязательно учту и даже благодарен за откровенное мнение.
P.S. Вы извините статью снимать не буду, пусть люди учатся на чужих ошибках.
Я и не побуждаю ее снимать, ваша статья, ваше право, я просто высказал мнение.
Перенос подключения заголовков из .h файла в .cpp уменьшает время компиляцииПочему? При изменении хэдера, возможно. Но почему время компиляции должно изменяться при изменении файла реализации?
Уточнение: "#include" просто вставляет код в место, где сама директива написана, то есть на стадии компиляции (после вставки кода препроцессором), перекомпилируетсяровным счетом столько же кода. Но! Подозреваю, что выигрыш будет на стадии прохода MOC'ом. Если так, объясните, пожалуйста, почему?
Ну может я несколько неправильно выразил мысль, в этом конкретном случае навряд ли будет приращение скорости компиляции. Но это является, как говорится Best Practice и вот почему:
1. Представим что у нас есть
A.h, который включается в B.h (но там не обязателен, т. к. его информация используется только в реализации и не используется в интерфейсе), а файл B.h включается еще в 100+ файлов, внимание вопроссколько раз будет прочитан и вставлен (как вы верно заметили на место #include) файл A.h?
2. Наиболее важное (но как правило редко касается библиотечных заголовков, т.к. они постоянны в долгосрочном периоде) инкрементальная сборка.
Все тот же пример A.h, который включается в B.h, а файл B.h включается еще в 100+ файлов, которые включаются еще в 1000+ файлов, так вот одно малюсенькое изменение в файле A.h приведет к тому, что и B.h и все что включает его, и все что включает то что включает его, будет перекомпилировано заново.
1. Представим что у нас есть
A.h, который включается в B.h (но там не обязателен, т. к. его информация используется только в реализации и не используется в интерфейсе), а файл B.h включается еще в 100+ файлов, внимание вопроссколько раз будет прочитан и вставлен (как вы верно заметили на место #include) файл A.h?
2. Наиболее важное (но как правило редко касается библиотечных заголовков, т.к. они постоянны в долгосрочном периоде) инкрементальная сборка.
Все тот же пример A.h, который включается в B.h, а файл B.h включается еще в 100+ файлов, которые включаются еще в 1000+ файлов, так вот одно малюсенькое изменение в файле A.h приведет к тому, что и B.h и все что включает его, и все что включает то что включает его, будет перекомпилировано заново.
Согласен с 1 и 2. Я просто имел в виду именно перекомпиляцию хедеров :-)
Как правило, чем легче хэдер, тем лучше.
Но! Ситуация бывает какая:
1) Ускорение при перекомпиляции .cpp и .h
2) Ускорение при перекомпиляции только .h
3) Неизменность при перекомпиляции только .cpp
Я просто указал на наличие ситуации номер 3 :-)
Как правило, чем легче хэдер, тем лучше.
Но! Ситуация бывает какая:
1) Ускорение при перекомпиляции .cpp и .h
2) Ускорение при перекомпиляции только .h
3) Неизменность при перекомпиляции только .cpp
Я просто указал на наличие ситуации номер 3 :-)
А ну само собой. Я нечетко выразил мысль. My fault.
Зато в будущем Вы, возможно, будете выражаться точнее :-)
Просто мне показалось, что было бы достаточно интересно, указать на небольшую неточность в комментарии, который уточняет пост :-)
Просто мне показалось, что было бы достаточно интересно, указать на небольшую неточность в комментарии, который уточняет пост :-)
Абсолютно согласен.
Скорость компиляции на самом деле тема больная для проектов на Qt (видимо из-за дополнительных манипулиций MOC'а, в смысле необходимости компилировать дополнительно «отмоканные» файлы), так что ваше замечание имеет особый смысл в контексте поста. У меня самого сейчас полная перекомпиляция текущего проекта на Qt занимает больше минуты.
да просто потому, что файл заголовков может быть вставлен во многие файлы .cpp, и компилятор «смотрит» кучу ненужных вещей, которые вы влепили в хедер, каждую компиляцию, теряя зря время.
Не, Вы не поняли. Я про то, что изменения скорости компиляции быть не должно при изменении одного и того же файла реализации. Потому что в данном случае компилируется только он, и ничто другое. А при компиляции хэдера ситуация понятна, я так и написал выше. Проблема в изначальной фразе:
Перенос подключения заголовков из .h файла в .cpp уменьшает время компиляцииВремя компиляции уменьшается только при перекомпиляции хэдера(ов).
Это побочный эффект, а прямой эффект — избегание лишних зависимостей.
Я добавлю по OpenGL, что сразу бросается в глаза:
1. glOrtho(0,500,500,0,1,0); // подготавливаем плоскости для матрицы
это конечно сильно :) glOrtho умножает текущую матрицу на ортогональную матрицу, ее аргументы — координаты плоскостей отсечения слева, справа, снизу, сверху, сблизи и издалека. эти координаты относительны, если принять за единицу ширину и высоту вашего viewport, то будет примерно так: glOrtho( 0, 1, 0, 1, 0, 1);
в приведенном коде мало того, что все вверх ногами, так еще и кто-то перепутал координаты векторов с пиксельными координатами. Оно-то рисует, но вычисления происходят при этом абсолютно дикие. Соответственно и glVertex2f() оперирует этими «дикими» пиксельными координатами.
2. glBegin() и glEnd() — моветон. Есть много способов нарисовать прямоугольник, а вот если этот код придется портировать на OpenGL-ES, то glBegin() и glEnd() попортят вам крови. Так что это дело лучше не использовать, тем более что эти 6 строк рисования можно заменить одной, glDrawArrays() например.
Глубже не смотрел, лень.
1. glOrtho(0,500,500,0,1,0); // подготавливаем плоскости для матрицы
это конечно сильно :) glOrtho умножает текущую матрицу на ортогональную матрицу, ее аргументы — координаты плоскостей отсечения слева, справа, снизу, сверху, сблизи и издалека. эти координаты относительны, если принять за единицу ширину и высоту вашего viewport, то будет примерно так: glOrtho( 0, 1, 0, 1, 0, 1);
в приведенном коде мало того, что все вверх ногами, так еще и кто-то перепутал координаты векторов с пиксельными координатами. Оно-то рисует, но вычисления происходят при этом абсолютно дикие. Соответственно и glVertex2f() оперирует этими «дикими» пиксельными координатами.
2. glBegin() и glEnd() — моветон. Есть много способов нарисовать прямоугольник, а вот если этот код придется портировать на OpenGL-ES, то glBegin() и glEnd() попортят вам крови. Так что это дело лучше не использовать, тем более что эти 6 строк рисования можно заменить одной, glDrawArrays() например.
Глубже не смотрел, лень.
Насчёт glBegin/glEnd поддерживаю. А вот насчёт первого не так всё однозначно. Если мы строим графический интерфейс, то пиксельные координаты вполне нормальное явление, почему вычисления «дикие»? Почему не оперировать пикселами, если так удобнее? Лично я не вижу смысла принимать ширину и высоту за 1 и пересчитывать координаты мышки вручную, если это может делать OpenGL, причём этап умножения на матрицу будет происходит в любом случае, поэтому ручное деление — это как раз лишнее действие.
Послушайте, но это даже смешно. Я не хочу доказывать, что glOrtho(), как и все остальное в OpenGL работает в векторных координатах. Исключения есть, но они в основном касаются некоторых расширений языка (например работа с GL_TEXTURE_RECTANGLE_EXT происходит в пиксельных координатах).
Дело вовсе не в удобстве, почитайте Ред Бук, базовые понятия о координатах.
Дело вовсе не в удобстве, почитайте Ред Бук, базовые понятия о координатах.
Я так понимаю заминусовал некий гуру OpenGL, не читавший Ред Бук. ;)
Ну-ну. Минусовать моё сообщение можно. Вот только мозгов это вряд ли прибавит.
Ну-ну. Минусовать моё сообщение можно. Вот только мозгов это вряд ли прибавит.
Я разве говорил обратное? Что OpenGL работает не с векторными координатами. Просто если мы в OpenGL делаем некое подобие пользовательского интерфейса, то сделать так, чтобы векторные координаты соответствовали пиксельным — это нормальная практика. Иначе прийдётся прогонять нормализованные координаты мышки через матрицу обратную к текущей, чтобы получить векторные координаты. Зачем?
Если нужно нарисовать два прямоугольника, то можно использовать координаты, приведенные к пиксельным. При этом, если уж на то пошло, я бы использовал gluOrtho2D(0, width, 0, height);
потому что в этом случае даже после различных glTranslatef() координат они останутся целочисленными, что подходит к пикселям.
Если же вам нужно отрендерить более сложную сцену, с возможностью зума и пр., — нормальная практика как раз использовать координаты создаваемого мира, а не пиксельные.
потому что в этом случае даже после различных glTranslatef() координат они останутся целочисленными, что подходит к пикселям.
Если же вам нужно отрендерить более сложную сцену, с возможностью зума и пр., — нормальная практика как раз использовать координаты создаваемого мира, а не пиксельные.
В исходниках (которые скачать, а не в статье приведены) так и есть — width x heigth. В статье не расчитано, что размер меняется, а жёстко 500х500. Ну, да, статью новичок в OpenGL писал.
Вся ирония сейчас в том, что я написал ради примера 2 строки:
Если кто смотрел исходный код, то там изначально было:
где wax и way это текущий размер нашего окна, point — количество набранных очков.
P.S. Ну буду доказывать, что этот вариант правильный, то сам факт того, что половину комментариев данного поста крутятся вокруг этих строк.
glOrtho(0,500,500,0,1,0);
renderText(10, 10 , 0, QString::fromUtf8("Вы набрали %1 очков:").arg(17), QFont() , 2000);
Если кто смотрел исходный код, то там изначально было:
glOrtho(0,wax,way,0,1,0);
renderText(10, 10 , 0, QString::fromUtf8("Вы набрали %1 очков:").arg(point), QFont() , 2000);
где wax и way это текущий размер нашего окна, point — количество набранных очков.
P.S. Ну буду доказывать, что этот вариант правильный, то сам факт того, что половину комментариев данного поста крутятся вокруг этих строк.
Да, вы правы, ляпов конечно много. Но если сделать то же самое по всем канонам и академично, любой новичок подумает что Qt+OpenGL это невероятно сложно и не для среднего ума. А так по крайней мере попробуют, why not?
Для новичков придумали Qt3D
Программирование вообще такая штука — не для среднего ума.
Профессиональное — да. Любительское — для всех.
Что такое любительское программирование?
Давайте тогда сделаем еще любительскую нейро-хирургию,
любительскую атомную энергетику,
и любительскую космонавтику.
Да и даже касательно любителей, ответьте, почему тот, кто выращивает, скажем, морковку на даче для себя, не кричит на всю округу, что он агроном, и не бежит повышать урожайность морковки к своему соседу за деньги. Но есть масса людей, которые прочитав половину книжки «С++ за 21 день», уже заявляют: «Я программист!» И большинство из них скромно не добавляет слово «любитель».
Давайте тогда сделаем еще любительскую нейро-хирургию,
любительскую атомную энергетику,
и любительскую космонавтику.
Да и даже касательно любителей, ответьте, почему тот, кто выращивает, скажем, морковку на даче для себя, не кричит на всю округу, что он агроном, и не бежит повышать урожайность морковки к своему соседу за деньги. Но есть масса людей, которые прочитав половину книжки «С++ за 21 день», уже заявляют: «Я программист!» И большинство из них скромно не добавляет слово «любитель».
>… программирования C++) + OpenQL… [2 строчка]
Возможно ошибаюсь, разве не OpenGL?
Если качать приложение для Windows то «глючно» работает, постоянно мерцает.запуск был под win7 Ult. 32bit
У меня и того хуже: s017.radikal.ru/i431/1111/0d/3291aaa7e931.png
> Обязательно прочесть про QTt
Обнаружил, что не знаю, что такое QTt, срочно пошёл читать, и ничего про QTt не нашёл.
Это какая-то новая технология?
Обнаружил, что не знаю, что такое QTt, срочно пошёл читать, и ничего про QTt не нашёл.
Это какая-то новая технология?
Не нужно показывать свое остроумие и об опечатках говорить в комментариях. Ссылка явно указывает на Qt, если Вы не заметили.
Не знаю, почему вы решили, что это остроумие и сразу наставили минусов.
1) Т.к. в тексте явно была опечатка, после того, как исправлял регистр буквы «t»
2) Я в этой теме никому минус не ставил и Вам в том числе вот скрин: s017.radikal.ru/i440/1111/76/cc5b63ee2de4.jpg
2) Я в этой теме никому минус не ставил и Вам в том числе вот скрин: s017.radikal.ru/i440/1111/76/cc5b63ee2de4.jpg
> Теперь предопределим переменные и методы
> // в описании заголовочного файла
На научном языке это называется объявление полей и методов класса.
Определеняются же здесь только поля, определение методов, соответственно, в файле описания.
> // в описании заголовочного файла
На научном языке это называется объявление полей и методов класса.
Определеняются же здесь только поля, определение методов, соответственно, в файле описания.
А давайте создадим блог «С++ для новичков» ну или «Qt для новичков», а?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Qt+OpenGL — Основы. Часть 1