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


M>Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".

А что делать в случае активных объектов и асинхронного общения ?
У объекта может не быть пользователей, а он продолжает работать, работать и работать... и убивать его нельзя.

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

Большое спасибо. Разобрался.
S>> Но как быть если у тебя не известна структура test на этапе компиляции.
WH>Надо знать КОНКРТНЫЙ формат информации о типах полей. К томуже в реальной жизни в 99% случаев все извесно компилятору.

Сразу видно не работал с БД и другими таблицами типа Ёкселя. А там твой подход с шаблонами не проходит.
Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
S>> Конечно не разобрался но по сути твой и мой код индентичны.
WH>Ну если не считать то что твой код не типизирован, с ним больше гемороя при поддержке, он в несколько раз больше то можно сказать что да
WH>А у тебя слишком много извратов.
Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.

Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.

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

S> Сразу видно не работал с БД и другими таблицами типа Ёкселя.
Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
S>А там твой подход с шаблонами не проходит.
Еще как подходит. Немного в другой форме но прекрасно подходит.
S> Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.

S> Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.
Ну и нафига ручками генерить то что может сделать компилятор? Если уж до конца следовать этому принципу то тогда надо писать прямо в машинных кодах.

S> Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.
Это не шаболоны. Это отмазка для галочки.

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

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

S>> Сразу видно не работал с БД и другими таблицами типа Ёкселя.
WH>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
S>>А там твой подход с шаблонами не проходит.
WH>Еще как подходит. Немного в другой форме но прекрасно подходит.
Проходит только на полвину. Все равно придешь к виртуальным методам.
S>> Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
WH>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.
Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.

S>> Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.
WH>Ну и нафига ручками генерить то что может сделать компилятор? Если уж до конца следовать этому принципу то тогда надо писать прямо в машинных кодах.
Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.
S>> Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.
WH>Это не шаболоны. Это отмазка для галочки.
Это твоя точка зрения, но она одна из многих. Шаблоны могут приносить больше вреда в ситуациях где предпочтительней наследование с переопределением виртуальныз методов. Шаблоны подменяют чистое ООП, но очень полезны для создания быстрых типизированных объектов на основе заготовок. Но на мышление сильно влияют применяемые инструменты.

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

WH>>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
S> Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
Ты хочешь сказать что ручками читаешь xls файлы?

WH>>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.
S> Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
А потом понадобилась еще функциональность, а потом нашлась ошибка,....
S>И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.
Одно другого не отменяет.

S> Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.
Где? В моих программах даже критичных к производительности нет ни одной асмовой вставки. Оптимизатор зверь.

S> Это твоя точка зрения, но она одна из многих. Шаблоны могут приносить больше вреда в ситуациях где предпочтительней наследование с переопределением виртуальныз методов. Шаблоны подменяют чистое ООП, но очень полезны для создания быстрых типизированных объектов на основе заготовок. Но на мышление сильно влияют применяемые инструменты.
Ну и зачем их тогда вобще вводить если от них вреда больше чем пользы? А зачем нужна перегрузко операторов если можно для класса студент определить оператор сложения? А зачем нужен while если можно поставить неверное условие и цикл будет выполнятся вечно? А зачем.....
И вобще пишите на брейнфаке ибо там каждый значит ровно то что он значит и ни чего больше.

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

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

WH>>>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
S>> Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
WH>Ты хочешь сказать что ручками читаешь xls файлы?

C MSSQL, не работаю а c DBF очень часто, т.к. основное мое занятие 1С (дбф версии).

WH>>>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.
S>> Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
WH>А потом понадобилась еще функциональность, а потом нашлась ошибка,....
Ну TFild и их наследники в Delphi очень давно. Тоже можно сказать и об ADO.

S>>И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.
WH>Одно другого не отменяет.

S>> Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.
WH>Где? В моих программах даже критичных к производительности нет ни одной асмовой вставки. Оптимизатор зверь.
А какже memcopy. Она на чистом С++ написана. Огромное количество низкоуровневых функций на асме.

WH>И вобще пишите на брейнфаке ибо там каждый значит ровно то что он значит и ни чего больше.
Все убедил. Ухожу обогащать. У меня диплом специалиста по ОБОГАЩЕНИЮ руд цветных металлов.
А что такое брейнфак не знаю.
Но уверяю тебя ты слишком переоцениваешь роль шаблонов. Все закрываю тему.

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

