C++: каждый класс в своём модуле. В чём прикол? (3 стр) / Общее / Форум / Программирование игр / GameDev.ru

war_zes
> где здесь ошибка? Ты же рефакторишь... Напомнить тебе какие модули называют "с
> душком"? Или сам вспомнишь что "разросшиеся"?

дело не в том, пишется код с ошибками или нет
дело в том, что код организуется так, что его сложно редактировать. И лично мне не понятен смысл

кстати я не знаю про "модули с душком" и "разросшиеся"

alex-r
Necrys

мечтаю встретить код "не упоротого" С++ программиста

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

#pragma once

class BigClass
{
public:
     class NestedClass1 {};
public:
    class NestedClass2 {};
public:
  enum eConstants {};

private:
    NestedClass1  m_nestedClass1;
    NestedClass2  m_nestedClass2;
};

Но на текущей работе так делать запрещается: XCode некорректно обрабатывает вложенные типы. Поэтому пишу так

#pragma once

namespace BigClassTypes
{
   class NestedClass1 {};

   class NestedClass2 {};

    enum eConstants {};
};

class BigClass
{
private:
    BigClassTypes::NestedClass1  m_nestedClass1;
    BigClassTypes::NestedClass2  m_nestedClass2;
};

Каждый класс в отдельном модуле пишут либо новички, начитавшихся самоучителей по С++ и не видевших реальных проектов, либо джависты у которых каждый класс должен содержаться в отдельном файле с именем как у класса.

З.Ы. Сейчас придет Великий и Ужасный Пушкофф, который раскритикует меня в хлам. Ибо "отцы" так не делают.

Aglaranir

вот в догонку кстати мысль об организации кода
Допустим есть несколько "областей", классы которых сортируются по папочкам.

Вопрос. Не проще ли воспринимать "область" как один файл с несколькими классами, нежели несколько файлов в одной папке?
я думаю разница принципиальная

Aglaranir
> XCode некорректно обрабатывает вложенные типы
вот это я понимаю отличная поддержка стандарта, настоящий энтерпрайз

Может уже кто говорил, но скажу еще раз)) что ты удобно можно было мержить. если над проектом работает куча людей это самое то.

project_manager
> Может уже кто говорил, но скажу еще раз)) что ты удобно можно было мержить.
> если над проектом работает куча людей это самое то.
аргумент

DevilDevil
> мечтаю встретить код "не упоротого" С++ программиста
Не претендую на "неупоротость", но вот пример того, что я имею в виду (часть моего проекта):

#ifndef _SHADER_D3D9_
#define _SHADER_D3D9_

#include "Core.h"
#include "Shader.h"
#include "RenderSystemD3D9.h"

// forward declaration
class RenderSystemD3D9;
class ConstantBufferD3D9;

//----------------------------------------------------------------------------------------------------------------------
// Name: ShaderD3D9
// Desc: Direct3D9 shader resource
//----------------------------------------------------------------------------------------------------------------------
class ShaderD3D9: public Shader
{
    protected:
        IDirect3DDevice9*   m_pDevice;
        ConstantBufferD3D9* m_pConstants;

    public:
        ShaderD3D9( RenderSystemD3D9* pRenderSystem, const char* sCode, uint32 nSize );
        virtual ~ShaderD3D9();

        virtual uint32  GetConstant(const char* sName);
        virtual void    SetConstant(uint32 nHandle, void* pValue, uint32 nSize);
        virtual uint32  GetResourceSlot(const char* sName);

        void            BindConstants();

    private:
        bool            Compile(const char* sCode, uint32 nSize);
};
//----------------------------------------------------------------------------------------------------------------------

//----------------------------------------------------------------------------------------------------------------------
// Name: VertexShaderD3D9
// Desc: Direct3D9 vertex shader resource
//----------------------------------------------------------------------------------------------------------------------
class VertexShaderD3D9: public ShaderD3D9
{
    private:
        IDirect3DVertexShader9*  m_pShader;

    public:
        VertexShaderD3D9( RenderSystemD3D9* pRenderSystem, const char* sCode, uint32 nSize );
        virtual ~VertexShaderD3D9();

        IDirect3DVertexShader9* GetShaderPtr();
};
//----------------------------------------------------------------------------------------------------------------------

//----------------------------------------------------------------------------------------------------------------------
// Name: PixelShaderD3D9
// Desc: Direct3D9 pixel shader resource
//----------------------------------------------------------------------------------------------------------------------
class PixelShaderD3D9: public ShaderD3D9
{
    private:
        IDirect3DPixelShader9*  m_pShader;

    public:
        PixelShaderD3D9( RenderSystemD3D9* pRenderSystem, const char* sCode, uint32 nSize );
        virtual ~PixelShaderD3D9();

        IDirect3DPixelShader9* GetShaderPtr();
};
//----------------------------------------------------------------------------------------------------------------------

#endif

DevilDevil
Если заголовочный или исходный файл разрастается до 500 строк и больше, то лучше его разделить на несколько поменьше. Мне в целом без разницы, для навигации по коду пользуюсь раскрывающимися списками в окне кода Visual Studio. Но все же считаю что слишком большие файлы кода - это плохо, осбенно для тех кто видит код первый раз - им будет сложнее составить картину происходящего, что делает код и для чего предназначен.

alex-r
спасибо :)
сегодня у меня праздник )

только зачем комментарии Name/Desc ?

Привычка идёт то ли ещё из Ц, то ли из жабы, то ли из дельфиума. Идея в том, что, если меняешь что-то в одном модуле, то при перебилде будет перекомпилироваться только он, и через это как бы будет достигнут профит.
Это на самом деле, конечно, фигня и суеверия. На практике оно зачастую не работает, а когда в дело вступают шаблоны, то перестаёт работать в принципе.
Иногда выдвигают аргументом ещё какие-то воображаемые профиты, типа "проще ориентироваться в проэкте" и всётакое. Но это совсем уж несерьёзно - достаточно вспомнить, во что превращается ориентация по проэкту при наличии сотни-другой файлов.

В общем, гнилой атавизм, прикрываемый высокой демагогией. Как и многие другие "технологии правильного программирования".

> Засунь всё в один файл и получи время Build Project == времени Rebuild
> Project, оч. круто да.
Верно, время билда взлетит, если все сложить в файл.

IDE находит объявление класса не мгновенно. Просто открыть файл с именем класса - это ноль времени.

Если надо менять зависимости, то проще иметь все в разных файлах и менять инклуды и форфарды.

Если в репозитории смотреть какой-то коммит, то лучше видеть имена файлов, которые один к одному соответствуют именам классов.
А если в том мегафайле менять классы местами (чтобы удовлетворить зависимости), то мерж с другой веткой почти 100% будет с конфликтами, и он может превратится в кошмар ручного мержа.