[Rgdengine-design] From Anubis.

[Anubis <ann...@fr...>]

Всем привет! Это ответ на письмо Ангела:

>Хмм, пора договорится о code-styling'е.

Пора... Но мне, если честно, все равно, как писать (лишь бы точно сказали, "как":) Так что, когда договоритесь, то пришлите мне примерчик
идеального кода:) Вот, как я пишу:
Это файл a_configfile.h:
/****************************************************

*                      Copyright (c) 2004 - A&A Corporation                            *

*  A_ConfigFile header file in which CA_ConfigFile class is defined *

*****************************************************/

#ifndef _A_Config_File_h__

#define _A_Config_File_h__

#include "A_Object.h"

class CA_ConfigFile : public CA_Object

{

public:

    CA_ConfigFile(char*);

    char opened, notend;

    char *command, *prevcommand;

    char *GetNextCommand();

    char *GetCommand();

    FILE *file;

    virtual ~CA_ConfigFile();

};

#endif //#ifndef _A_Config_File_h__

И пример реализации метода:

char *CA_ConfigFile::GetNextCommand()

{

    delete[]prevcommand;

    prevcommand = new char[strlen(command)+1];

    memcpy(prevcommand, command, strlen(command)+1);

    command = GetCommand();

    while((!command)&&(notend)) command = GetCommand();

    return prevcommand;

}

Ну, это так, если интересно...

>Чтение и запись. А что особенного, так своп-файл работает.
Ясно...

>rdrlsn> У меня core.h нет, я не могу вносить туда изменения... А как тогда надо файл-менеджер определять?
>Сейчас Jihar идею подкинул, цитирую:
>Jihar>мм... Вот какая идея в голову пришла. В принципе пакетный файл у тебя
>Jihar>и есть файловый менеджер, верно? Идея ясна? Ессно поясню немного
>Jihar>При создании ядра будем указывать типа:
>Jihar> core->CreateFileManager(Class_Usual, 'c:\games\rda');
>Jihar>Обычный манагер. Путь - откуда ему начинать искать. При открытии файла
>Jihar>ты будешь писать что-то вроде
>Jihar> file_man->OpenFile('data\textures\cube.jpg');
>Jihar>Что-то вроде. Ессно все условно, но думаю мысть понятна.
>Тут есть одна проблемка: file_man->OpenFile должен будет вернуть хэндл
>файла, который потом будем использовать для чтения и т.п. В принципе
>он может вернуть объект IFile, который будет использоваться для работы
>с файлом, либо сам FileManager становится привязан к открытому файлу,
>и работает только с ним. В таком случае повторное открытие любого
>файла (без закрытия рабочего) должно быть запрещено. Если использовать
>2-е решение с привязкой файла к менеджеру, логичнее было бы отказаться
>от название File manager и перейти к более подходящему.

имхо OpenFile должен возвращать IFile*, и открывать сколько угодно файлов одним менеджером... Иначе какой это нафиг менеджер, если только с одним файлом работает:)

>Jihar> core->CreateFileManager(Class_PacketByAngel, 'c:\games\rd\file.pba');
>Jihar>Не обычный манагер. В качестве пути принимает имя пакетного файла,
>Jihar>который и содержит в себе данные. Использование:
>Jihar> file_man->OpenFile('data\textures\cube.jpg');
>Jihar>Ессно использование полностью аналогичное.
>Jihar>Для включения поддержки какого-либо норвого пакетного формата,
>Jihar>достаточно написать плагин и все.
>Тут возникнет та же проблема. Либо метод OpenFile вернет объект IFile
>для работы с данными, либо менеджер привяжется к одному файлу. Вообщем
>думать надо.
>imho, необходимо различать работу с файлом на диске и в пакете. Т.е.
>не выгодно для работы с этими файлами использовать один интерфейс.
>Пакетные файлы придумывались для ускорения работы с данными, а если
>при открытии нового файла из пакета, мы будем создавать новый объект,
>какое же тут ускорение? Думаю нельзя вводить понятие "open file from
>packfile", можно лишь позиционировать менеджер на заданной записи
>(файле).

