std::string s;
Coder<ucs2>(ws).encode<utf8>(s);

std::string s = utf8(new ucs2(ws)).c_str();

std::string s = encode(ws, new ucs2, new utf8);

std::string s = Coder(new ucs2(ws)).encode(new utf8);

преобразование строк в from/to разные кодировки.

Что является более оптимальным (не по перфомансу а в общем.)
каждая строчка подразумевает совершенно определенную реализацию
1) шаблоны (причем не очень хорошие — функций)
2) наследование интерфейса + конструкторы копирования
3) наследование интерфейса + наменьшая связанность кода
4) гибрид 1+2 без шаблонов и копирования, но наследование от базового функционального класса
5) наверное можно чтото еще придумать..

мне кажется что с точки зрения правильного проектирования вариант 3 оптимален.

JakeS wrote:

> мне кажется что с точки зрения правильного проектирования вариант 3
> оптимален.
По-моему:

Converter converter("from-encoding", "to-encoding");
string str2 = converter.convert(str1);
string str3 = converter.convert(str1.begin(), str1.end());
string str4 = converter.convert(istream1.begin(), istream1.end());
converter.convert(istream1.begin(), istream1.end(), outputIterator);

Ибо кодировки вещь такая... может прийти из входного потока как строка, может быть "CP1251", "cp1251", "windows-1251". И
шаблоны тут вообще непонятно зачем.

Здравствуйте, kan, Вы писали:

kan>JakeS wrote:

>> мне кажется что с точки зрения правильного проектирования вариант 3
>> оптимален.
kan>По-моему:
kan>

kan>Converter converter("from-encoding", "to-encoding");
kan>string str2 = converter.convert(str1);
kan>string str3 = converter.convert(str1.begin(), str1.end());
kan>string str4 = converter.convert(istream1.begin(), istream1.end());
kan>converter.convert(istream1.begin(), istream1.end(), outputIterator);
kan>

kan>Ибо кодировки вещь такая... может прийти из входного потока как строка, может быть "CP1251", "cp1251", "windows-1251". И
kan>шаблоны тут вообще непонятно зачем.

Речь идет о проектировании. Т.е. для обеспечения расширяемости без вмешательства в код введены либо шаблоны либо наследование. ваш пример это уже wrapper который легко реализуется на любой из моих структур.

JakeS wrote:

> Речь идет о проектировании. Т.е. для обеспечения расширяемости без
> вмешательства в код введены либо шаблоны либо наследование. ваш пример
> это уже wrapper который легко реализуется на любой из моих структур.
Тогда я не понял вопрос. И, судя по количеству ответов, я не одинок в этом.
Расширяемость чего и куда?
Кстати, оператор "new" желательно использовать только в конструкторах, с соответствующим delete в деструкторе,
использование в пользовательском коде лучше сделать минимально возможножным.

Здравствуйте, JakeS, Вы писали:

JS>std::string s = encode(ws, new ucs2, new utf8);

JS>мне кажется что с точки зрения правильного проектирования вариант 3 оптимален.

Возможно. Только я бы убрал new и вместо них использовал синглтоны. (и не надо кричать что это антипаттерн )

Можно ещё вот так сделать:

typedef wchar_t common_cp; //это общий знаменатель через который будут конвертироваться все кодировки

class cp_UTF
{
public:
    typedef wchar_t cp_char;
    static basic_string<common_cp> to_common(const basic_string<cp_char> &s);
    static basic_string<cp_char> from_common(const basic_string<common_cp> &s)
    {
         return s;
    }
};

class cp_1251
{
public:
    typedef char cp_char;
    static basic_string<common_cp> to_common(const basic_string<cp_char> &s)
    {
        basic_string<common_cp> res;
        //здесь тоже чего-ниь преобразуем из string в wstring
        return res;
    }
    static basic_string<cp_char> from_common(const basic_string<common_cp> &s);
};

class cp_866
{
public:
    typedef char cp_char;
    static basic_string<common_cp> to_common(const basic_string<cp_char> &s);
    static basic_string<cp_char> from_common(const basic_string<common_cp> &s);
};

template <class D, class E>
class cp_conv
{
public:
    typedef D::cp_char src_char;
    typedef E::cp_char dst_char;
    static basic_string<dst_char> renc(const basic_string<src_char> &s)
    {
        return E::from_common(D::to_common(s));
    }
};

//использование
int main()
{
    string s = "Привет";
    wstring ws = cp_conv<cp_1251,cp_UTF>::renc(s);

}

При надобности в оптимизиции можно написать специализацию класса cp_conv например для прямого перекодирования из cp1251 в cp866 без промежуточного юникода.

Mazay wrote:

> wstring ws = cp_conv<cp_1251,cp_UTF>::renc(s);
> При надобности в оптимизиции можно написать специализацию класса cp_conv
> например для прямого перекодирования из cp1251 в cp866 без
> промежуточного юникода.
Я уже обращал внимание, что нужны текстовые имена кодировок. Часто имя кодировки приходит из вне
(text/html;charset=windows-1251). Плюс альясы имён кодировок. В общем, проще взять ICU (там уже всё есть) или iconv и
написать C++ wrapper.

Или это вопрос чисто теоретический, не для реального использования в жизни?