Использование вложенных пространств имен в 3D графическая библиотека двигателя


Я знаю, что вложенные пространства имен используются в C++ очень редко. Но я думаю, что это хорошее решение, чтобы исключить типы из глобальной области видимости, а иногда и это помогает писать программы быстрее, когда мы используем такие вещи, как "технологии IntelliSense" или искать в документации (возможно это похоже для разработчиков C#).

Я пытался организовать мой простой 3D-графикой движка в эту сторону. Вот ее главный заголовочный файл:

#ifndef RAZOR_H
#define RAZOR_H

#pragma warning (disable: 4482)

#include <Windows.h>
#include <fstream>
#include <iostream>
#include <string>
#include <fstream>
#include <vector>
#include <map>

#include <gl\GL.h>
#include "Externals\wglext.h"
#include "Externals\gl3.h"

namespace Razor
{
    namespace Framework
    {   
        #include "DisplayOrientation.h"
        #include "ButtonState.h" 
        #include "GameTime.h"
        #include "Rect.h"
        #include "Point.h"
        #include "Color.h"
        #include "Vector2.h"
        #include "Vector3.h"
        #include "Vector4.h"
        #include "Matrix.h"

        #include "GameWindow.h"
        #include "Game.h"

        namespace IO
        {
            #include "File.h"
        }

        namespace Input
        {   
            #include "ButtonState.h"
            #include "MouseState.h"
            #include "Keyboard.h"
            #include "Mouse.h"
            #include "TouchPanel.h"
        }

        namespace Graphics
        {
            #include "PrimitiveType.h"
            #include "VertexElementFormat.h"
            #include "VertexElementUsage.h"
            #include "VertexElement.h"
            #include "VertexDeclaration.h"
            #include "OpenGLExtensions.h"
            #include "DepthFormat.h"
            #include "BufferUsage.h"
            #include "PresentationParameters.h"
            #include "RenderTarget.h"
            #include "OpenGLVersion.h"
            #include "Viewport.h"
            #include "Shader.h"
            #include "VertexShader.h"
            #include "FragmentShader.h"
            #include "GeometryShader.h"
            #include "ShaderContainer.h"
            #include "VertexBuffer.h"
            #include "GraphicsDevice.h"
            #include "VertexBuffer.h"
            #include "GraphicsDeviceManager.h"
        }
    }
}

#endif // RAZOR_H

Какие проблемы я могу получить в будущем, если я организую свою библиотеку таким способом? Как вы думаете, это действительно плохой стиль кодирования?



3624
9
задан 16 августа 2011 в 06:08 Источник Поделиться
Комментарии
3 ответа

Я не думаю, что есть ничего плохого с вложенными пространствами имен.

Я также не согласен, что это редкость. Это просто не показывать.

std::tr1
CompanyName::ProductName
CompanyName::ProductName::Details

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

Если я включаю файл".ч" я ожидаю, что все включено до быть заявлены в правильное пространство имен. Но как вы определите это, то теперь можно включить его в пути, который ставит классы в неправильное пространство имен.

Каждый заголовочный файл должен быть разработан таким образом, что она не может быть неправильно использована.

15
ответ дан 16 августа 2011 в 06:08 Источник Поделиться

Это лучше, гораздо лучше защитить (вы в конечном итоге защитить) ваши имена в области файла, в котором они были объявлены. Таким образом, использование пространства защищает только имена включают в сферу, и что если я постараюсь, чтобы включить некоторые из ваших заголовков и забудьте обрамить его с пространством имен? Как я даже знаю, что пространство имен использовать?

Эта тема соотносится с заголовком стражи (который вы используете правильно здесь). Правило № 24 от "стандартов кодирования на C++: 101 Правил, руководящих принципов и наилучшей практики":


Всегда пишу внутренний #включают в себя охранников. Никогда не пишу внешний код #include
охранники

Кстати, очень хорошая книга.

2
ответ дан 16 августа 2011 в 09:08 Источник Поделиться

Там нет ничего плохого с вложенными пространствами имен, но учтите, что пространства имен (по-моему, и насколько я читал), предназначенные для предотвращения конфликта имен, не организовать код. Они не редкие-есть импульс, например, который имеет много вложенных пространств имен, но, насколько я видел, они обычно используются для разделения двух проектов (подпроектов), так что разработчикам не нужно беспокоиться о принятии друг друга по именам.

Примечание: когда я говорю "пространство имен верхнего уровня", я имею в виду бритву.

Другое Примечание: Вы в том числе некоторые файлы в несколько раз; я предполагаю, что это копипаст ошибки.

Некоторые идеи:


  • Пространства имен должны быть определены внутри каждого отдельного заголовка, а не в каких-то глобальных заголовков. Включая этот заголовок везде будет стоить Вам большое время компиляции. Это также означает, что ошибка в одном заголовочном файле не позволяют строить любого вашего проекта, которым может быть неудобно.

  • Вы действительно нуждаетесь в рамках пространства имен? Это просто, как бритва пространства имен, так зачем заморачиваться с этим? Вы можете переименовать бритвы для RazorFramework, и получите тот же эффект. (Если вы решите расширить позже, аддоны пространство имен может быть более правильным, во всяком случае.)

  • Это файл действительно важно класса, чтобы получить свое собственное пространство имен? Кроме того, вы будете использовать тот же файл класса для чтения и записи все файлы, или это можно изменить? Опять же, я бы поставил его в топ-уровне пространства имен, если это так вообще, но я подозреваю, что есть более конструктивные решения должны быть сделаны о том, что файл в любом случае.

  • Графика выглядит как хороший выбор для пространства имен, но тогда вы не должны префикс файлы с графикой. Пока не надо, это приятно, когда ваша структура пространства и структура заголовка похожи, если не идентичны.

  • Вершина выглядит как обычный префикс: возможно, поставив всех вершин, связанных с вещами в пространстве имен собственных позволило бы избежать этого. То же самое может пойти на буфер и шейдеров, в зависимости от того, насколько вероятно их столкновение.

  • Функции и классы, определенные в OpenGL и DirectX могут быть очень похожи, поэтому иметь в OpenGL пространства имен и совместимая с DirectX пространства имен, где-то позволит вам использовать те же названия для той же функции в каждом.

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

2
ответ дан 20 августа 2011 в 04:08 Источник Поделиться