на последок
http://info.borland.ru/events/open_letter/index.html
http://www.osp.ru/os/2003/09/004_5.htm

WH>>>Слабо на дельфях написить такого помошника?
A>>Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове.
WH>Ни на дельфе ни на шарпе не реализуемо.

A zachem ono v .NET nado — u nas reflection i GC

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

WH>>Нука изобрази аналог на дельфях.
WH>>

WH>>    std::sort(int_arr, int_arr+N);
WH>>    std::sort(float_arr, float_arr+N);
WH>>    std::sort(double_arr, double_arr+N);
WH>>    std::sort(string_arr, string_arr+N);
WH>>    return 0;
WH>>}
WH>>

M>Я вот не знаком с std::sort. Что такое этот код?

M>Сортировка и в Дельфи есть. Если нужно сортировать объекты некоторого типа, пишем функцию сравнения — и передаём задачу в функции стандартной библиотеки.

M>Если ты имеешь ввиду именно простую форму записи, тогда да. В этом случае запись на C++ действительно компактнее и проще. Но это частный случай, в реальных программах сишный код наоборот очень забористый.

WH>>Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.

M>В Дельфе тоже никакого оверхеда. Разве что, возможно, лишний уровень indirection, который в случае с шаблонами, возможно, компилятор исключит.

M>Ну, это оверхед просто гигантский. Особенно будет заметно на реальных задачах.

WH>>Ну окошки на дельфе рисовать это нормально но писать логику

M>Да уж, логику-то точно в сях писать хреново. Кто потом её читать будет, эту вот логику?

M>На сях нужно системные примочки делать, всякие критичные места. А логику нужно делать на таком языке, чтоб любой чужой человек прочитал с листа. К примеру, C#, Дельфи. На худой конец, VB.

U C# pljusovoj sintaksis

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

V>U C# pljusovoj sintaksis

С каких это пор ??? Больше похоже на яву

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

WH>>Ни на дельфе ни на шарпе не реализуемо.
V> A zachem ono v .NET nado — u nas reflection i GC
Ну рефлекшен тут вобще ни какой пяткой и если мне не изменяет скалероз то ГЦ не контролирует этот аллокатор.

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

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

DOO>>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.
WH>Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.

Smeshno, esli by ne bylo tak grustno. Nu ljudi dobrye — eto zhe ne religioznye voprosy: verish' kontra ne verish', ili kishki vyrezhu. C/C++ ne luchshe Delphi, no i Delphi ne luchshe C/C++. Eto raznye jazyki u nix raznye oblasti i dlja raznyx zadach. Da i dlja raznyx ljudej tozhe. I ja soglasen tol'ko s odnim vyskazyvaniem ( prosti uzhe ne pomnju kto, a iskat' vlom): VC++ luchshe uzhe tem, chto tam bol'she platjat. No obratnoe neverno: esli bol'she platjat — to jazyk luchshe. My zhe vse ljudi s vysshim obrazovaniem i neploxim matematicheskim i znaem, chto v zhizni v otlichii ot matematiki vyzhivajut ne luchshie, a bolee prisposoblennye. Vse znajut, chto Windows ne samaja luchshaja iz vozmozhnyx sistem, no ee prodano bol'she vsego. I ne potomu, chto ona luchshaja, a potomu, chto Djadja Bill genij v marketinge, on delaet ne samoe luchshee, no zato vsegda VOVREMJA. ak i VC++, otstoj na samom dele, kak po gljukavosti, po IDE, po ... ( kazhdyj mozhet sam dobavit'). No, moj znakomyj ispol'zuet dlja programmirovanij vorovannyj Editor ( zabyl kakoj) i "makefile" i dovolen, a proektiki ( etak na 300-500 kilostrok) delaet na C/C++ dlja Windows / Linux, xotja priznaet lish' BSD.

