Все- таки сколько бы люди не давали советов, всегда получается что-то свое и причем более рациональное.
И я считаю что такой информацией нужно обмениваться.

Я спрашивалл здесь как обрабатывать строку по шаблону, как выдрать слово и распознав его обратиться к свойству одноименной компоненты - мне мне отвечали - " А никак. Нет в С такого".
Тем не менее, привожу полученный код. Это часть программы, которая выводит степень опьянения в зависимости от концентрации алкоголя в крови. Причем выводит его по зараннее определенному шаблону, находящемуся в текстовом файле.

Код

AnsiString TForm1:: GetValue(AnsiString parameter) { return ((TEdit*)FindComponent(parameter))->Text; } //--------------------------------------------------------------------------- AnsiString TForm1::TranslateString(AnsiString source) { AnsiString p3; int begin, end, len; TReplaceFlags Flags; Flags << rfReplaceAll; while (!(begin == 0)) {  begin  = source.AnsiPos("{");  end = source.AnsiPos("}");  len = end-begin;  source= StringReplace (source, source.SubString(begin, len+1), GetValue(source.SubString(begin+1, len-1)), Flags); } return source; } //--------------------------------------------------------------------------- AnsiString TForm1::BuildAlcohol() {     TempBuffer ->Text = "";        if (Promille -> Text == "") TempBuffer -> Lines -> LoadFromFile("Templates/NoAlcohol.txt");           else            {                float a=StrToFloat(Promille->Text);                 if (a>0 && a<0.3) TempBuffer -> Lines -> LoadFromFile("Templates/LessAlcohol.txt");                 if (a>=0.3 && a<0.5) TempBuffer -> Lines -> LoadFromFile("Templates/TinyAlcohol.txt");                 if (a>=0.5 && a<1.5) TempBuffer -> Lines -> LoadFromFile("Templates/LightAlcohol.txt");                 if (a>=1.5 && a<2.5) TempBuffer -> Lines -> LoadFromFile("Templates/MediumAlcohol.txt");                 if (a>=2.5 && a<3) TempBuffer -> Lines -> LoadFromFile("Templates/StrongAlcohol.txt");                 if (a>=3) TempBuffer -> Lines -> LoadFromFile("Templates/TOAlcohol.txt");            }        return TranslateString(TempBuffer -> Text);  }

То есть, программа прочитав имя, фамилию, отчество и пр., берет из определенного *.txt шаблона текст типа

Код

Во время наступления смерти {Gr} {Family} {Name} {Father} находился в состоянии алкогольного опьянения, что подтверждается обнаружением при судебно-химическом исследовании в крови из трупа этилового спирта в количестве {Promille}%. . При жизни данное количество этилового спирта в крови обычно легкому алкогольному опьянению

заменит ее на

Код

Во время наступления смерти гр-н Иванов Иван Иванович находился в состоянии алкогольного опьянения, что подтверждается обнаружением при судебно-химическом исследовании в крови из трупа этилового спирта в количестве 1,2%.  . При жизни данное количество этилового спирта в крови обычно легкому алкогольному опьянению.

Ваши комментарии ?

Цитата

Я спрашивалл здесь как обрабатывать строку по шаблону, как выдрать слово и распознав его обратиться к свойству одноименной компоненты - мне мне отвечали - " А никак. Нет в С такого".

Молодец, конечно, что сделал, но...
Раз не понимаешь, о чем говоришь, то лучше не говори.
Под "обработкой строки по шаблону" ты понимаешь выковыривание и замену "{подстроки}" чтоль? Круто. Очень сложно. Надеюсь, фразу "а никак" ты не к этому отнес.
Тогда по другому вопросу.
В "С" такого быть в принципе не может (если не извращаться ).
В "С++" такого быть изначально тоже не может. Ты воспользовался конкретной библиотекой, ВЦЛ.
Кроме того, в том топике тебе очень хорошо посоветовали воспользоваться массивами, или же std::map<std::string,TEdit*>. По твоему, как в ПХП это реализовано на уровне интерпретатора? Наверняка именно так.
Вопрос: зачем вообще писать на C++, если принцип формы сохранился полностью? Делал бы на ПХП...

