Здравствуйте, 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.

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

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

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

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

А чем он плох?

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

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

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

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

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

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

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

Hello mosq, you wrote:

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 серьезных недостатков. Единственное — непривычно.

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

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

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

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

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

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

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

В>В коде, который тесно взаимодействует с 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> — так делать нельзя?

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

Здравствуйте, 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) от этого не страдают ведь?

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

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

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

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

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

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

Ага, спасибо.

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

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

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

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

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

M>Ага, спасибо.

Вам надо специализировать string_to_string_trais для класса AnsiString, думаю будет неплохо выложить эту специализацию в исходники на будущее

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

В>>Да, среда заточена под VCL, которая заточена под паскаль, и использовать ее из плюсов не так удобно и органично как из дельфей.
AB>Чем не удобно? Те же самые классы, те же самы методы... В чем неудобство? Да, не поддерживается множественное наследование... Да, есть еще ограничения пришедшие из Delphi...

1) Множественное наследование. Зафигачить нужную функциональность в готовый VCL класс "одним махом" — нереально. Хотя для С++ это естественно. Интерфейсы и те появились только в 6-м билдере.
2) Создание/удаление объектов. Только через неперегружаемые new/delete.
3) Виртуальные конструкторы/деструкторы. Помимо того, что они просто работают не так, как это принято в С++, они еще порождают массу глюков компилятора и самые неожиданные эффекты.
4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек.

Наверное еще есть, сейчас уже не помню, давно последний раз держал билдер в руках. Теперь вопрос: ради чего все страдания? Можно было предположить, что самые хитрые хотят клепать формы также легко как в дельфе, но хоть в какой-то мере задействовать мощь С++ (назло ограничениям VCL и глюкам компилятора). Однако выясняется, что "STL не нужна и хватает VCL". Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++? Я вижу только недостатки, самый главный из которых — скорость компиляции. Никакой С++ не угонится за дельфей. Для RAD это актуально (положил на форму компонент, посмотрел что получилось, выставил свойство, опять посмотрел что получилось).

AB>Но, если очень хочется, то ведь можно! Более того, если не хватает функциональности BCB, если он не поддерживает некоторые стандарты, а очень хочется — ведь всегда есть альтернативы — VC++, например. Стыковка модулей из разных сред компиляции на уровне DLL / COM проблем не составляет ведь?

Проблем со стыковкой Borland C++ с VC ровно столько же, сколько и со стыковкой дельфи с VC. Несмортя на то, что язык один, просто так взять и подключить модуль скомпиленный одним компилятором (BC) к модулю, скомпилированному другим компилятором (VC) — нельзя.

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

STL — это одно из преимуществ языка. И сознательный отказ от него требует серьезных обоснований, а несознательный отказ ставит под сомнение само знание этих преимуществ. Надеюсь под преимуществами ты подразумеваешь что-то более интересное, нежели "{} vs begin/end"?

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

Чтобы можно было использовать паскальную VCL из C++.

P.S. Кстати, билдер как продукт давно издох. О чем спорим?
P.S.S. Для меня это хоть уже и старая, но мозоль. Когда-то кучу времени потратил на "борьбу с VCL из С++".

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

В>4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек.

Не знаю, как на счет __fastcall, но мне очень не хватает в VC __closure и __property (__property именно в реализации BCB).

В>Наверное еще есть, сейчас уже не помню, давно последний раз держал билдер в руках. Теперь вопрос: ради чего все страдания? Можно было предположить, что самые хитрые хотят клепать формы также легко как в дельфе, но хоть в какой-то мере задействовать мощь С++ (назло ограничениям VCL и глюкам компилятора).

Да, именно так в моем случае! Когда в проекте нету каких-либо особенных тонких мест, требовательных к скорости выполнения, размеру, etc. Почему бы не написать ее за неделю, получить деньги и остаток месяца провести в свое удовольствие, чем писать точно такую же функциональность на MFC в течении более длительного периода, получив в итоге то же самое (с точки зрения клиента)?

В>Однако выясняется, что "STL не нужна и хватает VCL".

Но ведь действительно хватает! (мне опять же). С другой стороны, если STL когда-нибудь мне потребуется — я без зазрений совести буду ее использовать.

В>Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++?

Нет смешания сред, ИМХО. Для VCL, STL является чужеродной (опять же, ИМХО) — в итоге могут возникать различного рода труднообнаруживаемые ошибки и прочее. При использовании только VCL вероятность словить глюк при использовании STL равна нулю => остаются только "глюки" VCL, которые в большинстве случаев известны и легко обходятся => скорость разработки потенциально возрастает.

В>Я вижу только недостатки, самый главный из которых — скорость компиляции. Никакой С++ не угонится за дельфей. Для RAD это актуально (положил на форму компонент, посмотрел что получилось, выставил свойство, опять посмотрел что получилось).

Вне сомнения, скорость компиляции Delphi и BCB различны, но ведь и языки тоже разные. Давай посравниваем скорость компиляции VC и BCB VC проиграет в скорости за счет более сильной оптимизации.

AB>>Но, если очень хочется, то ведь можно! Более того, если не хватает функциональности BCB, если он не поддерживает некоторые стандарты, а очень хочется — ведь всегда есть альтернативы — VC++, например. Стыковка модулей из разных сред компиляции на уровне DLL / COM проблем не составляет ведь?
В>Проблем со стыковкой Borland C++ с VC ровно столько же, сколько и со стыковкой дельфи с VC. Несмортя на то, что язык один, просто так взять и подключить модуль скомпиленный одним компилятором (BC) к модулю, скомпилированному другим компилятором (VC) — нельзя.