I vot na eto "davaj ego sjuda..." xotelos' by rasskazat' takuju istoriju: dva, net uzhe 3 goda nazad ja iskal rabotu ( proekt delal odin, na Delphi, inache prosto po srokam ne popadal, zhena shefa ne imeja programmy uzhe prodala okolo 20 ekzempljarov. Eto byla sistema upravlenija urokom v shkolax. Dolzna begat' v seti. Proekt potjanul bol'she 200 kilostrok. No shef chto — to ne povyshal oklad, a pri 10 — 12 chasovoj rabote bez vyxodnyx eto bylo by edinstvennym stimulom, nu i ezdit' kazhdyj den' 60 km v odnu storonu po proselochnym dorogam, dazhe v Germanii ne saxar. Oni do six por prodajut etu programmu, lish' teper' moja doch' razvivaet ee dal'she). I vot v odnoj firme posle razgovorov stal ja delat' nechto vrode praktiki. Kak — to Chef razotkrovennichalsja. I vot chto on skazal, bukval'no: "Sushchestvuet lish' odin zhivoj jazyk — C, C++ — gljuchnyj i davno umer. Vo vsem mire programmirujut vse bol'shie firmy, zasluzhivajushchie uvazhenija, lish' na C. Vse drugie, kotorye pytalis' sdelat' chto libo na drugix jazykax, libo razorilis', libo razorjajutsja.( TOCHKA)" Ja snachala byl nemnogo osharashen, a potom ponjal, na samom dele on prav. U nego tol'ko Quellcoda ( ne binary — QUELLCOD) za 10 let nakopilos' 1,5 GByte ( poltora gigabajta). I on ne mozhet eto vybrosit'. A ljubaja peredelka v koncepcii stoit vsego dorozhe. I esli kakaja — to sobaka ili volk, a uzh tem bolee Vlad ili AVK budut chto — to imet' protiv, on chelovek vezhlivyj — rugat'sja ne budet, prosto ne voz'met na rabotu. A v opredelennyx situacijax eshche kak budesh' po volch'i vyt', bud' ty samaja rasprekrasnaja sobaka.
Vot tak dorogoj Sobaka-Chelovek!
A sam ja programmiruju i na VC, i na VC++, i na Delphi. Esli vremja est', ili zakazchik xochet ( esli xochet, to i na VB, C++Builde, JScript...). Kogda nado bystro to na Delphi. Pri etom kachestvo ne stradaet. Tut kto — to vse pytalsja uvedet' kak s shablonami privedennyj kod budet' vygljadet' na Delphi. Ja dumaju, chto kazhdyj Delphiec, dazhe programmirujushchij begin...end mozhet privesti analogichnye primery, no v druguju storonu. Poet skazal: "Zhivem my ne dolgo, davajte ljubit' i radovat' druzhboj drug druga. Nam nezachem bol'she serdca xolodit' i tak uzh za oknami v'juga. Davajte drug drugu dolgi vozvrashchat', shchadit' BEZZASHCHITNUJU strannost', davajte spokojnoj dushoju proshchat' talantlivost' i bestallannost'... Chto delat' — zemlja nash PREKRASNYJ udel, ishchi sredi nas vinovatyx..."
Takaja diskussija MOGLA by stat' i konstruktivnoj, esli by iskali obshchee, luchshee — kak eto luchshee iz odnogo jazyka ispol'zovat' v drugom.
Da i ne KODERY my, a programmisty, ili PROGRAMMISTY, po vsjakomu. A dlja normal'nogo programmera lish' odin vopros: KOGDA?
Moj e-mail: viktor_denk@web.de

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

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

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

DOO>>>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.
WH>>Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.

VD>Smeshno, esli by ne bylo tak grustno. Nu ljudi dobrye — eto zhe ne religioznye voprosy: verish' kontra ne verish', ili kishki vyrezhu. C/C++ ne luchshe Delphi, no i Delphi ne luchshe C/C++. Eto raznye jazyki u nix raznye oblasti i dlja raznyx zadach. Da i dlja raznyx ljudej tozhe. I ja soglasen tol'ko s odnim vyskazyvaniem ( prosti uzhe ne pomnju kto, a iskat' vlom): VC++ luchshe uzhe tem, chto tam bol'she platjat. No obratnoe neverno: esli bol'she platjat — to jazyk luchshe. My zhe vse ljudi s vysshim obrazovaniem i neploxim matematicheskim i ...
[skipped]

