Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А концепция это только для вас на поверхности………
Имел в виду, что предложение (концепция) "поэкспериментировать самостоятельно" - не требует озвучивания, это и так понятно. Игоря я прекрасно понял и сам обдумывал этот вариант, по той причине, что он является самым простым, но мне имхо он не очень подходит, по описанным выше обстоятельствам.
Тут вот в чём загвоздка: есть программы - 10 штук, которые пишут в файл и есть другие 10, которые из него читают, не хочется чтобы каждая читающая программа каждый раз обрабатывала весь накопленный массив данных за всё время.
А в этом случае вообще лучше отказаться от файла и работать с базой SQLite. Это очень похоже на работу с файлами, так-же можно создавать в общей папке, но обработка, поиск и удаление строки гораздо проще.
Сергей, если Вам не нужно смотреть в этот файл глазами, то пишите в него сразу массив своих данных
затем в любой момент извлекаете массив из файла
И работайте с массивом как хотите. Удаляйте последний элемент, добавляйте.
А в этом случае вообще лучше отказаться от файла и работать с базой SQLite. Это очень похоже на работу с файлами, так-же можно создавать в общей папке, но обработка, поиск и удаление строки гораздо проще.
Так а MQL4 поддерживает работу с SQLite, там вроде только TXT и CSV формат?
Доступ к файлу делаю через символическую ссылку, там не принципиально где лежит сам файл, в какой папке.
Сергей, если Вам не нужно смотреть в этот файл глазами, то пишите в него сразу массив своих данных
затем в любой момент извлекаете массив из файла
И работайте с массивом как хотите. Удаляйте последний элемент, добавляйте.
Так а в чём разница, массив же в любом случае в файл записывается построчно или в данном случае есть возможность удалить хотя бы последний или первый элемент, массив=строка?
Не совсем понял вопрос. Вы имеете массив данных, над которым можете производить любые манипуляции с легкостью. И простую запись и чтение из файла в четыре строчки кода. Это и есть преимущество. Зачем задумываться как устроена запись массива в файл?
Сделали нужные изменения в массиве, выгрузили изменённый массив в файл и всё.
Не совсем понял вопрос. Вы имеете массив данных, над которым можете производить любые манипуляции с легкостью. И простую запись и чтение из файла в четыре строчки кода. Это и есть преимущество. Зачем задумываться как устроена запись массива в файл?
Сделали нужные изменения в массиве, выгрузили изменённый массив в файл и всё.
Тут сложность заключается в том, что с одним и тем же массивом должны будут работать одновременно 20 приложений, и какая именно отредактированная версия массива является актуальной в данный момент времени определить не представляется возможным.
Допусти первый советник отредактировал массив и опубликовал его, а поверх него тут же записывается уже другая версия от другого советника, но без учёта редакции предыдущего, и всё... путаница...
Если бы например каждый советник мог удалить относящуюся к нему строку после её прочтения, то тогда всё складывается - никто никому не мешает и файл при этом не перегружается лишними данными, а каждый раз наперегонки записывать отредактированный массив, то тогда непонятно как синхронизировать актуальность данных от каждого из 20-ти советников.
Управление доступом нескольких советников к одному файлу это и есть то, о чём Вам нужно подумать.
Вот Вам для размышления:
1. Чтобы одновременно два советника не работали с одним файлом, создайте ещё один файл-флаг. Когда этот файл не существует, советник имеет право открывать файл с данными, перед этим создавая файл-флаг, показывая другим, что пока занято. После чтения-записи советник удаляет файл-флаг. Теперь данные свободны для работы любого другого советника.
2. Вы можете завести переменные для сбора информации о любых советниках, которые пользовались данными этого массива. Эти переменные записывайте в этот же файл.
3. Вместо обычного массива создайте массив структур, который включает различные типы данных и очень нагляден.
Управление доступом нескольких советников к одному файлу это и есть то, о чём Вам нужно подумать.
когда нескольким советникам требуется писать+дописывать+выбирать+читать один набор данных, то волей неволей задействуются базы данных.
как-бы можно накостылить через "глобальные переменные" и файлы-флаги, но чьёрт подери, зачем ?
это стезя СУБД. Разных, реляционных, NoSQL и прочих, но это их. И там в их механике всё отлажено годами-десятилетиями. Все локи-флаги-семафоры-мьютексы.
Пытаться повторить это дико напрасная трата времени.