[c++]кошерно ли использовать namespace для таких целей?

Да, так сама жырна

Вместо

int red = 5; 
int green = 6; 

наверное лучше будет

enum Color{RED, BLUE};

поддерживаю. ну если надо 5 и 6 то в enum можно и задать.

enum Color{RED=5, BLUE}

Да, но тогда уже:

namespace Colors 
{ 
  static const int red = 5;
  static const int green = 6;
}

Кошенрно. Но для начала - добейся константности

или через enum, либо через const. Первое идеологически более правильно

Хотя я бы тут сделат так

class Color {
enum PredefineColor {
Red,
Grean
}

Color(PredefineColor a_predefineColor);
};

void writeList(int, int, const Color&);

writeList(40,40,Color::red);

В С++ константы по умолчанию имеют область линковки только в пределах единицы трансляции. static здесь избыточен

зачем тут класс?

В чем смысл объявлять константы? //Не С программист

Повышение качества кода за счет дополнительно статической проверки типов на стадии компиляции

Инкапсулирование - дальнейшее развитие

хотя и enum подойдет. int -> enum неявно не преобразуется

const означает, что данные момент не изменяться по времени не зависимо от внешних факторов. Но на самом деле это договореность. В случае классов он вполне может изменяться, и обеспечение константности его - это задача программиста.

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

Кроме того, const с С++ делает объект связываемым только в пределах единицы трансляции (если не указан extern). В С же const не меняет область видимости.

у емуна есть другое приимущество. он не выделят память при объявлении

тьфу, блин, наплодят сущностей, и всё ради дальнейшего развития. я вот слабо вижу куда можно развить цвета.

а namespace то нужен? классов color и RED,GREEN,etc вагон целый.

еще const может быть параметром шаблона

Цвет можно развить в RGB, множество заранее заданых, и множество типов (цвет панелька такой-то, и такой-то)

Спасибо. Вроде бы простая задача, что ТС хочет сделать, а столько тонкостей надо знать )

пока этот стандарт не проучишь - можешь падать на ровном месте

кроме стандарта есть стиль. есть методы защиты и тд

Если язык статический - надо по максимому из этого вытягивать выгоду

офтоп: namezys, ты, наверное, и с Qt умеешь?

Если бы были константы - еще туда-сюда.
А так, конечно, typedef. То, что тут написано - суши вилкой.

MDC пост видел? Ядро и ассинхроные механизмы в нем - мое детяще

ГУИ не мое

QT + boost там

typedef вещь плохая. не какой защищености

так это всётаки ты в разработчиках. но раз гуё не твоё, то ладно. пойду в qt@c.j.r до народа домогаться.

то что GUI не мое - не значит, что я его не знаю

сейчас хоть и другой проект, но там у меня одна из задач - автогенерирвоание интерфейса по метоинформации

а домагаться завтра. с 8-30 утра

я щас спать

QT это QuickTime, а фреймворк Qt, сорри за оффтоп.

Сорри, пиво :)

я по этому поводу целый изврат строю:

namespace Colors
{
    enum Enum
    {
         Red,
         Green
    };
}
typedef Colors::Enum EColors;

потом развил идею макросами, и появилась возможность у каждого перечисления добавить метод toString(). кому надо - могу поделиться говновелосипедами)

KISS

enum Color{RED=5, BLUE}

Тогда BLUE будет равно 6 чтоли? А какой тип он будет иметь? Тот, которым инициализирую, как в случае с #define?

мне так удобнее :)
особенно когда гора перечислений, да еще и с похожими названиями (состояния визуальных игровых объектов к примеру), очень хочется отделить их в namespace.

qt-кунам:

www.linux.org.ru/view-message.jsp?msgid=4336717&lastmod=1260912248071

class Color {

enum PredefineColor {
Red,
Grean
}


Вот нафига тут ещё и класс? Неймспейса за глаза и уши хватит. Вообще чем enum'ы хороши, так это возможностью флаги делать, например.
enum Flags {
Foo = 0x1,
AnotherFoo = 0x2,
LastFoo = 0,x4
}
Главное, чтобы элементы перечисления были степенями двойки, тогда можно всякие финты делать навроде
Flags foo
if (foo & Foo)

> Тогда BLUE будет равно 6 чтоли? А какой тип он будет иметь? Тот, которым инициализирую, как в случае с #define?

Тип enum Colors::Enum. Вам этого мало?

Вполне законый тип, отличный от других. В отличае от того-же typedef

Ответил тебе, что думаю.

> Flags foo

if (foo & Foo)

А кто инициализировать то будет? Вот оно, зачем класс надо, чтоб инициализировало в дефолтовое значение хотя бы.

Кроме того, это легко позволяет потом расширять код, это раз.

Два - повышает защеность типов. Явно запряещает преобразование к int.

namespace вообще мало что дает, с точки зрения информации о типе. А в шаблонох это важно.

Кроме того, идея использования enum'ов для флагов мне чем-то не нраится. Но пока ничего лучше не придумал.

Да.

namespace config {
    namespace general {
        const char autostart[] = "autostart";
        const char someparam[] = "someparam";
    }
}

...

config::get (config::general::autostart, &value);

извините, у нас С++, а не С

тем более со строками тебя компилятор поругает, если забудешь const указать

извините, у нас С++, а не С

Ладно. Набросал пример для сущности, хранящей настройки. Условимся, что настройки читаются из конфигфайла (plain text), в целях экономии времени не стал тут это имплементить; при обращении к конкретному параметру - типизируются во что надо

evil.cc

#include <iostream>
#include <string>
#include <map>

//- example of complex type ------------------------------------------------------

namespace types {
    class point {
    public:
        point (int x = 0, int y = 0) : _x (x), _y (y) {
        };
        point (const std::string &serialized) {
            sscanf (serialized.c_str(), "%d %d", &_x, &_y);
        };