Это сообщение отредактировал(а) Hroft - 21.2.2005, 11:02

Hroft


Знаешь, я полный ноль в С, поэтому если честно я так и не понял твоей идеи.

Цитата

Под "обработкой строки по шаблону" ты понимаешь выковыривание и замену "{подстроки}" чтоль? Круто. Очень сложно. Надеюсь, фразу "а никак" ты не к этому отнес.

Вот этого, учитывая иронию в тексте я никак не понял.

Совет воспользоваться std::map<std::string,TEdit*> никак не был прокомментирован, и сколько я не искал в инете инфу на эту тему - ничего путного не нашел.

Может я и сильно ошибусь, я ведь не такой корифей как вы, но по-моему, ((TEdit*)FindComponent(parameter))->Text намного проще и рациональней чем перебор массивов и пр.
И по крайней мере, учитывая что это не консольное приложение, а с использованием визуальных компонент - более рациональное. Впрочем, повторюсь, возможно я и ошибаюсь.



Воспользовался библиотекой ВЦЛ? А зачем мне от нее отказыватся если собственно на компонентах и базируется программа?

Цитата

Вопрос: зачем вообще писать на C++, если принцип формы сохранился полностью? Делал бы на ПХП...

А вот сам подумай, нафига мне изучать новый язык чтобы написать такую же программу с такими же формами? Тем более, что в PHP я чувствую себя как рыба в воде, а тут два дня не мог строку обработать? Наверное возникла такая необходимость, как ты думаешь?


А в целом, спасибо за критику и добрые советы. Удачи!

Первое, что увидел

Код

AnsiString TForm1:: GetValue(AnsiString parameter) { return ((TEdit*)FindComponent(parameter))->Text; }

Эта функция свалит программу в том случае, если компонет с именем равным parameter не является объектом класса TEdit или его потомком. Да и вообще, не следует использовать такое преобразование типов для классов, содержащих виртуальные функции. Копай в сторону dynamic_cast<>()

srd

Знаю, я узнал про dynamic_cast тогда же когда и про FindComponent. Дело в том что в моей программе такая ситуация исключена полностью.

Цитата

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

Если не трудно, поподробнее в этом месте..

to =Женек=
Модератор: Название темы должно отражать ее суть!

Про map говорилось в соседнем топике, это просто удобнее и бысрее, чем vector<pair<>>, который предложил, если не ошибаюсь, _hunter (лень смотреть точно).
Это обычный ассоциативный массив, они и в ПХП есть, и работает он очень быстро в таких случаях. Это не проще, чем приведение типа, но с помощью этого приема локализуются все проверки на корректность указателей (даже если они не нужны тебе, как ты говоришь), в маленькой программе не имеет это особого значения, но раз тебе НУЖНО осваивать новый язык, то лучше сразу приучаться. Кроме того, тебе же самому должно быть это приятно, ведь очень сильно напоминает ПХП с его переменными имен переменных, если я еще не все забыл.

Цитата

Я спрашивалл здесь как обрабатывать строку по шаблону, как выдрать слово и распознав его обратиться к свойству одноименной компоненты - мне мне отвечали - " А никак. Нет в С такого".

Тут можно подумать, что ты "никак" отнес к "обрабатывать строку по шаблону". А раз ты хорошо знаком с ПХП, то обработка строк, тем более такая простая, для тебя не должна составлять проблемы, так чего о ней вообще говорить...
Про ВЦЛ - ну да, на компонентах ты основываешься, но вот только компоненты - виндовые, и в винде никакой информации об имени конкретного элемента управления нет, поэтому ты не С++ использовал для поиска компонента, а ВЦЛ как надстройку над виндой, в ВЦЛ уже предусмотрены имена контролов. В МФС такой подход уже не сработает, вроде бы, хотя контролы будут те же самые. В голом С++ с windows.h вот так просто это у тебя не получится, а вот map или vector<pair<>>работать будут.
Про необходимость - ну да, резон у тебя должен быть.
Если что, извини, но название темы меня едва не взбесило.
Я и сам не особо "корифей", но больше так темы не называй, ок?