Нда, было бы намного интереснее читать статью на русском и даже на английском, но не на транслите... На транслите читать даже и не буду...

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

J>Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.

О да, STL это глыба! И совершенн верно, что макросы — это не есть inline! inline такие возможности и не снились! Я видел наполнение огромного массива на этапе компиляции сделанное с помощью переопределения макроса и #include. Не помню точно как это было сделано, но 5-ю строками написали целую программу!
Насчет STL, наследовать можно и нужно. У меня был случай, что пришлось переставлять
элементы списка list местами с сохранением ссылок на них, т.е. все созданные итераторы должны продолжать указывать на свои элементы. Я просто создал насдедника от
list и добавил функуию длиной в 10 строк. Где еще так можно! (хотя не спорю, в кишках STL без ста грамм не разберешся!)

Интересно, а где модератор? Спит что ли.
Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.

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

Oxy>Интересно, а где модератор? Спит что ли.
Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.
Да, совершенно согласен. Каждый язык хорошь там для чего придуман. Попробуй на MSVC сделать разветвленный интерфейс какой нибудь АС, с ума сойдешь! А сделать парсер файлов Word на Pascal? Тоже не сахар...
Все эти споры совершенно ни к чему. Работать надо, а не болтать.

Товарищи
Ваще ветка клевая получилась — реально почитал, получил удовольствие, много узнал.
Но все таки хотелось бы вставить свои пять копеек. Вот спорят тут типа "Делфи!" "С++!" "Шаблоны!" "быстрее!" "медленнее!" "свойства!". Я предлагаю взглянуть на этот вопрос в несколько иной плоскости. А че ваще нужнее. То есть мы тут не для чистого кайфа программим, и не для удовлетворения комплекса создателя и творца в нас. Педалинг должен приносить пользу народному хозяйству. Вот давайте посмотрим, что нужно щас больше народному хозяйству — пользователь голосует рублем.
А сделаем так. Заходим на сайтилу по работе (скажем job.ru), и набираем следующие запросы

1) Раздел — информационные технологии
Город — Москва
Образование — Высшее
З/п — от 1000 уе
График работы — полный день
Занятость — полная
Ключевое слово — С++
Исключить слова — Delphi (шоб не было объяв с коктейлями а как можно более чисто сишные)

2) Раздел — информационные технологии
Город — Москва
Образование — Высшее
З/п — от 1000 уе
График работы — полный день
Занятость — полная
Ключевое слово — Delphi
Исключить слова — C++ (шоб не было объяв с коктейлями а как можно более чисто дельфовые)

И что же мы видем, сладкие мои
Запрос 1)
Кол-во вакансий — 148
З/п — 2500, 3000 уе и выше

Запрос 2)
Кол-во вакансий — 33
З/п — 1500б 1300 уе и ниже

Так что, как говорил товарищ Сталин: "Факты — вещь упрямая". То есть оказывается не нужны людям свойства, не нужны им быстрые кнопочки на формах, не нужны им самопальные реализации контейнеров через наследование и код через Копи/Паст. А нужны им шаблоны, нужен им монстроидальный синтаксис, нужна им, гадам, перегрузка операторов. И готовы они потерпеть лишнее время, так как как ни крути, а на сях прожект сложнее разработать и реализовать (может потому что задачи сложнее). И готовы эти гады (работодатели всмысле) в 2 раза больше денег платить за все эти сишные неудобства, и хотят они их почти в 5 раза больше и сильнее чем все TContainer"ы и ТПрограммер компоненты вместе взятые. Так что королевство дельфей может сушить сухари. Где то я там видел фразу типа "С++ и дельфи — умирающие направления". Ага, жестко они умирают. А лохи эти, из котор программерских — они ж лапти, у них денег куры не клюют — вот и платят специалистам по тупиковым направлениеям по 3000 уе.
Вот такие дела

Oxy>Интересно, а где модератор? Спит что ли.
Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки

Так вроде не противоречит правилам.

Здравствуйте, mihailik, Вы писали:
M>Так вроде не противоречит правилам.

Правила не мешало бы дополнить...

M>>Так вроде не противоречит правилам.
Oxy>Правила не мешало бы дополнить...

Может и не мешало бы. Смотря чем дополнять.