Я говорил про стыковку на уровне DLL / COM, а не на уровне исходного кода / obj / lib.

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

STL — это библиотека и ничего более. То, что она "Standard" еще ни о чем не говорит — я не удивлюсь, когда таким же стандартом станет boost, например. А то, что шаблоны — приемущество языка — я с этим и не спорю — именно по этому я использую BCB, а не Delphi

В>И сознательный отказ от него требует серьезных обоснований, а несознательный отказ ставит под сомнение само знание этих преимуществ. Надеюсь под преимуществами ты подразумеваешь что-то более интересное, нежели "{} vs begin/end"?

Как ни парадоксально — и это тоже А если серьезно, то с учетом майнстрима в .NET, STL там не только не требуется, но и вредна с точки зрения идеологии (смешивание managed и unmanaged). Там же, где вредна .NET (скорость работы, например), то по моему опыту оказывается, что эффективнее (с точки зрения производительности) использовать собственные реализации. Однако, у STL есть одно огромное приемущество, которое может покрыть все вышеизложенное — написание кросс-платформенных приложений, но в этом случае, ни о каком классе AnsiString (и VCL вообще) и речи быть не должно

В>P.S. Кстати, билдер как продукт давно издох. О чем спорим?

Да, собственно, не знаю Наверное, о приемуществах и недостатках использования STL в BCB.

В>P.S.S. Для меня это хоть уже и старая, но мозоль. Когда-то кучу времени потратил на "борьбу с VCL из С++".

А для меня не мозоль, но старая... Так что предлагаю закончить с этим.

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

В>>4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек.
AB>Не знаю, как на счет __fastcall,

__fastcall портит жизнь там, где ожидается "обычные" сишные соглашения. Например в той же STL от борланда (хотя ее тожно было доточить, правки тривиальные, но борланд об этом не позаботился).

AB> но мне очень не хватает в VC __closure

Посмотри на boost::signals/function/bind — использовать после этого дельфийские расширения не захочется даже в BCB Не говоря уже о том, что реализовано это на страндартном С++ со всеми вытекающими рулезами.

AB> и __property (__property именно в реализации BCB).

Может ты про __published? Ибо сам по себе __property чужд языку и мешает при использовании STL, а толк от него — чисто косметический и на любителя.

[...]
В>>Однако выясняется, что "STL не нужна и хватает VCL".
AB>Но ведь действительно хватает! (мне опять же). С другой стороны, если STL когда-нибудь мне потребуется — я без зазрений совести буду ее использовать.

Ладно. Навскидку из самого популярного. Что ты используешь вместо STL'ых контейнеров std::lst, std::vector, std::map, вместо алгоритмов find/find_if и вместо std::auto_ptr? Потому что я себе не представляю программы на С++ сложнее "хелло ворд" без этих штук из STL или без собственных аналогичных велосипедов. Кстати, без boost (прежде всего как средства избавления от собственных велосипедов) уже тоже не представляю

В>>Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++?
AB>Нет смешания сред, ИМХО. Для VCL, STL является чужеродной (опять же, ИМХО)

Ну еще бы. Запихать TList или TComboBox->Items в std::for_each не получится. Хотя я когда-от писал такие обертки

В>>- в итоге могут возникать различного рода труднообнаруживаемые ошибки и прочее. При использовании только VCL вероятность словить глюк при использовании STL равна нулю => остаются только "глюки" VCL, которые в большинстве случаев известны и легко обходятся => скорость разработки потенциально возрастает.

На самом деле глюков непосредствено при использовании STL как таковой я сейчас не припомню (просто получаешь ошибку компиляции при поптыке засунуть TList в алгоритм или при попытке забайндить __fastcall). Глюки начинаются при попытке заиспользовать VCL-классы в плюсовом стиле (затемплейтизировать и т.д). Вот тут начинается...

[...]
AB>Вне сомнения, скорость компиляции Delphi и BCB различны, но ведь и языки тоже разные. Давай посравниваем скорость компиляции VC и BCB VC проиграет в скорости за счет более сильной оптимизации.

Оптимизация включена только для релизных билдов. Но даже в дебаге BCB компилит быстрее (в пределах порядка, я точно не замерял). Пока дело не доходит до больших precompiled headers. А оно доходит в больших проектах. Вот тут BCB уже начинает сливать, а сама среда безбожно тормозит на каждый чих.

[...]
AB>Как ни парадоксально — и это тоже А если серьезно, то с учетом майнстрима в .NET, STL там не только не требуется, но и вредна с точки зрения идеологии (смешивание managed и unmanaged).

Не понял. Я вообще не знаток .NET, но почему STL не может быть managed?

Hello Владик, you wrote:

> сама среда безбожно тормозит на каждый чих.

Полностью поддерживаю. Даже на P4 3000 HT, пользоваться такими вещами как Code Insight и т.п. невозможно.

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

Hello Владик, you wrote:

> сама среда безбожно тормозит на каждый чих.

Полностью поддерживаю. Даже на P4 3000 HT, пользоваться такими вещами как Code Insight и т.п. невозможно.

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

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

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

да. Прошу прощения. Привык

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

M>

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

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

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

да. именно. Отчасти для этого предлагаемоер ешение и разрабатывалось.

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

Нет! Вы используете только 1 тип строк: MyStr. Всегда и везде. Приведение типов будет только при работе с VCL классами, и то достаточно условное,
ведь внутри MyStr — AnsiString.

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

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