А тут мне и вариант Jihar'а нравиться, и твое замечание в тему... Прямо не знаю, за что и проголосовать:)

>>> Имхо, нет необходимости использования путей поиска ресурсов. В моем
>>> понимании всё должно быть упаковано в один файл, в крайнем случае
>>> должно быть в одной папке. Хотя тут кому как удобней, не
>>> принципиально.
>rdrlsn> Jihar сказал, что надо...
>Надо, так надо :) Я не против.

А может и не надо:) В общем, у себя в программах я реализовываю без списка путей, хотя это может быть и полезная вещь...
 
>>>J>         virtual bool RGDE_CALL DeleteFile(char*) = 0; //Deletes a file, passing throw the search path list.
>>>J>                                                       //arguments: file name.
>>> А зачем это если не секрет?
>rdrlsn> Секрет:) Не нужно, наверное, это я сглючил:)
>Можно конечно для удаления свопа, но я просто обнулял его размер.

Пускай останется... Не жалко...

>>> J> #ifndef _IFile_H_
>>> J> #define _IFile_H_
>>> Все интерфейсы относящиеся к уровню ядра логичнее объявлять в одном
>>> файле.
>rdrlsn> Ну и файлик тогда получиться!!!
>Не, не большой. На уровне ядра всего-то интерфейсов 5 будет.

А что это за интерфейсы? И на уровне чего будут остальные?

>rdrlsn> Однако один может сам использовать другой, но имхо лучше, если на каждый объект по файлу -- так удобнее, и файлы не очень большие.
>Так куча файлов будет. Вот за это я не люблю DX, взгляни на ОГЛ, вот
>где порядок.

Порядок у них только потому, что там куча объявлений функций, а если это будут объявления классов с реализациями всех методов, то имхо код будет дико нечитабельный. А так: файл configfile.h -- класс CConfigFile, файл renderer.h -- класс CRenderer и т.д. все понятно и удобно. А все файлы распихать по куче директорий пятерной вложенности и все будет очень серьезно выглядеть:)

>>> Чем SEEK_CUR, SEEK_SET, SEEK_END неустраивает? Так вобщем-то все
>>> привыкли.
>rdrlsn> Так ведь будет конфликт с уже определенными SEEK_CUR, SEEK_SET, SEEK_END?
>А нэймспейсы зачем? К тому же stdio будет подцеплятся только в
>реализации файловых объектов.

Ну дык в реализации встретиться что-нибудь, типа этого:

CWinFile::Seek(position, int num)
{
 if(position==SEEK_CUR) fseek(file, SEEK_CUR, num) ...
 ...
}

Неужели не будет конфликта?

>rdrlsn> А как же недвоичный вывод? Вручную float'ы в строки превращать?
>А зечем это? Если в лог или настройки, то fprintf.

А зачем тогда вообще IFile?:) Если файл карты или модельки, то fwrite:) Если уж делать единый интерфейс для работы с файлами, так делать...

>>>            Еще не учел, что файл может быть пакетный открыт. Надо
>>>            добавить методы для позиционирования на заданной записи и
>>>            т.п.
>rdrlsn> Не понял... Не знаю, что это такое -- все предложение в целом:(
>Ну пакетный файл - это файл в котором упакованы множество других файлов
>(см. квейковский pak).

Ясно, но не совсем... А после позиционирования на записи мы будем работать с этим IFile так, как будто это обычный открытый файл, тот, который лежит на данной позиции в пакетном?

>>> Вывод один: сначала надо выработать стандарты. У меня недели две в
>>> голове летает идея о RGD Evangelion - сборник спецификаций и правил
>>> для разработчиков и основная документация по движку.
>>> Для начала необходимы следующие главы:
>>>     - Project managing
>>>     - Architecture specification
>>>     - Code style
>>>     - Debugging
>>>     - Interfaces specification

>rdrlsn> Может и надо... Я не знаю, я в этом опыта не имел...
>Тут вообщем-то ни у кого реального опыта нету :)

Ну, тогда, вперед...:)

Anubis.