Про виртуальные функции имелось в виду, наверное, то, что в классе с оными всегда содержится указатель на таблицу виртуальных функций, и он может попортиться, хотя это может произойти, на мой взгляд, только если классы из разных иерархий, а в рамках одной этот указатель будет одинаковым для всех классов. Но, опять же, точно не знаю.

Я имел в виду следующее:

Код

#include <iostream> class Base { public:    virtual void func(void)    {        std::cout << "Base::func";    } }; class Child1 : public Base { public:    virtual void foo(void)    {        std::cout << "Child1::foo";    } }; class Child2 : public Base { public:    virtual void bar(void)    {        std::cout << "Child2::bar";    } }; int main(void) {    Child1 child1;    Base *base = (Base *)&child1;    Child2 *child2 = (Child2 *)base;    child2->bar();    return 0; }

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

Я честно сказать здесь никакого бардака не вижу.
Более того, этот код - классический пример при вступление в описание интерфейсов и работе с ATL COM.

Бардак здесь будет только в том случае, если нет логики в разработке кода. Тут уж извините.

Ничего похожего на интерфейсы здесь нет! Между Child1 и Child2 нет наследования.

Пример очень специфичный, зависимый от реализации, и в целом идея преобразования одного класса в другой посредством общего предка - очень опасная штука. Тут и динамик каст не поможет. Более того, явное преобразование &child1 к Base* бессмысленно, это и так нормальное преобразование потомка к предку, а последующее преобразование к типу из другой ветки - скорее ошибка, чем использование фичи языка. В чем я неправ?

Цитата(Hroft @ 25.2.2005, 08:16)

Если что, извини, но название темы меня едва не взбесило.

А чего тут бесится, все правильно - сколько не спрашивай, а свои проблемы надо решать самому.

Цитата(srd @ 25.2.2005, 08:46)

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

Тут барадак в логики преобразований, а не в отсутсвии использования dynamic_cast. С использованием dynamic_cast программа бы вылетела по null pointer exception. dynamic_cast имеет смысл применять тогда, когда есть вероятность предусмотренная логикой программы при которой преобразование может быть неверным и в этом случае просле dynamic_cast должна быть проверка указателя на null. Если же логика программы построенна так, что преобразование всегда заведомо неверное, то и dynamic_cast не поможет. Или наоборот, если всегда точно известно, что преобразование верно, то и dynamic_cast не нужен - достадочно static_cast (он, кстати, быстрее). Как например здесь:

Цитата(srd @ 21.2.2005, 16:22)

Первое, что увидел

Код

AnsiString TForm1:: GetValue(AnsiString parameter) { return ((TEdit*)FindComponent(parameter))->Text; }

Этот кусок лучше переписать тогда так:

Код

AnsiString TForm1:: GetValue(AnsiString parameter) {  TControl *wc = dynamic_cast<TControl*>(FindComponent(parameter));   if (wc!=0)        return wc->Text;   return "";   }

Правда свойство Text может быть protected, для этого его надо опубликовать известным приемемом Fake класса.


=Женек=, есть такая функция Format - на вид она делает то, что ты хочешь.

Это сообщение отредактировал(а) Fantasist - 25.2.2005, 20:25

Цитата(Fantasist @ 26.2.2005, 03:24)

Тут барадак в логики преобразований, а не в отсутсвии использования dynamic_cast. С использованием dynamic_cast программа бы вылетела по null pointer exception.

Верно, а без dynamic_cast отработала бы без ошибок, потому что child2 на самом деле указывает на объект Child1, и вызывается функция-член foo(), хотя написано child2->bar(). Но это ведь явно не то, что хотели.

Цитата(Fantasist @ 26.2.2005, 03:24)

Или наоборот, если всегда точно известно, что преобразование верно, то и dynamic_cast не нужен - достадочно static_cast (он, кстати, быстрее).

В этом случае для надежности можно использовать шаблон, который для DEBUG-версии разворачивается в dynamic_cast<> плюс assert, а в RELEASE-версии - в static_cast.