Что использовать в проекте (оба варианта или один)? Как конвертировать одно в другое?

Я привык к std::string, а теперь приходиться мучить Билдер , и не знаю, стоит ли мне использовать для внутреннего мяса std::string, тогда как потом всеравно придется преводить к Анси (для рисования UI). А если использовать только Анси, то насколько он подходит для работы с контейнерами STL ???
Неужели придется юзать метод c_str() ?

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

M>Что использовать в проекте (оба варианта или один)? Как конвертировать одно в другое?

M>Я привык к std::string, а теперь приходиться мучить Билдер , и не знаю, стоит ли мне использовать для внутреннего мяса std::string, тогда как потом всеравно придется преводить к Анси (для рисования UI). А если использовать только Анси, то насколько он подходит для работы с контейнерами STL ???
M>Неужели придется юзать метод c_str() ?

Сталкивался с подобной проблемой и в итоге был сделан класс (назовём его MyStr), который в зависимости от defines ведёт себя либо как std::string, либо как AnsiString. Точнее, если сказано использовать std::string, то typedef std::string MyStr. Иначе используется класс-адаптер над AnsiString, с интерфейсом std::string.

Здравствуйте, eugy, Вы писали:
E>Сталкивался с подобной проблемой и в итоге был сделан класс (назовём его MyStr), который в зависимости от defines ведёт себя либо как std::string, либо как AnsiString. Точнее, если сказано использовать std::string, то typedef std::string MyStr. Иначе используется класс-адаптер над AnsiString, с интерфейсом std::string.

О нет! Только не это! Мне еще собственный класс для строк писать не хватает (Ну не целый конечно, но все-таки...)

Нда... Хреновенько...

Кто еще чем может поделиться?

Здравствуйте, mosq, Вы писали:
M>Нда... Хреновенько...

В голову лезут крамольные мысли вообще об отказе от STL. В VCL тоже контейнеры есть всякие тот же TLIst, TStringLIst и т.п.

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

M>О нет! Только не это! Мне еще собственный класс для строк писать не хватает (Ну не целый конечно, но все-таки...)
Я, наверное, не совсем правильно описал решение.
Выглядит оно так

#ifdef USE_STD_STRING

typedef std::string MyStr;

#else

class MyStr
{
public:
//дублирование(полностью или частично) интерфейса std::string + методы из/в AliasString и, необязательно,  std::string
private:
AliasString m_str;
};

в итоге вы работаете с MyStr ровно также, как и std::string везде(в том числе и при чтении/записи строк в контролы).

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

M>Здравствуйте, mosq, Вы писали:
M>>Нда... Хреновенько...

M>В голову лезут крамольные мысли вообще об отказе от STL. В VCL тоже контейнеры есть всякие тот же TLIst, TStringLIst и т.п.

ИМХО вполне удобные, как и вся VCL.

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

E>Я, наверное, не совсем правильно описал решение.
E>Выглядит оно так

E>

E>#ifdef USE_STD_STRING

E>typedef std::string MyStr;

E>#else

E>class MyStr
E>{
E>public:
E>//дублирование(полностью или частично) интерфейса std::string + методы из/в AliasString и, необязательно,  std::string
E>private:
E>AliasString m_str;
E>};
E>

E>в итоге вы работаете с MyStr ровно также, как и std::string везде(в том числе и при чтении/записи строк в контролы).

Под "AliasString" вы подразумеваете AnsiString? Ок, опечатка.

Тое есть я смогу сделать:

TEdit *edt(0);
...... // инициализация edt

MyStr str;
str = edt->Text; // да???

и при этом сохраниться возможность исользовать str в контейнерах STL ?

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

Есть вариант вообще не использовать std::string и STL...
А чем вас не устроил вариант использования AnsiString и контейнеров из VCL, что вам пришлось решать данную проблему?

Здравствуйте, Аноним, Вы писали:
А>ИМХО вполне удобные, как и вся VCL.

Ок. Я тоже думаю, что не стоит мешать STL c VCL , потому что получится это все искусственно и неудобно. Жалко конечно STL...

Пока я не нашел у AnsiString серьезных недостатков. Единственное — непривычно.

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

M>Я привык к std::string, а теперь приходиться мучить Билдер , и не знаю, стоит ли мне использовать для внутреннего мяса std::string, тогда как потом всеравно придется преводить к Анси (для рисования UI). А если использовать только Анси, то насколько он подходит для работы с контейнерами STL ???

А есть ли такая сильная необходимость в STL при использовании VCL? Может, имеет смысл пользовать те решения, которые для данной библиотеки предназначены?

M>Неужели придется юзать метод c_str() ?

А чем он плох?

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

AB>А есть ли такая сильная необходимость в STL при использовании VCL? Может, имеет смысл пользовать те решения, которые для данной библиотеки предназначены?

К этому и склоняюсь. Просто не хотелось, что бы в уже сформировавшемся проекте вдруг возникла надобность в СТЛ.

M>>Неужели придется юзать метод c_str() ?

AB>А чем он плох?

Да бог его знает

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

M>Я привык к std::string, а теперь приходиться мучить Билдер , и не знаю, стоит ли мне использовать для внутреннего мяса std::string, тогда как потом всеравно придется преводить к Анси (для рисования UI).