        int _x;
        int _y;
    };
}

std::ostream& operator << (std::ostream &stream, const types::point &pt) {
    stream << pt._x << '@' << pt._y;
    return stream;
}



//- conversion functions for basic types ---------------------------------------

namespace serialize {
    template <typename T> T convert (const std::string &serialized) {
        return T (serialized);
        // return T::from (serialized); will look more explicitely
    }

    template <> int convert (const std::string &serialized) {
        int x = 0;
        sscanf (serialized.c_str (), "%d", &x);
        return x;
    }
}



//- application settings store ---------------------------------------------------

namespace conf {

    template <typename T> class entry {
    public:
        entry (const std::string &name) : _name (name) {
        }
        operator const std::string () {
            return _name;
        }
        std::string _name;
    };

    class store {
    protected:
        std::map <std::string, std::string> _db;
        
    public:
        template <typename T> T get (conf::entry<T> e) {
            return serialize::convert<T> (_db[e._name]);
        }
    };
}



//- demo -----------------------------------------------------------------------

namespace config {
    namespace examples {
        conf::entry <int>           latency   ("latency");
        conf::entry <std::string>   startmsg   ("startup message");
        conf::entry <types::point>  position  ("position");
    }
}


class sample_store: public conf::store {
public:
    sample_store () {
        _db [config::examples::latency]  = "97";
        _db [config::examples::startmsg] = "hello LOR!";
        _db [config::examples::position] = "23 44";
    }
};



int main (int argc, char *argv[]) {
    sample_store demo;
    std::cout
        << demo.get (config::examples::latency) << std::endl
        << demo.get (config::examples::startmsg) << std::endl
        << demo.get (config::examples::position) << std::endl;
    return 0;
}

d:/work $ g++ evil.cc 
d:/work $ ./a.exe
97
hello LOR!
23@44

>d:/work

Упс :]

во. во теперь стало куда лучше и демонстративнее

отдам под BSDL

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

да ну:) даже если забыть про глобальные переменные и ввод-вывод, то все равно константынй объект может содержать указатель, указатель не меняется, а то на что он указывает меняется.

Дык адрес того-кто-изменится не изменится, или я чота не понимаю?

дальше читай.

class A {
public:
int f() const;
}

const A a;
.....
a.f();
.....
a.f();

Функция должне вернуть одно и то же. Потому что компилятор имеет полное право не вызывать второй раз ее.

Если ты неумешь писать const объеты с перемеными данными, то не пиши

Он имеет в виду следующий случай

classs A {
mutable a;
public:
A() : a(0) {}

int f() const
{ return a; }

void setF(int a_a) const
{ a = a_a; }

};

Но если ты это написал, то ССЗБ

при оптимизации компилятор под консты тоже не будет выделять память.

А что если не

std::ostream& operator << (std::ostream &stream, const types::point &pt) { 
    stream << pt._x << '@' << pt._y; 
    return stream; 
} 

a

std::ostream& operator << (std::ostream &stream, const types::point &pt) { 
    return stream << pt._x << '@' << pt._y; 
} 

-1 строка. А то Моно, вон, уже количеством строк кода хвастается...

Кроме того, идея использования enum'ов для флагов мне чем-то не нраится. Но пока ничего лучше не придумал.

А чем это? По потреблению памяти это уже теоретический предел. По скорости в общем то тоже, хотя это уже видимо от архитектуры процессора зависит. Синтаксис вполне опрятный, не похоже на шмоток макросов. Один недостаток иногда только мешает, низя в строку скастовать никак. Вообще для дополнительных плюшек и защищенности юзаю Q_DECLARE_FLAGS

> при оптимизации компилятор под консты тоже не будет выделять память.

Это постфактум оптимизации, причем необязательный

Ага. Я тоже. Но есть какое-то внутреннее противоречии