чтобы когда этот макрос включится #ifdef'ом то я смогу вызывать у классов конструкторы как A_init(.....);

но у меня не получается правильно его определить

Бля, другими словами хочу сделать что-то вроде такого: class A { public: _CTOR(A)(int x, int y) {} }; И вот этот макрос должен заменить конструктор на A_init(int x, int y)

А почему не пашет предложенный метод?

тьфу, то, что есть

Error (active) explicit type is missing ('int' assumed)

точно

сейчас попробую

спасибо

Покажи)

#ifdef C_CODE #define _CTOR(NAME) void NAME##_init #endif

Точно

если кому интересно, вот конечная версия: #ifdef C_CODE #define _CTOR(NAME) void NAME##_init #define _CTOR_CALL(TYPE, NAME) TYPE NAME; NAME.TYPE##_init #endif #ifdef CPP_CODE #define _CTOR(NAME) NAME #define _CTOR_CALL(TYPE, NAME) TYPE NAME #endif

тащем-то если добавить замену класса на структуру, то можно наебать систему и использовать классы в си коде

правда они кастрированные будут

только в сишном коде в структуре напрямую функцию не обьявить

только указатель

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

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

еще для расчетов контрольной суммы заранее известных тебе пакетов

Конфигурация распиновок лежит отдельно?

Интересно, спасибо

сами пины это гора шаблонных параметров, сама конфигурация распиновок это структура по факту ничего не имеющая, но внутри нее находятся тайпдефы. щас я скину пример

http://pastebin.com/GQy2izC7 вот инициализация херовой горы пинов в микросхеме

это конкретно класс отвечающий за микросхему ksz8051

gpio это шаблонный класс он тут https://github.com/ThatEmbeddedGuy/Stm32-Template-Gpio-Library/blob/master/Gpio.h

но это опять же микроконтрллеры, там специфичная работа с регистрами

и прямая работа с железом

в итоге инициализация микросхемы с поднятием стека tcp ip внутри контроллера выглядит так

typedef ksz8051Pins< PortA,2, //Mdio PortC,1, //Mdic PortC,4, //Rxd0 PortC,5, //Rxd1 PortB,0, //Rxd2 PortB,1, //Rxd3 PortA,7, //Rxdv PortA,1, //Rxdclk PortB,10, //Rxerr PortA,4, //Int PortB,12, //Txd0 PortB,13, //Txd1 PortC,2, //Txd2 PortE,2, //Txd3 PortB,11, //Txen PortC,3, //Txclk PortE,3 //Reset > pinlist; ksz8051<pinlist> instance; MacDma macdma(&instance); macdma.Init(); tcpip_init( NULL, NULL );

Сначала подумал что Хренова гора - преувеличение, ан нет) спасибо за use case

http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8051MNLU_RNLU.pdf

там в конкретно этой микросхеме 32 ноги, их нужно куда то подключать) у каждой ноги микроконтроллера есть еще 5 или 6 параметров (вход это или выход, скорость, подтяжка и.т.п.)

в итоге получаем реально гору данных которые нужно хранить, а потом зачем то передавать в конструктор

в итоге мы передаем их compile time

Выглядит крайне уместно

Спасибо за пример)

незачто)

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

в конечном приложении есть constexpr

Аналогичная позиция )

для зума в точке, где курсор мыши расположен, как нужно менять камеру? glViewport (mouseX, mouseY, glutGet(GLUT_INIT_WINDOW_WIDTH), glutGet(GLUT_INIT_WINDOW_HEIGHT)); gluOrtho2D (-glutGet(GLUT_INIT_WINDOW_WIDTH)*zoomFactor, glutGet(GLUT_INIT_WINDOW_WIDTH)*zoomFactor, -glutGet(GLUT_INIT_WINDOW_HEIGHT)*zoomFactor, glutGet(GLUT_INIT_WINDOW_HEIGHT)*zoomFactor);

если так делаю, то зум правильный только в левой верхней части окна

зачем

просто умножь на матрицу переноса (0, 0, -1)

или (0, 0, 1)

просто не знаю что такое матрица переноса и что на неё умножать

а как ты в опенгл попал вообще.

а

тебе в точку мыши надо

задачка поинтересней, там надо перенос по всем осям

если ты про линал то знаю

а что на что в гл умножать нет, но это лирика

а перенос и объекта и камеры?

матрицы везде.

просто не знаю что такое матрица переноса и что на неё умножать

лолшто

неправильно выразился, endor.

перенос делать только всего рисунка glTranslat ом? просто много вариантов решения вроде как, и вьюпортом, и глЛукАутом, и глПерспективойй

я хз

попробуй в 2003 поспрашивать

перенос делать только всего рисунка glTranslat ом? просто много вариантов решения вроде как, и вьюпортом, и глЛукАутом, и глПерспективойй

Срочно надо? Если не, я завтра вечером поковыряю

не срочно

для зума в точке, где курсор мыши расположен, как нужно менять камеру? glViewport (mouseX, mouseY, glutGet(GLUT_INIT_WINDOW_WIDTH), glutGet(GLUT_INIT_WINDOW_HEIGHT)); gluOrtho2D (-glutGet(GLUT_INIT_WINDOW_WIDTH)*zoomFactor, glutGet(GLUT_INIT_WINDOW_WIDTH)*zoomFactor, -glutGet(GLUT_INIT_WINDOW_HEIGHT)*zoomFactor, glutGet(GLUT_INIT_WINDOW_HEIGHT)*zoomFactor);

я чуть выше небольшую телегу писал про это. не помогло?

есть тут шарящие в winapi? проблема такая: создаю окно библиотекой glfw, на некоторых этапах я могу позволить пользователю изменить его размеры, но потом размер изменяться не должен. соответственно я ликвидирую ws_sizebox и ws_maximizebox. однако получается такая фигня: если пользователь развернул окно на весь экран (как через sc_maximize, например) можно даблкликнуть по заголовку окна и случится sc_restore и размер окна изменится чего я допустить не могу

заменять wndproc нет возможности т.к. эта функция принадлежит glfw

А в глфв разве нельзя отключить это?

Или в колбеке ресайза ресайзить обратно, хотя это костыльно

есть тут шарящие в winapi? проблема такая: создаю окно библиотекой glfw, на некоторых этапах я могу позволить пользователю изменить его размеры, но потом размер изменяться не должен. соответственно я ликвидирую ws_sizebox и ws_maximizebox. однако получается такая фигня: если пользователь развернул окно на весь экран (как через sc_maximize, например) можно даблкликнуть по заголовку окна и случится sc_restore и размер окна изменится чего я допустить не могу

Можно сделать SetWindowLong

И запретить разворот окна

так через него и делается

А в глфв разве нельзя отключить это?

glfw может только при создании окна такие штуки отключать, потом уже никак.

А еще можно перехватить сооьщение WM_GETMINMAX и в нем возвращать одинаковые минимальные и максимальные размеры окна

у меня другая идея - сделать свою wndproc и перехватывать там нужное событие, а остальное сливать в wndproc от glfw где оно успешно дойдет до defaultwndproc

только можно ли текущий wndproc узнать?

и мне как-то ссыкотно до такой степени потрошить glfw, мне кажется на следующем релизе библиотеки мой билд сдомается

хотя они и дают native access

только можно ли текущий wndproc узнать?

Можно. GetWindowLong(GWL_WNDPROC)

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

черт его знает) Александреску, наверное

Кстати