В коде, который тесно взаимодействует с VCL, использовать std::string, конечно, смысла не имеет.

M>А если использовать только Анси, то насколько он подходит для работы с контейнерами STL ???

Нормально он подходит.

M>Неужели придется юзать метод c_str() ?

А что тебя смущает?

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

В>В коде, который тесно взаимодействует с VCL, использовать std::string, конечно, смысла не имеет.

Просто он не совсем тесно взаимодействует
Но не важно. Все равно использование std::string не стОит путаницы с двумя типами строк — я уже попробывал. Так что разрулю всё на Анси.

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

AB>А есть ли такая сильная необходимость в STL при использовании VCL? Может, имеет смысл пользовать те решения, которые для данной библиотеки предназначены?

А что VCL покрывает из STL? Ну строки покрывает И те глючат. Все. Контейнеры? Жалкий нетипизированный TList (с кучей проблем по контролю за временем жизни элементов) против std::list, std::vector, std::map и т.д.? А где алгоритмы? А где функции высшего порядка (хотя __closure, пожалуй сюда записать можно)? Нет даже аналога такой элементарной и повседневно востребованной вещи как std::auto_ptr. Зачем тогда вообще С++, если собираешься использовать только VCL — пиши на дельфе и не выпендривайся, избежишь кучи граблей, связанных с состыковкой паскальной VCL и С++.

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

AB>>А есть ли такая сильная необходимость в STL при использовании VCL? Может, имеет смысл пользовать те решения, которые для данной библиотеки предназначены?
В>А что VCL покрывает из STL? Ну строки покрывает И те глючат.
[skip]
В>Зачем тогда вообще С++, если собираешься использовать только VCL — пиши на дельфе и не выпендривайся, избежишь кучи граблей, связанных с состыковкой паскальной VCL и С++.

Не... ну хочешь использовать STL — используй, никто же не запрещает изначально вопрос стоял об AnsiString и std::string. Мне лично расширения STL, находясь в VCL, никогда не требовались. Что же касается выпендрежа при чем здесь это, если среда заточена под VCL...

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

AB>Не... ну хочешь использовать STL — используй, никто же не запрещает изначально вопрос стоял об AnsiString и std::string. Мне лично расширения STL, находясь в VCL, никогда не требовались. Что же касается выпендрежа при чем здесь это, если среда заточена под VCL...

Да, среда заточена под VCL, которая заточена под паскаль, и использовать ее из плюсов не так удобно и органично как из дельфей. Поэтому если "VCL хватает на все случаи", то использование С++ — "выпендреж" (в смысле нерационально). Язык сложный, концепции другие, с паскалем стыкуется плохо... нафига?

Hello mosq, you wrote:

А какие проблемы STL + AnsiString?
list<AnsiString> — так делать нельзя?

--
Всего хорошего, Слава

Hello mosq, you wrote:

А какие проблемы STL + AnsiString?
list<AnsiString> — так делать нельзя?

--
Всего хорошего, Слава

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

SA>А какие проблемы STL + AnsiString?
SA>list<AnsiString> — так делать нельзя?

Так все нормально. Проблемы только с конвертацией std::string <-> AnsiString — надо писать .c_str().

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

AB>>Не... ну хочешь использовать STL — используй, никто же не запрещает изначально вопрос стоял об AnsiString и std::string. Мне лично расширения STL, находясь в VCL, никогда не требовались. Что же касается выпендрежа при чем здесь это, если среда заточена под VCL...
В>Да, среда заточена под VCL, которая заточена под паскаль, и использовать ее из плюсов не так удобно и органично как из дельфей.

Чем не удобно? Те же самые классы, те же самы методы... В чем неудобство? Да, не поддерживается множественное наследование... Да, есть еще ограничения пришедшие из Delphi... Но, если очень хочется, то ведь можно! Более того, если не хватает функциональности BCB, если он не поддерживает некоторые стандарты, а очень хочется — ведь всегда есть альтернативы — VC++, например. Стыковка модулей из разных сред компиляции на уровне DLL / COM проблем не составляет ведь? Не бывает плохих методов — бывает неправильное их использование (с) Евтушенко В.Ф.

В>Поэтому если "VCL хватает на все случаи", то использование С++ — "выпендреж" (в смысле нерационально).

Я не говорил, что его хватает на все случаи жизни. Я говорил о том, что не было надобности использовать STL. А всте остальные приемущества языка (именно языка, а не библиотек и языка в реализации от Inprise) от этого не страдают ведь?

В>Язык сложный, концепции другие, с паскалем стыкуется плохо... нафига?

А зачем его стыковать с паскалем?

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

M>Что использовать в проекте (оба варианта или один)? Как конвертировать одно в другое?

M>Я привык к std::string, а теперь приходиться мучить Билдер , и не знаю, стоит ли мне использовать для внутреннего мяса std::string, тогда как потом всеравно придется преводить к Анси (для рисования UI). А если использовать только Анси, то насколько он подходит для работы с контейнерами STL ???
M>Неужели придется юзать метод c_str() ?

Можно воспользоваться классом string_to_string

Автор: _nn_
Дата: 09.09.04

для автоматического перевода строк.