Сколько байт занимает один бар в hst файле

 

Необходимо внешней программой проверить сколько баров есть в истории по определенному инструменту и таймфрейму.


Например, у меня Gold H1 имеет 2520 баров, а файл GOLD60.hst занимает 111028 байт, т.е. примерно 44.059 байт на один бар. Если предположить, что один бар занимает 44 байта, тогда заголовок должен иметь длину 111028 - 2520 * 44 = 148 байт.


Это верно или нет?

 
В терминале жми F1->Содержанме->Сервис->Архив Котировок
 
JavaDev >>:
В терминале жми F1->Содержанме->Сервис->Архив Котировок

Я знаю, что там есть описание заголовка и отдельных записей. Но, там не указано сколько байт все это хозяйство занимает. Для этого, как минимум нужно знать сколько байт занимает тот или иной тип:


time_t - ?

double - ?

int - ?

char - 1 или два байта, а если формат Unicode или UTF-8, то может достигать и трех байт в зависимости от первых двух битов начальных байтов?


#pragma pack(push,1)
//---- Стандартное представление котировки в базе
struct RateInfo
{
time_t ctm; // текущее время в секундах
double open;
double low;
double high;
double close;
double vol;
};
#pragma pack(pop)


struct HistoryHeader
{
int version; // версия базы
char copyright[64]; // копирайт
char symbol[12]; // инструмент
int period; // период инструмента
int digits; // число знаков после запятой в инструменте
time_t timesign; // временной отпечаток создания базы
time_t last_sync; // время последней синхронизации
int unused[13]; // для будущего использования
};
 

time_t - 8 (?)

double - 8

int - 4

char - 1

 
JavaDev >>:

time_t - 8

double - 8

int - 4

char - 1


Если так, тогда:


Заголовок: 4 + 64 + 12 + 4 + 4 + 8 + 8 + 52 = 156 байт

Бар: 6 * 8 = 48 байт


Итого:


Расчетное значение: 156 + 48 * 2520 = 121116 байт

Реальная длина файла: 111028 байт


Бухгалтерия не сходится.

 
Reshetov >>:

Бухгалтерия не сходится.

Все сходится, если предположить, что time_t занимает 4 байта, а не 8. Тогда получается верно, т.е. как я и предполагал в самом начале: 148 байт - заголовок, а 44 байта - бар.

 
Reshetov писал(а) >>

Все сходится, если предположить, что time_t занимает 4 байта, а не 8. Тогда получается верно, т.е. как я и предполагал в самом начале: 148 байт - заголовок, а 44 байта - бар.

Так и есть... я по привычке про long (миллисенкунды) подумал, а тут unsign int (секунды)... сорри за ошибку...

 
JavaDev >>:

Так и есть... я по привычке про long (миллисенкунды) подумал, а тут unsign int (секунды)... сорри за ошибку...

Cпасибо за инфу. На других hst, с учетом четырехбайтового поля времени, арифметика сходится.

 
Reshetov >>:

Необходимо внешней программой проверить сколько баров есть в истории по определенному инструменту и таймфрейму.


Например, у меня Gold H1 имеет 2520 баров, а файл GOLD60.hst занимает 111028 байт, т.е. примерно 44.059 байт на один бар. Если предположить, что один бар занимает 44 байта, тогда заголовок должен иметь длину 111028 - 2520 * 44 = 148 байт.


Это верно или нет?

Однозначно, размер заголовка 148 байт.

Проверил где-то 50 файлов - во всех заголовок заканчивается последовательностью из 52 нулевых байт, в которую входит и unused[13]. Так что есть еще unused[39] :)

Соответственно, один бар=44 байта, где

time_t = 4 байта 
double  = 8 байт
int  = 4 байта
char = 1 байт

Для проверки возьми размер любого файла, вычти 148 (размер заголовка) и раздели на 44.

Всегда должно получаться целове число = кол-ву баров в истории.

P.S. В терминале не всегда показывает правильно кол-во баров. Понятия не имею, почему :)

Ну вот... пока я проверял файлы, уже сам все вычислил:)

 
_Sergio_ >>:

Однозначно, размер заголовка 148 байт.

Проверил где-то 50 файлов - во всех заголовок заканчивается последовательностью из 52 нулевых байт, в которую входит и unused[13]. Так что есть еще unused[39] :)

Соответственно, один бар=44 байта, где

time_t = 4 байта 
double  = 8 байт
int  = 4 байта
char = 1 байт

Для проверки возьми размер любого файла, вычти 148 (размер заголовка) и раздели на 44.

Всегда должно получаться целове число = кол-ву баров в истории.

P.S. В терминале не всегда показывает правильно кол-во баров. Понятия не имею, почему :)

Ну вот... пока я проверял файлы, уже сам все вычислил:)

вот так правильно, в хелпе есть какие-то несоответствия, я уже не помню, вручную в HEX-радакторе выяснял

код на С#, FieldOffset означает смещение поля от нуля, это шарповские заморочки по парсингу 

  [StructLayout(LayoutKind.Explicit, Size = 148, CharSet = CharSet.Ansi)]
  public unsafe struct HistoryHeader
  {
  [FieldOffset(0)]
  public int version; // версия базы
  [FieldOffset(4)]
  public fixed byte copyright[64]; // копирайт [64]
  [FieldOffset(68)]
  public fixed byte symbol[12]; // инструмент [12]
  [FieldOffset(80)]
  public int period; // период инструмента
  [FieldOffset(84)]
  public int digits; // число знаков после запятой в инструменте
  [FieldOffset(88)]
  public Int64 timesign; // временной отпечаток создания базы
  [FieldOffset(96)]
  public Int64 last_sync; // время последней синхронизации
  [FieldOffset(104)]
  public fixed int unused[11]; // для будущего использования [13]
  }
  // begin index is 148
  [StructLayout(LayoutKind.Explicit, Size = 44, CharSet = CharSet.Ansi)]
  public unsafe struct RateInfo
  {
  [FieldOffset(0)]
  public Int32 ctm;
  [FieldOffset(4)]
  public double open;
  [FieldOffset(12)]
  public double low;
  [FieldOffset(20)]
  public double high;
  [FieldOffset(28)]
  public double close;
  [FieldOffset(36)]
  public double vol;
  }


Причина обращения: