Здравствуйте, 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 в wstringreturn 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 без промежуточного юникода.
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 оптимален.
Ибо кодировки вещь такая... может прийти из входного потока как строка, может быть "CP1251", "cp1251", "windows-1251". И
шаблоны тут вообще непонятно зачем.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
kan>Ибо кодировки вещь такая... может прийти из входного потока как строка, может быть "CP1251", "cp1251", "windows-1251". И kan>шаблоны тут вообще непонятно зачем.
Речь идет о проектировании. Т.е. для обеспечения расширяемости без вмешательства в код введены либо шаблоны либо наследование. ваш пример это уже wrapper который легко реализуется на любой из моих структур.
JakeS wrote:
> Речь идет о проектировании. Т.е. для обеспечения расширяемости без > вмешательства в код введены либо шаблоны либо наследование. ваш пример > это уже wrapper который легко реализуется на любой из моих структур.
Тогда я не понял вопрос. И, судя по количеству ответов, я не одинок в этом.
Расширяемость чего и куда?
Кстати, оператор "new" желательно использовать только в конструкторах, с соответствующим delete в деструкторе,
использование в пользовательском коде лучше сделать минимально возможножным.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
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.
Или это вопрос чисто теоретический, не для реального использования в жизни?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай