библиотеки в маркет - как правильно готовить ?
- судя по документации, нельзя чтобы API в параметрах принимал указатели, невзирая на то что внутри MQL,снаружи MQL и всё это указатели на экз.класса; То есть придётся порождать класс-хендер который должен "прятать" сей указатель ?
Внимательно прочитал правила. Кроме ограничений по использованию ДЛЛ и очевивидных - типа, не должен приносить вред, ничего такого не увидел.
Где это написано (про указатели)? Мож не докопался.
Внимательно прочитал правила. Кроме ограничений по использованию ДЛЛ и очевивидных - типа, не должен приносить вред, ничего такого не увидел.
Где это написано (про указатели)? Мож не докопался.
в справке по директиве #import :
Так как импортируемые функции находятся вне компилируемого модуля, компилятор не может проверить правильность передаваемых параметров. Поэтому, во избежание ошибок выполнения, необходимо точно описывать состав и порядок параметров, передаваемых в импортируемые функции. Параметры, передаваемые в импортируемые функции (как из EX4, так и из DLL-модулей), могут иметь значения по умолчанию.
В импортируемых функциях в качестве параметров нельзя использовать:
·указатели (*);
·ссылки на объекты, содержащие динамические массивы и/или указатели.
В импортируемые из DLL функции нельзя передавать в качестве параметра классы, массив строк или сложные объекты, содержащие строки и/или динамические массивы любых типов.
в справке по директиве #import :
ИМХО, для ех4-5 библиотек некритично (мы же о Маркете). Классы передавать можно, а все остальное через них решается. Даже проще получается класс передал, и весь импорт.)
ЗЫ С библиотеками тоже не работал. Но вроде, по описанию, так.
зы2 Надо, кстати, на днях попробовать.
ИМХО, для ех4-5 библиотек некритично (мы же о Маркете). Классы передавать можно, а все остальное через них решается. Даже проще получается класс передал, и весь импорт.)
ЗЫ С библиотеками тоже не работал. Но вроде, по описанию, так.
зы2 Надо, кстати, на днях попробовать.
первые два вопроса сняты. Указатели на экземпляры использовать можно, но export/import классов и интерфейсы делаются немного через зад :-) https://www.mql5.com/ru/articles/362 и в особенности https://www.mql5.com/ru/forum/127
вкратце:
- - делается класс публичного интерфейса (class Foo) в котором: конструкторы protected, а методы виртуальны
- - в библиотеке от него производится приватный класс (class PrivateFoo: public Foo)
- - из библиотеки экспортируются функции ( Foo *NewFoo(); ) которые будут служить заменой "new Foo", или надо строить фабрики
- 2012.01.06
- //www.mql5.com/ru/users/sergeev">
- www.mql5.com
Указатели на экземпляры использовать можно, но export/import классов и интерфейсы делаются немного через зад :-) https://www.mql5.com/ru/articles/362 и в особенности https://www.mql5.com/ru/forum/127
вкратце:
- - делается класс публичного интерфейса (class Foo) в котором: конструкторы protected, а методы виртуальны
- - в библиотеке от него производится приватный класс (class PrivateFoo: public Foo)
- - из библиотеки экспортируются функции ( Foo *NewFoo(); ) которые будут служить заменой "new Foo", или надо строить фабрики
))) Как раз сейчас сижу и варганю нечто в этом роде. Советник должен вызывать по таймеру функции класса из ех5 library. Пока не идет, но если есть наработки - бросаю и иду спать.))) Завтра докуем.)
есть способ упрятать приватную часть в библиотеку и при этом дозволить пользователю наследовать класс. Через делегирование. Но это весьма криво и развивать поддерживать такие библиотеки будет то ещё удовольствие.
получилось так:
- в публичном mqh делается "почти" абстрактный класс FooAbstract в котором: конструкторы protected, все методы виртуальны но вбиты заглушки, полей нет, к данным доступ исключительно через сетеры/гетеры
- в библиотеке пишется реализация class FooCore:FooAbstract, конструкторы переезжают в public и на них пишется экспортируемая функция (на замену new FooCore)
- далее опять в mqh делается наконец-то class Foo:FooAbstract с единственным полем FooAbstract *core куда вручную делегируются все методы.
теперь пользователь может производить классы от Foo :-) но есть конечно вопросы про память и скорость..
есть способ упрятать приватную часть в библиотеку и при этом дозволить пользователю наследовать класс. Через делегирование. Но это весьма криво и развивать поддерживать такие библиотеки будет то ещё удовольствие.
получилось так:
- в публичном mqh делается "почти" абстрактный класс FooAbstract в котором: конструкторы protected, все методы виртуальны но вбиты заглушки, полей нет, к данным доступ исключительно через сетеры/гетеры
- в библиотеке пишется реализация class FooCore:FooAbstract, конструкторы переезжают в public и на них пишется экспортируемая функция (на замену new FooCore)
- далее опять в mqh делается наконец-то class Foo:FooAbstract с единственным полем FooAbstract *core куда вручную делегируются все методы.
теперь пользователь может производить классы от Foo :-) но есть конечно вопросы про память и скорость..
Я ночью отрабатывал нечто близкое к https://www.mql5.com/ru/articles/362. Вы меня вовремя остановили. )
Если мы не можем наследовать библио класс, то наследование пользователем я вижу так. Создается класс А вызывающий библиотечный - пользователь с ним и имеет дело. В нем уже виден весь функционал библиотечного ( Можно предварительно заместить в нем все методы библиотечного.). Его (А) уже и наследовать.
- 2012.01.06
- //www.mql5.com/ru/users/sergeev">
- www.mql5.com
Зачем protected конструкторы? Почему не банальная имплементация интерфейса?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
ни разу пока не "испекал" библиотек (исключая тупой интерфейс к DLL) годных к распространению через Маркет, но почему-бы и нет...
отсюда пачка вопросов:
- судя по документации, нельзя чтобы API в параметрах принимал указатели, невзирая на то что внутри MQL,снаружи MQL и всё это указатели на экз.класса; То есть придётся порождать класс-хендер который должен "прятать" сей указатель ?
- как правильно делать интерфейсы : если ничего кроме "public:" юзера волновать не должно, как и куда упрятываются прочие поля ? Класс-конверт и делегирование ??
- как разруливаютcя (и разруливаются ли вообще) конфликты версий ? Если библиотека v2 стала несовместимой с v1 (интерфейсы поменялись) - по хорошему должнО чтобы у юзера были обе версии, но есть смутные сомнения, что это не так.
или правильно "забить на ОО и классы" и делать интерфейсы-заглушки а-ля Си ?? (а зачем тогда весь сыр-бор)
PS/ вообще хотелось-бы увидеть хороших практик по разработке библиотек MQL.