QT, конфликтующий с Ликованием

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

Что касается геттеров и сеттеров, то это зависит от того, какой язык вы используете. В некоторых языках это может быть довольно многословно. Лично я предоставляю геттеры и сеттеры только для открытых свойств и / или если изменение свойства связано с логикой, а не просто установкой / получением свойства.

5
задан James 29 May 2009 в 14:34
поделиться

3 ответа

Краткий ответ: используйте glew. он отлично работает с QT.

0
ответ дан 14 December 2019 в 13:45
поделиться

Это все еще не так чисто, как хотелось бы, но он, по крайней мере, строит и запускает без взлома GLee.h.

После всего остального, #include qobject.h, GLee.h и qgl.h (в указанном порядке).

Итак, файл заголовка может выглядеть как

...blah...
...other #includes

#include <qobject.h>
#include "GLee.h"
#include <qgl.h>

class MyGlWidget : public QGLWidget
{
...
}

, тогда исходный файл будет # включать этот файл последним.

3
ответ дан 14 December 2019 в 13:45
поделиться

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

( Edit: Я больше не подозреваю, что после прочтения одного из ваших комментариев - если все, что вы вытащили из GLee.h, это проверки и директивы #error , все должно работать ... Возможно.)

Насколько я могу судить, проблема связана с попыткой Qt определить перечисления, которые конфликтуют с макросами препроцессора X. В частности, CursorShape определяется Xh как 0, а затем qnamespace.h как перечисление, что приводит к довольно бесполезному сообщению об ошибке «ошибка: ожидаемый идентификатор перед числовой константой»

Более чистый способ делать то, что вы попытка сделать это включить файлы в этом порядке, и с этими макросами undefined:

#include "qgl.h"
#undef __glext_h_
#undef __glxext_h_
#undef __gl_h_
#include "GLee.h"

Это не ' t требует исправления GLee.h, но может дать неожиданные результаты в зависимости от того, почему GLee.h хочет быть включен первым.

Лучшим решением было бы включить GLee.h и qgl.h в отдельные модули компиляции, но это может невозможно.

Между прочим, хорошая стратегия отладки для такого рода проблем - передать -E в gcc - это даст вам предварительно обработанный исходный код, который вы можете изучить, чтобы найти проблемную строку. В этом случае имя перечисления было заменено константой 0, что давало понять, что имя определялось где-то еще. При поиске имени перечисления в / usr / include выяснилось, что оскорбительный заголовок - Xh. Честно говоря, оскорбительный элемент здесь - Qt - разработчики должны знать лучше, чем использовать константы X11 в качестве идентификаторов в кроссплатформенной структуре.

h хочет быть включен первым.

Лучшим решением было бы включить GLee.h и qgl.h в отдельные блоки компиляции, но это может оказаться невозможным.

Между прочим, хорошая стратегия отладки для такого рода Проблема заключается в том, чтобы передать -E в gcc - это даст вам предварительно обработанный исходный код, который вы можете изучить, чтобы найти неправильную строку. В этом случае имя перечисления было заменено константой 0, что давало понять, что имя определялось где-то еще. При поиске имени перечисления в / usr / include выяснилось, что оскорбительный заголовок - Xh. Честно говоря, оскорбительный элемент здесь - Qt - разработчики должны знать лучше, чем использовать константы X11 в качестве идентификаторов в кроссплатформенной структуре.

h хочет быть включен первым.

Лучшим решением было бы включить GLee.h и qgl.h в отдельные блоки компиляции, но это может оказаться невозможным.

Между прочим, хорошая стратегия отладки для такого рода Проблема заключается в том, чтобы передать -E в gcc - это даст вам предварительно обработанный исходный код, который вы можете изучить, чтобы найти неправильную строку. В этом случае имя перечисления было заменено константой 0, что давало понять, что имя определялось где-то еще. При поиске имени перечисления в / usr / include выяснилось, что оскорбительный заголовок - Xh. Честно говоря, оскорбительный элемент здесь - Qt - разработчики должны знать лучше, чем использовать константы X11 в качестве идентификаторов в кроссплатформенной структуре.

Между прочим, хорошая стратегия отладки для такого рода проблем - передать -E в gcc - это даст вам предварительно обработанный исходный код, который вы можете изучить, чтобы найти проблемную строку. В этом случае имя перечисления было заменено константой 0, что давало понять, что имя определялось где-то еще. При поиске имени перечисления в / usr / include выяснилось, что оскорбительный заголовок - Xh. Честно говоря, оскорбительный элемент здесь - Qt - разработчики должны знать лучше, чем использовать константы X11 в качестве идентификаторов в кроссплатформенной структуре.

Между прочим, хорошая стратегия отладки для такого рода проблем - передать -E в gcc - это даст вам предварительно обработанный исходный код, который вы можете изучить, чтобы найти проблемную строку. В этом случае имя перечисления было заменено константой 0, что давало понять, что имя определялось где-то еще. При поиске имени перечисления в / usr / include выяснилось, что оскорбительный заголовок - Xh. Честно говоря, оскорбительный элемент здесь - Qt - разработчики должны знать лучше, чем использовать константы X11 в качестве идентификаторов в кроссплатформенной структуре.

1
ответ дан 14 December 2019 в 13:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: